Message-Id: <199512070127.TAA01212@jean-baptiste.internetMCI.ietf.org>
To: Robert Elz <kre@munnari.oz.au>
From: Eric Allman <eric@reference.com>
cc: drums@cs.utk.edu
Subject: Re: comments on draft-ietf-drums-smtpupd-01.txt 
In-reply-to: Mail from Robert Elz <kre@munnari.OZ.AU> 
	dated Thu, 07 Dec 1995 10:17:13 +1100
	<4519.818291833@munnari.OZ.AU> 
Date: Wed, 06 Dec 1995 19:27:33 -0600
Sender: eric@CS.Berkeley.EDU

Re:
: From:  Robert Elz <kre@munnari.OZ.AU>
: Subject:  Re: comments on draft-ietf-drums-smtpupd-01.txt 
: Date:  Thu, 07 Dec 1995 10:17:13 +1100

:     Date:        Wed, 06 Dec 1995 12:39:26 -0600
:     From:        Eric Allman <eric@sendmail.org>
:     Message-ID:  <199512061839.MAA01027@jean-baptiste.internetMCI.ietf.org>
:
:     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...

You make an interesting point.  After all, all clients must be
prepared to deal with the possibility of a network failure that will
cause the connection to terminate with extreme prejudice.

: Again, while here, let me also say I very much dislike 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.

Every message has a size....

:     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.

Yes, later on in the draft.  But it is elsewhere in the draft (I
think under Security Considerations).  Even if this section just
adds ``(but see the discussion under Security Considerations)''
the draft would be improved.

: 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!

I like history too, but I think the dates should at least be changed
to use 4-digit year syntax.

eric