Meng,
This is why I said, at a minimum SPF should, no "MUST" provide protection
against Local Domain Spoofing.
This is what I suggest:
---- start of suggestion ---
2.2.2 Lookup
Step 1: HELO/EHLO domain Validation
To protect against local domain spoofing, the SPF client MUST first analyze
the HELO/EHLO domain to see if it belongs to the MTA-receiver local domains.
If the HELO/EHLO domain is a local domain, then it should be validated
against the client IP address. Since local domains are in full control of
their setup and configuration, this should always provide a 100% reliable
validation check.
To protect against remote domain spool, SPF client MAY analyze the
HELO/EHLO to validate it against the client IP address. This is left as a
system implementation option since you have no control over remote
configurations. The
overhead associated with unreliable results may not be feasible. However, a
SPF-fail condition should be consider 100% reliable. A SPF-pass or
SPF-softfail result can be used as a weight/factor in the next lookup.
Step 2: Return Path Domain Validation
[Normal specification]
---- end of suggestion ---
This has nothing to do with the fact of HOW it is implemented, at the MTA
level of not. But having it in the SPF "functional specification" needs to
be done. If we wish to mix it up with technical specifications, great,
which you partially do, but the fact remains:
SPF with no HELO/EHLO local domain validation provision is a
loophole.
as I already shown.
Yes, what SPF is explicitly implying or presuming is that the MTA is
expected to do its own HELO/EHLO checking. That is a bad presumption
because the SMTP specification does not mandate it.
The typical reasons why the HELO is not valid is:
- non-server MUA sending directly using NETBIOS computer names
- badly configured outgoing sender MTA machines or farms using the same
domain name.
This is why the biggest benefit of LMAP is to protect yourself against local
domain spoofing. The reliability is not there with remote domain checking.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, February 24, 2004 10:39 AM
Subject: Re: [spf-discuss] Possible SPF machine-domain loophole???
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.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-20040209.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