SPF Failures with Backup MX That Should Be SPF_Pass

Problem reported by ScottF - 2/7/2018 at 1:05 PM

Resolved

Recently I upgraded our primary and backup MX to SM 15.7.6607. I discovered messages from domains setup with SPF and routed through the gateway failed SPF. Messages delivered directly to the primary server passed SPF. Is it possible that the Bypass Gateways feature on the primary server is not working?

I also tested a primary SM server running 16.3.6607 and a gateway running 15.7.6607. Messages routed through the gateway also failed SPF. Also, found that the Bypass Greylisting setting for the Bypass IP feature in 16.x did not work. The message from the gateway was delayed by greylisting.

Can anyone else confirm this behavior? Thanks.

34 Replies

Reply to Thread

ScottF Replied

2/12/2018 at 8:59 AM

I did some testing with SM 15.7.6614 and 16.3.6614. Still have SPF failures that should be SPF_Pass.

1. Primary and Gateway running 15.7.6614. Messages routed through the gateway fail SPF.

2. Primary running 16.3.6614 and GW running 15.7.6614. Messages routed through the gateway fail SPF.

Messages routed directly to the primary servers pass SPF.

Can anyone else confirm this behavior?

Thanks,

Scott

Steve Guluk Replied

2/12/2018 at 10:47 AM

I'm getting PTR issues as SM is sending Forwards out on seemingly random IPs from my server. The IPs are all present but not bound to the primary domain.

Maybe related?

kevind Replied

2/15/2018 at 2:34 PM

Checking to see if there are any updates on this.

Thanks,

Kevin

kevind Replied

2/15/2018 at 2:40 PM

This problem is with incoming messages that pass thru a gateway, so guessing it's not related.

Matt Petty Replied

2/16/2018 at 7:41 AM

Employee Post

We've put in a fix and it will be in today's release.

Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com

kevind Replied

2/16/2018 at 8:33 AM

Great! v15 also? Thanks.

ScottF Replied

2/19/2018 at 8:09 AM

Still have SPF failures that should be SPF_Pass.

I did some testing with a SM 15.7.6614 gateway and a 16.3.6621 primary server. The gateway's IP is setup in Antispam - IP Bypasses on the 16.3.6621 primary server with Bypass Spam Checks and Greylisting checked.

1. I found that messages routed through the gateway to the primary still fail SPF when they should pass.
2. The primary server greylists messages routed from the gateway.
3. Messages routed directly to the primary server pass SPF.

Can anyone else confirm this behavior? Thanks.

Employee Replied

2/19/2018 at 9:59 AM

Employee Post

In SmarterMail 16 we added the ability to perform SPF checks on SMTP sessions where as before they used to only run during the delivery session. The SMTP level SPF checks perform the check against the IP address used to connect into the SMTP session, since this would be the gateway IP and not the authorized IP for the domain, this would fail.

SmarterMail version 16.3.6621 should have contained a fix that would skip the SPF check on the SMTP level.

Now this requires you to have a bypass IP setup for your gateway, these are configured under Settings -> Antispam -> IP Bypasses.

Release note for the fix:
Changed: SPF is skipped at the SMTP level if it is being received by a gateway or bypass IP; runs at the spool level, if enabled.

Do you have the IP Address of the gateway listed under the IP Bypass section and have the option setup for 'Bypass Spam Checks' enabled ?

Merle Wait Replied

2/19/2018 at 12:00 PM

so to be clear, when a new inbound gateway is set-up, we have to setup ByPass Spam Checks as well, OR because it is an inbound gateway, nothing more is required for set-up on the main server??

Employee Replied

2/19/2018 at 12:13 PM

Employee Post

Merle, when configuring the Inbound Gateway, no action is required for the IP bypass list.

However, on the primary server, you will want to add the IP address of the Inbound Gateway to the IP Bypass list to ensure the SPF checks are not being ran on the SMTP level for the connections from the incoming gateway to your main server. 'Bypass Spam Checks' is not required for this behavior to take place.

Employee Replied

2/22/2018 at 10:48 AM

Employee Post

Kevin, We're still working on the issue in SmarterMail 15, we should have this behavior corrected in the next minor update. If you'd like to submit a support ticket we can provide you with a custom build once it's available, this ticket will be credited back to your account as well.

