SPF and rDNS check passing spoofed email

Hi, RB, and, after 8+ years, welcome to active participation in the User BB!

This is usually caused by an Exception.  If that isn't enough to go on, please post all of the log lines for the email above.

Cheers - Bob

Hello RB

As the according your description mails are faked with your own domain as sender, this sounds like backscatter to me. This can happen, if for example spammers miuse your domain @example.com for sending spam, and you are the lucky one receiving all backscatter rejected by all spamfilters around the world.

Simple solution should be to activate BATV on the UTM, which will reject such mails from your own domain, as they got not "signed" by the UTM with a PRVS signature during sending out, and therefor rejects such returing mails from your domain you've never sent out.

/Sascha

Thank you for the welcome, Bob and thanks to you and Sascha for your replies.

I would classify the emails being received more as Joe Jobbing rather than backscatter, as the mails received are not bounce notifications, but rather spam spoofed using legitimate user's addresses or domains as the sender.  

In prior events, SPF checking and missing/invalid rDNS rejections were rather efficient at preventing Joe Jobbing from reaching the users.

We have found it effective having greylisting exception rules for well known sources such as *@gmail.com, *@yahoo.com, *@aol.com, etc.  Since the UTM is very effective at determining the actual sender host vs implied sender host (From: address via the envelope), this effort has not seemed to have any impact on increasing spam and reduces wait times for well known sources.  In reviewing the exception rules, per your suggestion, Bob, we did find a few secondary domains in our system that were included as exception source addresses in error.  

While this does not explain why SPF checking and missing rDNS were affected, the removal of these greylisting sources appears to have improved this issue.

Sascha, once upon a time, we sent outbound SMTP directly from the MTA, rather than the UTM, which prevented the use of BATV, (along with Sophos' warning that BATV may not be compatible with all receiving mail systems...)  Having lately discovered the joys of using DKIM and SPX, now all outbound mail relays through the UTM as well, and initial BATV tests over the last several days seem positive.

I do have one question on a log entry spotted which I found curious... 
2015:03:25-22:32:40 mx exim-in[32026]: 2015-03-25 22:32:40 1Yb0PH-0008KY-1y Greylisting: Successful greylist retry from 14.169.63.181 (original host was 83.111.229.98/32)

If greylisting can hop IP's as indicated above, would that not dilute the effectiveness?  Did not know this was possible.  (In this case, both IP's were spoofed and managed to bypass greylisting, rDNS checks and SPF checks, with mail finally delivered)  Still a bit of a mystery...


Best Regards,

 -- Ron

(Since ASL V4)

It sounds like you know your stuff, Ron, so I'm mystified as I've always seen either Sascha's or my guess as the cause.  You might want to get Sophos Support involved.

Cheers - Bob

Hello Ron

...Having lately discovered the joys of using DKIM and SPX, now all outbound mail relays through the UTM as well, and initial BATV tests over the last several days seem positive.

Sounds so far so good [;)]

I do have one question on a log entry spotted which I found curious... 
2015:03:25-22:32:40 mx exim-in[32026]: 2015-03-25 22:32:40 1Yb0PH-0008KY-1y Greylisting: Successful greylist retry from 14.169.63.181 (original host was 83.111.229.98/32)

If greylisting can hop IP's as indicated above, would that not dilute the effectiveness?  Did not know this was possible. 

This behaviour was changed in the past AFAIK, because many ISP's use multiple MTAs, and greylisted retries may source from new IP's every time. This led in some cases to long deliver times, until a retry was donw from a previously known IP. This also shouldn't "dilute" the functionality, as it's "good and RFC compliant" SMTP behaviour to retry sending mails, and in the past when greylisting was introduced, spammers (BOTs and co.) didn't retry but instead simply bobmed out thousands of mails ignoring all protocol specifics and replays from spam gateway. Those "stupid" bot senders also got more intelligent over the years I guess, as in my eyes greylisting still may stop some "stupid" spams, but in most cases the other methods as RDNS, SPF and RBL does them block too. So in my eyes greylisting got little outdated todays...the little benefits does not justify the added receiving delays anymore in my eyes (personal philosophy ;o))

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