Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA27983; Tue, 2 Jul 1996 14:58:21 -0400 Received: by CS.UTK.EDU (bulk_mailer v1.6); Tue, 2 Jul 1996 14:57:58 -0400 Received: from koobera.math.uic.edu (qmailr@KOOBERA.MATH.UIC.EDU [128.248.178.247]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA27907; Tue, 2 Jul 1996 14:57:54 -0400 Received: (qmail-queue invoked by uid 666); 2 Jul 1996 19:01:26 -0000 Date: 2 Jul 1996 19:01:26 -0000 Message-ID: <19960702190126.8150.qmail@koobera.math.uic.edu> From: djb@koobera.math.uic.edu (D. J. Bernstein) To: drums@cs.utk.edu Subject: Re: libel > p.s. At the risk of starting a discussion of elementary statistical sampling > theory, one has to be suspicious of any email behavior pattern statistics > derived by inspecting the mail database of someone who builds and > distributes mail systems, especially when those statistics "prove" that the > behavior of the mail system in question is dominant/correct. qmail's SMTP client does not support ESMTP. The statistic that I was pointing out---namely, the vast majority of current ESMTP clients revert to HELO if they don't see ESMTP in the greeting line---is thus independent of qmail's behavior. It also doesn't ``prove'' anything about qmail's behavior. Most of the issues I've discussed on DRUMS are things that won't affect qmail. The problem is that DRUMS is carelessly standardizing behavior that could hurt _other_ implementors and users. Two recent examples: (1) My 822 parsing library can trivially handle multiple To fields---in fact, to stop after the first To field, the caller would have to do a bit more work---but the same is apparently not true of other libraries. (2) qmail automatically handles its own aliases in RCPT commands, with no configuration, but sendmail doesn't. > In any event, only a fool would claim that ESMTP deployment isn't still in a > transitional state. And only a fool would pretend that ESMTP is 100% deployed. ---Dan