Probleme mit POP3-Sammlern
Bitte lesen Sie hier genau, welche Probleme Sie sich mit der Anbindung per POP3 Sammelkonto einhandeln.
Das Grundproblem
Ehe Sie sich nun die verschiedenen Probleme im Detail betrachten schauen wir erst mal das Prinzip an und vergleichen das mit einem Postbrief. Das sollte für jeden verständlich sein. Ein Brief besteht aus zwei Teilen:
- Der Brief selbst
Damit meine ich das DIN-A-4 Blatt mit ihrem Text, auf dem aber auch der Adressat, der Absender und ihre Nachricht steht - Der umschlag.
Hierauf schreiben Sie noch mal den Empfänger, den Absender. Fensterumschläge gibt es bei EMail nicht. Dieser Teil wird oft auch als "Envelope" bezeichnet.
Was passiert nun, wenn Sie einen Brief an alle Personen senden wollen ?. Richtig sie kopieren den Brief bzw. drucken ihn dreimal aus und tüten jeden in einen umschlag ein.
- Brief 1 für den Empfänger A
- Brief 1 für den Empfänger B (Kopie)
- Brief 1 für den Empfänger C (Blindkopie)
Die Empfänger A und B wissen nicht, dass eine Blindkopie (BCC) an Empfänger C gegangen ist
Auf den umschlag schreiben sie nun aber nur je einen der Empfänger und geben diese Brief zur Post. Diese Briefe gehen jetzt zum Zielpostfach. Im Gegensatz zum Postboten nimmt der Mailserver des Providers nun den Brief an, aber entfernt den umschlag. Im Sammelpostfach landet nur noch der Brief selbst. Und nun kommt ihr POP3-Sammelprogramm, welches diesen Brief nun abholt. Das POP3 Sammelprogramm hat keine Information über die früheren umschläge und kann nur aus den Adressaten aus dem Brief selbst die Empfänger ermitteln. Was passiert nun ?
- Empfänger A
Wird korrekt erkannt und die Mail wird per SMTP an den Empfänger gesendet - Empfänger B
Angenommen dieser Empfänger sitzt bei einer anderen Firma. Dann muss ihr POP3 Sammler dies erkennen. Sendet ihr POP3Sammler nun die Mail auch per SMTP an diesen Empfänger, dann wird ihr Mailserver entweder sagen "Relay denied" oder die Mail weiterleiten und Empfänger B bekommt zwei Nachrichten. - Empfänger C
Dieser ist nicht auf dem Brief selbst zu sehen. Sitzt diese Empfänger jedoch in ihrem Netzwerk, dann wird er die Mail nicht erhalten. Der POP3Sammler hat überhaupt keine Informationen über diesen Empfänger
Diese Problematik können Provider und Hersteller eines POP3 Sammlers nur gemeinsam lösen. Der Mailserver des Providers muss die ursprünglichen Empfänger aus dem Briefumschlag auf den Brief selbst schreiben und der POP3 Sammler muss diese Informationen finden, nutzen aber auch wieder entfernen. Ansonsten würden Empfänger A und Empfänger B erkennen können, dass es noch einen dritten Empfänger C gibt.
Schauen wir und das ganze mal technisch an an einer Mail an
Die Standard Mail ohne Probleme
Fangen wir mal mit einer "normalen" Mail von einem Absender an einen Empfänger an. Eine Mail von User an an User 2 wird über die SMTP-Server bis zum Ziel übertragen. Die Mailserver orientieren sich dabei aber am "Envelope", welcher aber nicht Bestandteil der eigentlichen Mail ist
Envelope:
====================
MAIl
FROM: User1@FIRMA1
RCPT
TO: User2@FIRMA2
Message:
====================
RFC-822
FROM: User1@FIRMA1
TO: User2@FIRMA2
Subject: Dies ist der Betreff
Und dies der Body
Diese Mail wird nun in das Sammelpostfach eingeworfen.
RFC-822
FROM: User1@FIRMA1
TO: User2@FIRMA2
Subject: Dies ist der Betreff
Und dies der Body
Der POP3 Sammeldienst holt nun die Mail aus dem Postfach und liest die Zeile "TO" aus, um die Mails dann entweder direkt in das Postfach abzulegen oder als SMTP-Mail an den lokalen Mailserver zu senden. Das Problem ist gelöst und die Funktion ist fehlerfrei vorhanden.
POP3-Probleme mit CC
Nun nehmen wir an, dass wie die Mail als "Kopie" empfangen. Das Original ist an User3@Firma3 gegangen. Beim Mailserver des Providers kommt daher an:
Envelope:
====================
MAIl
FROM: User1@FIRMA1
RCPT
TO: User2@FIRMA2
Message:
====================
RFC-822
FROM: User1@FIRMA1
TO: User3@FIRMA3, User2@FIRMA2
Subject: Dies ist der Betreff
Und dies der Body
Der Mailserver legt die Mail in das POP3 Sammelpostfach ab
RFC-822
FROM: User1@FIRMA1
TO: User3@FIRMA3, User2@FIRMA2
Subject: Dies ist der Betreff
Und dies der Body
Der POP3 Sammeldienst versucht nun erneut aus der "TO"-Adresse zu ermitteln, in welches Postfach er die Mails ablegen oder an welchen Server er die Mails weiterleiten muss.
Ein "gutes" Programm wird nun erkennen, welche Empfänger in der TO-Zeile die eigenen Empfänger sind und wird die anderen Empfänger einfach ignorieren. Es legt die Mail also in dem jeweiligen Postfach ab bzw. sendet es per SMTP direkt an den Server.
Es gibt aber auch "schlechte" Programme, die diese unterscheidung nicht vornehmen und einfach jede Mailadresse, die in der "To:"-Zeile drin steht, als Empfänger übernehmen. Je nach der Konfiguration ihres Mailservers führt dies dann dazu, dass dieser die Mail als "offenes Relay" weitergibt oder die Annahme verweigert (550 unable to relay). Einmal bekommt der Empfänger die Mail mehrfach und das andere Mal bekommt der Absender eine NDR-Meldung, wenn ihr POP3-Sammler überhaupt mit dem 550 Fehler umgehen kann.
POP3-Probleme mit BCC
Ein generelles Problem von POP3 ist die Abhandlung von BCCs (Blind carbon copies, Blindkopien). Die vollständige Liste der Empfänger darf ja nicht in der Mail selbst als "to:", "cc:" oder gar "bcc:" auftauchen, da die Empfänger ja sonst durch einen Blick in den Header die Liste einsehen könnte.
Da die Empfänger eine Blindkopie demnach nicht in der Message selbst enthalten sind, landen die Empfänger ohne weitere Mitarbeit des Mailservers nicht in der Mail die letztlich im POP3 Sammelpostfach landet. Ein Empfänger, der aber nicht in der TO oder CC-Zeile auftaucht, kann die Mail aber auch nicht erhalten, da der POP3-Sammeldienst keinerlei Information darüber erhält.
Der BCC User wird ja nur in den Steuerungsdaten übertragen. Im eigentlichen "Mailbody""" (Beginnt ab dem Schlüsselwort "DATA") ist der BCC Empfänger nicht enthalten. Besonders knifflig wird es z.B. wenn in ihrer Firma nur ein BCC Empfänger sitzt. Ohne entsprechende Umsetzung könnte so sogar eine "ungültige" Mail herauskommen, die der SMTP-Dienst nicht annimmt und je nach Implementation kann die die gesamte Funktion blockieren.
POP3 Lösungsansätze
Das ganze Problem mit der Zustellung per "Sammelpostfach" lässt sich aber nur dadurch lösen, dass der Provider des Sammelpostfachs mithilft. Dessen Mailserver muss die Empfänger aus dem Envelope mit in die Mail übernehmen und im Postfach ablegen.
- Provider addiert RCPT-TO Empfänger
Der Mailserver beim Provider muss die Empfänger, die in der RCPT-TO-Zeile enthalten sind in ein benutzerdefiniertes Feld in die Mail addieren - Der POP3-Sammler muss dieses Feld nutzen und entfernen
Der POP3-Sammler liest dann aus diesem Feld die Empfänger der Mail aus und entfernt dann dieses Feld wieder, ehe die Mail per MAPI oder SMTP zum Postfach übertragen wird
Leider gibt es dafür keinen Standard. Insofern sind Sie darauf angewiesen, dass der Provider dies implementiert, auf Dauer beibehält und ihr POP3 Programm dies auch versteht. Sie sehen, es ist gar nicht einfach eine Funktion, die bei SMTP zum Standard gehört, auf POP3 Sammelkonten umzusetzen. Siehe auch Envelope und Header.
Felder die ich bei Mails ein einem POP3-Sammelpostfach schon gesehen habe waren:
X-MDRcpt-To: Liste der Empfänger Mailadressen
X-Rcpt-To: Liste der Empfänger Mailadressen
Envelope-To: Liste der Empfänger Mailadressen
Anscheinend hat sich das Feld "Envelope-To:" als Quasistandard entwickelt, weil mehrere POP3Sameldienste genau dieses Feld auswerten. Allerdings habe ich genauso Provider gefunden, die dieses Feld nicht nutzen und dafür ein "X-"-Feld einsetzen.
Als Absender einer Mail mit Blindkopien sind Sie bei solchen Funktionen natürlich darauf angewiesen, dass die Empfänger einer Mail eben diese Felder wieder entfernen, da ansonsten sichtbar werden kann, dass es BCC-Empfänger gegeben hat.
Kontrollieren Sie daher vor dem Kauf und der Implementierung, welches Feld der Provider für Sammelkonten anbietet und welches Feld ihr POP3-Sammler auswertet.
POP3-Unstimmigkeiten mit Quittungen
Einen kleinen kosmetischen Effekt können Sie bei dem Einsatz eines POP3-Saugers erleben. Wenn ich ihnen als Absender eine Nachricht zusende, mit der ich eine Quittung anfordere, dann könnte es passieren, dass ihr Provider mit bei der Zustellung in ihr Sammelpostfach schon eine "Zugestellt" Quittung.
Auf der anderen Seite werden zustell bar und unzustellbar Quittungen von dem empfangenden SMTP-Server mit einem LEEREN Absender versendet. Dies ist Standard und erlaubt, aber einige POP3 Sauger haben auch damit Probleme, da sie beim Auslesen als Absender eben "NICHTS"! haben und beim Weiterleiten per SMTP diese Feld aber füllen müssen. Siehe auch ( http://www.dataenter.co.at/doc/popbeam.htm#KBPB018)
Ein anderes Problem von Quittungen sind, dass einige POP3 Sammler die Mail irrtümlich aufsplitten und wieder verteilen. Anders kann ich mir folgende Mail nicht erklären
Ich habe eine Mail an "eine" Person gesendet und in der Quittung ist die Zustellen bestätigt aber warum, auch immer, wollte irgend etwas die Mail auch noch mal an mich senden, obwohl ich nicht als Empfänger aufgeführt bin.
Stabilität einer POP3-Anbindung
Ich habe ihnen zwar schon erklärt, wie POP3 Sauger funktionieren und vielleicht ist es ihnen auch gelungen ein funktionierendes System zu installieren. Aber wenn Sie nicht gerade ihr eigenes System pflegen, sondern im Auftrag eines Kunden arbeiten, dann ist die Frage der Zuverlässigkeit und Stabilität sehr wichtig, da sie ansonsten bei jeder Änderung "Nachbessern" dürfen. Und was kann sich alles ändern ?
Der Abruf per POP3 nutzt Informationen aus dem Kopf der abgerufenen Nachricht um die eigentlichen Empfänger wieder aufzubereiten. Dies funktioniert nur dann korrekt, wenn auch der Provider mitspielt und Informationen im Header bereitstellt und der MTA des Providers nicht (wie z.B.: bei BCCs) löscht. Damit können wir dann schon alle Abhängigkeiten aufzählen:
- von dem POP3 Sauger
Die Software muss die Werte - von dem Provider
er konfiguriert sein Mailsystem und muss ihr Sammelpostfach passend einrichten - von der Unix des Providers
Auf diesem Betriebssystem läuft meistens der Mailserver und diese wird immer mal wieder aktualisiert, d.h. es gibt neue Versionen die vom Provider hoffentlich auf die Kompatibilität mit ihrem POP3 Sauger getestet werden, denn oft aktualisiert solch ein Update auch Serverdienste wie einen SENDMAIL. Darauf achtet nicht jeder Provider. - vom verwendeten SENDMAIL /POP3 Server
Der Mailserver nimmt in ihrem Auftrag die Nachrichten aus dem Internet an und legt diese zur Abholung in ihrem Sammelpostfach ab. Hierbei darf er nun nicht wie bei einem "normalen" POP3 Benutzer die Nachricht anpassen, sondern muss passend zu ihrem POP3-Sauger erweiterte Informationen mit speichern. Da es aber keinen POP3-Standard gibt, können Sie auch nicht sicher sein, dass die neue Version sich diesbezüglich wie die alte Version verhält. - Und vom Skript des Providers
Ein Sammelostfach wird bei einigen Systemen durch besondere Einstellungen, Skripte zur zusätzliche Dateien eingerichtet. Wenn die Installation eines Updates hier wieder "Defaultwerte" einträgt, ist es auch erst mal vorbei
Daher ist POP3 Sammeln aus meiner Sicht auch langfristig keine stabile Lösung. Auf jeden Fall sollten Sie einen vom Provider getesteten und unterstützten POP3-Sauger nutzen oder gleich einen "Standard" wie ETRN, ATRN, oder SMTP-Zustellung per fester IP oder DynDNS einsetzen.
Vielleicht wird dann auch die Warnung des SBS Produkt Teams verständlich
Like its predecessors, the POP3 connector in SBS
2008 is meant to be a migration solution to allow companies to
transition from hosting their email at the ISP to hosting their email
in-house on Exchange server. It is highly recommended to retire the POP3
Connector once your migration is complete and allow Exchange 2007 to
directly host email für your domain.
Quelle: Introducing the POP3 Connector
http://blogs.technet.com/sbs/archive/2009/07/01/sbs-2008-introducing-the-pop3-connector.aspx