ietf-nntp Draft 20 pre-release 2

[Ken Murchison]

Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>You do not HAVE to send either.  Its recommended for the client to
>>announce itself to the server using one or the other, but not required.
> 
> 
> RFC 2821, section 4.1.1.1:
> 
>    [...] In any event, a client MUST issue HELO or EHLO before starting a
>    mail transaction.

My bad.  I read through the doc earlier today and could have sworn that 
it was optional.  I know for a fact that a default Sendmail install will 
allow mail to be submitted/relayed w/o HELO or EHLO.

> Yeah, I'm rather worried about that myself.  It's one of the reasons why I
> hate to revisit old discussions, but I do understand that the security
> extensions cannot be cached.  It's also part of the reason why this has
> taken so long.

Sorry about that.  I pointed Rob and Mark Crispin at section 11.6 to see 
if they were comfortable with it (since I know that they don't frequent 
the list), and neither were.  Rob decided to respond immediately, and 
Mark is waiting for IESG review.

> In the interest of expediency, I'm willing to go along with just outlawing
> all caching of the results of LIST EXTENSIONS.  I really want to get this
> document out the door.  I think we'll catch grief about it from news
> authors during last call, but it may be less grief than we catch from IESG
> review, and whatever gets the document done faster is better as far as I'm
> concerned.

Your call as you're the WG chair.  I'm sure that you're aware that this 
will most likely come up again during the IESG review, especially if 
more of the "evil mail folks" get involved.  ;)

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp