Sophos XG 17.5 - SPF Check not working

Can you show us the mail header of this email?

Maybe they only spoof the FROM? 

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.

In my Tests during Beta, SPF was working. Unfortunatedly, anonymized Mailheaders do not help in this case... Nobody can proof how the SPF Record looks like...

In UTM's world softfail was ignored. Maybe your customer is using softfail as well instead of hardfail (~ instead of -).

Additionally, you should provide Logfiles to your Partner (/log/smtpd_main.log) and name him a Timestamp where this mail was sent. This will help for further troubleshooting (cause here we cannot due to lack of informations).

Edit: Just found your Support Case in our system. It's not configured to be softfail on this Domain. As seen, my colleague is allready helping you. I'll let him do his work :-)

In my Tests during Beta, SPF was working. Unfortunatedly, anonymized Mailheaders do not help in this case... Nobody can proof how the SPF Record looks like...

In UTM's world softfail was ignored. Maybe your customer is using softfail as well instead of hardfail (~ instead of -).

Additionally, you should provide Logfiles to your Partner (/log/smtpd_main.log) and name him a Timestamp where this mail was sent. This will help for further troubleshooting (cause here we cannot due to lack of informations).

Edit: Just found your Support Case in our system. It's not configured to be softfail on this Domain. As seen, my colleague is allready helping you. I'll let him do his work :-)

Great. :)

I'm waiting for his response.

It's kind of strange that it doesn't work.

Maybe I do misunderstand the configuration completely or something is not working as it should be.

Just wanted to see if there are others were SPF does or doesn't work. :)

Update:

SPF Checking seems to work fine if any external address is used as sender.

It doesn't semm to work when as sender an internal domain is used for which a smtp policy is present.

Maybe you have configured any exception for this on a Domain Level, which is skipping SPF ?

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.

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 :)

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.

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.

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

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. 

Thank you for the clarification.

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?