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".
The purpose of changes should be to avoid lost mail, as opposed to rejected
mail, which doesn't have any damaging effects on reliability. SMTP REJECT
should be encouraged as the proper response to doubtful requests. (Sorry, we
don't accept mail from unidentified transmitters.)
So what are you asking for that isn't there already?
Elimination of the IP address literal option? Some criteria for
"verifiable" that would presumably lie well outside the scope of
SMTP?
If you can deprecate HELO, surely you can do the same for address literals.
Do keep in mind that we know from experience that the bad guys
have absolutely no trouble obtaining perfectly valid domain
names.
I agree that reputation requirements should be outside the scope of 5321. Same
for the details of any particular authentication method. What I am suggesting
is not that level of detail.
I know you can't turn back the clock and make radical changes to SMTP, but in
revising the spec, we should do everything we can to make up for the original
deficiency in the HELO command and the lack of attention to security issues.
-- Dave