SPF Failures with Backup MX That Should Be SPF_Pass
Problem reported by Scott Forsythe - February 7 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
2
Scott Forsythe Replied
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
0
Steve Guluk Replied
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?
4
kevind Replied
Checking to see if there are any updates on this.
 
Thanks,
Kevin
0
kevind Replied
This problem is with incoming messages that pass thru a gateway, so guessing it's not related.
0
Matt Petty Replied
Employee Post
We've put in a fix and it will be in today's release.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
kevind Replied
Great! v15 also? Thanks.
2
Scott Forsythe Replied
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.
1
Von-Austin See Replied
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 ?
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Merle Wait Replied
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??
0
Von-Austin See Replied
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.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Von-Austin See Replied
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.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
kevind Replied
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

1
Colton Morrison Replied
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???
0
Colton Morrison Replied
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.
0
Von-Austin See Replied
Employee Post
Thanks Kevin, glad to hear the issue has been resolved. I've updated the related thread accordingly.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Von-Austin See Replied
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.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Von-Austin See Replied
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.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Colton Morrison Replied
Thank you!!
0
kevind Replied
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.
0
Von-Austin See Replied
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.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
kevind Replied
OK, sounds good.
4
kevind Replied
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.
2
Merle Wait Replied
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?
0
Matthew Leyda Replied
Good Question.
Kendra Support
http://www.kendra.com
support@kendra.com
425-397-7911
Junk Email filtered ISP
0
Matt Petty Replied
Employee Post
We pushed the minor this morning.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
2
Colton Morrison Replied
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?
0
Scott Forsythe Replied
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.
0
Colton Morrison Replied
Thanks Scott,
Great....Did they say when 15.x will receive the fix?
0
Scott Forsythe Replied
They did not provide an ETA.
3
kevind Replied
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."
2
kevind Replied
Just checking on the ETA for this fix. Thanks.
3
Scott Forsythe Replied
Just want to confirm that I tested and the SPF problem is fixed with the latest release of SM15, version 15.7.6663.
0
Dennis Ameling Replied
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!
0
Gabriele Maoret Replied
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???

Reply to Thread