ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-01 Issue 19: Explanatory text after literal in EHLO

2007-05-09 09:07:33

ned+ietf-smtp(_at_)mrochek(_dot_)com <ned+ietf-smtp(_at_)mrochek(_dot_)com> 
wrote:
On Thu, 3 May 2007, Tony Hansen wrote:

I'm going to close the issue, but note, as Frank suggests, that it
should be checked as part of the implementation and interoperability
report.

   We've got to drop this if we can't find interoperable implementations.
The question is: should we even try to?

Based on my testing, common implmentations (Sendmail, Exim, Postfix,
Exchange) do not accept this syntax. (Some of them can be configured to
accept any kind of junk after EHLO but if their syntax checker is turned
on they reject explained-literals.) My servers have seen no (zero)
instances of this syntax by clients in the last month (out of two to
three million messages per day). (We don't keep logs longer than that.)

   I don't have that much traffic, but I can't find a use of it in our
logs either.

As far as I can tell from the DRUMS archive this wording was added to
draft-ietf-drums-smtpupd-04 without any pertinent discussion - it
seemed to be a reaction to an argument about canonical names.

I think this all indicates that the feature should be removed.

I have to agree with Tony [Finch] here. I like the idea behind this
and as it happens our implementation can accept this syntax.

   We might include text allowing a receiving SMTP server the option to
parse the EHLO string and treat only the part before SP as the domain
or address-literal. (I recall discussing this exact issue with Dave
Crocker during the design of CSV -- we decided to follow the BNF...)

However, the checks many people have in place will prevent it from
working on a lot of actual systems out there. I can virtually guarantee
a ton of interop problems if this is adopted.

   The evidence is clear that its use is not mainstream. Our analysis
shows it to be unusable except in special cases which amount to prior
arrangement between client and server. It looks to me to be pretty
close to consensus to drop it from the text (and BNF).

   I recommend dropping it: adding it to the BNF would clearly violate
the principle of least amazement.

--
John Leslie <john(_at_)jlc(_dot_)net>