fetchmail - [fork] set imap idle timeout to 600s, some servers don't follow rfc recommendations

	Commit message (Collapse)	Author	Age	Files	Lines
*	Add rudimentary autobuild support.	Matthias Andree	2005-11-27	1	-0/+11
	Add a trivial self test, required for autobuild. svn path=/trunk/; revision=4479

<!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">  </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>  </body> </html>