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

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.

Best regards,
Constantine.