On Tue, Feb 24, 2004 at 05:18:44AM -0600, wayne wrote:
|
| As others have pointed out, many MTAs already have an option to
| validate the HELO domain. I think doing the SPF checking is better
| than most of these options, but these MTAs didn't have access to the SPF
| code when the options were created.
I have a pragmatic reason for not doing HELO checking.
There are a lot of legitimate machines with bad HELO strings.
I have an intuition, but no more, that in many of these cases where
legitimate machines have misconfigured HELO strings, is easier for the
DNS admins to add an SPF record for the MAIL-FROM return-path domain
name than it is for them to get the HELO strings corrected.
If we were to do strict HELO checking, many of those legitimate machines
would now begin to fail, and the false-positive rate of SPF would become
very high right away; it would be high enough that people would reject
it as too idealistic.
I bought some nice tea a while ago. Here's the confirmation email
cooking.com sent me:
Received: from smmsmq02.COOKMSMQ.LOCAL (nat1.cooking.com[64.94.104.78])
by boggle.pobox.com (Postfix) with ESMTP
for <mengwong(_at_)pobox(_dot_)com>; Tue, 18 Nov 2003 22:58:16
-0500 (EST)
Here are the headers added by pobox.com:
X-Pobox-Antispam: bad_helo returned DENY: no MX or A records found for
smmsmq02.COOKMSMQ.LOCAL
Received-SPF: unknown: domain of Orders(_at_)Cooking(_dot_)Com does not
designate permitted senders
X-SPF-Guess: pass: best guess: seems reasonable for
Orders(_at_)Cooking(_dot_)Com to mail through 64.94.104.78
So here we have a legitimate message sent by a box with a bad HELO
name. Cooking.com might want to publish SPF records to protect their
brand, but if we tell them "okay, now you need to also get into the
configuration of every single mail server and update the hostname" they
might say:
- not required by RFC2821
- causes us massive inconvenience, because the HELO string is taken
directly from the windows hostname field, and if we change the
windows hostname field we have to reconfigure every windows file
sharing client on our network, etc etc.
- in fact, that host isn't even owned by us, we outsource to a vendor
who is not responsive about things like this
So organizationally there are many land mines.
But what about the null sender scenario? If that box needs to send a
bounce, SPF will look at the HELO name and say "gosh, I certainly
couldn't find a TXT record for smmsmq02.cookmsmq.local", I will return
UNKNOWN. But not FAIL!
If you want to require that all incoming SMTP carries a valid HELO, I
believe that is a policy decision that should be made by each individual
SMTP receiver. At pobox, we let each end-user make that decision at
SMTP time.
I do appreciate that it's bad when a spammer uses your name in the HELO
string. But this can be solved if a receiver requires that the HELO
machine domain match the client IP address. If a complaint arises, it
is because the receiver MTA did not make this check.
SPF is a hard enough sell as it is: I don't want this to be the straw
that breaks the camel's back.