To: "D. J. Bernstein" <djb@cr.yp.to>
Cc: drums@cs.utk.edu
Subject: Re: SMTP WG Last-Call
From: "Nick Shelness/SSW/Lotus" <shelness@lotus.com>
Message-ID: <OF25C4A745.AA8204AE-ON80256923.00290F6F@lotus.com>
Date: Fri, 21 Jul 2000 05:39:05 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Dan,

Now that you have now produced a list of concerns minus personal attacks, 
I will respond.

1.
>   In reality, for interoperability with existing clients, servers
>   recognize \012 as a line terminator ...

This is true, but is independent of whether it should be required under 
the standard. I believe that we reached rough consensus that under the 
standard, <CRLF> be the only valid command terminator.

2.
>   In reality, for interoperability with existing clients, servers
>   accept (for example) EHLO requests containing underscores. ...

Again, this is true, but is independent of whether it should be required 
under the standard. I believe that we reached consensus that under the 
standard EHLO requests MUST NOT contain underscores.

3.
>   In reality, if an SMTP client is in the middle of sending a message,
>   and is unable to read the next portion of the message from disk, it
>   ruthlessly closes the connection. ...

Again, this is true, and the standard should and does state what a server 
and client should do when a connection is closed prior to the transmission 
of a QUIT and receipt of a QUIT response.

To that end, I think that the text in the final paragraph of section 3.9 
(the only one that addresses client behavior) could be expanded slightly 
to make it clear that there are environmental circumstances (in addition 
to those listed) beyond a client's control that may require it to 
terminate a connection. For example,

   SMTP clients that experience events beyond their control, such as an 
   unrecoverable disk read failure, a notification of impeding system 
   shutdown,> a connection close, a connection reset, or other type
   communications failure (in violation of the intent of this 
   specification but sometimes unavoidable) SHOULD, to maintain the 
   robustness of the mail system, treat the mail transaction as if a 451 
   response had been received and act accordingly.

But fundamentally, this was never at issue. What was at issue is whether 
it was valid under the standard for a client to tear down a connection 
after receiving a positive response to a <CRLF> . <CRLF> and with out 
sending a QUIT and receiving a response. Again, I believe that rough 
consensus was reached that it was not.

4.
>   In reality, as of 1999, approximately 90% of the servers that support
>   both VRFY and EHLO do not list VRFY in response to EHLO. ...

So. There was no rough consensus that VRFY and/or EXPN be dropped from the 
standard. I would quite happily see them both dropped, but there wasn't 
enough support to do so. What there was rough consensus on was, that under 
RFC 821bis servers that support EHLO and VRFY MUST announce VRFY support 
in an EHLO response.

5.
>   In reality, servers that do not support EHLO are still able to
>   receive mail. ...

Absolutely, but again there was rough consensus that RFC 821bis should 
encourage the infrastructure to move to employing EHLO in place of HELO.

6.
 >  In reality, clients that have no need for extensions can and should
 >  start with HELO; EHLO adds quite a bit of unnecessary complexity. ...

I have no objection to your use of the word "can", but again there was 
rough consensus that RFC 821bis should encourage the infrastructure to 
move to employing EHLO in place of HELO.

7.
>   In reality, EXPN is obsolete. Thousands of the most heavily used mail
>   servers on the Internet always respond 502 to EXPN. ...

See my response to 4. above

8.
>  In reality, VRFY is obsolete. Thousands of the most heavily used mail
>  servers on the Internet always respond 252 to VRFY. ...

See my response to 4. above

9.
>   In reality, thousands of SMTP clients close the connection
>   immediately after sending QUIT. ...

See my response to 3. above.

10.
>   In reality, connections are abruptly dropped for a wide variety of
>   reasons, including server shutdowns. ...

Absolutely. See my response to 3 above. The question is whether, in the 
absence of abnormal events beyond the control of an SMTP client or server 
task, it is valid under the standard to drop a connection prior to a 
client sending a QUIT and receiving a response. Again, there was not rough 
consensus to make such a change from RFC 821. 

11.
>   In reality, firewalls and POP toasters do not, and should not,
>   support mailing lists. ...

In the case of firewalls, as long as they are completely transparent at 
the connection and command level to an SMTP client and server, RFC 821bis 
is silent as it should be. Where an SMTP relay is deployed as a firewall, 
then it SHOULD (MUST?) comply with the standard. POP toasters are beyond 
the scope of drums.

12.
>   In reality, thousands of SMTP servers ignore such parameters. ...

Yes, but?

13.
>  In reality, firewalls and POP toasters often run pure SMTP servers.
>  They do not send mail through SMTP, and they are not expected to
>  support any SMTP client features. Installing unused code is a
>  violation of some corporate security policies. ...

RFC 821bis describes on the wire behavior. Thus, an SMTP server need only 
support on the wire RFC 821bis server features, and an SMTP client need 
only support on the wire RFC 821bis client features. Where's the problem?

14.
>   In reality, many relays support other protocols for transferring
>   Internet mail messages, such as QMTP. ...

Certainly true, though within the nomenclature of RFC 821bis these would 
be gateways rather than relays. They may be completely transparent 
gateways, but they are gateways none the less. Gateway behavior beyond 
their SMTP client or server behavior is not within the scope of RFC 821bis

15.
>   In reality, there are many common non-MIME body structures. ...

This is also true, but again rough consensus was reached within the 
working group that RCF 821bis and 822bis should strongly encourage the use 
of MIME, to the exclusion of all other body structures.

16.
>   In reality, there will be a year 10000. 

Yup

17.
> You think these are ``opinions''?

In general you state a fact (a reality in your terminology). This is then 
almost always followed by an opinion. I think that Keith was referring to 
your opinions as opinions. Your facts are certainly facts.

Nick

Nick Shelness, IBM Fellow
Chief Technology Officer
Lotus Development Corp
Tel: (617) 693-7484

Assistant: Mary McGurran
Tel: (617) 693-4321