spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Resolving MFROM/HELO conflicts

2010-01-14 16:08:20
Don Lee wrote:
David MacQuigg wrote:
Stuart D. Gathman wrote:
Here is a little nit that wasn't addressed in RFC4408.  If HELO SPF says to reject, but 
SPF for MAIL FROM says Pass, which takes precedence?  For spfv1, I think we are stuck 
with "receiver policy" (especially since checking HELO is optional).  Should we 
specify a precedence for spfv3?
Make HELO check a MUST?  Or keep HELO optional, but give precedence to MFROM?
The HELO check should be mandatory, and should take precedence over the MFROM check.  There is no 
"forwarding problem" (or any other excuse for failure) with the HELO check.  Furthermore, 
all the "bells and whistles" in an SPF record should not apply to the HELO check.  It 
should be a simple Pass/Fail, with an immediate SMTP REJECT on Fail.
We had already talked with John Klensin about this subject and concluded that it is 
hardly practicable because of brain damaged clients out there who don't even know their 
IP address. John suggested to use a different verb, VHLO, for clients who wish to undergo 
such a severe scrutiny. A "pass" would then result in some sort of 
whitelisting. I've detailed the finish for this line of thought in 
http://tools.ietf.org/html/draft-vesely-vhlo

IMHO, in spfv3, we can drop the whole idea of HELO-checking, because 
backscattering has been substantially reduced in the mean time, while SPF 
records for host names have never flown.

FWIW - I find that over time, (non-spammer) mailservers
that do not issue a reasonable HELO/EHLO are increasingly rare.

On the one hand,  CNAME for HELO is all too common (and accepted - wrong
though it may be), but HELO that does not resolve, or does not have
port 25 open on the resolved IP is more and more commonly the reason
for mail from that server being rejected.

As a result, SPF on host names, and a requirement that HELO be "OK"
is more and more palatable as a standard.

For my mailserver, which I admit is relatively small, I see several
thousand incoming unique hosts each day, and filter quite successfully on
a series of filters based on HELO.  I can count on one hand the number of
complaints of "false positives" with this technique in the last
5 years.

We avoid the "false positive" (false reject) problem by not rejecting if we are not sure. Our HELO check is basically a bypass for reputable domains to avoid the spam filters. It is not intended to catch the bad guys (although it will if they are stupid enough to use a HELO name that is protected from forgery).

As for "brain damaged clients" we have a web page that explains in simple terms how to fix their HELO name. My experience in using this system over the last two years is that small domains are cooperative (sure, whatever will help our mail delivery), and only a few large domains are a problem (nobody tells *us* what to do!). We have default records for these large domains, using their entire IP allocation (still a small fraction of the entire zombie space). I haven't seen it happen yet, but if they do get some zombies inside their IP allocation and using their HELO name, I expect they will move quickly to correct their record (it's easier than calling their lawyer).

The important thing in getting sender cooperation is to not ask too much, and make sure the benefit exceeds the cost. Asking them to install special software is too much. Asking them to change DNS providers (so they can publish special SRV records) is too much. Asking them to add "-all" to their SPF records is too much. Asking them to simply correct our best guess as to their transmitter addresses is not too much. It only takes a few minutes, and it will eliminate the zombies entirely, restore their reputation, and avoid the quarantine.

-- Dave



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ 
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com