kevind Replied

2/22/2018 at 12:18 PM

Von-Austin, glad you're on the case! Thanks for update and looking forward to the fix. I can just wait for the next minor unless you need me to open a ticket to make sure it gets done.

BTW, I didn't see anything in the release notes, but I think you can mark this similar problem as resolved:
https://portal.smartertools.com/community/a90262/dkim-failures-with-backup-mx.aspx

Colton Morrison Replied

2/27/2018 at 8:45 AM

I have run into this bug as well. We use the SmarterMail gateway function and all SmarterMail servers run 15.7.6614. We also have been using our own Barracuda device as an alternative in/outbound gateway.

There have been no problems until the recent upgrade this weekend when SmarterMail decided that the AntiSpam > Bypass Gateway entries no longer mattered. In previous versions this operated just fine.

New Headers with two X-Src-Center entries:

Return-Path: <xxxxxxxxx@gmail.com>
X-Src-Sender: (xxxxxpopout.cxxxxions.com) [SMGatewayIP]:49483
Received: from gwxxxx1.oxxxxxks.net (xxxxxpopout.cxxxxions.com [SMGatewayIP]) by gwxxxx1.oxxxxxks.net with SMTP;
   Tue, 27 Feb 2018 10:29:01 -0500
X-Src-Sender: (mail-uxxxxxx.google.com) [209.85.217.170]:35081

Old Header with no X-Src-Sender Entries and correct processing:

Return-Path: <xxxxxxxxx@creativeworks.org>
Received: from gwxxxx1.oxxxxxks.net (xxxxxpopout.cxxxxions.com [SMGatewayIP]) by mail.oxxxxxkxxs.net with SMTP;
   Thu, 15 Feb 2018 14:40:35 -0500
Received: from zh-gw.zixsmbhosted.com (spfdal-g.zixsmbhosted.com [199.30.234.212]) by gwxxxx1.oxxxxxks.net with SMTP
   Thu, 15 Feb 2018 14:40:41 -0500

This is a major problem for thousands of people now. When is this being fixed???

Colton Morrison Replied

2/27/2018 at 9:00 AM

Von-Austin,

My understanding from this is:
If you have a SmarterMail Incoming Gateway, you specify the following settings

On the Incoming Gateway Server: Manage > Routing > Incoming Gateways > Specify your Gateway Mode and Primary server.

On the Primary Server: Security > Antispam Administration > Bypass Gateways
Add IP Address(es) of the Incoming Gateway Server.
This is for what you said: "ensure the SPF checks are not being ran on the SMTP level for the connections from the incoming gateway to your main server."

This is based on SM15.4.6151 (not SM16). Please clarify if anything is incorrect.

Employee Replied

2/27/2018 at 9:43 AM

Employee Post

Thanks Kevin, glad to hear the issue has been resolved. I've updated the related thread accordingly.

Employee Replied

2/27/2018 at 10:00 AM

Employee Post

Colton,

This is correct for SM 15 with the exception for "ensure the SPF checks are not being ran on the SMTP level for the connections from the incoming gateway to your main server."

The SPF checks being performed on the SMTP level functionality was added in SmarterMail 16. You would simply exclude this step in 15.

Employee Replied

2/27/2018 at 10:03 AM

Employee Post

Colton, this issue has already been fixed on our end and will be released publicly in our next minor update. I've sent you a PM with a link to a pre-release build that you can apply to correct this behavior. If the behavior persists with this custom build please open a ticket with our support department so we can review further.

Colton Morrison Replied

2/27/2018 at 10:08 AM

Thank you!!

kevind Replied

2/27/2018 at 10:41 AM

OK and I see the ver. 15 problem reported here in this thread is fixed with a custom build. Do you know when it will be publicly released? If later this week, we can wait. Thanks.

Employee Replied

2/27/2018 at 11:01 AM

Employee Post

Kevin, I just had a chat with one of our SM dev's, looks like we will be pushing out a minor release of 15 this week on Thurs\Friday.

kevind Replied

2/27/2018 at 12:22 PM

OK, sounds good.

kevind Replied

2/27/2018 at 12:26 PM

Suggestion to Improve QA

