https://web.archive.org/web/20050315094239/http://docs.freeb... Date: Sat, 17 Feb 2001 23:49:58 +0000 (GMT)
From: Terry Lambert <tlambert@primenet.com>
To: roam@orbitel.bg (Peter Pentchev)
Cc: arch@freebsd.org
Subject: UUCP must stay; fetchmail sucks (was list 'o things)
[...]
>-- A tangential diatribe on the unsuitability of fetchmail -------
>As to fetchmail: it is an abomination before God. If someone in
the press ever paid for an audit of the source code, the result
would refute the paper "The Cathedral and the Bazaar" to such an
extent that it could damage the Open Source movement, which has
pinned so much on the paper, in ill-considered haste.
>ESR has constantly maintained that fetchmail is "not an MTA", and
he is right: it could be, but it's not.
>When mail is delivered to a POP3 maildrop, envelope information
is destroyed. To combat this, you would need to tunnel the
enveleope information in headers. Generally, sendmail does not
support "X-Envelope-To:" because it exposes "Bcc:" recipients,
since fetchmail-like programs generally _stupidly_ do not strip
such headers before local re-injection of the email.
>Without this information, it can not recover the intended
recipient of the email. The fetchmail program delivers this
mail to "root".
>The program has another bug, even if you elect single message
delivery (in order to ensure a "for <user@domain>" in the
"Received:" timestamp line. The bug is that it assumes the
machine from which the download is occurring is a valid MX for
your domain. Many ISPs use one machine to do the virtual domain
expansion, and another to do final deliver into ISP hosts POP3
maildrops. The net effect of this is that it attempts to use
the "for <domain-account@isphost>" stamp, since it does not
reverse-priority order "Received:" timestamp lines.
>Similarly, fetchmail fails to order headers in "confidence"
order. This means that, given an email with a "valid" (MX
matches in the "by <MX>" and a "for <user@domain>" exists)
"Received:" timestamp line, a "To:", "Cc:", or "Bcc:" line, or
an "X-Envelope-To:" line (which must be configured, and which
is terrifically screwed up by qmail, requiring un-munging),
fetchmail -- takes the first one it sees, not the most correct
one.
>Using the "To:", "Cc:", or "Bcc:" lines ("data") to do the
delivery buys a spammer the ability to relay mail, though the
route it must take is rather circuitous. It also means that
if the "Bcc:" was properly stripped before handing the RFC 822
message to an MTA, or if you are a list recipient, that data
is useless for recovering envelope information. This means
that root gets all mailing list mail from lists which do not
do recipient rewriting (like the SVBUG list does), and root
also gets all mail addressed to non-existant local users that
was intended for particular local users (all SPAM and all
mail that was requested but not sent specifically targetted to
a particular user, via email header data).
>Unfortunately, ESR would not accept patches for the mistaken
MX problem, nor for the preference order problem, nor for the
tunneled envelope information stripping problem. He seemed to
be too busy with speaking engagements, and has since declared
fetchmail to be in "maintenance mode", in order to demonstrate
a recognizable commercial software lifecycle for an Open Source
project, to give business the warm fuzzies.
>-- End diatribe ------------------------------------------------