Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 21 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 17324 views
  • Users 0 members are here
Options
Suggested
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

Sophos XG 17.5 - SPF Check not working

Björn Ebner

I installed Sophos XG 17.5 on a Sophos XG in HA Active/Passive Cluster.

Yesterday and today we received several E-Mails from user@domain.com to our internal domain user@domain.com.

SPF-Records are set for domain.com.

The E-Mail was sent from an external adress that doesn't match the SPF-Record.

All these mails were accepted without restrictions or filtered out as beeing probable Spam.

 

The Policy is configured accordingly and SPF Check is activated in the Policy.

It looks like SPF isn't checked at all.

 

I already opend a ticket with our Distribution and waiting for response.

Anyone here experiencing the same?



This thread was automatically locked due to age.
Parents
  • 0

    Can you show us the mail header of this email?

    Maybe they only spoof the FROM? 

  • 0 in reply to LuCar Toni

    This is the header (anonymized) of an example Mail that got through:

    Received: from mail.domain.com (192.168.2.222) by
     SBSPZ2011.domain.local (192.168.2.2) with Microsoft SMTP Server (TLS)
     id 14.3.382.0; Thu, 6 Dec 2018 11:25:35 +0100
    Received: from emkei.cz ([46.167.245.206]:51434 helo=localhost)    by
     mail.domain.com with esmtps (TLSv1.2:AECDH-AES256-SHA:256)    (Exim 4.91)
        (envelope-from <administrator@domain.com>)    id 1gUqqF-0001Vp-Hs    for
     administrator@domain.com; Thu, 06 Dec 2018 11:25:11 +0100
    Received: by localhost (Postfix, from userid 33)    id F2BE6D5CF7; Thu,  6 Dec
     2018 11:25:10 +0100 (CET)
    To: <administrator@domain.com>
    Subject: Test Fakemail
    From: Administrator <administrator@domain.com>
    X-Priority: 3 (Normal)
    Importance: Normal
    Errors-To: administrator@domain.com
    Reply-To: <administrator@domain.com>
    Content-Type: text/plain; charset="utf-8"
    Message-ID: <20181206102510.F2BE6D5CF7@localhost>
    Date: Thu, 6 Dec 2018 11:25:10 +0100
    X-Sophos-IBS: success
    X-CTCH-PVer: 0000001
    X-CTCH-Spam: Unknown
    X-CTCH-VOD: Unknown
    X-CTCH-Flags: 0
    X-CTCH-RefID: str=0001.0A0C0207.5C08F907.00BE,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
    X-CTCH-Score: 0.000
    X-CTCH-ScoreCust: 0.000
    X-CTCH-Rules:
    X-Sophos-Firewall: smtpd v1.0
    MIME-Version: 1.0
    Return-Path: administrator@domain.com
    X-MS-Exchange-Organization-AuthSource: SBSPZ2011.domain.local
    X-MS-Exchange-Organization-AuthAs: Anonymous

     

    The same mail that came through on this domain was catched by Office 365 in SPF Check.

  • 0 in reply to HuberChristian

    Previously there was an exception but to skip SPF.

    Currently there is no exception for this domain.

    I could reproduce the same behaviour on Sophos UTM 9.510.

  • 0 in reply to Björn Ebner

    Meanwhile I tested with XG17.5 and https://emkei.cz as fakemailer as you did.

    First mail was dropped because emkei.cz uses inproper RDNS (localhost instead of something valid.)

    Switched RDNS-Check off in my XG.

    Second mail was dropped because of Greylisting.

    Switched this off in my XG.

    Third mail was dropped because lack of authentication (It's a Mail of my domain, but the user did not authenticate, so it was dropped).

    If you switched off all those protection features, I can well imagine you do have issues recieving that kind of spam... Furthermore you maybe should check what you configured under "Host based relay".

     

    Any shouldn't be in there :)

  • 0 in reply to HuberChristian

    I know that this Fake Mailer doesn't have a valid RDNS Entry.

    I just disabled it to be able to test it with this Fake Mailer.

    The original mail, that was the reason I started testing, did have a valid RDNS Entry, so that wouldn't have helped.

    Greylisting is currently turned off because it often takes some time for mails to get delived, which is the downside of this mechanism.

    Do you mean a authenticated relay, when you mention authentication?

    I'm using Host Based Relays, which doesn't stop that. ;)

    Update:

    I got response from Sophos Support.

    It seems that E-Mail that are sent from a protected domain are treated like outgoing mails and it isn't checked if they are coming from a host that may relay emails.

    So no SPF Check is performed on this emails. It seems that Sophos UTM does handle this similar.

    Currently that seems to be the case.

    Maybe it would be good to open a sugestion regarding this.

  • 0 in reply to Björn Ebner

    Thanks for reporting the issue. Email sent from internal domain to internal domain from Internet also should get thru SPF check. We acknowledge the issue and we are tracking this bug with JIRA ID NC-41574. It will get fixed in upcoming MR.

  • 0 in reply to vishalpatel

    Any idea, why this Bug isn't listed in the actual Known Issue List?

  • 0 in reply to Björn Ebner

    Most likely we are not going to update the KIL for issues, which are going to be fixed in the next release. 

    Most of our customers are going to use the Community / Sophos support to get the information, whether there is an bug or a known behavior of the product. 

    My personal approach to this. 

  • 0 in reply to LuCar Toni

    Thank you for the clarification.

  • 0 in reply to LuCar Toni

    LuCar Toni said:

    Most likely we are not going to update the KIL for issues, which are going to be fixed in the next release. 

     

    According release notes (https://community.sophos.com/products/xg-firewall/b/xg-blog/posts/sfos-17-5-mr1-released), this Issue was not fixed in 17.5 MR1... Maybe you can give us a timeline for this?

  • 0 in reply to LuCar Toni

    I can't see that this is fixed in 17.5.3 and it doesn't show up in the KIL List.
    Any news on this?

  • 0 in reply to HuberChristian

    A little bit off-topic but my experience with greylisting and SPF was not good.

    Greylisting: every email got greylisted, no matter if the sender was known to us. I suppose that at least after sending an email to an email address emails from this address should not be greylisted in the future... last tested with 17.0.5 and decided it slows down communication too much (some mails were blocked for several hours)

    SPF: even well-known companies seem to have wrong SPF entries so too many emails were blocked or quarantined. Rated as not useful as long if SPF entries are mainly in a bad constitution

     

    Any suggestions on this are appreciated. Thanks.

Reply
  • 0 in reply to HuberChristian

    A little bit off-topic but my experience with greylisting and SPF was not good.

    Greylisting: every email got greylisted, no matter if the sender was known to us. I suppose that at least after sending an email to an email address emails from this address should not be greylisted in the future... last tested with 17.0.5 and decided it slows down communication too much (some mails were blocked for several hours)

    SPF: even well-known companies seem to have wrong SPF entries so too many emails were blocked or quarantined. Rated as not useful as long if SPF entries are mainly in a bad constitution

     

    Any suggestions on this are appreciated. Thanks.

Children
  • 0 in reply to Jelle

    Not checking SPF because senders don't set their SPF Records correctly is not the solution.

    That's a problem or the sender that the sender should address.

  • 0 in reply to Björn Ebner

    In the beginning I started to address these senders and their admins but nothing happened. Didn't even get response. And internal users kept pushing because they didn't get expected mails from these senders. So what to do?

  • 0 in reply to Jelle

    The last resort would be to configure a Exception for those sender domains.
    But that is something that the sender should adress because in this case you are not the only one who can't receive mails of this sender.

    If no SPF-Record is set there is no problem.
    If a SPF-Record is set the administrator of the sender should know what he does.

    If not he has to expect E-Mails not being delivered anymore.

     

    I didn't have the experience that many SPF-Records are set incorrectly.