macquigg at ece
Jan 14, 2010, 2:07 PM
Post #11 of 20
(3266 views)
Permalink
|
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
|
