Jump to content

Duplicate Mail detection


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hey Ihrs,

 

ich bräucht zur Abwechselung mal wieder einen guten Tipp von Euch. Soweit ich heraus finden konnte - und korrigiert mich bitte, falls ich da irre - hat Exchange ja sowas wie eine Duplicate Mail detection, will heißen basierend auf der Versandzeit und der Message-ID entsorgt das Ding stillschweigend E-Mails.

 

Genau so ein Problem trifft uns hier grade, und ich vermute, dass besagte Duplicate Mail Detection verantwortlich ist. Wir betreiben hier einen SBS w2k3 u.a. als Mailserver. Neben den reinen Postfächern haben wir auch noch ein paar E-Mail-aktivierte Ordner, die wir z.B. als Auftragseingangskorb verwenden.

 

Folgenden Fall konnten wir mit einem unserer Kunden replizieren:

  1. Sachbearbeiter Kunde schickt E-Mail an auftrag@wir.tld, und setzt einen Vertriebler von uns auf CC. (wg. zugeh. telefonischer Absprache).
  2. Mailserver Kunde (Postfix) schickt beide Mails mit identischer Message-Id und zum selben Zeitpunkt raus.
  3. Unser Mailserver stellt die CC-Mail einwandfrei zu, die Mail an den öffentlichen Ordner verschwindet aber im Nirvana.
  4. In unseren Eingangslogs taucht ausschließlich die CC-Mail auf. Die andere Hälfte hinterlässt absolut keine Spuren. Ich hab schon das Reporting hoch gedreht, und es scheint, als ob die Mail nie an uns geschickt wurde. Ich hab allerdings auch die Log-Auszüge vom Postfix gesehen, und aus denen geht ganz klar eine Queued for Delivery Aussage unsers SBS hervor - für beide Mails.

 

Das Problem dabei ist, dass der Vertriebler nicht der Durchführende bei dem Auftrag ist. Unsere "Durchführer" arbeiten in Abhängigkeit der Informationen des öffentlichen Ordners. Ist nun der Vertriebler aus irgendwelchen Gründen nicht am Platz, kann es also passieren, dass Aufträge nicht durch geführt werden.

 

Nun zu meinen Fragen:

  1. Soweit ich die Duplicate Mail Detection verstehe, greift diese in Abhängigkeit von Message ID, Zeitpunkt und Empfänger. So ganz trifft das unseren Problemfall ja nicht. Kann die DMD für unser Problem wirklich verantwortlich sein?
  2. Wenn ja, wie schalte ich das Ding ab?
  3. Wenn nein, welche Diagnosemöglichkeiten hätte ich noch, um dem Problem weiter auf den Grund zu gehen?
  4. Wie löst Ihr derartige Probleme - sowohl organisatorisch, als auch technisch?

 

Schon mal vielen Dank für jeden guten Tipp.

 

Gruß Jens

Link zu diesem Kommentar

Bitte entschuldigt den Push, aber ich bin noch immer auf der Suche nach Anhaltspunkten zum obigen Problem. Hat vielleicht doch jemand einen Tipp für mich?

 

Ich hab mittlerweile ein wenig weiter gelesen, und so wie ich die Duplicate-Geschichte mittlerweile verstehe, kann man sie als Ursache wohl ausschließen. Trotzdem muss ich dringend heraus finden, warum bei uns Mails verschwinden. Jede Idee, und sei es auch nur zur weiteren Diagnose des Problems, würde mir da extrem weiter helfen.

 

Mich machen die sich widersprechenden Logs vom Mailserver der Gegenseite und von uns ziemlich ratlos, was das weitere Vorgehen angeht.

 

Gruß Jens

Link zu diesem Kommentar

Hallo.

 

Zusätzlich holt sich der Server per "on board"-POP3-Connector noch Mails vom Backup-Mailserver.

 

Wie darf ich den dieses Konstrukt verstehen?

 

Ich würde auf jeden Fall einmal eine saubere Konfiguration einsetzen, daher den POP3 Connector des SBS deaktivieren und das Logging des virtuellen SMTP aktivieren.

 

LG Günther

Link zu diesem Kommentar

Die Domain wird bei 1&1 gehosted. Dort haben wir die MX-Records so umgebogen, dass sie auf die Subdomain zeigen, über der unser SBS Server erreichbar ist.

 

Zusätzlich gibt es ja noch die 1&1 Backup-Mailserver. Da wir (logischerweise) nur einen SBS haben, missbrauchen wir diese für unsere Zwecke, und wir haben sie einfach als Backup in den MX-Records stehen lassen. (geringere Prio, usw) Nun macht ein Backup ja aber nur Sinn, wenn man auch irgendwie an seine Mails kommt, und die 1&1 Backup-MTA sind halt so konfiguriert, dass sie die Daten nicht aktiv weiter leiten. Wir nutzen halt den POP3 Connector dafür. Das Ding ist so konfiguriert, dass einmal die Stunde nachgeschaut wird, ob was über die Backup-Route rein kam.

 

Hinzu kommt für uns, dass wir neben den Adressen auf unserer Domain noch ein paar ältere T-Online-Adressen haben, die nach wie vor von Kunden benutzt werden. Dafür brauchen wir den POP3-Connector sowieso. Entnehm ich Deinen Ausführungen, dass man beide aufgrund irgendwelcher Inkompatibilitäten besser nicht parallel betreibt?

 

