Re: RFC 5321bis / 2821ter

[John C Klensin <[e-mail]>]

--On Thursday, January 29, 2009 16:28 +0100 Alessandro Vesely
<[e-mail]> wrote:

>...
>> We 
>> have yet to come across a recipient where if they change it
>> so that it sends 'EHLO [<local ip address>]' or 'EHLO
>> domain.com' it won't work, even though the first is useless
>> and the second is strictly incorrect.

> I'd say the second is valid, since the spec says it must not
> be rejected. From an ethical POV, having a DNS record to
> confirm that the domain endorses the address being used should
> be preferred. (From an operations POV, users cannot read their
> mail from outside the office without that.)

Alessandro, I think this is what you are missing that Paul and
others are trying to explain.  5321 rather carefully explains
what is valid and what is not.  To be valid under 5321, it must
meet the syntax rules for either a Domain or for an address
literal.  If it looks like a Domain, it must be a resolvable
FQDN.  The server is also encouraged to check the relationship
between the EHLO argument and whatever else it knows about the
sending machine (particularly its IP address from the
connection) but told that it must not reject the mail simply
because whatever tests it applies at that level fails.  That
doesn't somehow make the argument "valid" or "invalid" as far as
5321 is concerned, it just means that an optional test failed,
one whose results the server is prohibited from using to reject
the message.

If the intention of the text was to say "the argument to EHLO is
noise and you can ignore it", that certainly could have been
said, and probably should have been.   The following are all
perfectly valid decisions under 5321 as written:

	* Rejecting the EHLO command and message because the
	argument does not follow the syntax rules.
	
	* Rejecting the EHLO command and message because the
	apparent FQDN in the argument does not resolve at all in
	the public DNS.
	
	* Noticing that the EHLO argument does not resolve to
	the address obtained from the connection, writing a
	private-use header into the message that records that
	fact, and then forwarding/delivering the message anyway.
	
	* Noticing that the EHLO argument does not resolve to
	the address obtained from the connection, delivering the
	message anyway, but delivering it to a folder different
	from the one that would normally be used for incoming
	messages associated with the RCPT command address.

If others disagree with that interpretation, we should discuss
it.  If people believe that the text needs further
clarification, I'd welcome suggested text modifications.  But
I'm confident that the description above is what 5321 is
intended to say and how it should be interpreted.   Other
interpretations are, IMO, a change to the spec.

> OK, DNS checks can be worked around. However, I'd reckon that
> it is
> still easier for legitimate senders than for spammers to do
> that.

In many cases, actually not.  

> DNS/whois data has experienced a series of adjustments for the
> sake of
> privacy and users' right to anonymity. I accept that it should
> be
> possible for a user to send mail anonymously. However, I'd
> refuse that
> the operators of an SMTP relay may remain anonymous. Is that a
> more or less universally agreed stance?

It depends on _exactly_ how you define "SMTP relay".  If it
includes submission servers, the same privacy arguments that
have been applied to senders would apply to it too.  The ability
to close down or restrict traffic from servers that support
anonymous senders is equivalent to the ability to shut the
anonymous senders down.

    john