Date: Wed, 28 Apr 2004 05:53:12 -0000 From: <freebsd-hackers@davehart.net> To: <freebsd-hackers@freebsd.org>, "Shawn Harrison" <harrison@tbc.net>, "Dave Hart" <davehart@davehart.com> Subject: RE: Loosing STDOUT after file rotation Message-ID: <255A839665EA24408EB27A6AAE15518EACC5@europa.ad.hartbrothers.com>
next in thread | raw e-mail | index | archive | help
> >> Anything DJB has written is a last resort, not an alternative. > >> > >> DES Shawn Harrison wrote: > Are you speaking with regard to the code or the license? If=20 > the code, what are your reasons for saying this? If the=20 > license, nevermind. I'm not DES, but I have a couple of examples in qmail 1.03 of code problems. If I had any expectation that djb would update qmail, I would address these to him instead of to you and to individuals I SMTP with who use qmail. 1. qmail violates SMTP RFCs in the name of being picky about line endings in SMTP DATA. I saw it operating a different MTA as backup MX for someone using qmail on their primary inbound MX. Someone dropped off some spam on my MTA which had a "bare LF" in qmail parlance, which may be a problem in that legitimate SMTP line endings are required to pair CR and LF. My MTA attempted to deliver the mail to the primary MX for the domain in question, triggering qmail's poorly coded "bare LF" check, which writes a 451 temporary failure response with a pointer to a djb web page shaking fingers over line endings: =20 451 See http://pobox.com/~djb/docs/smtplf.html. However, the SMTP violation comes in here. First of all, the response comes in immediately, not after the <CRLF>.<CRLF> termination of the DATA payload. RFC821/STD0010 section 4.4 states regarding DATA payload: "Note that the 'data' here here is a series of lines sent from the sender to the receiver with no response expected until the last line is sent." More seriously, qmail then simply terminates the process and thereby closes the SMTP connection, which clearly violates RFCs 821 and 2821, section 4.1.1 on command semantics, which says regarding QUIT: The receiver should not close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The sender should not close the transmission channel until it send a QUIT command and receives the reply (even if there was an error response to a previous command). If the connection is closed prematurely the receiver should act as if a RSET command had been received (canceling any pending transaction, but not undoing any previously completed transaction), the sender should act as if the command or transaction in progress had received a temporary error (4xx). So a standards-compliant MTA sending a "bare LF" bomb to qmail engages in a race between recognizing the premature 451 response to the DATA command, or noticing the socket has been dropped by the server in violation of spec. Such a sender will in either case treat this as a temporary failure and retry after some interval. If the sender is an innocent backup MX, the resulting behavior is wasteful repeated resending of the bare LF bomb, terminally receiving a hopeful "temporary" failure. If you use qmail, please consider simply editing out the bare LF check entirely, nothing else goes haywire in the experience of several of my friends. At least for inbound MXes, if not for customer-facing outbound relays. 2. Yes, despite two or three RFC violations above, there's another bone I have to pick with qmail. In today's world of massive worm-infested-sender spam, joe-job spam backscatter, and worm infection attempts via email and their backscatter, it is irresponsible though not violating any RFCs to blindly accept any and all RCPT email addresses "@" a domain name qmail handles mail for, only to generate bounce emails later on for mails addressed to non-existent local parts. That is, even though qmail is in a position to know that, say, davehart@distributed.net is not a valid email address, instead of responding to a RCPT TO:<davehart@distributed.net> command with an error, qmail chooses to accept the address and the accompanying mail traffic, then quickly turn around a bounce email message to the purported sender including a copy of the message. Why do I care if qmail is accept-then-bounce instead of refusing to accept the address? Because worms forge my email addresses as purported sender after finding it on someone else's computer. One of my former email addresses (davehart@distributed.net again) is handled by qmail, and to do my part I'd like to see worm bounces and other wasteful traffic refused before DATA rather than using the bandwidth of the distributed.net mailserver twice over. Similarly, I'd rather see worm attempts to infect davehart@distributed.net result in the worm failing to send the email in the first place, rather than having it send it successfully only to have distributed.net's mailserver send a helpful bounce to an innocent purported sender (remember, worms lie about sender habitually) containing a copy of the infection vector. I hear wonderful things about Postfix, and my impression is it has a license that won't leave you down a dead-end road like qmail's does. Dave Hart davehart@davehart.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?255A839665EA24408EB27A6AAE15518EACC5>