----- Original Message -----
From: "David MacQuigg" <david_macquigg(_at_)yahoo(_dot_)com>
To: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Saturday, January 24, 2009 2:23 PM
Subject: Re: RFC 5321bis / 2821ter
At 05:53 PM 1/23/2009 -0500, John C Klensin wrote:
--On Friday, January 23, 2009 14:32 -0700 David MacQuigg wrote:
...
I have yet to see any sensible use-case that would be
complicated by a requirement that the HELO/EHLO name end in a
registered, verifiable domain name.
...
David,
Today, under 5321, EHLO clearly requires a fully-qualified
domain name that can be resolved unless the host doesn't know
its name and has to use an IP address, a situation that the spec
doesn't encourage. My reading of 5321 (but not necessarily 821)
says that HELO does too.
Perhaps it is just a matter of emphasis. As I read the spec it *does*
seem to encourage using HELO/EHLO names that are useless for
authentication. For example, the language in 4.1.4 "if the verification
fails, the server MUST NOT refuse to accept a message" puts the burden on
the receiver to deal with mis-configured transmitters. Receivers are
expected to accept mail from transmitters that say "HELO this is Jupiter".
It does not say that. Why did you forgot to copy "on that basis" ?
"An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis. Information captured in the
verification attempt is for logging and tracing purposes. Note that
this prohibition applies to the matching of the parameter to its IP
address only
"
Verifying that "Jupiter" is not a FQDN is not covered by that statement.
It says: Note that this prohibition applies to the matching of the parameter
to its IP address only.
In other words: one mailhost, two addresses and two names, names
"primary.example.com" and "secondary.example.com".
This box connects to you, it says "EHLO primary.example.com." but after
verification you know it is really secondary.example.com connecting to you.
This is not an acceptable ground for rejecting a message.
But that does not mean a mailhost can just use any name it wants to. It
still MUST (if possible) use its own primary name. My example box has no
choice but to use primary.example.com in EHLO, eventhough it is connecting
via the other interface.
But when a spammer uses the same EHLO parameter, and if I happen to have
knowledge such as provided by SPF, it's perfectly okay to reject.