[Top] [All Lists]

Re: RFC 5321bis / 2821ter

2009-01-29 11:38:42

--On Thursday, January 29, 2009 16:28 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:

have yet to come across a recipient where if they change it
so that it sends 'EHLO [<local ip address>]' or 'EHLO' 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

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


<Prev in Thread] Current Thread [Next in Thread>