Multidrop is a way to receive mail for several receivers in one
+mailbox. It is sort of abusing the system (using address extensions
+would be more useful, where available) and has quite some
+requirements to work properly. I wrote a separate article to document
+this, it is avavailable in English
+and in German.
Viele Provider bieten ihren Kunden ein POP3-Multidrop oder
+ "domain-in-a-mailbox"-Schema an, um für mehrere Empfänger in
+ einer Domain die Mail "in einem Rutsch" abholen zu lassen.
+
+
Oft genug geht so ein Unterfangen dann bei der Mailabholung
+ schief, die Ursachen und Abhilfen dafür sollen hier näher
+ betrachtet werden.
+
+
Eingangsbetrachtungen
+
+
POP3, das Post-Office-Protokoll Version 3, war ursprünglich
+ dazu gedacht, Mail für einen einzelnen Benutzer zu
+ transportieren. Es erhält den sogenannten Umschlag
+ ("Envelope"), der die tatsächlichen Empfänger und Absender
+ angibt, nicht.
+
+
Nun wird oft der Absender im Header "Return-Path"
+ hinterlegt, bezüglich des Empfängers kocht sich jeder
+ Programmierer eines Mailservers seine eigene Suppe. Gängig sind
+ "gar nichts" (sendmail), "Delivered-To:" (qmail, evtl. mit
+ einem Präfix, Postfix), "X-Envelope-To:" (bestimmte
+ procmail-Setups) und "X-Original-To:" (neuere Postfix-Versionen
+ zusätzlich zum Delivered-To:).
+
+
Wichtige Hintergrundinformation: Die
+ Mail-HEADER wie To:, Cc:, Bcc: sind für die Zustellung der Mail
+ NICHT RELEVANT. Die Mailzustellung erfolgt ausschließlich
+ anhand des UMSCHLAGS, wie bei der Sackpost auch!
+
+
Es ist zwar häufig so, dass der Umschlag bei der ersten
+ Einlieferung der Mail aus den Headern erzeugt wird, doch NUR
+ DER UMSCHLAG trägt, im Gegensatz zum HEADER (Briefkopf), die
+ vollständige Information:
+
+
+
Bcc: wird bei erster Gelegenheit entfernt, er soll ja
+ beim Empfänger nicht mehr sichtbar sein
+
+
To: und Cc: werden bei Mailweiterleitungen nicht an das
+ Ziel angepasst
+
+
To: und Cc: enthalten bei Mailinglistenteilnahme die
+ Adresse der Liste und nicht die Adresse desjenigen, der die
+ Liste bestellt hat
+
+
+
Der Umstand, mehrere Empfänger in einer Mailbox zu
+ vereinigen, erfordert nun, dass der tatsächliche Empfänger der
+ Mail hinterlegt wird, damit die Mail richtig zugestellt werden
+ kann. POP3 trifft hierfür keine Vorkehrungen, daher müssen sie
+ außerhalb des Protokolls eingerichtet werden. Es bietet sich
+ hierfür der Mailheader an.
+
+
Voraussetzungen
+
+
Unter bestimmten Voraussetzungen kann POP3-Multidrop dennoch
+ zuverlässig funktionieren. Diese sind:
+
+
+
Der Provider MUSS für jeden Empfänger der eigenen Domain
+ eine Kopie der Mail in die Mailbox werfen.
+
+
Der Provider MUSS in JEDER Mail den sogenannten "Envelope
+ Recipient" hinterlegen. Welcher Header das ist, sieht man
+ entweder an der Mail oder kann es beim Provider erfragen.
+ Typisch wird man einen Header wie X-Original-To:,
+ X-Envelope-To: oder Delivered-To: finden.
+
+
Der POP3-Client (Mercury/32, fetchmail, getmail, ...)
+ MUSS den Header, in dem der "Envelope Recipient" hinterlegt
+ ist, zuverlässig erkennen und ausschließlich anhand seiner
+ die Mail zustellen.
+
+
Der POP3-Client DARF KEINESFALLS die To: oder
+ Cc:-Header auswerten. Er DARF KEINESFALLS die Mail in einen
+ Befehl wie sendmail -t -oi stecken (sendmail mit
+ einer fixen, lokalen Mailadresse, z. B.
+ sendmail -oi hans ist hingegen
+ vertretbar).
+
+
+
Erklärungen
+
+
+
Ad 1:
+
+
Ist diese Voraussetzung nicht erfüllt, werden bei Mails,
+ die an mehrere Empfänger der eigenen Domain gehen, einige
+ Empfänger die Mail nicht bekommen.
+
+
Ad 2:
+
+
+ Ist diese Voraussetzung nicht erfüllt, kommt es zu
+ Fehlzustellungen. Der Versuch, die Information aus den
+ Mailheadern selbst (To:, Cc:) zu entnehmen, ist gefährlich
+ und unzuverlässig:
+
+
+
Einerseits kann Mail an Mailinglisten zurückgeschickt
+ werden, deren Adresse oft im To:- oder Cc:-Header steht,
+ was eine Mailschleife auslöst, die unbedingt vermieden
+ werden muss (weil sie Kosten verursacht)
+
+
andererseits ist die Regenerierung von Empfängern,
+ die beim Absender im "Bcc:"-Header eingetragen waren,
+ nicht möglich, da der Bcc:-Header beim Transport entfernt
+ werden muss, wie der Name "Blind Carbon Copy" schon
+ andeutet.
+
+
+
+
+
+
+
diff --git a/website/multidrop.html b/website/multidrop.html
new file mode 100644
index 00000000..2de3efc3
--- /dev/null
+++ b/website/multidrop.html
@@ -0,0 +1,143 @@
+
+
+
+
+
+
+ Requisites for working multidrop mailboxes
+
+
+
+
+
+
+
+ Link zur deutschen Version/link to German-language version
+
+
Many ISPs offer a POP3 multidrop or "domain in a mailbox"
+ setup to their clients who can then fetch mail for multiple
+ recipients in their domain "in one go".
+
+
Often enough, such an undertaking goes awry during the mail
+ fetch, causes and remedies are to be presented in this
+ document.
+
+
Initial Examination
+
+
POP3, the Post Office Protocol version 3, was intended to
+ transport mail for a single recipient. It does not keep the
+ envelope that indicates the actual recipient and sender.
+
+
The envelope sender is often copied to the "Return-Path"
+ header, with respect to the envelope recipient, every
+ programmer of a mail server will have their own implementation.
+ Common solutions are "do nothing" (sendmail), "Delivered-To:"
+ (in qmail, potentially with a domain prefix; Postfix),
+ "X-Envelope-To:" (certain procmail-based setups) and
+ "X-Original-To:" (Postfix releases after 2002-10-25 will write
+ this in addition to Envelope-To:)
+
+
Important background information: Mail
+ headers such as To:, Cc:, Bcc: are IRRELEVANT for routing and
+ delivery of the mail. Mail routing will only look at the
+ ENVELOPE - there is no difference from snail mail here.
+
+
We will frequently see that upon injection, the envelope is
+ created from the headers, but ONLY THE ENVELOPE carries, in
+ contrast to the HEADER, the full information:
+
+
+
Bcc: is removed from the header - it is supposed to be
+ invisible to the recipients
+
+
To: and Cc: are not updated to reflect the new target
+ when mail is being redirected
+
+
To: and Cc:, in mailing list mail, contain the LIST
+ address and not the subscriber's address
+
+
+
Dropping off mail for multiple distinct recipients in the
+ same mailbox requires the server to deposit the actual
+ recipient in the mail in order to achieve proper delivery. POP3
+ makes no provisions, so this must take place outside the
+ protocol, the mail header lends itself to the task.
+
+
Requirements
+
+
POP3 multidrop can work reliably all the same, provided that
+ some requirements are met. These are:
+
+
+
The ISP MUST drop one copy per recipient in that
+ domain.
+
+
The ISP MUST deposit the envelope recipient in the mail
+ header. Which one your ISP chooses can be asked from their
+ tech support or you'll see it when looking at a mail header.
+ You'll typically find X-Original-To:, X-Envelope-To:,
+ Delivered-To:.
+
+
The POP3 client (Mercury/32, fetchmail, getmail, ...)
+ MUST reliably recognise the header where the envelope
+ recipient has been deposited and use ONLY this header for
+ mail delivery.
+
+
The POP3 client MUST IN NO CASE evaluate To: or
+ Cc: headers. It MUST ON NO ACCOUNT feed the mail into a
+ command that is used for injection, such as
+ sendmail -t -oi (whereas sendmail with a fixed
+ local mail address, for instance, sendmail -oi joe,
+ is justifiable).
+
+
+
Explanations
+
+
+
Ad 1:
+
+
If this requirement is not met, mails to multiple
+ recipients of the multidrop domain will only reach one of the
+ recipients.
+
+
Ad 2:
+
+
+ If this requirement is not met, delivery will be faulty.
+ Attempting to derive this information from the headers
+ (To:, Cc:) is dangerous and unreliable:
+
+
+
Mail for mailing lists (which have their addresses in
+ the To: or Cc: header) will loop, which must be
+ avoided
+
+
the regeneration of recipients that were placed in
+ the Bcc: header at the sender's site, is impossible
+ because the Bcc: header is removed for transport, as the
+ name "blind carbon copy" suggests.