On 2015-09-28 14:39, David Jones wrote:
I thought the same thing so I eased it in with the sqlgrey discrimination
option. My users never even knew I implemented it since I went live on
a Friday evening. I filter for almost 100,000 mailboxes and zero complaints
from users, just a lot less reports of spam to our support mailbox.
One other trick you can use, if you haven't already considered it and
are starting a fresh implementation, see if you can "prime" the database
by feeding recent history into the greylist "approved" list before you
start. Or if not, start with a 1 second greylist period for the first
couple weeks, such that any retry gets through, then raise it to a more
reasonable number once your greylist database has a more useful picture
of the type of mail you receive.
You could use the discrimination to just start with those rare 4 letter
and longer TLDs and ease into it.
I've had good success by only triggering greylisting if a session is
already suspicious in some fashion. My current criteria are:
- EHLO or rDNS mismatch.
- SPF fail or softfail.
- DKIM headers exist, but don't validate.
- SpamAssassin score over 4.9.
- "Suspicious" TLD (a moving target, I admit).
- Any DNSBL hit.
Some of these are applied at RCPT TO time, some not until DATA, but none
of these are candidates to reject mail outright, just to run it through
greylisting. If greylisting decides to let it through, it will get
accepted, but if not, maybe a 30 minute cool down period will be enough
for other DNSBLs or bayes to be ready to reject it outright.
You might also want to see if you can avoid greylisting some big
senders. There is zero advantage in greylisting Google, Outlook.com,
Outlook 365, Yahoo, AOL, etc, as you know they're real mail servers and
you know they will retry. For senders that send a large amount of good
mail, content filtering is worthwhile, but greylisting won't do anything
but potentially delay legitimate traffic.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
