From 1ff7ec141e23c7d6f4eb292c035011b6158ad2bd Mon Sep 17 00:00:00 2001
From: Matthias Andree <matthias.andree@gmx.de>
Date: Thu, 26 Nov 2020 11:14:47 +0100
Subject: Import multidrop documents, and link in FAQ.
---
website/multidrop.de.html | 149 ++++++++++++++++++++++++++++++++++++++++++++++
website/multidrop.html | 143 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 292 insertions(+)
create mode 100644 website/multidrop.de.html
create mode 100644 website/multidrop.html
(limited to 'website')
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 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+"http://www.w3.org/TR/html4/loose.dtd">
+
+<html>
+ <head>
+ <meta name="generator" content=
+ "HTML Tidy for Linux/x86 (vers 1st April 2002), see www.w3.org">
+
+ <title>Voraussetzungen f�r funktionierendes Multidrop</title>
+ <meta name="author" content="Matthias Andree">
+ <meta http-equiv="Content-Type" content=
+ "text/html;charset=iso-8859-15">
+ <link rev="made" href="mailto:matthias.andree@gmx.de">
+ <style type="text/css">
+ <!--
+ body {
+ background-color: #ffffff;
+ color: #000000;
+ }
+ //-->
+ </style>
+ </head>
+
+ <body>
+ <a href="multidrop.html">Link to English-language version/Link zur englischen Sprachfassung</a>
+ <h1>Voraussetzungen f�r funktionierendes Multidrop</h1>
+
+ <address>
+ <a href="mailto:matthias.andree@gmx.de">Matthias Andree</a> 2003-10-12
+ </address>
+
+ <h2>Einleitung</h2>
+
+ <p>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.</p>
+
+ <p>Oft genug geht so ein Unterfangen dann bei der Mailabholung
+ schief, die Ursachen und Abhilfen daf�r sollen hier n�her
+ betrachtet werden.</p>
+
+ <h2>Eingangsbetrachtungen</h2>
+
+ <p>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.</p>
+
+ <p>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:).</p>
+
+ <p><strong>Wichtige Hintergrundinformation:</strong> 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!</p>
+
+ <p>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:</p>
+
+ <ul>
+ <li>Bcc: wird bei erster Gelegenheit entfernt, er soll ja
+ beim Empf�nger nicht mehr sichtbar sein</li>
+
+ <li>To: und Cc: werden bei Mailweiterleitungen nicht an das
+ Ziel angepasst</li>
+
+ <li>To: und Cc: enthalten bei Mailinglistenteilnahme die
+ Adresse der Liste und nicht die Adresse desjenigen, der die
+ Liste bestellt hat</li>
+ </ul>
+
+ <p>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.</p>
+
+ <h2>Voraussetzungen</h2>
+
+ <p>Unter bestimmten Voraussetzungen kann POP3-Multidrop dennoch
+ zuverl�ssig funktionieren. Diese sind:</p>
+
+ <ol>
+ <li>Der Provider MUSS f�r jeden Empf�nger der eigenen Domain
+ eine Kopie der Mail in die Mailbox werfen.</li>
+
+ <li>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.</li>
+
+ <li>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.</li>
+
+ <li><strong>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).</strong></li>
+ </ol>
+
+ <h2>Erkl�rungen</h2>
+
+ <dl>
+ <dt>Ad 1:</dt>
+
+ <dd>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.</dd>
+
+ <dt>Ad 2:</dt>
+
+ <dd>
+ 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:
+
+ <ul>
+ <li>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)</li>
+
+ <li>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.</li>
+ </ul>
+ </dd>
+ </dl>
+ <!-- vim: set filetype=html: -->
+ </body>
+</html>
+
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 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+"http://www.w3.org/TR/html4/loose.dtd">
+
+<html>
+ <head>
+ <meta name="generator" content=
+ "HTML Tidy for Linux/x86 (vers 1st April 2002), see www.w3.org">
+
+ <title>Requisites for working multidrop mailboxes</title>
+ <meta name="author" content="Matthias Andree">
+ <meta http-equiv="Content-Type" content=
+ "text/html;charset=iso-8859-15">
+ <link rev="made" href="mailto:matthias.andree@gmx.de">
+ <style type="text/css">
+ <!--
+ body {
+ background-color: #ffffff;
+ color: #000000;
+ }
+ //-->
+ </style>
+ </head>
+
+ <body>
+ <a href="multidrop.de.html">Link zur deutschen Version/link to German-language version</a>
+
+ <h1>Requisites for working multidrop mailboxes</h1>
+
+ <address>
+ <a href="mailto:matthias.andree@gmx.de">Matthias Andree</a> 2004-05-27
+ </address>
+
+ <h2>Introduction</h2>
+
+ <p>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".</p>
+
+ <p>Often enough, such an undertaking goes awry during the mail
+ fetch, causes and remedies are to be presented in this
+ document.</p>
+
+ <h2>Initial Examination</h2>
+
+ <p>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.</p>
+
+ <p>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:)</p>
+
+ <p><strong>Important background information:</strong> 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.</p>
+
+ <p>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:</p>
+
+ <ul>
+ <li>Bcc: is removed from the header - it is supposed to be
+ invisible to the recipients</li>
+
+ <li>To: and Cc: are not updated to reflect the new target
+ when mail is being redirected</li>
+
+ <li>To: and Cc:, in mailing list mail, contain the LIST
+ address and not the subscriber's address</li>
+ </ul>
+
+ <p>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.</p>
+
+ <h2>Requirements</h2>
+
+ <p>POP3 multidrop can work reliably all the same, provided that
+ some requirements are met. These are:</p>
+
+ <ol>
+ <li>The ISP MUST drop one copy per recipient in that
+ domain.</li>
+
+ <li>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:.</li>
+
+ <li>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.</li>
+
+ <li><strong>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).</strong></li>
+ </ol>
+
+ <h2>Explanations</h2>
+
+ <dl>
+ <dt>Ad 1:</dt>
+
+ <dd>If this requirement is not met, mails to multiple
+ recipients of the multidrop domain will only reach one of the
+ recipients.</dd>
+
+ <dt>Ad 2:</dt>
+
+ <dd>
+ If this requirement is not met, delivery will be faulty.
+ Attempting to derive this information from the headers
+ (To:, Cc:) is dangerous and unreliable:
+
+ <ul>
+ <li>Mail for mailing lists (which have their addresses in
+ the To: or Cc: header) will loop, which must be
+ avoided</li>
+
+ <li>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.</li>
+ </ul>
+ </dd>
+ </dl>
+ <!-- vim: set filetype=html: -->
+ </body>
+</html>
+
--
cgit v1.2.3