Subject: SMTP WG Last-Call

From: DRUMS WG Chair <[email-masked]>
Date: Wed, 19 Jul 2000 16:22:10 -0700

This is the WG last call on draft-ietf-drums-smtpupd-12.txt.  Please read 
this draft.  Unless I hear significant objections in the next week, I will 
consider this draft the rough concensus of this working group and will ask 
for an IETF-wide last call for Proposed Standard status.

		- DRUMS WG Chair

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jul 2000 00:14:01 -0000

My web page http://cr.yp.to/smtp/klensin.html contains many objections
to this draft. A copy of the text appears below.

(Procedural notes: I have raised all of these objections before. In at
least two cases, there is already overwhelming evidence that Klensin's
position is not the consensus of the working group:

   http://cr.yp.to/smtp/drums/19990215054214-9088-qmail@cr-yp-to
   http://cr.yp.to/djbdns/namedroppers/20000204012814-28947-qmail@cr-yp-to

I'd rather discuss content than procedure. Unfortunately, certain people
habitually try to destroy productive discussions by claiming, falsely,
that there's consensus against my objections. So I feel compelled to
preemptively point out these two clearly established counterexamples.)

---Dan

smtpupd-10 was released in February 1999. This page is a list of
problems in smtpupd-10. I've excluded issues of procedure, document
organization, and 8-bit mail.

smtpupd-11 was released in March 2000. As far as I can tell, none
of these problems were fixed.

smtpupd-12 was released in July 2000. Two problems were fixed, as
noted below.

Interoperability failures in smtpupd-10
---------------------------------------

Klensin says that a client without a name registered in DNS
        SHOULD send an address literal ... optionally followed by
        information that will help to identify the client system
in HELO. The address literal is fine; a bracketed IP address is a
valid RFC 821 domain, and any server that rejected it would be
violating RFC 1123, section 5.2.5. However, ``information that will
help to identify the client system'' is a Klensin invention that
creates new interoperability problems. Clients that send such
information will find themselves completely unable to send mail to
some hosts.

Klensin says that servers ``MUST NOT recognize'' anything other
than \015\012 as a line terminator. In reality, for interoperability
with existing clients, servers recognize \012 as a line terminator
for client requests. Clients do not (and, in practice, cannot) use
\012 inside requests except as a line terminator.

Klensin says that SMTP servers ``MUST reject'' requests containing
underscores or other ``illegal character codes.'' In reality, for
interoperability with existing clients, servers accept (for example)
EHLO requests containing underscores.

Klensin has extended the Received-line syntax to allow fractional
seconds. This breaks some Received-line parsers. This problem was
fixed in smtpupd-12.

There are dozens of other interoperability issues where Klensin
does not give adequate warning to future implementors.

Safe behavior prohibited by smtpupd-10
--------------------------------------

Klensin says
        Only resolvable, fully-qualified, domain names (FQDNs) are
        permitted when domain names are used in SMTP.
This prohibits the behavior of many existing clients: for example,
a client relaying a message to a smarthost is violating the protocol
if the user typed an address incorrectly. Obeying Klensin's requirement
means checking every address in DNS. This is an unacceptable policy
violation at some corporate sites, an unacceptable expense for many
dumb clients, and an unacceptable obstacle for the vast majority
of users when their ISPs are temporarily unable to reach the rest
of the Internet. The requirement also prohibits the standard use
of domain literals as specified in RFC 1123.

Modern MTAs send ``double-bounce'' notifications to the local
postmaster when a bounce message is undeliverable. Klensin has three
requirements saying that this ``MUST NOT'' be done; only one of the
requirements has a relevant exception.

Klensin says that an SMTP client ``MUST NOT intentionally close the
transmission channel until it sends a QUIT command.'' 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. Sending QUIT in this situation
means sending a corrupted message.

Klensin says that VRFY ``MUST be listed ... in an EHLO response''
if it is supported. In reality, as of 1999, approximately 90% of
the servers that support both VRFY and EHLO do not list VRFY in
response to EHLO. If a client wants to use VRFY for some reason,
it simply tries the VRFY command, as per RFC 821; paying attention
to the EHLO response would be foolish. There's no reason to require
an announcement.

Klensin says that SMTP clients ``MUST NOT'' send message data unless
the response to DATA is 354. This prohibits the behavior of many
existing clients: if a server (in violation of RFC 821) sends (e.g.)
a 387 reply, these clients will (as encouraged by RFC 821) treat
387 the same way as 354. The correct rule is that clients must not
send message data if the reply begins with 4 or 5.

Klensin says that servers ``MUST support the EHLO command even if
they do not implement any specific extensions.'' In reality, servers
that do not support EHLO are still able to receive mail. If a server
does not support any extensions, its only benefit from supporting
EHLO is to save a small amount of time for clients that start with
EHLO. This is enough of a benefit for me to recommend that all
servers support EHLO, but there is no interoperability excuse for
requiring it.

Klensin says
        Servers MUST NOT return the extended EHLO-style response
        to a HELO command.
It is unclear what this means. Some obvious interpretations prohibit
the behavior of existing hosts.

Klensin says
        Whatever mechanisms are used, servers MUST contain provisions
        for detecting and stopping trivial loops.
It is horrendously unclear what this means. Some obvious interpretations
prohibit the behavior of existing hosts.

Safe behavior discouraged by smtpupd-10
---------------------------------------

An essential element of a proper multidrop POP mailbox delivery is
that the (single) envelope recipient is copied to a header field
in the message, typically Delivered-To. However, Klensin says
        SMTP clients and servers SHOULD NOT copy the full set of
        RCPT TO command arguments into the headers, either as part
        of trace headers or as informational or private-extension
        headers.
Klensin says that this ``requirement'' should be violated ``only
under exceptional and well-understood circumstances''; Klensin
claims that MTAs that use Delivered-To may not ``interoperate
properly'' unless ``great care is taken.'' This is garbage. Klensin's
alleged justification---namely, that such copying ``defeats the
purpose'' of mailing lists and blind carbon copies---is completely
incorrect for a message being delivered to one recipient at a time.

The normal behavior of part-time dialup hosts and dumb clients is
to connect to a relay identified by name (or sometimes IP address).
Klensin says that clients that use relays ``SHOULD'' instead perform
MX lookups on the relay name. Klensin says that this ``requirement''
should be violated ``only under exceptional and well-understood
circumstances''; Klensin claims that clients using the normal
procedure may not ``interoperate properly'' unless ``great care is
taken.'' This is garbage. There is no reason to demand that these
clients use MX lookups.

