Milter-greylist

> 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

> - 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 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).