Block spoofing emails

Hi,

I recommend setting SPF-records for your domain and enabling "Perfom SPF check" in SMTP->Antispam.

Hi Josef, thank you for your reply. 

SPF is always enabled and records are update-to-date, this seems to be an open relay problem in UTM.

Config looks ok.

You should do an "open-relay-test" (included here https://mxtoolbox.com/diagnostic.aspx ) and check the mail-log afterwards.

You should see "relay not permitted" for the mail from supertool@mxtoolboxsmtpdiag.com to test@mxtoolboxsmtpdiag.com

... but your mailsystem is configured to receive mail for users within your domain ... and it don't check if the sender is from your domain too. (may be, anoter location of your domain send the mail .. this may be ok)
If you activate SPF-check and SPF is configured ok and there is no exception ... the system should not accept mails from mail servers not included within the SPF-record.
You may PM me your domain and i will check the SPF record.

Hi dirkkotte, 

I can confirm the SPF is configured ok, we tested it many times on different testing sites and there are no issues.

I did the "open-relay-test" as you suggested, which seems to be an open relay, any suggestions on how to fix it in UTM, our MX records are all pointing to the UTM 9 server

This kooks like my installations.

Please check the UTM-Mail-log (within mail-manager). There i have "blocked - relay not permitted"

Do you really activate SPF filtering at UTM?

Yes, SPF filter is enabled 

I cannot see "blocked - relay not permitted" in Mail Manager.

just send an email from an external source as postmaster@yourdomain through the firewall and you have your open relay... no checks at all will be applied...

Which result do you see for the mail from supertool@mxtoolboxsmtpdiag.com to test@mxtoolboxsmtpdiag.com ?

Hi,

maybe you are completely on the wrong track, I don't think that there is a open relay problem in the UTM.

What was your problem:

Johnny Long said:

lot of our users have received spoofing emails that appear from themself

How exactly look this emails? Are the spoofed senders email-addresses maybe only in the body and not in the envelope FROM. Check the SMTP Log in the Mail Manager, what exactly is the from address here.

If these from-domain is your domain, then check your SPF-domainsettings in your DNS.

This is the email header looks like

Received: from EX2016-MDB-C.MYDOMAIN.Hosted (10.2.4.212) by
 EX2016-MDB-C.MYDOMAIN.Hosted (10.2.4.212) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8
 via Mailbox Transport; Wed, 4 May 2022 04:16:58 +1000
Received: from EX2016-MDB-AN.MYDOMAIN.Hosted (10.2.2.129) by
 EX2016-MDB-C.MYDOMAIN.Hosted (10.2.4.212) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2308.8; Wed, 4 May 2022 04:16:58 +1000
Received: from ip-1xxxxxxxx-2.compute.internal (10.2.6.109) by
 EX2016-MDB-AN.MYDOMAIN.Hosted (10.2.2.129) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.8
 via Frontend Transport; Wed, 4 May 2022 04:17:40 +1000
Received: from [10.2.6.120] (helo=mail.MYDOMAIN.net)
	by ip-1xxxxxxxx-2.compute.internal with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.90_1)
	(envelope-from <lxxxxx@xxxxx.com>)
	id 1nlx5g-0003dL-JJ
	for lxxxxx@xxxxx.com; Wed, 04 May 2022 04:17:40 +1000
Received: from mail.ghfhgdg.com ([85.239.34.13]:33068)
	by mail.MYDOMAIN.net with esmtps  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.95)
	(envelope-from <lxxxxx@xxxxx.com>)
	id 1nlx5X-00057p-2m
	for lxxxxx@xxxxx.com;
	Wed, 04 May 2022 04:17:32 +1000
Received: from ip63.ip-51-91-202.eu ([51.91.202.63]:53416 helo=galsan.com)
	by mail.ghfhgdg.com with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.95)
	(envelope-from <lxxxxx@xxxxx.com>)
	id 1nlx5V-0007v8-Vs
	for lxxxxx@xxxxx.com;
	Tue, 03 May 2022 21:17:28 +0300
