2010, Pop3 Connector, Fehlerantwortmails funktionieren nicht

[PowerShellAdmin 169]

Also laut AOL war die IP nicht Yellow / Red listed-war auf der Postmaster Website.

Habe nun die IP auf 46 geswitcht, rDNS und DNS angepasst.

85.220.158.46 lautet jetzt die IP (nicht mehr 45). IP ist beim Provider & Hoster ergänzt.

NSLookup sollte dsrv48.exchange.domain.de ergeben, ist auf keiner Blacklist.

 

Ebenfalls habe ich die öffentliche IP unsere Gateways in den rDNS eingetragen, dies ist laut AOL notwendig, da die Versandip eben nicht die .46 sonder .34 ist(Informationen habe ich alle von der AOL Postmaster Website, Testemail von an eine spezielle AOLeMailadresse-Hat die 34 geantwortet als Absender).

 

Das mit Arcor war klar, meinte damit auch nur, dass der Mailer von AOL generell funktioniert-nicht gestört ist.

 

@Greylisting: Bedeutet ja dass die eMails nur alle x Minuten oder x Zustellversuche übernommen werden. Könnte ja durchaus der Fall sein.

[NorbertFe 2.045]

Das mit Arcor war klar, meinte damit auch nur, dass der Mailer von AOL generell funktioniert-nicht gestört ist.

 

Also davon geh ich erstmal aus. ;)

 

Bye

Norbert

[PowerShellAdmin 169]

(-; na ich hatte da schon anderes bei Freemailern erlebt.

 

So nebenbei, alles umgestellt, neugestartet ~20Minuten hat die eMail zu AOL gebraucht.

Gehe davon aus, dass der Server mittlerweile korrekt konfiguriert ist-wenigstens weitgehenst.

Habe jetzt bei AOL eine Whitelistantrag gestellt und teste das dann im Anschluss.

 

Aufgrund der Problematik überlege ich, ob es nicht doch besser ist über 1und1 direkt zu versenden.

Denke AOL ist kein Einzelfall und dass solche Probleme häufiger auftreten können.

[NorbertFe 2.045]

 

Aufgrund der Problematik überlege ich, ob es nicht doch besser ist über 1und1 direkt zu versenden.

Denke AOL ist kein Einzelfall und dass solche Probleme häufiger auftreten können.

 

1&1 steht oft genug selbst auf diversen Blacklists. Wenn es dich beruhigt, ich kann an AOL versenden und die Mails sind im Allgemeinen normal schnell dort. ;) Kann also nur irgendwie an deiner Konfiguration hängen.

 

Bye

Norbert

[PowerShellAdmin 169]

Ah danke, das klingt gut.

Aus irgendeinen Grund werden die eMails wieder NICHT zugestellt.

Auch per Telnet auf einen AOL Mailserver gibt die selbe Fehlermeldung, also gehe ich nicht von einen Exchange, sondern anderweitigen Problem aus.

 

Werde das womöglich "abwarten", da es ja durchaus ein DNS Eintrag sein kann, der noch nicht seitens AOL aktualisiert wurde.

Gegen ein Problem am Exchangeserver sprechen einige Forenposts, da die Fehler wohl nur mit AOL auftreten.

Sobald die Whitelist bestätigt ist, werde ich das weitertesten. Denke man tritt sich hier nur selbst auf den Fuß.

 

Bzgl. Redundanz, macht es Sinn, gibt es hier eine Lösung, um eine Ausweichlösung bereitzustellen- In Form eines 2 Exchange z.B. (wir haben demnächst 2 Enterpriselizenzen.

Diesen könnten wir ebenfalls durch Forefront sichern.

Lizenzen haben wir alle (2x Silber Partnerschaft/ISV-2 Standorte)

[NorbertFe 2.045]

Dazu müßte man erstmal darüber sprechen, was genau du redundant auslegen willst. Um ehrlich zu sein, wenn du schon am AOL/DNS SMTP Problem scheiterst... ;) Eventuell solltest du dann einen Partner mit Exchange Know How mit ins Boot holen.

 

Bye

Norbert

