From 1ff7ec141e23c7d6f4eb292c035011b6158ad2bd Mon Sep 17 00:00:00 2001 From: Matthias Andree Date: Thu, 26 Nov 2020 11:14:47 +0100 Subject: Import multidrop documents, and link in FAQ. --- website/multidrop.de.html | 149 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 website/multidrop.de.html (limited to 'website/multidrop.de.html') diff --git a/website/multidrop.de.html b/website/multidrop.de.html new file mode 100644 index 00000000..e132a9d7 --- /dev/null +++ b/website/multidrop.de.html @@ -0,0 +1,149 @@ + + + + + + + Voraussetzungen für funktionierendes Multidrop + + + + + + + + Link to English-language version/Link zur englischen Sprachfassung +

Voraussetzungen für funktionierendes Multidrop

+ +
+ Matthias Andree 2003-10-12 +
+ +

Einleitung

+ +

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:

+ + + +

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:

+ +
    +
  1. Der Provider MUSS für jeden Empfänger der eigenen Domain + eine Kopie der Mail in die Mailbox werfen.
    2. + +
  2. 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.
    3. + +
  3. 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.
    4. + +
  4. 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).
    5. +
+ +

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.
    • +
+
+
+ + + + -- cgit v1.2.3