Exchange 2003/2007, Spam, postfix, Debian, DNS

Nach einer Migration von Exchange 5.5 auf Exchange 2007 gab es mit einigen Postfächern Probleme im Bezug auf den Junk-E-Mail Filter. Dieser war zwar aktiv, sortierte jedoch keine Nachrichten in den Junk-E-Mail Ordner ein. Eine funktionierende Lösung war, das gesamte Postfach zu exportieren, anschließend zu löschen und nach der Neuerstellung die Daten wieder zu importieren.

Der erste Ansatz war, die Systemordner des Postfaches durch Outlook reparieren zu lassen. Dazu muss Outlook mit zwei Parametern gestartet werden.

outlook /resetfolders /resetfoldernames

Dies brachte jedoch nicht die gewünschte Änderung. Der Junk-E-Mail Ordern wurde zwar nicht mehr als einfacher Ordner angezeigt, dennoch sortierte Outlook keine E-Mails ein.

Junk-E-Mail Listen löschen

Bei Aktivierung de- & aktiviertem Caching-Modus kam dann zutage, dass Outlook der Meinung ist, dass die Junk-E-Mail Listen zu groß sind, und die Filterung von Junk-E-Mails deaktiviert wird, bis dies behoben ist. Jedoch waren die Listen alle leer.

Diese Meldung taucht aber nur beim ersten Öffnen des Profils auf. Auch wenn der Fehler weiterhin existiert, erscheint diese Meldung nicht mehr. Erst nach dem Löschen und Neuerstellen des Outlook-Profils erscheint diese Meldung wieder.

Also musste eine Möglichkeit her, den Eintrag im Postfach für die Junk-E-Mail Listen zu löschen. Google gab da leider gar nichts her. Also hab ich mal die Tools durchgeschaut die Microsoft für den direkte MAPI Zugriff auf Postfächer anbietet. Der MAPI Editor war dann die Lösung.

Um dieses Problen zu lösen, muss das Postfach wie unten beschrieben geöffnet werden. Doch anstelle des JunkEmailRule Eintrages müssen IPM.Rule.Message and IPM.ExtendedRule.Message gelöscht werden, wobei der letzte nicht immer existiert. Weiterlesen

Nachdem ich gestern den halben abend damit verbracht habe, ein Exchange Problem zu finden, was nicht da ist sonder in wirklichkeit ein Leistungsproblem gewesen ist wollte ich kurz ein Worte zu netcps verlieren.

Obwohl bei dem gestrigen Problem ein Monitoring der Leitung ergab, dass diese zu ~10% belastet ist, was es einem Exchange Server nich möglich über diese WAN Strecke eine eMail innerhalb der Organisation einem anderen Exchangeserver zuzuerstellen.

Die Fehlermeldung war:
451 4.4.0 Primary target IP address responded with: “421 4.4.2 Connection

Duch einen Test der Leitung mit netcps hätte man diesen Leitungsengpass bemerken können, denn es wurden Daten übertragen aber mit einer solchen Geschwindigkeit das die eMail Kommunikation in einen Timeout lief.

Netcps ermöglicht es, solche Leistungsenpässse zu erkennen. Dazu startet man netcps -s auf einer Maschine und überträgt von einer zweiten (netcps hostname) in der Voreinstellung 10 MB. Während der Übertragung wird die Datenrate angezeigt. Somit erhält man einen Überblick über die Transferrate sowie die benötigte Zeit.

Die zu übertragende Datenmenge lässt sich beliebig erhöhen.

NetCPS 1.0 - Entering client mode. Press ^C to quit
Connecting to 10.46.4.251 port 4455... Connected!
---> CPS    528384.00  KPS:   516.00  MPS: 0.50
Avrg CPS    414098.47  KPS:   404.39  MPS: 0.39
Peek CPS    559104.00  KPS:   546.00  MPS: 0.53
Done. 104857600 Kb transferred in 253.22 seconds.