Milter-greylist

I am using the "racl whitelist spf pass" and I have not seen any junk
mail whitelisted by SPF so far - so I consider this as a safe enough option.
That's also why I do not agree with the proposed "awbyspf" option.

Big mail farms tend to fight with greylisting, yes, but they also
usually have SPF defined so the clause above will take a care of them
without my intervention.

Ondrej

Adam Katz wrote:
>
> > All the major ISP and email providers (such as gmail) use "mail farms"
> > to handle outbound SMTP connexions: mails in the output queue may be
> > processed (and retried) by whichever server in the farm.
>
> gmail is the only such farm I've encountered to both rotate servers on
> sending attempts AND exceed the number of servers to cause a problem.
> Now that I've been alerted to lazyaw, this is less of an issue (since
> popular sites send mail to/from lots of people, and other "mail farms"
> won't be as extensive as gmail, which I've already whitelisted).
>
> Scary "fun fact" - gmail lists almost 140,000 IPs in their SPF record.
>
> > So workarounds *must* be taken in greylist.conf:
> > - define "lazyaw" and "subnetmatch" to be more tolerant about incoming
> > submissions (sounds quite dirty to me);
>
> I didn't know about lazyaw. That almost solves my issue, though it breaks
> with free mail, universities, ISPs, and other giants (which is of course
> why I suggested using the sender address if the domain has 4+ MX records).
>
> To formalize: I propose an optional argument to lazyaw specifying the
> number of MX records a domain should have in order to make use of the
> sender address (so my earlier proposal would be implemented with "lazyaw
> 4"). Not specifying a number would make the default very high, depending
> on what Emmanuel et al think is a good default high threshold (maybe 5?);
> hotmail has only four (each of which maps to three IPs), and other big
> players seem to have 5+. 255 should be enough to disable the threshold.
>
> "subnetmatch" would end up whitelisting compromised DHCP subnets (which is
> likely common thanks to spammer viruses and thus very "dirty" indeed).
> My SPF suggestion should alleviate the need for subnetmatch on domains
> that properly use SPF. I'll call this feature proposal "awbyspf" and
> define it as "autowhitelist all of a domain's SPF-specified IPs when one
> passes." See also
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445841
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445841>
>
> > - locally whitelist by ACL (IP or domain match) all known server farms
> > (a pain to maintain, but quickly responsive in case of problem
> discovery);
>
> This is in place, but I again agree that this is a pain to maintain and
> not an acceptable long-term strategy.
>
> > - make use of centralized DNS whitelists such as list.dnswl.org by a
> > DNSRBL ACL clause;
>
> hrm. that's an idea (since i've already compiled dnsrbl support in).
> http://www.dnswl.org/tech <http://www.dnswl.org/tech> doesn't list
> configuration help for using dnswl
> with milter-greylist. it appears nontrivial due to their different
> response codes and milter-greylist's apparent need to know the response
> ahead of time. (Or perhaps I don't understand the option.) Advice?
>
> > - whitelist on behalf of sender's SPF record.
>
> I can't see using milter-greylist without the "nospf" option as
> responsible. If you're suggesting manual insertion of known problematic
> domains based on the mail servers listed in their SPF records, yes, I do
> that manually. If there were an option for this, that would be nice (it
> would be a trivial add-in if my "light lazy" feature is added).
>
> Ondrej Valousek wrote:
> >> racl whitelist spf pass
>
> It took me a while to figure out what "racl" was (I'm using
> milter-greylist 3.0 since 4.x isn't in debian unstable yet). It turns out
> that "racl" is a synonym for "acl," so your line appears to simply undo
> the "nospf" option that I consider a must-have.
>
> My "awbyspf" proposal autowhitelists all SPF records for a domain once one
> of them becomes autowhitelisted. milter-greylisting's built-in SPF
> capabilities only implement the first half of that (all SPF servers for
> all domains are always whitelisted).
>
>