X-SASI-Hits: BODYTEXTH_SIZE_3000_MORE 0.000000,
	BODYTEXTP_SIZE_3000_LESS 0.000000, BODYTEXTP_SIZE_400_LESS 0.000000,
	BODY_SIZE_10000_PLUS 0.000000, BODY_SIZE_25K_PLUS 0.000000,
	EXCESSIVE_SUBDOMAINS7 3.000000, FRAUD_ATTACH 0.050000,
	FROM_NAME_ALLCAPS 0.100000, FROM_RCPT_DOMAIN_NOT_IN_RCVD 0.000000,
	FROM_SAME_AS_TO_DOMAIN 0.000000, HTML_90_100 0.100000, HTML_95_100 0.100000,
	IMGSPAM_TABLE_1 0.000000, NO_FUR_HEADER 0.000000, NO_URI_HTTPS 0.000000,
	OUTBOUND 0.000000, OUTBOUND_SOPHOS 0.000000, SENDER_NO_AUTH 0.000000,
	SINGLE_HREF_URI_IN_BODY 0.000000, SINGLE_HREF_URI_WITH_EMAIL 0.000000,
	__ANY_URI 0.000000, __ATTACHMENT_PHRASE 0.000000, __BODY_NO_MAILTO 0.000000,
	__BULK_NEGATE 0.000000, __CSHC_NS_B_FN_FA 0.000000, __CT 0.000000,
	__CTYPE_HAS_BOUNDARY 0.000000, __CTYPE_MULTIPART 0.000000,
	__CTYPE_MULTIPART_ALT 0.000000, __DATA_URL_SCHEME 0.000000,
	__DATE_TZ_HK 0.000000, __DQ_NEG_DOMAIN 0.000000, __DQ_NEG_HEUR 0.000000,
	__DQ_NEG_IP 0.000000, __EXCESSIVE_SUBDOMAINS6 0.000000,
	__EXCESSIVE_SUBDOMAINS7 0.000000, __FAX_BODY 0.000000,
	__FILESHARE_PHRASE 0.000000, __FRAUD_ANTIABUSE 0.000000,
	__FROM_DOMAIN_IN_ANY_TO1 0.000000, __FROM_DOMAIN_IN_RCPT 0.000000,
	__FROM_NAME_NOT_IN_ADDR 0.000000, __FROM_NAME_NOT_IN_BODY 0.000000,
	__FUR_RDNS_SOPHOS 0.000000, __HAS_FROM 0.000000, __HAS_HTML 0.000000,
	__HAS_MSGID 0.000000, __HTML_AHREF_TAG 0.000000, __HTML_BAD_END 0.000000,
	__HTML_TAG_CENTER 0.000000, __HTML_TAG_IMG_X2 0.000000,
	__HTML_TAG_TABLE 0.000000, __IMGSPAM_TABLE_1 0.000000,
	__IMG_THEN_TEXT 0.000000, __MIME_HTML 0.000000, __MIME_TEXT_H 0.000000,
	__MIME_TEXT_H1 0.000000, __MIME_TEXT_H2 0.000000, __MIME_TEXT_P 0.000000,
	__MIME_TEXT_P1 0.000000, __MIME_TEXT_P2 0.000000, __MIME_VERSION 0.000000,
	__MULTIPLE_URI_TEXT 0.000000, __OUTBOUND_SOPHOS_FUR 0.000000,
	__OUTBOUND_SOPHOS_FUR_IP 0.000000, __OUTBOUND_SOPHOS_FUR_RDNS 0.000000,
	__PHISH_PHRASE10_D 0.000000, __RCPT_DOMAIN_IS_FROM_DOMAIN 0.000000,
	__SANE_MSGID 0.000000, __SUBJ_ALPHA_END 0.000000, __TAG_EXISTS_HTML 0.000000,
	__TO_DOMAIN_IN_FROM 0.000000, __TO_DOMAIN_IN_MSGID 0.000000,
	__TO_MALFORMED_2 0.000000, __TO_NO_NAME 0.000000,
	__URI_EMAIL_IN_QUERY 0.000000, __URI_IN_BODY 0.000000, __URI_MAILTO 0.000000,
	__URI_NOT_IMG 0.000000, __URI_NO_PATH 0.000000, __URI_NO_WWW 0.000000,
	__URI_NS 0.000000, __URI_WITHOUT_PATH 0.000000
X-SASI-Probability: 30%
X-SASI-RCODE: 200
X-SASI-Version: Antispam-Engine: 4.1.4, AntispamData: 2022.5.3.173622
From: HOA ORDERS <lxxxxx@xxxxx.com>
To: <lxxxxx@xxxxx.com>
Subject: Requested HOA Letter
Date: Wed, 4 May 2022 02:17:27 +0800
Message-ID: <20220504021727.BFD45D6D250BF3FA@xxxxx.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_1F95ED89.02DDA1DF"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.ghfhgdg.com
X-AntiAbuse: Original Domain - xxxxx.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xxxxx.com
X-Get-Message-Sender-Via: mail.ghfhgdg.com: authenticated_id: dennis@ghfhgdg.com
X-Authenticated-Sender: mail.ghfhgdg.com: dennis@ghfhgdg.com
X-Source:
X-Source-Args:
X-Source-Dir:
Return-Path: lxxxxx@xxxxx.com
X-MS-Exchange-Organization-Network-Message-Id: 2be4961d-c269-4b3a-e3f4-08da2d3135da
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-AuthSource: EX2016-MDB-AN.MYDOMAIN.Hosted
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Processed-By-BccFoldering: 15.01.2308.008

Ok, I suggest xxxxx.com stands for your domain.

Which hop is your UTM? mail.MYDOMAIN.net?

How looks your SPF-Setting in the DNS?

Ok, I suggest xxxxx.com stands for your domain.

Which hop is your UTM? mail.MYDOMAIN.net?

How looks your SPF-Setting in the DNS?

Yes, mail.MYDOMAIN.net is the UTM hop.

