This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SPF and rDNS check passing spoofed email

With SMTP Proxy enabled on the UTM220, most of our users are typically >98% spam free every month.  It seems since upgrading to 9.309-3, that emails spoofed as being sent from our users to their own addresses from IP's outside our address space are being delivered, despite Missing RDNS, Greylisting and SPF Check being enabled.

Example:
F= R= Accepted: to postmaster

The sender IP address listed in Mail Manager and the User Portal clearly contains an invalid IP address (not our own mx IP's) and there is no FQDN or SPF records coinciding with these invalid IP's.

Our own DNS records contain SPF, DKIM and rDNS records, so it's unclear why the UTM is passing spoofed mail.

It should be noted that when spam email originates from a sender other than a (spoofed) verified recipient, that these anti-spam features work as expected.

Any ideas?

Thanks, 

 - RB


This thread was automatically locked due to age.
Parents
  • 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
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 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
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 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)
  • 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))