Re: Harvest netblocks of good MTAs from SPF for whitelisting from greylisting

"Constantine A. Murenin" <[email protected]> wrote:

>On 12 February 2013 14:55, Stuart D Gathman <[email protected]> wrote:
>> On Feb 12, Constantine A. Murenin transmitted in part:
>>
>>
>>> I'd guesstimate that a setup with pf(4) whitelisting of common MTAs
>>> through the SPF harvesting approach described, together with
>>> greylisting at the firewall level, for my domains would be much more
>>> effective in combating spam than any kind of SPF or DKIM
>>> implementations at my MTA level, and without the false positives.
>>
>>
>> But you are doing the same thing as SPF - except guessing the valid
>MTAs
>> instead of using the official list conveniently provided in SPF
>records.
>> If you are worried about efficiency, SPF records that don't involve
>> localpart or PTR macros can be resolved to a set of IPs (more general
>> than a netblock) with a TTL, and cached.  I believe libspf2 has this
>> feature already.  Take the union of the IP sets of all your "good"
>> domains if you are going to treat them all the same.
>
>No.  I cannot have my firewall do SPF evaluations, and I'm not
>attempting to do the same thing as SPF.  I am also not guessing valid
>MTAs, I'm getting their list deterministically based on static SPF
>information that is published by relevant entities whose mail I might
>care to never delay.
>
>Let's do a quick reality check here:  SPF cannot block spam.  It can
>only block forgeries, and if you configure it as such, it is also very
>much so likely to have many false positives, too.
>
>My approach, as described above, involves the following:
>
>* collect SPF information statically (every week or so) and compile a
>list of netblocks
>* pass connections from such whitelist directly to sendmail/qmail/mta
>of choice
>* pass other connections to spamd, to do greylisting
>* if a host passes greylisting, spamd updates the firewall, and the
>next connection attempt will go to sendmail/qmail/etc
>
>The novelty of my approach is collecting a whitelist through an
>SPF-based record harvesting.
>
>SPF-wise, this approach has limitations of, for example, obviously not
>supporting SPF's "ptr" and "exists" declarations, and also not being
>real-time; however, even for such domains that rely on such features,
>they'd still be able to deliver mail after passing greylisting, and
>with no false positives.
>
>Non-SPF-wise, this approach might make SPF actually useful for those
>who think that it is not, and would complement any greylisting policy
>with very little overhead and a 0,000% false positive rate.
>
>Yes, I'm not trying to use SPF as it was designed, but who cares?
>It's not like we use IPv4 for what it was originally designed either,
>is it?
>
>Right now I'm trying to see if someone has already done this before,
>as it seems simple enough.  Else, some ideas on a possible
>implementation, or perhaps just stirring some interest amongst people
>who are thinking of better ways to use the SPF records that remain
>largely unused.

This seems way harder than just whitelisting mail from the domains on your list that pass SPF.  You are assuming that all mail from those hosts is as trustworthy as the mail from your list of good domains. I don't think that is a safe assumption. 

Scott K