[Dovecot] Odd Feature Request - RBL blacklist lookup to prevent authentication

[Robin]

On 10/22/2013 3:22 PM, Noel Butler wrote:
> But I agree with you on the rest, since of those 500K IP's Marc claims
> to have I'd bet that 99% are hijacked innocent pc's/servers, and of
> them, >75% would likely be a one time usage.

This accords with our own statistics.  While it IS tempting to treat 
every IP# that "spams" or hits you with a port-scan as something worthy 
of blackholing, the reality is that the vast majority of the attempts 
are from "innocent" victim hosts.

Now, there's little doubt that MOST of these are not legitimate MTA 
endpoints, and so "shouldn't" be issuing email directly to your MX 
hosts.  SPF + OpenDKIM are great, but only for those domains that 
actually use them; you can score "improperly delivered" emails bearing 
those domains with a policy defined by their operators, but many domains 
don't publish a policy.

I would caution people to avoid throwing out the baby with the 
bathwater.  I've been collecting an increasing number of "mysterious" 
email delivery problems to endpoints which do not issue DSN/bounces, 
*OR* provide any feedback to their users that emails have been "blocked".

The list includes some big names, like:

comcast (cable ISP subscribers)
secureserver.net hosted emails (GoDaddy's "hosted email" service, which 
uses Cloudmark's anti-spam solutions)
McAfee's "MXLogic" anti-spam services

McAfee's "SaaS/MXLogic" anti-spam service has a responsive false 
positive mediation system, whereas comcast's + GoDaddy's setups are 
thoroughly dysfunctional and broken.  Despite publishing SPF, fully 
specified OpenDKIM and using DomainKeys signing, having perfectly clean 
IP# reputations and not being on ANY RBLs, emails to those hosts is at 
best "random", or in comcast's case - when it's hosting "vanity domains" 
for its customers - completely broken.

I strongly suspect these inferior anti-spam systems are mistakenly 
ascribing fault for "Joe Jobbed" spam runs, even if they're delivered by 
non-compliant hosts as specified in the domain's SPF.  All of my clients 
"login" and issue emails through our MTAs, which are specified as 
permitted senders in SPF, so there are no "rogue" road warriors 
"allowed" by our domains' SPF policies.

My point is simple: it's easy to let frustration about spam get the 
better of you, but don't create worse problems for your users and those 
who try to legitimately reach them.  It's progressively making email 
less and less usable in a global context.

=R=