Alex wrote:
On Sat, Jan 05, 2008 at 09:50:17PM +0000, Mark wrote:
The 'problem' with RFC-compliant HELO data is, of course, that,
officially, there's no other requirement than that HELO be a FQDN
or an address literal.
That's not correct.
Officially, the name which is used as HELO parameter MUST be "a valid
principal host name [...] for its host." (or an address literal,
under certain specific circumstances)
Your statement ignores the 'for its host' part.
Well, my statement, to be precise, was a from-memory paraphrase of RFC
2821, Section 3.6 Domains, which reads:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
The 'for its host' part is the language of 4.1.4 Order of Commands:
- The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a valid principal host name (not a CNAME or
MX name) FOR ITS HOST. (...)
(last caps mine). Of course, we both agree that it MUST be a principal
host name for its host, so the point is somewhat moot. :) In fact, the
language of 3.6, "if the host has no name" already hints to the same. The
problem, however, remains the next paragraph:
- An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
Though it's near treading on the realm of semantics, in the strictest
sense you could say RFC 2821, stating that HELO, if possible, MUST be a
valid principal host name for its host, leaves not much room. However, the
text of 4.1.4, at the same time, robs us of an important way to verify a
correspondence to the connecting IP address (or, rather, robs us of the
option to reject for that reason). So, where does that leave us? In the
somewhat awkward position that, the gnashing of the teeth despite, when
someone comes along and asks whether they are, by RFC, allowed to reject a
HELO name when no correspondence to the connection IP address can be
established, we'd have to say no. So, effectively, yes, there's room for
spammers to move in. A spammer could, for instance, use a very low-key,
'karma'-neutral FQDN for HELO, one that has not been blacklisted anywhere,
and for which no SPF record is published yet, and which is not obviously
not his.
Don wrote:
In the broad scheme of things, this would be very high on my list of
things to change. The RFCs should, IMHO, require a traceable
HELO/EHLO for server "greeting". It is already that way de-facto by
virtue of the checking on HELO that most servers already do for
anti-spam.
The "MUST NOT refuse" verbiage should just be removed.
That alone, I fear, wouldn't cut it. Inherent in the language "MUST be a
valid principal host name for its host," is buried the inability of
reliably tying said principal host name to the connecting client. Maybe
something like:
"MUST be a valid principal host name that corresponds to the IP address of
the connecting client."
It may be a while, though, before the powers that be are willing to make
such changes. :) In the meantime, we can all just publish SPF records for
our HELO names, too. I'm seeing in my logs a larger amount of "none" for
HELO names than for MFROM domains. Not sure what that means, exactly.
Maybe folks forgot to set up SPF records for their HELO names as well? At
any rate, the more HELO can be verified the better, of course.
- Mark
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=82352583-39322d
Powered by Listbox: http://www.listbox.com