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) Message-ID: <200102172349.QAA11724@usr05.primenet.com> In-Reply-To: <20010217173019.A431@ringworld.oblivion.bg> from "Peter Pentchev" at Feb 17, 2001 05:30:19 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Just a minor comment-with-a-question. What is UUCP used for - mainly mail?
> If so, then here's a datapoint - about two years ago I took part in
> converting an existing UUCP mail transfer config to one using fetchmail.
> Quite simple - invoke fetchmail -d from the PPP link-up script, kill it
> in the link-down script in such a way that it sends a QUIT to avoid
> message duplicates. There were a couple of other issues too, but in
> the end, it all started working, and it's been working flawlessly for
> the past two years.
UCP belongs in the base system; you can skip the rest of this, if
you are not interested in the gory details of UUCP vs. fetchmail.
UUCP is the UNIX-UNIX Copy Program. It is used for copying files
around. I formerly used it to copy TCP/IP and other packages to
SVR4 boxes, since it was faster to do it over a null-modem cable
than to use floppies.
Primarily, it is used for email and usenet in areas of poor
connectivity. The UUCP 'g' protocol is much more forgiving
of noise than PPP or SL/IP over the same noisy connection.
-- 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 ------------------------------------------------
UUCP, comparatively, avoids this whole mess, by not destroying
the envelope information, which normally exists only on on a
mail transport (in SMTP, this is the "MAIL FROM:<addrspec>" and
"RCPT TO:<addrspec>"; in UUCP, it's the control file contents).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102172349.QAA11724>