[PowerShellAdmin 169]

Also eMailversand an AOL funktioniert nun. Die gestrigen eMails gingen noch ein - 8 Stunden Verspätung.

Seit heute kommen die eMails sofort, also läuft das Ganze mittlerweile korrekt.

 

Bzgl. Redundanz, ich benötige nicht zwangsläufig einen 2. Exchangeserver oder gar ein Failovercluster. Prinzipiell reicht ein zweiter Mailboxserver.

Die Anforderung wäre dann allerdings der eMailtransport.

Gibt es hier womöglich eine passende Lösung?

 

Ich wurde hier ja schon mehrfach hingewiesen, das eine Redundanz nicht notwendig ist. Ist dem wirklich so?

Soweit ich das gesehen habe unterstützt der Exchangeserver 2010 DAG, in wie weit sich das migrieren lässt ist mir noch nicht klar.

Aufgrund der beschränkten Internetanbindung, würde ich hier aber eine Replikation mit einen 2. Standort (Rechenzentrum) ausschließen.

Könnte also nur innerhalb des 1. Standorts die Exchangeserver serverseitig trennen und am Internetanschluss.

Einzigen Vorteil den ich hier sehe: Wartungsausfälle werden reduziert, die Situation aber erheblich verkompliziert.

 

Bzgl. betreuender Partner, ich kann dich bedingt verstehen. Allerdings erlangt man eine Expertise auch immer nur durchs "Tun".

Ich würde hier womöglich Microsoft ins Boot holen. Allerdings müsste ich auch erstmal einschätzen können wie sinnvoll das Ganze ist.

[NorbertFe 2.045]

Also eMailversand an AOL funktioniert nun. Die gestrigen eMails gingen noch ein - 8 Stunden Verspätung.

Seit heute kommen die eMails sofort, also läuft das Ganze mittlerweile korrekt.

 

Also war Geduld das einzige was dir fehlte? ;)

 

Bzgl. Redundanz, ich benötige nicht zwangsläufig einen 2. Exchangeserver oder gar ein Failovercluster. Prinzipiell reicht ein zweiter Mailboxserver.

 

Aha, und wie sollte so eine Lösung ohne zweiten Exchange deiner Meinung nach aussehen?

 

Die Anforderung wäre dann allerdings der eMailtransport.

Gibt es hier womöglich eine passende Lösung?

 

Wenn du erklärst, was genau du damit meinst, kann man das vielleicht beantworten.

 

 

Ich wurde hier ja schon mehrfach hingewiesen, das eine Redundanz nicht notwendig ist. Ist dem wirklich so?

 

Worauf beziehst du dich?

 

Soweit ich das gesehen habe unterstützt der Exchangeserver 2010 DAG, in wie weit sich das migrieren lässt ist mir noch nicht klar.

 

In wie weit sich was migrieren läßt?

 

Einzigen Vorteil den ich hier sehe: Wartungsausfälle werden reduziert, die Situation aber erheblich verkompliziert.

 

Glaubt eigentlich wirklich irgendwer, dass eine Hochverfügbarkeit total easy ist und jeder sofort sowas managen kann, bloß weil sein Chef zu faul ist, ihn auf die Schulung zu schicken und man sich das Know How ja ggf. auch im Forum abholen kann? :confused:

 

Bzgl. betreuender Partner, ich kann dich bedingt verstehen. Allerdings erlangt man eine Expertise auch immer nur durchs "Tun".

 

Siehe oben.

 

Ich würde hier womöglich Microsoft ins Boot holen. Allerdings müsste ich auch erstmal einschätzen können wie sinnvoll das Ganze ist.

 

Auch dazu gibt es Know How, welches man tage- oder von mir aus auch stundenweise einkaufen kann.

 

Bye

Norbert

[PowerShellAdmin 169]

Hi Norbert,

ursprünglich dachte ich an ein "Zwischenlager", siehe b) & c).

Das ist aber ****sinn, da man hier nur Probleme mit Spam bekommt, niemand weiß wo die eMail liegt und man hat nichts verbessert-Gegenteil.

