SPF and rDNS check passing spoofed email

Spam rejection percentages

Like Sascha, I don't recommend Greylisting.  Here are some statistics from our SMTP Proxy.  We have about 2.4% of incoming mail that is quarantined, 81.7% is rejected and the rest (about 7 for every mail that was quarantined) is delivered.  You can see that very little spam even gets to the point where its "signature" is calculated and checked against CYREN's cloud service.

I bet an experiment would show that no email that would fail greylisting would get past all of the following rejection tests (presented, I think, in the order in which they are checked):

RHDS/HELO   33.8%

RBL         48.0%

BATV         0.5%

Rcpt Verif  17.5%

SPF          0.2%

Cheers - Bob
PS Did disabling Greylisting stop the problem you were seeing with delivered spams?

That's a great explanation, Sascha, and it makes good sense as to why greylist operations are able to jump IP's.

We once considered greylisting to be the equivalent a blunt instrument.  Where its proven effective for us, is those dozen or so new random /24's that seem to spring up almost daily, spewing spam from servers up and down the last octet.  The spammers are dumb enough to practice "fire and forget" practices, yet smart enough to include rDNS in their IP's.  Therefore, rDNS tests are satisfied, there is no SPF listing, (still considered optional by RFC), and send addresses are new enough that they haven't hit the RBL's quite yet.  Greylisting stops all this spam activity cold.  The exception list we employ (as described previously) eliminates the delay from well known sources, vendors and clients.  Yes, new mail from outside this scope will be delayed, but in comparison, it represents a small percentage of legitimate incoming email and the delay in these cases is not inordinate.  For our situation, the anti-spam benefits of greylisting outweigh the downside.  We used to blacklist these /24's manually in UTM's Blocked Hosts/Networks, once identified, although they they ultimately would be added to global RBL's, so our efforts were the equivalent of whack-a-mole.  Greylisting (with appropriate exceptions) resolved this issue.

We used to use Strict rDNS rules, but abandoned this after too many user complaints of high priority incoming mail being bounced.  (It seems there are many large companies who run their own mail domains that don't believe that all RFC's apply to them...)

We haven't really seen any repeat performance of the Joe Jobs since removing secondary domain sources that were erroneously included in the exception list.  Could be coincidental or contributory.  If the behavior returns, we'll drop a trouble ticket with Sophos (thanks for the suggestion, Bob), and post our findings back here on the Sophos BB.

Regards,

 -- Ron

That's a great explanation, Sascha, and it makes good sense as to why greylist operations are able to jump IP's.

We once considered greylisting to be the equivalent a blunt instrument.  Where its proven effective for us, is those dozen or so new random /24's that seem to spring up almost daily, spewing spam from servers up and down the last octet.  The spammers are dumb enough to practice "fire and forget" practices, yet smart enough to include rDNS in their IP's.  Therefore, rDNS tests are satisfied, there is no SPF listing, (still considered optional by RFC), and send addresses are new enough that they haven't hit the RBL's quite yet.  Greylisting stops all this spam activity cold.  The exception list we employ (as described previously) eliminates the delay from well known sources, vendors and clients.  Yes, new mail from outside this scope will be delayed, but in comparison, it represents a small percentage of legitimate incoming email and the delay in these cases is not inordinate.  For our situation, the anti-spam benefits of greylisting outweigh the downside.  We used to blacklist these /24's manually in UTM's Blocked Hosts/Networks, once identified, although they they ultimately would be added to global RBL's, so our efforts were the equivalent of whack-a-mole.  Greylisting (with appropriate exceptions) resolved this issue.

We used to use Strict rDNS rules, but abandoned this after too many user complaints of high priority incoming mail being bounced.  (It seems there are many large companies who run their own mail domains that don't believe that all RFC's apply to them...)

We haven't really seen any repeat performance of the Joe Jobs since removing secondary domain sources that were erroneously included in the exception list.  Could be coincidental or contributory.  If the behavior returns, we'll drop a trouble ticket with Sophos (thanks for the suggestion, Bob), and post our findings back here on the Sophos BB.

Regards,

 -- Ron