Klensin says that clients ``SHOULD preferentially utilize EHLO
rather than HELO.'' Klensin says that this ``requirement'' should
be violated ``only under exceptional and well-understood circumstances'';
Klensin claims that clients starting with HELO may not ``interoperate
properly'' unless ``great care is taken.'' This is garbage. In
reality, clients that have no need for extensions can and should
start with HELO; EHLO adds quite a bit of unnecessary complexity.
Of course, clients that want to use extensions will start with EHLO.

Klensin says that SMTP servers ``SHOULD support EXPN.'' Klensin
says that this ``requirement'' should be violated ``only under
exceptional and well-understood circumstances''; Klensin claims
that SMTP servers that always respond 502 to EXPN may not ``interoperate
properly'' unless ``great care is taken.'' This is garbage. In
reality, EXPN is obsolete. Thousands of the most heavily used mail
servers on the Internet always respond 502 to EXPN.

Klensin says that SMTP servers ``SHOULD support VRFY''; this means
``at least recognition of local mailboxes.'' Klensin says that this
``requirement'' should be violated ``only under exceptional and
well-understood circumstances''; Klensin claims that SMTP servers
that always respond 252 to VRFY may not ``interoperate properly''
unless ``great care is taken.'' This is garbage. In reality, VRFY
is obsolete. Thousands of the most heavily used mail servers on the
Internet always respond 252 to VRFY.

Klensin says that an SMTP client ``SHOULD'' wait until it receives
the reply to QUIT before closing a connection. Klensin says that
this ``requirement'' should be violated ``only under exceptional
and well-understood circumstances''; Klensin claims that clients
closing the connection immediately after sending QUIT may not
``interoperate properly'' unless ``great care is taken.'' This is
garbage. In reality, thousands of SMTP clients close the connection
immediately after sending QUIT. There is no reason to wait for the
response.

Klensin says that an SMTP server ``SHOULD attempt to send a line
containing a 421 response code'' if it is shut down by the system
administrator. Klensin says that this ``requirement'' should be
violated ``only under exceptional and well-understood circumstances'';
Klensin claims that servers that simply close the connection may
not ``interoperate properly'' unless ``great care is taken.'' This
is garbage. In reality, connections are abruptly dropped for a wide
variety of reasons, including server shutdowns.

Klensin says that every ``SMTP-capable host SHOULD support both the
alias and the list models of address expansion for multiple delivery.''
Klensin says that this ``requirement'' should be violated ``only
under exceptional and well-understood circumstances''; Klensin
claims that servers that don't support mailing lists may not
``interoperate properly'' unless ``great care is taken.'' This is
garbage. In reality, firewalls and POP toasters do not, and should
not, support mailing lists.

Klensin says that SMTP servers ``SHOULD reject'' parameters in RSET,
DATA, or QUIT. Klensin says that this ``requirement'' should be
violated ``only under exceptional and well-understood circumstances'';
Klensin claims that servers that ignore such parameters may not
``interoperate properly'' unless ``great care is taken.'' This is
garbage. In reality, thousands of SMTP servers ignore such parameters.

Klensin says that all ``fully-capable SMTP implementations'' are
``expected to support'' various client features. This is garbage.
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.

Other misleading statements in smtpupd-10
-----------------------------------------

sendmail rewrites messages received through SMTP. Klensin claims
that this behavior was ``in response to weak SMTP clients'' that
generated incomplete messages. That's backwards. First sendmail was
designed to feed all messages, whether received locally or via SMTP,
through the same rewriting and routing mechanisms. Then people took
advantage of this and wrote dumb clients.

Klensin claims that, ``in most cases,'' SMTP clients that send all
mail through a relay host neglect to retry delivery after failures.
This might be true for some dumb clients but it's certainly not
true for serious MTAs such as sendmail.

Klensin defines ``relays'' as receiving mail by SMTP and forwarding
mail by SMTP. In reality, many relays support other protocols for
transferring Internet mail messages, such as QMTP. (These relays
generally do not change message formats, so they do not fit Klensin's
``gateway'' requirements.)

Klensin says that ``the [message] body, if structured, is defined
according to MIME.'' In reality, there are many common non-MIME
body structures.

Klensin's document begins the same way as the original SMTP
specification, RFC 821, written in 1982:
        The objective of the Simple Mail Transfer Protocol (SMTP)
        is to transfer mail reliably and efficiently.
Unfortunately, SMTP does not achieve this objective. It is painfully
slow; more importantly, its design has led to a string of
interoperability disasters.

Klensin requires that years contain at most four digits. In reality,
there will be a year 10000. This problem was fixed in smtpupd-12.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jul 2000 09:42:56 +0900

>I'd rather discuss content than procedure. Unfortunately, certain people

just to provide a quick, public, on-the-record counterpoint:

         The objection being raised is noteworthy for pointedly 
personalizing the target of the objection.  That fact highlights its 
primary failing, since the working group has had to respond to the many, 
cited objections before.

         The working group has been diligent to evaluate these objections, 
even to the *strategic* detriment of making progress.

         Whatever the remaining objections, they are the position of only 
one working group participant, and they run contrary to well-established 
*working group* consensus, contrary to the claim.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Philip Hazel <[email-masked]>
Date: Thu, 20 Jul 2000 09:39:33 +0100 (BST)

> *working group* consensus, contrary to the claim.

To keep the record straight, let me record here that there are several 
of Dan's points with which I entirely agree. So it isn't just one 
participant, it's at least two. And, like Dan, I am an MTA implementor.

I have to confess that I decided to give up trying to argue these points
in the face of apparently overwhelming opposition. They include the
8-bit thing, which he does not mention in his message. The other major
points with which I agree are:

  In reality, for interoperability with existing clients, servers
  recognize \012 as a line terminator for client requests. Clients do not
  (and, in practice, cannot) use \012 inside requests except as a line
  terminator.

  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. Sending QUIT in this situation means
  sending a corrupted message.

  If a client wants to use VRFY for some reason, it simply tries the VRFY
  command, as per RFC 821; paying attention to the EHLO response would be
  foolish. There's no reason to require an announcement.

  The correct rule is that clients must not send message data if the
  reply begins with 4 or 5.
  
Actually, I would say that the correct rule is that clients must not 
send data unless the reply begins with 3. 

  Servers MUST NOT return the extended EHLO-style response to a HELO
  command. It is unclear what this means. Some obvious interpretations
  prohibit the behavior of existing hosts.
  
It is indeed unclear what this means, since a multi-line response to 
HELO is permitted. 

  In reality, EXPN is obsolete.

  In reality, VRFY is obsolete.

  In reality, thousands of SMTP clients close the connection immediately
  after sending QUIT. There is no reason to wait for the response.
  
... provided that this does not screw things up because of the way the 
TCP/IP stack works on the operating system. Unix is a safe system in 
this respect.

  In reality, connections are abruptly dropped for a wide variety of
  reasons, including server shutdowns.
  
