To: Eric Allman <eric@sendmail.org>
Cc: drums@cs.utk.edu
Subject: Re: comments on draft-ietf-drums-smtpupd-01.txt 
In-Reply-To: Your message of "Wed, 06 Dec 1995 12:39:26 MDT."
             <199512061839.MAA01027@jean-baptiste.internetMCI.ietf.org> 
Date: Thu, 07 Dec 1995 10:17:13 +1100
Message-Id: <4519.818291833@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>


    My suggestion is to have EXPN return the internal form,
    even if that doesn't make sense from another host

Violent agreement.   Lots of noisey applause...
    
    Section 3.10.  I don't see any advantage to adding a new 5yz code
    for idle shutdown.

I agree.  I'll also add here that I was slightly disturbed to see
the language in the draft deprecating servers going away.  Thanks
all the same, but when I want my server to simply exit, it WILL
(magic language there) simply exit...

    Section 4.1.1.1 seems to imply that HELO/EHLO imply RSET,

I saw that too, and thought that was perhaps simply old behaviour
I had not noticed before.  However if Eric has not noticed it
either, then it is probably new, in which case I disagree with it.
RSET has a purpose, lets leave RSET to achieve the purpose of reset,
and not attempt to optimise it away (the few cases where it is ever
needed anyway can tolerate one extra command).

Again, while here, let me also say I very much like the emphasis
towards EHLO over HELO - I would have come to this in the meeting
the other day had we had time, and still might on Friday, if there
is time.  If a client is not planning on using any of the new
extended SMTP functionality, EHLO is of no benefit to it at all,
and possibly incurs the cost of an EHLO rejection to which a
HELO must be sent instead.   This is absurd, if I don't need EHLO,
send HELO instead, send EHLO only when EHLO functionality is
planned to be used if available.
    I had the impression from Stockholm that the WG had consensus to drop
    the NUL byte from the list of legal characters (that is, in the <x>
    non-terminal).

Then general "all 128 characters are legal" is plainly absurd.
Not only is null practically unworkable (mailers simply don't
implement it), but various combinations of \r \n (<CR> <LF>)
are also problematic.  There is no point attempting to legislate
these away.   SMTP is line based, not stream based, and will
remain that way.  There is really little point attempt to get
all 128 7 bit characters through, that is still not binary, and we
know we don't have that.  We need encoding to get characters >127
through SMTP (extensions excepted), we may as well use the encoding
for the other problem cases as well, in those few occasions when
they are needed.

    Section 4.4 says that the ``FOR field MAY contain a list of <path>
    entries when multiple RCPT commands have been given.''  [...]
    Second, this may expose Bcc: recipients.

I think there is a comment about this somewhere.
    
    Section 5.2 suggests that examination of Received: lines for the
    domain name is effective for preventing loops.  However, this is
    not reliable.

It will work iff the address (FOR <foo>) is added to the received,
giving up any bcc hiding, and the address currently to be
dispatched to is compared with the address in the FOR field of the
Received header.   Frankly, counting Received's seems about as
likely to work to me.

kre

ps: I quite like the draft using examples from the early 80's.
I'd keep it with examples showing mail to POSTEL@USC-ISIF.ARPA
that is all legal syntax (any examples showing mail to
postel@USC-ISIF I would change), it is also a nice reference
to history.  Leave that stuff alone.  Similarly, leave the dates
in the headers as they are!