Re: Possible SPF machine-domain loophole???

OK, here is some quick feedback... rather than replying to each message in 
turn I will combine my thoughts so far on this thread.

Everyone:  Dang, you wrote a lot of mail in one day!

Hector:  You have NOT shown that this is a loophole.  Please don't describe 
it as a "loophole" or "flaw" -- there is a good reason to limit these 
checks that has to do with limiting any potential losses of real, desired 
mail (such as the cooking.com example Meng mentioned).  If you believe I am 
fundamentally missing something, it's OK to write me privately.  I will 
accept remedial lessons and if I change my mind I will admit it to 
everyone.  :)
Ernesto:  You have a good point, and so does Hector, that being that we 
*could* validate the HELO name at other times than when the spec says. 
But, it's important to listen to what Meng points out - many hosts will 
have HELO configured wrong.
If you are checking envelope sender all the time, and only checking HELO 
when the envelope sender is blank, then the hosts with mis-configured HELO 
will still be able to send you legitimate, non-forged mail.  If you limit 
the HELO check to MAIL FROM: <> then you are limiting the scope of the 
false-positive problem to 1. bounces from badly-configured servers, but 
still allowing legitimate mail from those servers, and 2. suspicious 
messages not following SMTP guidelines.  I think it is a mistake to tell 
people to apply HELO checks to ALL mail -- yet.  (BUT, read on for what I 
am actually suggesting).
Meng: We may actually be able to satisfy all parties, with some very 
simple, very minimal changes.  If we can get away with not changing the 
syntax of the spec (i.e. not adding new elements) but we can satisfy people 
anyway, great.
So, here is a suggestion that incorporates what I think Hector and Ernesto 
are suggesting.
1. Allow receivers to check the HELO name.  They MAY check the HELO. 
(After everyone likes it and agrees it is a good idea, we can change the 
spec to SHOULD check, but we probably should try not to piss off anyone who 
has already implemented it.)  The receiver that *chooses* to check the HELO 
name all the time should be warned that some sites may have their HELO 
names set up wrong, and if they check all the time, the might be losing 
some legitimate mail from those badly-configured servers, not just bounces 
from the mailer daemon of those servers.  The practice should carry a 
disclaimer until we have some good, solid data.
2. Check the HELO name for *known forged* values only.  That is, the bad 
HELO name is one that would have failed SPF if the message had been MAIL 
FROM: <>  But we know that many servers have short names (like HELO 
mailserver) or weird names that don't resolve (like HELO 
mailserver.localhost).   But IF the HELO name they are claiming to use has 
an SPF record, that record MAY be used to validate the server name even if 
the mail is not from <>  - Basically, this is enough to check for blatant 
forgeries like HELO microsoft.com or HELO baschny.de.  Ernesto will be 
happy.  But the check should not be strict enough to fail the mail 
transaction if the HELO name doesn't resolve.
2.1. Check the HELO name against the SPF record for whatever domain name 
HELO is claiming to be, and check the MAIL FROM name against whatever 
domain name MAIL FROM is claiming to be.  Do NOT check the HELO name 
against the MAIL FROM SPF or vice versa.  We are following the existing 
spec, just widening the applicability a bit.
2.2. Do not mark the message as failed if HELO doesn't resolve or doesn't 
have SPF records.  Some mail admins may decide to block mail from servers 
with a non-existent HELO name but that is NOT supported by SPF policy.
2.3. If the HELO check is PASS, SOFTFAIL, or UNKNOWN, proceed as OK.  Don't 
add this information to the headers or to any scoring unless the MAIL FROM 
is <>.  All of the SPF spec is built around the MAIL FROM and the HELO is 
an optional add-on.  Don't modify the added headers and what not - HELO is 
either failed or not recorded/scored anywhere.
3. We are already recommending to people that mail servers have their own 
SPF records, so bounce messages from those servers can be validated, we are 
just (optionally!) widening the range of applicability of those checks. 
Therefore, I don't think we really need to change the spec to add 
scope=helo.  If the existing spec works, use it.  In other words, it is 
opt-in for the receiver, but we are not giving the sender a choice, since 
we have already told them to set up mail server records.
4. I would strongly recommend NOT to "go up the chain".  For example, if 
there is an SPF record for baschny.de, that should protect against rogue 
machines saying "HELO baschny.de".  It should NOT be extended to apply to 
"HELO www.baschny.de".  This is already a principle of SPF.  If you want to 
protect those other names, make SPF records for them too.
There is already a good reason to provide SPF records for ALL names that 
have either A or MX.  We are not adding any valid reason to go up the chain 
with HELO checking.  If there is no SPF for www.baschny.de, I can claim my 
HELO name is www.baschny.de -- but then I can also claim my mail is from 
gconnor(_at_)www(_dot_)baschny(_dot_)de(_dot_)  We should be very very very very cautious and 
suspicious of any attempt to "generalize" the SPF policy of domain.com as 
applying to name.domain.com.  Some SPF senders may choose not to do this 
until forgery of their sub-domains becomes a problem.  That is OK.  (If you 
have wildcard A or wildcard MX, add wildcard SPF.  If you don't already 
have a wildcard A or MX in your domain then wildcard SPF will not be 
needed.)
5. Domain owners should be aware of this -- there MIGHT be mail servers out 
there (if you have a large diverse user base and they set up their own mail 
servers) that claim their HELO name is baschny.de even if they are not 
sending out mail as user(_at_)baschny(_dot_)de(_dot_)  Those servers will already have a 
problem sending bounces - now they will have a problem sending ANY mail, 
even mail for other domains not in baschny.de.  Remind any local folks who 
might set up their own mail server to make an SPF record for their mail 
server and to make sure it matches the HELO name.

Would this suggestion satisfy people?


Here is another side note I just thought of.  In the case of after-receipt 
filtering (like spamassassin) I'm assuming they already check MAIL FROM:<> 
in a different form, but it's worth checking to make sure those checks are 
being performed correctly.  If we mention checking Received: lines in the 
spec we should mention the <> case too because it may be hard to spot from 
the headers.  For <> mail, the Return-Path is probably not <> but 
MAILER-DAEMON(_at_)receiving-server-name(_dot_)  If you are checking SPF against the 
headers by looking for Received: lines added by your server (say 
mail1.mydomain.com) then you should look for messages from 
MAILER-DAEMON(_at_)mail1(_dot_)mydomain(_dot_)com, and activate the HELO checking on that 
line.  Are after-receipt checking systems already doing this correctly?  If 
so, then all we have to do is add an optional check so that the 
administrator can choose to check HELO information ALL the time, not just 
when Return-Path is MAILER-DAEMON(_at_)receiving-server-name(_dot_)



--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>