Are there any MTAs that interwork with the "shutdown" command to support 
what the draft says?

  In reality, firewalls and POP toasters do not, and should not, support
  mailing lists.
  
I see no reason to mention aliasing and mailing list expansion in the
document that defines SMTP. These activities are things that go on 
inside an MTA after it has received a message and don't seem to me to 
have anything to do with a message transfer protocol. The problem is
that the document contains material about the way "common" MTAs actually
work - useful stuff that certainly should be written somewhere - but
there are plenty of situations that are "uncommon".
 
Some other comments of Dan's are valid points, IMHO, but I don't think
they are a problem, because they refer to situations where a client is
passing data to a known, fixed host (e.g. dial-up client to smarthost).
In those cases, the client and server are obviously allowed to use
whatever protocol they fancy, and "not-quite-public-SMTP" is an obvious
choice. But maybe that could be said somewhere.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: Dave Sill <[email-masked]>
Date: Thu, 20 Jul 2000 08:45:28 -0400 (EDT)

>*working group* consensus, contrary to the claim.

I agree with Dan's objections. I've been here nearly two years and I
don't recall seeing clear consensus against any of them.

-Dave

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jul 2000 22:59:16 +0900

>To keep the record straight, let me record here that there are several

several.  yes.  my language was sloppily absolute.  several, however, is a 
small number from the set.

>participant, it's at least two. And, like Dan, I am an MTA implementor.

two, yes.  and a third has chimed in.

again I used absolute language and should have been more 
"proportional".  so far, the 2 statements in support of some of Dan's 
concerns substantiate my primary observation about lack of substantial 
support for those concerns.

That is, working group consensus was consistently and massively against 
those concerns.

d/

=-=-=-=-=

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Jul 2000 12:45:46 -0400

I'm always amused (not) when Dan calls his own opinions "reality" and
characterizes the opinions of the docuent editor as if they were
purely personal opinions ("Klensin says...") rather than representing
the group.  It's the document editor's job to state concrete positions
on subtle issues and see whether the working group supports those 
positions.  While it's certainly okay for WG participants to object
to the language in a document, Dan's efforts to personally target the 
editor are inexcusable. 

having said that, I do agree with Dan on some points.

> Interoperability failures in smtpupd-10

IIRC, the WG discussed this at one point and came up with some language
very similar to the current smtpupd draft.  However, I also have a 
problem with the notion that the client can send something which is
not syntactically compatible with a domain here (or an address literal),
as it seems likely to break compatibility with existing servers that 
quite legitimately expect a domain.

Note that section 3.6 says that the host must use either a domain name
or an address literal.  they need to be consistent.

I think the HELO/EHLO argument needs to be
a) the FQDN if known, else
b) the client's IP address literal, if available, else
c) some string which is syntactically compatible with a domain name
   but unlikely to be confused with a "real" domain name.

> \012 inside requests except as a line terminator.

Despite the fact that some broken clients send LF-terminated commands,
I'm comfortable with "MUST NOT recognize" in this case.  A server which
accepts LF as a terminator introduces the possibility of synchronization 
errors.  While such errors are rare, they have been observed in practice.

> EHLO requests containing underscores.

aside: Just because some servers accept such requests does not mean 
that the standard should endorse such behavior.  The purpose of a 
standard is to specify how things should behave, not to document 
all of the brain-damage that has been observed.

I can live with ``MUST reject'' here.  However given that the EHLO
and HELO domains typically aren't used for anything other than to
put into received header fields, and their use there has marginal
utility, MUST seems a bit strong to me.
 
> This prohibits the behavior of many existing clients: 

So be it.  Those clients are not following the standard.  smtpupd
doesn't say that the server has to reject such messages; it just says
that such messages are not permitted *by the standard*.

I suppose one could interpret "Only...are permitted" as saying that the
server should not accept such messages or that the client must check
all domains before sending a message.  If so then a slight rewording
could be useful.  It seems entirely appropriate to say that the use of 
anything besides an FQDN is an error.  However, I would not say that 
doing so is a violation of the standard as long as the name is in
legal FQDN (or domain literal) syntax.  

so I would recommend changing the text to say that the use of non-FQDNs
is an error, rather than to say that such things MUST NOT be sent.

> means sending a corrupted message.