Just a polite suggestion to the SM team. We need to try and improve Quality Assurance so that when existing bugs are fixed, it doesn't introduce new ones like this. It causes a lot of extra work as we need to roll back or wait for the next release. That might not sound like a big deal, but for sites with multiple servers and/or hundreds of users, all this maintenance needs to be done off hours. Thanks for your support and if there's any way for the community to help, let us know.

Merle Wait Replied

3/3/2018 at 9:48 AM

sooo... the "minor update for SM15 references.. were a couple of weeks ago, but the last SM15.X upgrade was Feb 9th? When will the next SM15 upgrade be rolling out?

Matthew Leyda Replied

3/3/2018 at 9:53 AM

Good Question.

Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP

Matt Petty Replied

3/5/2018 at 7:40 AM

Employee Post

We pushed the minor this morning.

Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com

Colton Morrison Replied

3/19/2018 at 6:23 AM

I don't see this is fixed...in this build. We still have these SPF checks scoring incorrectly.

I've updated to this version on our mail server. Here is what I see:

2018.03.18] 06:33:47 [82159] Delivery started for xxxxxxxxx@gmail.com at 6:33:47 AM

[2018.03.18] 06:33:54 [82159] Spam check results: [_REVERSEDNSLOOKUP: passed], [_NULLSENDER: passed], [_BAYESIANFILTERING: passed], [_COMMTOUCH: 0,Unknown], [_SPF: SoftFail], [BARRACUDA - BRBL: passed], [SPAMCOP: passed]

[2018.03.18] 06:33:47 [82160] Delivery started for xxxxxxxxx@gmail.com at 6:33:47 AM
[2018.03.18] 06:33:54 [82160] Spam check results: [_REVERSEDNSLOOKUP: passed], [_NULLSENDER: passed], [_BAYESIANFILTERING: passed], [_COMMTOUCH: 0,Unknown], [_SPF: SoftFail], [BARRACUDA - BRBL: passed], [SPAMCOP: passed]

I no longer see that X-Src-Sender line in the header.

What's going on here?

ScottF Replied

3/19/2018 at 7:40 AM

Yes, 15.7.6638 still has the problem. Messages delivered from the gateway to the primary fail SPF when they should pass. We have an open ticket so ST knows it needs fixed.

SmarterMail 16.x does not have the problem.

Colton Morrison Replied

3/19/2018 at 7:50 AM

Thanks Scott,
Great....Did they say when 15.x will receive the fix?

ScottF Replied

3/19/2018 at 11:14 AM

They did not provide an ETA.

kevind Replied

3/19/2018 at 11:52 AM

The latest version of SM15 (Mar-5) has this in the release notes:

Changed: SPF is skipped at the SMTP level if it is being received by a gateway or bypass IP; runs at the spool level, if enabled.

But evidently this change did not fix the problem. Since this bug was introduced in a recent maintenance release (Dec-29 or Jan-26?) you'd think it would be a quick fix.

Not trying to be mean, but I just saw this comment from 9/21/2017 in another thread and think it's a good idea: "One idea for SmarterTools is to hire someone to test your software before release."

kevind Replied

3/30/2018 at 8:46 AM

Just checking on the ETA for this fix. Thanks.

ScottF Replied

4/2/2018 at 7:26 AM

Just want to confirm that I tested and the SPF problem is fixed with the latest release of SM15, version 15.7.6663.

Dennis A. Replied

4/10/2018 at 1:04 AM

Hi Von-Austin, this new feature in 16.3.6621 is great and works as expected! I can see my primary MX doing the spam checks based on the original SMTP server now, not on my Backup MX server anymore. So that's good news.

However, the naming of this feature "Bypass Spam Checks" sounds a bit confusing to me. What it is doing in the end (in my opinion) is not bypassing spam checks, but instead performing a spam check based on the original SMTP. Is it possible to somehow rename this toggle to better reflect its actual functionality? Or am I just misunderstanding something here? Thanks!

Gabriele Maoret Replied

7/2/2018 at 3:22 AM

This problem is not fixed:

IP BYPASS work fine at SMTP level, so the maessage come in correctly, but it will be blocket afterward at DELIVERY level.

Can you fix it???

Back to Community Threads

Please leave this box unchecked