Date: 5 Mar 1996 04:40:54 GMT
Message-ID: <19960305044054.3652.qmail@koobera.math.uic.edu>
From: djb@koobera.math.uic.edu (D. J. Bernstein)
To: drums@cs.utk.edu
Subject: Re: proposed agenda for 8 March WG meeting

I see that you have uncritically adopted RFC 1123's incorrect
``efficiency feature'' language. Multiple RCPTs are a _slowness_
feature. Except in extreme circumstances, good MTAs can achieve much
lower latency with separate SMTP connections than with multiple RCPTs.
(This changes in the presence of pipelining, but I'm talking about the
real world.)

RFC 821 fails to define ``text.'' Suggested definition: a sequence of
printable ASCII characters.

>    [ ] detection of mail loops  (using either received headers
>        or envelope information)

How about using what's already been implemented and proven to work in
practice? See ftp://koobera.math.uic.edu/pub/docs/RFCLOOPS, section 4.
I respectfully request that you not standardize vaporware.

>    [ ] handling of source-routed addresses

Why does this require discussion? Has somebody pointed out a problem
with the RFC 1123 rules?

>    [ ] Whether to require 8BITMIME extension for compliance with the
>        new SMTP spec.

Are you trying to artificially extend the lifetime of RFC 821? As an MTA
implementor, I have _many_ things higher on my todo list than 8BITMIME.
(In fact, I haven't gotten around to any ESMTP features yet, and until I
implement ESMTP's extended MAIL FROM and RCPT TO parsing I can't legally
support EHLO. See section 6.1 of the ESMTP spec.)

>    [ ] use of 822 as a message submission protocol 
>        (derivation of an envelope from the header, bcc handling, etc.)

Data point: When my MTA (more precisely, MHA = header agent, between the
MUA and the MTA) is fed a message with no recipient fields other than
Bcc, it generates a new

   Cc: recipient list not shown: ;

field. sendmail 8.7 can be configured to do something similar.

>    [ ] which syntax to use for ipv6 domain literals:
>        user@[ip6.abcd.ef01.2345.6789]

Is there some reason you're breaking with tradition? What's wrong with
user@[171.205.239.1.35.69.103.137]?

>    [ ] language for EXPN and VRFY

Here's a suggestion: Scrap 'em. My comments elsewhere on this topic:

: RFC 1123 requires VRFY support, but says that it's okay if an
: implementation can be configured to not allow VRFY. qmail-smtpd doesn't
: allow VRFY. If you desperately want your SMTP server (i.e., inetd) to
: support VRFY, just compile and install sendmail. Were the RFC 1123
: writers aware of the as-if principle of interface specification? ...
: They say that VRFY and EXPN are important for tracking down cross-host
: mailing list loops. Catch up to the 1990s, guys: with Delivered-To,
: mailing list loops do absolutely no damage, _and_ one of the list
: administrators gets a bounce that shows exactly how the loop occurred.
: Solve the problem, not the symptom.

---Dan