aboutsummaryrefslogtreecommitdiffstats
path: root/website/multidrop.de.html
blob: c727c05111d20567697da049864e96f983c4d809 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
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=utf-8">
    <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&nbsp;-t&nbsp;-oi stecken (sendmail mit
      einer fixen, lokalen Mailadresse, z. B.
      sendmail&nbsp;-oi&nbsp;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>
Metz's inet6-apps library). <LI> Support for IMAP with RFC1731-conformant GSSAPI authentication. <LI> Fixed and verified support for Cyrus IMAP server, M$ Exchange, and Post Office/NT. <LI> Support for responding with a one-time password when a POP3 server issues an RFC1938-conforming OTP challenge. <LI> Support for Compuserve's RPA authentication protocol for POP3 (not compiled in by default, but configurable). </UL> <H2>Since 3.0:</H2> <UL> <LI> Support for IMAP RFC 1731 authentication with Kerberos v4. <LI> Support for multiple-folder retrieval in a single session under IMAP. <LI> Following SMTP 571 response to a From line, fetchmail no longer downloads the bodies of spam messages. <LI> Support for a `hunt list' of SMTP hosts. <LI> Support for ESMTP 8BITMIME and SIZE options. <LI> Support for ESMTP ETRN command. <LI> The stripcr & forcecr options to explicitly control carriage-return stripping and LF-&gt;CRLF mapping before mail forwarding. </UL> <H2>Since 2.0:</H2> <UL> <LI> Support for secure use with ssh. <LI> Mailserver passwords can be parsed out of your .netrc file. <LI> When forwarding mail via SMTP, fetchmail respects the 571 "spam filter" response and discards any mail that triggers it. <LI> Transaction and error logging may optionally be done via syslog. <LI> (Linux only) Security option to permit fetchmail to poll a host only when a point-to-point link to a particular IP address is up. <LI> RPOP support (restored; had been removed in 1.8). </UL> <H2>2.0 and earlier versions:</H2> <UL> <LI> Support POP2, APOP, RPOP, IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1. . <LI> Support for Kerberos V4 user authentication (either MIT or Cygnus). <LI> Host is auto-probed for a working server if no protocol is specified for the connection. Thus you don't need to know what servers are running on your mail host in advance; the verbose option will tell you which one succeeds. <LI> Delivery via SMTP to the client machine's port 25. This means the retrieved mail automatically goes to the system default MDA as if it were normal sender-initiated SMTP mail. <LI> Configurable timeout to detect if server connection is dropped. <LI> Support for retrieving and forwarding from multi-drop mailboxes that is guaranteed not to cause mail loops. <LI> Large user community -- fetchmail has a large user base (the author's beta list includes well over two hundred people). This means feedback is rapid, bugs get found and fixed rapidly. <LI> Carefully written, comprehensive and up-to-date man page describing not only modes of operation but also how to diagnose the most common kinds of problems and what to do about deficient servers. <LI> Rugged, simple, and well-tested code -- the author relies on it every day and it has never lost mail, not even in experimental versions. (In the project's entire history there has only been one recorded instance of lost mail, and that was due to a quirk in some Microsoft code.) <LI> Strict conformance to relevant RFCs and good debugging options. You could use fetchmail to test and debug server implementatations. <LI> For anybody who cares, fetchmail is Y2K safe. </UL> <H2>Features in common with other remote-mail retrieval programs:</H2> The other programs I have checked include fetchpop1.9, PopTart-0.9.3, get-mail, gwpop, pimp-1.0, pop-perl5-1.2, popc, popmail-1.6 and upop. <UL> <LI> Support for POP3. <LI> Easy control via command line or free-format run control file. <LI> Daemon mode -- fetchmail can be run in background to poll one or more hosts at a specified interval. <LI> From:, To:, Cc:, and Reply-To: headers are rewritten so that usernames relative to the fetchmail host become fully-qualified Internet addresses. This enables replies to work correctly. (Would be unique to fetchmail if I hadn't added it to fetchpop.) <LI> Message and header processing are 8-bit clean. </UL> <HR> <table width="100%" cellpadding=0><tr> <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a> <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a> <td width="30%" align=right>$Date: 2001/02/11 19:56:10 $ </table> <P><ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com">&lt;esr@snark.thyrsus.com&gt;</A></ADDRESS> </BODY> </HTML>