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>