diff options
| author | Matthias Andree <matthias.andree@gmx.de> | 2020-11-26 11:14:47 +0100 |
|---|---|---|
| committer | Matthias Andree <matthias.andree@gmx.de> | 2020-11-26 11:19:33 +0100 |
| commit | 1ff7ec141e23c7d6f4eb292c035011b6158ad2bd (patch) | |
| tree | 654cb33ab4d2586b97a8f6e1ff2425454e648f3a /website/multidrop.html | |
| parent | 297dff5913c3fbbb6ba17ffa89d8a1e3a424402b (diff) | |
| download | fetchmail-1ff7ec141e23c7d6f4eb292c035011b6158ad2bd.tar.gz fetchmail-1ff7ec141e23c7d6f4eb292c035011b6158ad2bd.tar.bz2 fetchmail-1ff7ec141e23c7d6f4eb292c035011b6158ad2bd.zip | |
Import multidrop documents, and link in FAQ.
Diffstat (limited to 'website/multidrop.html')
| -rw-r--r-- | website/multidrop.html | 143 |
1 files changed, 143 insertions, 0 deletions
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> + |