the correct thing is to say that the SMTP client SHOULD send QUIT under
normal conditions; simply omitting QUIT is a violation of the standard.
if it is necessary to abort sending a message in a DATA phase, the 
client MUST close the connection (there's no other way to do it).   

finally a client that aborts a connection without sending QUIT 
MUST NOT treat the messages which were transmitted in that session as 
if they were transferred to the server.

> to the EHLO response would be foolish. There's no reason to require

the purpose of the standard is to describe how things should work,
not to describe reality.  however I don't know of any reason for
a MUST requirement to list VRFY.  especially given that normal clients
shouldn't be using VRFY anyway ... these days, VRFY is for debugging.

> send message data if the reply begins with 4 or 5.

the correct rule is that the DATA response must begin with 3.

> they do not implement any specific extensions.'' 

this is entirely appropriate.   the implementation burden is small.

> the behavior of existing hosts.

since the EHLO response should be legal for HELO also (can be 
multi-line, is syntactically compatible, reply code is the same), 
I don't see any reason for this prohibition.

if we want to say that HELO responses should be single-line, say that,
rather than saying it should not be the same as EHLO.

> prohibit the behavior of existing hosts.

I would say "servers that relay or forward messages to other servers".
some servers cannot cause loops.

this might be a good use of SHOULD.

> Safe behavior discouraged by smtpupd-10

should be reworded to say 'servers MUST NOT inculude any envelope 
recipient address obtained from a RCPT TO command in a message 
header generated by the server, except that a copy of a message 
delivered to a particular recipient the message header MAY disclose 
the recipient address(es) which caused the message to be delivered to
that recipient.

> MX lookups on the relay name. 

we need to distinguish between clients that forward all messages
of unknown destination to a smart relay (i.e. they have a "default
route"), and relays that route messages to their destinations 
over the Internet.  The latter MUST use MX records, or address records
if MX records are not found.  The former don't need DNS except
to find the smart relay. 

> start with HELO; EHLO adds quite a bit of unnecessary complexity.

actually, that's false - the client has to be prepared to see a 
multiline response even if it sends HELO.  just because the
client sends EHLO doesn't mean that it has to parse the response,
beyond the normal SMTP framing, if it's not going to use any
extensions.

there may be some extensions that all clients SHOULD implement,
but I don't know of any reason for a client to send EHLO if it
doesn't implement any extensions.
 
> Klensin says that SMTP servers ``SHOULD support EXPN.'' 

I take this to mean that a server SHOULD implement EXPN if it
implements forwarding or mailing lists, but it MAY be configured 
to always return "sorry, not going to give this to you".  (it 
probably SHOULD be shipped with "no access" being the default)

at any rate I think this is a confusion between requirements on
the implementaion and requirements on operation - the SHOULD
in this case is a requirement of the implementation.

> Klensin says that SMTP servers ``SHOULD support VRFY''

similar reasoning to EXPN.

> the reply to QUIT before closing a connection. 

since it's a SHOULD, I don't have a problem with this.

> administrator. 

seems reasonable.  some network stacks are better than others at
detecting shutdown connections and delivering the news to the application.

> alias and the list models of address expansion for multiple delivery.''

I don't have a problem with SHOULD.  I think the assumption is that
a SMTP-capable host is a normal MTA with normal MTA functions, rather
than some sort of specialized MTA that doesn't implement aliases
and mailing lists.  it wouldn't hurt to state this explicitly, though.

> DATA, or QUIT. 

I don't have a problem with this at all; clients that supply parameters
to these commands may be expecting behavior that the server is not 
prepared to support.

> In reality, firewalls and POP toasters often run pure SMTP servers.

I don't think of firewalls and POP toasters as 'fully-capable SMTP
implementations'.  the wording could be better, but it's hard to nail 
down definitions for all types of SMTP implementations of interest.

> advantage of this and wrote dumb clients.

since sendmail and its rewriting behavior predate SMTP, sendmail's
rewrite capability obviously was not in response to weak SMTP
clients.  on the other hand, sendmail's rewriting has often been
used in an attempt to fix weak clients and client writers have become
accustomed to this.  this situation should be rectified.

so a slight rewording might be in order.

> true for serious MTAs such as sendmail.

depends on what you mean by 'client'.  'user agent' might be a better term.

> according to MIME.'' In reality, there are many common non-MIME

I don't see any harm in providing a reference to the MIME spec.
a lot of first-time readers have a hard time figuring out how
the pieces fit together.

> Unfortunately, SMTP does not achieve this objective. 

depends on what you're comparing it with.  it's certainly more reliable
and efficient than X.400.  there's certainly room for improvement.
I would say that SMTP is designed for reliability; the interoperability
problems have generally been the result of poor implementation and
failure to implement the spec rather than poor design.  SMTP doesn't
seem terribly efficient given todays network speeds (has too many
round-trips) but the per-recipient verification was in fact an 
efficiency consideration - attempting to avoid transferring messages
and nondelivery reports over the net for non-existent recipients.
the thing that's missing from this statement is that SMTP was
designed to be reasonably simple, hence the lock-step request-response model.

anyway I don't think it's necessary to fix this text.

Keith

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Jul 2000 10:51:26 -0700

I generally agree with Keith Moore.   We've been around this block
before, but nevertheless, this is the time in our process for
objections.  Consider this note largely speaking an endorsement of
the document, but one or two touch-ups would be nice.

There are two generic themes to Dan Bernstein's note.

The first is that he offensively uses the term "Klensin says" when in
reality John has done an extraordinary job of bringing together
different views for what amounts to the singularly most visible project
since IPng or HTTP1.1.  I agree with others that I find it hard to
navigate through such ad hominem (doubly so when I might agree with one
of his points).

The second is that Mr. Bernstein hides behind the phrase "breaks
existing implementations".  Some behavior is simply wrong and to do
otherwise would cause MORE interoperability problems.  The goal of the
document is to improve interoperability.  There is a natural tendency to
test against existing implementations.  However, we must avoid leaving
sufficient ambiguity in the text that several independent
implementations could be developed such that it would be impossible to
interoperate amongst the group.  A clean and clear spec. with as little
wiggle room as possible is the best solution to this problem.

By the way, Bernstein's own mailer is notoriously broken, in as much as
it refuses valid messages from a valid source to a valid destination. 
Playing fast and lose with the rules only further confuses unwitting
civilians for what amount to trivial reasons.

So for the record, in the interests of space and time, unless otherwise
indicated, I fully agree with Keith.  Here are the exceptions and
elaboration.

Dan Bernstein complains 
	about language that says that servers must deal with trivial loops. 
They must.  Because indirection is part and parcel with alias and
mailing list parsing, and because such indirection occurs across
multiple hosts, you need some form of loop detection.  John cites the
obvious method.  However, there are others.  For instance, one can look
to see how many times a message-id was processed over a fixed period of
time or combine that approach with a destination hash.  Each method has
its own pitfalls but is better than nothing.  The wording in the
document demonstrates that this is implementation guidance and not The
Idiot's Guide to SMTP.

Dan Bernstein complains
	that prohibition of the user of VRFY in ESMTP without it being listed
in the EHLO response is foolish, even though this is sound conservative
architecture.  More to the point- programs that attempt to use VRFY
should use EHLO and not bother the server if it's not listed.

Dan Bernstein complains
	that rejection of verbs with excess garbage on them is wrong, when in
reality accepting them may well lead to unforeseen interoperability
problems as well as security risks.  What happens if there is a
collision in the non-standard usage?  That turns into an SMTP
interoperability problem, about which Mr. Bernstein later complains.

In fact, Mr. Bernstein is basing most of his objections on HIS
implementation and not looking beyond it.  The group has rightly looked
beyond one implementation and provided for methods for Mr. Bernstein to
deal with his implementation through the use of X- EHLO extensions.

Dan Bernstein complains
	that the document requires SMTP agents to present themselves as full
implementations.  They should.  Firewalls and "POP toasters" need to
follow the same rules as everyone else so long as connections can occur
in a way that was not pre-arranged.  Consenting adults don't need
standards.

Dan Bernstein complains
	about the definition of mail relays.  That definition is consistent
with what we've said previously.  Mention of QMTP or other protocols
would be at best superfluous and at worst an endorsement of a non-IETF
protocol.

Dan Bernstein complains
	that we only endorse MIME as the structured format.  For
interoperability reasons, we should, especially since it is the ONLY
IETF-endorsed structured format.  Structure is most useful when others
can understand it.  Want to use your own?  That's fine between
consenting adults.

Dan Bernstein complains
	that clients ought not use MX records when connecting to relays.  Why? 
This is a perfectly fine use of an MX record and allows for a very
simple mechanism for MULTIPLE relays with preference indication!  In
fact this point bothers me more than most, since a so-called implementor
is making trade-offs against his potential customers.  Please let there
be no doubt.  When we did RFC 1123 we weighed existing behavior against
potential benefit to the user, and neither side had an infinite amount
of weight.

Dan Bernstein complains
	that the document restricts him from copying envelope information into
the headers.  That is correct, it does, in order to preserve blind
carbon copy functionality.  The reasoning for the objection has to do
with multi-drop POP boxes.  Isn't that POP's failure, not SMTP?  It *is*
possible to preserve envelope information at the end points, and that is
strictly an end implementation decision.

Dan Bernstein complains
	about the desire to move people to ESMTP.  This is important, as more
and more clients move to ESMTP, old code paths are going to get dusty. 
Let's move people away from it sooner than later.  The notion that EHLO
adds excessive complexity is beyond the pale.  Especially in mail relays
the benefits clearly outweigh the costs.  Again, I pretty much agree
with Keith on this point.

And so I find myself in luke warm agreement with Dan Bernstein on
several points, the QUIT businesses being two such points, as previously
mentioned.  VRFY and EXPN should be done away with, since at this point
they can cause more harm than good, and we ought not encourage their
use.  Also, clients MUST send the appropriate code, and servers should
be liberal in honoring 3xx.

Finally, I agree with Dan Bernstein that SMTP is most certainly not the
most efficient protocol.  This follows the rule that specific
optimizations always outperform general optimizations.  SMTP must cover
a broad number of cases and provide interoperability for implementations
stretching back 15 years, a truly honerous task, one that Mr. Bernstein
clearly does not appreciate.

Y10K indeed.  Let's see if we can make it to Y2.037k.
--
Eliot Lear
[email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jul 2000 18:20:11 -0000

Dave Crocker writes:
> they run contrary to well-established *working group* consensus,

There's no nice way to say this: Crocker is lying. He's perfectly aware
that his claimed consensus has _not_ been established. He is, in fact,
trying to _prevent_ the working group from settling these issues.

---Dan

---

From: Dave Sill <[email-masked]>
Date: Thu, 20 Jul 2000 15:00:18 -0400 (EDT)

[email-masked] wrote:

>document is to improve interoperability.

How does a server accepting \012 as a terminator for client requests
harm interoperability? Same thing for servers accepting requests
containing underscores. How is interoperability improved by allowing
only a single "OK" response code to DATA?

>it refuses valid messages from a valid source to a valid destination.

Is that broken? I thought the destination MTA was allowed to bounce
mail to any local address, valid or not. Do you have a pointer to the
section in the draft that disallows bounces to valid addresses from
valid sources? I'm sure the anti-spam crowd will object vocally to
anything that makes bouncing spam illegal. And doesn't this also
prevent servers from using mail quotas?

-Dave

---

From: Philip Hazel <[email-masked]>
Date: Thu, 20 Jul 2000 20:27:23 +0100 (BST)

> if they were transferred to the server.

Surely not? Once a client has received an OK response to the final "." 
for a message, the server takes responsibility, whatever happens, 
doesn't it? Consider:

EHLO
MAIL
RCPT
DATA
message 1
.
MAIL
RCPT
DATA
.... Suppose at this point the client discovers that can't read its disk. 
All it can do is break the the connection, but message 1 is long gone;
the server may even have delivered it already.

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Jul 2000 15:36:12 -0400

> doesn't it? 

sorry, I sent the message prematurely.  I meant to go back and fix this.

I was originally trying to make a case for MUST NOT, but I wasn't 
able to do it. 

Keith

---

From: Michael Scharff <[email-masked]>
Date: Fri, 21 Jul 2000 12:53:52 +0100

Were we to follow the logic that Keith presents, then any messages 
transmitted during a session that did not complete with a proper QUIT would 
be resent. This would result in a harrowing number of duplicate messages 
being received on the recipient side, not to mention the inefficiency of 
such logic on the server end. Most servers I've worked with WILL deliver 
ANY message that was "received" i.e.  a CR/LF . CR/LF was received allowing 
the server to end receipt of that particular message, whether or not a QUIT 
was received to end the session. The reasons for this are numerous, but the 
most obvious is the fact that there are still a very large number of users 
on the internet who establish their connection via Dialup. This is 
unreliable at best, and "drops" in the middle of a session are quite 
frequent. A nightmare in the making so to speak.

Michael Scharff
RealNetworks
[email-masked]

---

From: Michael Scharff <[email-masked]>
Date: Fri, 21 Jul 2000 12:54:42 +0100

Well then, I'll apologize in advance for the message I just sent, reasoning 
why this was such a bad idea

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jul 2000 20:16:38 -0000

> allowing only a single "OK" response code to DATA

Just to clarify: Everyone agrees that the _protocol_ should prohibit the
server from sending, say, 387. The question is whether the _client_ is
permitted to accept 387 from a broken server.

Please be careful to distinguish what the _protocol_ allows the server
to do from what the _client_ might allow the server to do.

If the server sends 387 (bad!), the server is violating RFC 821.

If the client then treats the 387 as 354 (good! this simplifies the
client code, and is encouraged), the client is not violating RFC 821.
But it is violating Klensin's spec.

It's reasonably clear what Klensin was thinking when he wrote this text.
Legitimate servers will occasionally send things like 451 in response to
DATA. Clients have to be ready for this. Sending the message after 4xx
or 5xx would be a disaster. Clients MUST NOT do that.

But Klensin's text is overbroad. He didn't just prohibit sending the
message after 4xx or 5xx. He singled out 354.

Existing clients that treat all 3xx codes the same way (e.g., exim) are
in violation of Klensin's spec. Existing clients that treat all codes
below 400 the same way (e.g., qmail) are in violation of Klensin's spec.

Procedural matters: Klensin made this change from RFC 821 without the
consensus of the working group. When I pointed out Klensin's change more
than a year ago, several people agreed with me that clients shouldn't be
forced to inspect the 54, and nobody disagreed. But the document still
has Klensin's change.

---Dan

---

From: Russ Allbery <[email-masked]>
Date: 20 Jul 2000 15:35:16 -0700

> two, yes.  and a third has chimed in.

Make it four on several of these points.

> That is, working group consensus was consistently and massively against

That is not in agreement with my reading of this working group for the
time that I've been here.  The working group consensus was consistently
and massively against the way in which the concerns were presented, but I
think some of these are good points, and do not have a consensus against
them.

I personally don't have an interest in belaboring these points further
because I think at this stage it's considerably more important to the rest
of the Internet to get an RFC *published* than to deal with these issues,
which I think are by and large minor and can possibly be dealt with in a
later revision.  But I do feel like I have to chime in given the assertion
that no one agreed with any of Dan's points.

If someone wants to try to make minor revisions at this stage, Philip
Hazel's summary is one that I also generally agree with.  If the choice is
to not do that due to how late this is in the process, I also agree with
that.  I've enough experience with IETF working groups to know that if the
goal is to get the RFC perfect, there will never actually be an RFC.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: [email-masked]
Date: Thu, 20 Jul 2000 19:13:56 -0400

> think some of these are good points, and do not have a consensus against

Make it five because I too agree.  Dan's style is deeply obnoxious but some
of his technical points have merit.  We should not succumb to the temptation
to shoot the messenger.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The price of liberty is, always has been, and always will be blood.  The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty.  Are
you free? 
	-- Andrew Ford

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jul 2000 09:09:36 +0900

At 03:35 PM 7/20/00 -0700, Russ Allbery wrote:
>time that I've been here.

Out of curiosity:  Over what proportion of the life of this working group 
have you been monitoring the working group's treatment of input from a 
participant who prefers ad hominems, at the level of calling other 
participants liars and presuming to know their motives, always claiming 
them base?

>The working group consensus was consistently

I am surprised you have not noted the working group's long history of 
trying to wade through the morass of aggressive ad hominems to find an 
occasional gem of valid technical content.  The work of the group has been 
delayed by, perhaps, a year due to this distraction.  As well, the overall 
ability to conduct coherent discussion has been impaired, likely damaging 
the coherence of the resulting document, in spite of considerable effort by 
the editors to counteract the problem.

d/

=-=-=-=-=

---

From: Russ Allbery <[email-masked]>
Date: 20 Jul 2000 18:02:13 -0700

Dave Crocker <[email-masked]> writes:

> Out of curiosity:  Over what proportion of the life of this working
> group have you been monitoring the working group's treatment of input
> from a participant who prefers ad hominems, at the level of calling
> other participants liars and presuming to know their motives, always
> claiming them base?

I think the working group has by and large done a very good job of this.
I didn't mean to imply otherwise.

>> The working group consensus was consistently and massively against the
>> way in which the concerns were presented, but I think some of these are
>> good points, and do not have a consensus against them.

> occasional gem of valid technical content.

I have.  That was precisely my point.  People have objected to the way in
which concerns were presented but have *not* objected to some of the
specific concerns that were raised.  In other words, there has been
working group consensus against the *tone* of some of the discussions
here, but there has *not* been working group consensus against every
proposal raised in an unnecessarily confrontational manner.  Quite to the
contrary, the working group has, in my opinion, done a fairly good job of
separating the content from the presentation.

Accordingly, I don't agree with the statement that there has been an
overwhelming consensus against all of Dan's positions.  I think there is a
consensus against some of them, I think that some of them have been put
aside as good enough and not worth the time to debate further (like
whether clients should be required in the standard to issue QUIT), and I
think that some of them could still be merged into the existing draft.
The ones in the latter category have also been singled out by Keith Moore
and Philip Hazel.

Again, I'm not personally asking that this be done.  I'm content either
way.  As I said, I think the most important goal is to get this draft
finally published, and that the world needs that more than it needs
corrections to how clients are allowed to handle 387.  That's just my
personal opinion.

It is precisely because I *don't* think the working group has overall put
personality above producing a solid technical specification that I can't
agree with your characterization.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Jul 2000 04:08:44 -0000

Keith Moore writes:
  [ about Klensin allowing clients to send 821-violating HELO syntax ]
  [ that some existing servers will reject, destroying mail service ]
> very similar to the current smtpupd draft.

Really? Where exactly can I find that language in the DRUMS archives?

My servers accept all sorts of HELO garbage, of course, so I won't have
problems with clients that use Klensin's extended syntax. But the AOL
servers say

   helo [1.2.3.4] this is a test.
   501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS

and I think it's thoroughly irresponsible to hide this fact from future
implementors.

This is not a minor issue. This is an interoperability disaster. I've
pointed it out repeatedly and it still isn't fixed.

  [ servers accepting \012 as a line terminator for client requests ]
> introduces the possibility of synchronization errors.

No, it doesn't. As I said, clients do not (and, in practice, cannot) use
\012 inside requests except as a line terminator.

  [ Klensin says SMTP servers ``MUST reject'' underscores ]
> The purpose of a standard is to specify how things should behave, not
> to document all of the brain-damage that has been observed.

Please be careful to distinguish _clients sending underscores_ from
_servers accepting underscores_.

The client is violating RFC 821. The server is not violating RFC 821.
The server behavior is good.

Klensin prohibits the server behavior. This is a change from RFC 821.
It's a bad change. It's also a change without working group consensus.

  [ client -> smarthost ---dialup--> ISP, when users mistype domain names ]
> Those clients are not following the standard.

That's ridiculous. The clients don't have any way to check that the
names are valid. The smarthost doesn't offer the feature, and the
client computers don't have their own modems.

The smarthost will eventually bounce the message, because the domain
doesn't exist. Does this mean that the client did something wrong? Of
course not. But Klensin insists that all domain names be ``resolvable.''

> this is entirely appropriate.   the implementation burden is small.

I agree that it's easy to implement. However, that doesn't justify the
requirement. Servers work even if they don't support EHLO.

  [ relays are normally identified by name; ``SHOULD'' use MX instead? ]
> we need to distinguish
  [ dumb clients ]

You misunderstand. Klensin really does think that dumb clients should be
feeding their configured relay names to MX lookups. He even claimed, as
I recall, that this was common MUA behavior.

> > clients that have no need for extensions can and should
> actually, that's false

Actually, what I said is true. Go read the ESMTP specification.
Multiline responses are not the issue.

> I think the assumption is that a SMTP-capable host is a normal MTA

Bad assumption. Many SMTP-capable hosts don't support mailing lists.
Anyway, this is not an interoperability issue.

  [ RSET, DATA, QUIT ]
> clients that supply parameters to these commands may be expecting
> behavior that the server is not prepared to support.

You're talking about noncompliant behavior by nonexistent clients. Who
cares what they expect? Why should we make this change to RFC 821?

> implementations'.

I don't think of sendmail as a fully-capable SMTP implementation. :-)

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Jul 2000 05:31:32 -0000

Eliot Lear writes:
> programs that attempt to use VRFY

No! Programs that want to use VRFY should simply try it. Programs that
behave as you suggest will fail miserably and be discarded by users.

> you need some form of loop detection.

I can't respond to your alleged justifications until I see a coherent
definition of the phrase ``some form of loop detection.''

> Mr. Bernstein is basing most of his objections on HIS implementation

False. Half of my objections are on issues that don't affect my code.
The other half are on issues that affect other people's code too.

> it refuses valid messages from a valid source to a valid destination. 

Huh? I'm under no obligation to accept your messages.

> a so-called implementor

This ``so-called implementor'' wrote an SMTP server now running on more
than one hundred thousand computers around the Internet. 

> offensively uses the term "Klensin says"

Let's try an example:

   Klensin says ``Servers MUST NOT return the extended EHLO-style
   response to a HELO command.''

This is a simple statement of fact about Klensin's document. It seems to
be true. Why do you find it offensive?

You then assert that this is ``ad hominem.'' Here you're simply wrong.
You are, in fact, making a fool of yourself.

> Mr. Bernstein hides behind the phrase "breaks
> otherwise would cause MORE interoperability problems.

I'm not sure what you mean by ``hides'' here. My objections are to

   (1) Klensin requiring or allowing non-interoperable behavior,
   (2) Klensin prohibiting safe behavior,
   (3) Klensin discouraging safe behavior, and
   (4) Klensin misleading readers.

In #1, there's ample evidence that the behavior causes interoperability
failures. Are you seriously suggesting that such breakage be allowed?

In #2 and #3, the behavior is widely used, and there's not a shred of
evidence that it causes interoperability problems. Are you seriously
suggesting that users be forced to install new software for no benefit?

It would help if you focused on concrete examples, instead of referring
to ``some'' unspecified behavior.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Jul 2000 05:51:48 -0000

Keith Moore writes:
> It's the document editor's job to state concrete positions on subtle
> issues and see whether the working group supports those positions.

In a legitimate standards organization, it is the document editor's job
to record the established consensus of the group---and there are
procedures in place to prevent them, and you, from misrepresenting the
conesnsus.

> I'm always amused (not) when Dan calls his own opinions "reality"

Let's go back to the videotape, and see how the word ``reality'' was
actually used:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   In reality, there will be a year 10000. 

You think these are ``opinions''?

---Dan

---

From: Glenn Anderson <[email-masked]>
Date: Fri, 21 Jul 2000 20:04:29 +1200

>    recognize \012 as a line terminator ...

In reality, thousands of SMTP servers do not recognise \012 as a line 
terminator. Clients that use just \012 as a line terminator are 
broken and should be fixed.

Glenn.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Jul 2000 09:52:36 -0000

Glenn Anderson writes:
> Clients that use just \012 as a line terminator are 

Certainly. Clients that use \012 as a line terminator for requests are
violating RFC 821 and will be violating 821bis. I hope that they all
disappear someday. I support education efforts aimed at this goal.

In the meantime, however, I refuse to punish the users of those clients.
Deliberate torture is not an acceptable way to educate implementors. I
will continue to accept \012 as a line terminator for client requests.

To summarize the situation: The sender's misbehavior is inexcusable and
should be prohibited. But the receiver's tolerance is beneficial and
should be allowed. As Jon Postel said:

   It is nice that many mail-reading programs will accept mail that does
   not conform to the standard, but that does not justify mail-sending
   programs' violation of the standard.

---Dan

---

From: Philip Hazel <[email-masked]>
Date: Fri, 21 Jul 2000 11:33:50 +0100 (BST)

On 21 Jul 2000, D. J. Bernstein wrote:

> As Jon Postel said:

I think it is a great pity that *any* mail-reading programs accept mail 
that does not conform to the standard. If, from the start, all such
programs had been strict, we wouldn't be in the mess we are in today,
where, because such tolerance has been common, new implementations are
forced to accept non-conforming mail, but their implementors don't know
they have do this to until it bites them, because such behaviour is not
described in the standard. 

You cannot implement a usable MTA for today's Internet purely from the
information in the RFCs. This is a serious disaster.

It is no wonder that some people take a cavalier attitude towards
standards when faced with this situation.

"Be liberal in what you accept" is always a recipe for storing up 
trouble that will come back to bite people later. Once you start down
that road, you can't retreat, however. We are stuck with the legacy of 
this attitude.

All IMHO, of course.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 21 Jul 2000 04:22:25 -0700

> behave as you suggest will fail miserably and be discarded by users.

The whole point of EHLO was to prevent this sort of poking and prodding.
If the server wants implementations to use VRFY it should announce that
capability.
 
> definition of the phrase ``some form of loop detection.''

Alleged?  Come on.  Run a mailing list of 100 people or more and tell me
that with a straight face.  And the point of the document is that the
method is left to the implementor.  I'm not saying it can't be done
wrong (numerous mailing list management software have blown it in this
area). Why not state a credible argument that this presents a serious
interoperability problem, rather than resorting to vague fud?

> [...]

> failures. Are you seriously suggesting that such breakage be allowed?

Yes in the cases where the alternatives could lead to worse problems.
Consider the case where two implementations attempt to add garbage on
the end of a command.  The result is undefined and then we hear
complaints about SMTP, such as the one in your objection.

Worse than producing an error is accepting a message with parameters you
do not understand, since you may not be able to deliver it properly.  By
mandating allowance for broken behavior (as in the case with crud on the
end of a line) we also open up opportunities for lots of implementation
errors, which raise security concerns (improper parsing, buffer
overflows).

In fact normally I don't think I'd be a stickler on this issue, but
because there is an existence proof of abuse of the standard, others
WILL follow if we don't fix it.

> suggesting that users be forced to install new software for no benefit?

Except that they'll have the benefit of improved interoperability,
meaning that their mail will more likely reach them or their receivers.
--
Eliot Lear
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Sat, 22 Jul 2000 01:25:22 +1000

Date:        Thu, 20 Jul 2000 09:39:33 +0100 (BST)
    From:        Philip Hazel <[email-masked]>
    Message-ID:  <[email-masked]>

In all this discussion, this is the one message that really makes
the issues clear (from a WG last call perspective) ...

  | To keep the record straight, let me record here that there are several 
  | of Dan's points with which I entirely agree. So it isn't just one 
  | participant, it's at least two. And, like Dan, I am an MTA implementor.
  | 
  | I have to confess that I decided to give up trying to argue these points
  | in the face of apparently overwhelming opposition. They include the
  | 8-bit thing, which he does not mention in his message. The other major
  | points with which I agree are:

That demonstrates exactly what happens in WGs.  People argue for their point
of view, until it becomes clear that the WG is not going to accept the
argument (and whether the WG is wrong or not is not something that matters).

That really should be the end of the issue - unfortunately there are some
participants who never realise that however certain they are that their
arguments are correct and valid, and that only a moron could fail to
understand the underlying truths, the WG is simply not going to accept them.

Those (fortunately few) people keep bringing up the same objections over
and over again - and can usually find a few other people who will agree
with any one of their points - and from that become even more convinced that
their arguments are valid, and are simply being ignored (usually due to some
imagined malfeasance by the doc editor).

The right thing to do is just as was mentioned above - give up arguing in
the face of apparently overwhelming opposition.   That's what should have
happened here too, unfortunately it hasn't.   None of this noise should
be treated even half seriously by the WG chair or the IESG.  It is noise.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Jul 2000 06:05:15 -0000

Philip Hazel writes:
> new implementations are forced to accept non-conforming mail, but
> their implementors don't know they have do this to until it bites them,

This crucial information is on my web pages, of course. Example: ``Some
clients fail to include the \015.'' But Klensin refuses to include this
warning in 821bis.

Klensin then exacerbates the problem by requiring that servers stop
talking to those clients. Klensin's requirement is actively disobeyed by
most SMTP servers on the Internet. Good! Obeying Klensin's requirement
would immediately cause massive harm to users.

> that does not conform to the standard.

Nobody has ever written a server that detects every visible misbehavior
by SMTP clients. The protocol is far too complicated. A tolerant server
is much easier to implement.

> If, from the start, all such programs had been strict,

Then nobody would have written the programs in the first place. You are
talking about a _huge_ implementation expense. SMTP---not to mention the
Internet mail message header format---wasn't designed to make this easy.

Please note that my comments are specific to these poorly designed
protocols. There are other protocols where the same job is easy.

---Dan

P.S. Just as a reminder: The issue you're raising was discussed here in
late 1998. In a legitimate standards organization, discussions aren't
repeated; issues are settled when they're first brought up, and the
logic behind each decision is recorded in a format designed for quick
future reference.

---

From: [email-masked] (Kai Henningsen)
Date: 22 Jul 2000 18:23:00 +0200

> potential benefit to the user, and neither side had an infinite amount

Are you by any chance talking about the case where a MUA talks to a  
submission server (*not* a relay)? (Or maybe a "smarthost" scenario -  
essentially the same thing.)

Because in that case, I agree that MX records are exceedingly counter  
productive. OTOH, I also think that the doc doesn't actually prescribes  
any behaviour for this case. (Smarthost is by definition by previous local  
agreement.) If people disagree, a wording fix might be in order.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 22 Jul 2000 18:41:00 +0200

> of his technical points have merit.  We should not succumb to the temptation

Six. (And you all know how much I dislike djb's style.)

In fact, ISTR that some of the points he made had rough consensus *for*,  
not against, them. (And some others were, indeed, right out there.)

MfG Kai

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Jul 2000 02:53:21 -0000

Kai Henningsen writes:
> OTOH, I also think that the doc doesn't actually prescribes  
> any behaviour for this case.

Oops, you're right. Klensin's bad text in smtpupd-10 (the relay name
``SHOULD be processed'' by the MX procedure) disappeared in smtpupd-11.
I didn't catch this change. My apologies.

---Dan

---

From: Glenn Anderson <[email-masked]>
Date: Sun, 23 Jul 2000 10:51:38 +1200

>would immediately cause massive harm to users.

I disagree, my server refuses \012 as an end of line, has done for 
years now, and the only "clients" that I have had users report 
problems with recently are scripts that have been hastily written. 
These reports are very infrequent.

Glenn.

---

From: Philip Hazel <[email-masked]>
Date: Tue, 25 Jul 2000 09:22:20 +0100 (BST)

> These reports are very infrequent.

On how many hosts does your server run?

I originally wrote Exim to be strict; after it had found its way out 
into the world, it hit this problem. I cannot now remember which clients 
caused it. I left the "strict" code in, controlled by an #ifdef, but I 
don't suppose anybody uses it.

---

From: Philip Hazel <[email-masked]>
Date: Tue, 25 Jul 2000 09:43:46 +0100 (BST)

Perhaps this problem is about to get worse. This was recently posted on 
comp.mail.misc:

------ Forwarded Article <[email-masked]>
------ From Karsten Fischer <[email-masked]>

Hi,

i've got a problem with javamail. I discovered that all apperances of
the linefeed character "\n" were changed into an "\r\n" (Carriage
Return+Linefeed) while sending the mail to the smtpserver. I'm working
with S/MIME Routines and signed Mails so that all Mails had a bad digest
(bad signature) because of the changed Mail Body. Is there an option to
prevent this modification ? 

Ciao,

Karsten

------ End of Forwarded Article

---

From: Glenn Anderson <[email-masked]>
Date: Tue, 25 Jul 2000 23:31:01 +1200

>On how many hosts does your server run?

Judging by Dan's survey at 
<http://cr.yp.to/surveys/smtpsoftware4.txt>, it is running on tens of 
thousands of hosts.

Glenn.

---

From: Philip Hazel <[email-masked]>
Date: Tue, 25 Jul 2000 13:59:49 +0100 (BST)

> <http://cr.yp.to/surveys/smtpsoftware4.txt>, it is running on tens of 

Hmm. I wish I could now remember what client it was that caused me to 
change Exim. There certainly *was* a problem, and I remember being cross 
about it when I added the following to Exim's ChangeLog:

  67. It seems there are sites that send only LF instead of CRLF in their SMTP
  transactions, and that smail and sendmail can handle them. Relax Exim's
  constraints so as to run with the herd.

This was in February, 1997. Maybe the rogues have become extinct in the
last three years?

---

From: "Mark Symons" <[email-masked]>
Date: Tue, 25 Jul 2000 11:35:28 -0400

>  <http://cr.yp.to/surveys/smtpsoftware4.txt>, it is running on
>  tens of thousands of hosts.

There's another useful survey that can be found at:

http://www.sirana.com/smtp/default.asp

The survey claims to have surveyed 1.3 million hosts.

Mark Symons
Ipswitch, Inc
Augusta GA

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2000 03:55:10 -0700

So, my question to the list is this:

What is being accomplished by this lengthy thread?

We are re-hashing a topic that was argued and decided before.  Why?  Do we 
have new information? No!

We are seeing that some participants have not read, or do not recall, the 
specification text or the history of relevant discussion.  Document 
progress should not be delayed by such clarifications.

We are seeing that some participants do not understand the difference 
between rules of a standard, versus choices made in the privacy of one's 
own network.  Is it really necessary to delay the document further while we 
engage in pedagogy about standards?

Let's move on.

d/

=-=-=-=-=

---

From: DRUMS WG Chair <[email-masked]>
Date: Wed, 26 Jul 2000 18:04:58 -0700

> to this draft. A copy of the text appears below.

This thread contains too many issues, and many of them are stated in a 
fashion which could be construed as impolite.

If you wish these issues to be tracked, please follow the procedures in my 
post "Procedures for Moving Forward" if you have not already done so.

I apologize for the fact that I have done a poor job of tracking some of 
the issues you have raised and hope these new procedures will help.

		Thank you,
		- DRUMS WG Chair

---

From: DRUMS WG Chair <[email-masked]>
Date: Wed, 26 Jul 2000 18:07:59 -0700

This issue will be considered closed unless specific proposed changes to 
draft 12 of the SMTP document are posted and at least 4 people (including 
initial poster) support the proposed change.

		- DRUMS WG Chair