Das reine SMTP-Connector Setup ist aber ansonsten eigentlich standard, und wie überall sonst auch - natürlich mit der temporären Ausnahme, dass wir das Logging aktiviert haben, und uns nun für die Bereiche MSExchangeMTA und MSExchangeTransport das Log zukleistern lassen (ersteres auf Mittel, zweiteres auf Max).

 

Ergebnis: Nichts. Eine Mail unseres Kunden kommt ganz normal an, von der anderen ist weder Fehler, noch Erfolgsmeldung zu sehen. Auf unserer Seite findet sich weder in der Log-Datei im Exchange-Verzeichnis ein Hinweis auf zwei Mails, noch im Syslog. Schaue ich aber auf der anderen Seite in die Logs, krieg ich dort zwei wunderschöne Queued For Delivery zu sehen, Absender "unser Mailserver".

 

Für mich lässt das drei mögliche Szenarien zu:

 

1) Der Postfix-Server spinnt und spricht mit Gespenster-Mailservern.

2) Der Postfix-Server trennt die Mails nicht in zwei auf, sondern übermittelt sie unter Verwendung zweier MAIL TOs an unseren Server. Der ignoriert aber eins.

3) Wir kriegen zwei Mails, unser MTA sagt aber "och nö, den Schrott kenn ich schon", und entsorgt eine Hälfte stillschweigend.

 

Ergebnis: Ich ratlos ;)

 

Gruß Jens

Link zu diesem Kommentar

Hallo,

 

vorneweg: etwas das sich "Duplicate Mail detection" nennt (o.ä.) gibt es in Exchange Server nicht. Was Du da evtl. mal in der Richtung gehört haben könntest nennt "Single Instance Store" (SIS). In Exchange 2003 funktioniert das in ganz grob so: Du erstellt eine interne Mail in Outlook und drückst auf "senden". Dabei wird in der Datenbank ein Objekt erzeugt und mit Deinem Folder "Sent Items" verlinkt. Beim Empfänger passiert in etwa dasselbe, hier wird eben ein Link dasselbe Objekts in der "Inbox" (Posteingang) erzeugt. In Exchange 2003 funktioniert die SIS nur innerhalb einer Datenbank/Speichergruppe.

 

Dein Problem ist definitiv ein gänzlich anderes. Wenn vermisste Mail in keinem Log autaucht (SMTP Logging deaktiviert?) wurde Sie dem Exchange auch nicht zugestellt. Mögliche Ursachen gibt es viele, oft ist ein Tippfehler in der Adresse (kein Scherz). Ich würde Dir in jedem Fall erstmal raten Deine Konfiguration mit dem 2. MX-Record zu überdenken, wenn sich sonst keine neuen Erkenntnisse ergeben solltest Du versuchen das Problem zu reproduzieren.

 

ASR

Link zu diesem Kommentar

Moin ASR,

 

erstmal danke für Deine Erklärung. Dann ist zumindest ein verdächtiger vom Tisch, da unterschiedliche Speichergruppe.

 

Mein Problem mit den Mails ist, dass ich das Szenario genau so reproduzieren kann. Man schicke von besagtem Kunden zwei einzelne Mails, und das ganze geht einwandfrei und an beide Adressen durch. Man schicke eine Mail mit Adressat öffentlicher Ordner (also Auftrag@) und setze irgendwen anders von uns auf CC, und nur das CC kommt an. In Anbetracht der ja ankommenden CC-Mail ist ersichtlich, dass die Auftrags-Adresse richtig geschrieben ist. Die Postfix-Logs sagen, "ist richtig raus".

 

Ihr ratet beide so explizit von dem Konstrukt SMTP & POP 3 parallel ab. Was würdet Ihr alternativ vorschlagen? Einen weiteren SMTP-Server "irgendwo" aufstellen, und den als Relay auf unseren SBS konfigurieren? Weil: So 100% zuverlässig ist meine Außenanbindung nicht, als das ich ohne Backup glücklich wäre. Und: Wie sieht es mit den T-Online-Adressen aus? Da komm ich ja um einen POP3-Abruf nicht herum.

 

Gruß Jens

Okay Leute, vergesst den Part mit den verschwindenden Mails. Wir haben heute offensichtlich ne spontane Wunderheilung erfahren. Ich weiß nicht warum, aber jetzt gehen solche Mails auf einmal wieder durch. Ob da wohl der Kunde an irgendeiner Schraube gedreht hat, ohne uns was zu sagen?

 

Kommentare & Ratschläge zur zweiten Baustelle nehm ich aber trotzdem noch gerne...

 

Gruß Jens

Link zu diesem Kommentar

Ich finde dieses Konstrukt, bei dem der Backup-MX per Pop3 geleert wird, gar nicht so schlecht. Allerdings werden Spam-/Viren-Filter, welche den externen SMTP-Verkehr abhören, dabei umgangen.

Schöner wäre m.E. ein Backup-MX welcher zyklisch die aufgelaufenen Mails ohne Verfallszeitpunkt zuzustellen versucht. Über die Backscatter-Problematik müsste man sich dann allerdings auch noch Gedanken machen.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...