Fällt der primäre MX aus, wird weiterhin über mehrere Stunden versucht die eMailzuzusenden und der Versender erhält auch einen Fehler.

Daher benötige ich kein Backup des MX (Redundanz war das flasche Wort in dem Fall)

Da wir generell keinen Exchange Cluster benötigen, ist das wohl auch der falsche Ansatz.

Ich gehe davon aus, dass d) am besten den Anforderungen entspricht.

 

a)

Exchange Cluster

b)

Backup MX

Dagegen spricht aber

-Spamschutz

-Datensicherheit

-Erreichbarkeit, die eMails landen ja erstmal im "Nirvana"

siehe hier:

MSXFAQ.DE - Backup-MX

=> Backup MX nein danke

 

c)

2er MX Record mit höheren Kosten, Standort Rechenzentrum.

-Spamschutz

-Mailboxzwischenlager

etc...

 

d) 1 MX Eintrag & Exchange

-Versender erhält nach gewisser Zeit Fehler

-Kommunikationswege sind "kurz"

-Bei Ausfall werden die eMails erneut zugestellt

 

Möchte auch nochmal gerne den Punkt Schulung aufgreifen, da stimme ich dir vollkommen zu.

Allerdings muss man ja auch erstmal den richtigen "Weg" zum Ziel finden, anschließend kann ich auch zum Chef gehen (:

Wobei es mir da derzeit schon in den Fingern juckt, da das Thema sehr interessant ist.

[PowerShellAdmin 169]

Forefront for Exchange funktioniert prinzipiell wunderbar.

Ich möchte das bei Dateifiltern der Absender eine Benachrichtigung erhält.

Dazu habe ich einen entsprechenden Filter angelegt -z.B. exe etc./Anwendung- und anschließend die Benachrichtigungseinstellungen für "externer Absender" im Dateifilter aktiviert.

Externer Absender betrifft ja immer einen Versender außerhalb der Organisation,sobald ich unter "CC:" z.B. %ESNAME% ergänze, erhält er auch eine eMail (aber nur als CC und ohne Betreff).

Also greift der Benachrichtungsfilter korrekt, sprich ich bin bei der richtigen Stelle, scheinbar hat er da ein Problem mit dem direkten Rücksenden. In der Warteschlange war keine eMail.

Die Absenderkennung habe ich ebenfalls auf Forefront.domain.tld geändert.

Ist das Problem bekannt ?

[PowerShellAdmin 169]

Forfront for Exchange2010@Bebachrichtigung externer Versender:

Geht nicht, ein "bekanntes" Problem, angeblich im Hotfix 1-4 behoben, ist es aber nicht (3er & 4er installiert).

Trägt man %ESABSENDER% z.B. bei Administrator ein, dann erhält er über Umwege die eMail, da man hier einen Empfänger auswählen kann

Scheinbar liegt es an der Identifizierung externer eMails.

Wobei er laut Status die Nachrichten Intern und Extern richtig erkennt, jedenfalls laut Speicherort: "SMTP-Nachrichten\Intern" oder "SMTP-Nachrichten\EINGEHEND" bei extern

 

 

Forfront for Exchange2010@verschiedene Dateitypen Filtern

Man muss eine Dateifilter Namesregel anlegen *.exe z.B. Dateiheader werden so natürlich nicht validiert.

bearbeitet 14. Dezember 2011 von PowerShellAdmin

[PowerShellAdmin 169]

Falls jemand von euch über den selben Fehler stolpert => externe Absender Benachrichtigung funktioniert nicht

 

 

Laut MS KB kb2619883 muss man Forefront deinstallieren, Programmdaten löschen & anschließend neu installieren.

Folgenden Ablauf habe ich ausgeführt

 

1. uninstall forefront for exchange 2010

2.delete the folder&subfolders on:C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server

3. reboot

4. install forefront for exchange CU4

=> Notification doesnt work

5. Changed Forefront Notifiaction eMail

(set HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Notifications\FromAddress to forefront@domain.tld)

6. reboot

=> Notification is working

bearbeitet 15. Dezember 2011 von PowerShellAdmin