This is what the SPF settings look like:
v=spf1 mx ip4:13.xx.xx.xx ip4:13.xx.xx.xx ip4:13.xx.xx.xx ip4:13.xx.xx.xx ip4:13.xx.xx.xx include:spf.messagelabs.com include:spf.protection.outlook.com include:spf.smtp2go.com ~all

Can anyone spot any issues?

Ok so you use "Softfail" (~all) in your SPF-policy, these will not stop the spoofed mail on the UTM.

More details see here Sophos UTM: Enable Sender Policy Framework (SPF)

"... Your SPF record should contain the token "-all" at the end not "~all". This is a common reason why people are not rejecting spoofed mail as expected."

Hi Josef, I know we use "Softfail", but we have "Perform SPF check" turned on and I can see a lot of emails got rejected because of SPF check failed.

I still think we have is an open relay problem, not an SPF problem.

If you don't check your own mail logs after doing the OpenRelay test, you would never really know this.

PS: and i think SPF soft-fail will pass UTM-Spam filter. (you may check SPF-records from SPF-blocked mails)

As said the UTM will not reject when the SPF-policy is set to Softfail, this is documented in the link I posted.

All the mails which you see rejecting for sure have a Hardfail SPF-policy. Your Domain have a Softfail-policy, so the mails got not rejected. The Feature "Perform SPF check" just enable the check general.

Good morning, Johnny.  You got the answer from both Dirk and Josef.

Cheers - Bob

Apologies for the late reply.

Unfortunately, the solutions proposed didn't work, we updated SPF to "hard fail" but it still doesn't stop the phishing emails.

Here is the email header looks like -

Received: from EX2016-MDB-AN.xxx.hosted (10.2.4.129) by
 EX2016-MDB-AN.xxx.hosted (10.2.4.129) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.8
 via Mailbox Transport; Wed, 20 Jul 2022 14:15:40 +1000
Received: from EX2016-MDB-AN.xxx.hosted (10.2.4.129) by
 EX2016-MDB-AN.xxx.hosted (10.2.4.129) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.2308.8; Wed, 20 Jul 2022 14:15:40 +1000
Received: from ip-10-2-3-109.ap-xxxx.compute.internal (10.2.5.109) by
 EX2016-MDB-AN.xxx.hosted (10.2.4.129) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.8
 via Frontend Transport; Wed, 20 Jul 2022 14:15:40 +1000
Received: from [10.2.4.120] (helo=mail.xxx.com)
	by ip-10-2-3-109.ap-southeast-2.compute.internal with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.90_1)
	(envelope-from <user@xxx.com>)
	id 1oE17c-0004qV-OG
	for user@xxx.com; Wed, 20 Jul 2022 14:15:40 +1000
Received: from [185.222.58.69] (port=62467 helo=xxx.com)
	by mail.xxx.com with esmtp (Exim 4.95)
	(envelope-from <user@xxx.com>)
	id 1oE17W-0001WW-0x
	for user@xxx.com;
	Wed, 20 Jul 2022 14:15:34 +1000
From: xxx.com Server <user@xxx.com>
To: <user@xxx.com>
Subject: Three (4) Incoming mails not delivered
Date: Wed, 20 Jul 2022 06:15:30 +0200
Message-ID: <20220720061530.C5379167367D62FD@xxx.com>
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-Path: user@xxx.com
X-MS-Exchange-Organization-Network-Message-Id: e0bd540b-123e-4816-8107-08da6a0681e5
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-AuthSource: EX2016-MDB-AN.xxx.hosted
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Transport-EndToEndLatency: 00:00:00.1880204
X-MS-Exchange-Processed-By-BccFoldering: 15.01.2308.008

Received: from [185.222.58.69] (port=62467 helo=xxx.com)
by mail.xxx.com with esmtp (Exim 4.95)
(envelope-from <user@xxx.com>)
id 1oE17W-0001WW-0x
for user@xxx.com;
Wed, 20 Jul 2022 14:15:34 +1000

The first "Received: from [185.222.58.69]" is not in the SPF record, yet it is the IP that the email originated from.

Hi,

send me a PM with the real log.

Josef will help you.  The line we would need to see is the one where the SMTP Proxy receives the email.  That line would be above those you posted.

     Received: from mail-dm6nam10on2109.outbound.protection.outlook.com ([40.107.93.109]:27105 helo=NAM10-DM6-obe.outbound.protection.outlook.com)
         by xxxxx.mediasoftusa.com with esmtps

The above came from a client at a company that hosts their email with outlook.  40.107.93.109 is included in the SPF record for spf.protection.outlook.com.

Cheers - Bob

Thank you all, I have sent a pm to Josef.

We received another phishing attack, the attacker managed to pass the SPF check

 Authentication-Results: wps01.wadax.ne.jp;
spf=pass (sender IP is 18.119.141.193) smtp.mailfrom=abc@xxx.com smtp.helo=[127.0.0.1]
Received-SPF: pass (wps01.wadax.ne.jp: connection is authenticated)

I have no idea how they could they do that? the IP is probably in one of these includes

include:spf.messagelabs.com include:spf.protection.outlook.com include:spf.smtp2go.com