Email bouncing even though domain is on Trusted Senders list

Question asked by Dave Kidd - 9/17/2015 at 4:37 AM

Unanswered

We appear to have an issue where even though I have put our company accountant's domain name on the Trusted Senders list, their email to us is still bouncing so was wondering if anyone might be able to advise what might be going wrong. When I look in the logs it states they are being rejected due to an SPF Fail, yet when I look up their domain (hwca.com) using MxTools, that reports that their SPF passes so I am puzzled why their email is not bypassing the Smartermail spam checks.

We are using a combination of Bruce Barnes' suggested settings for antispam (the latest ones he has kindly provided) and also MessageSniffer but no matter what I try I cannot seem to get this domain to be accepted by our mail server.

If anyone has any ideas / suggestions I would be grateful as these emails are important to us being as they are from our accountants!

Dave

12 Replies

Reply to Thread

Dave Kidd Replied

9/17/2015 at 4:39 AM

Oh and to add we are running the latest version of Smartermail (14.2)

SpamHurts Replied

9/17/2015 at 5:48 AM

I believe this is because the spam filtering occurs first, and that is happening before the content filter, IE the trusted senders list. I make the rule in content filters for trusted senders, and move that rule in front of all the other content filters, so it is the first one. That way it will be the first action on the message.

The other issue, is the spf fail. What weight to you give it that it fails for SPF? In our system, the spf is a spam weight of 30, Is your rule for the spam weight that you have assigned to the SPF to bounce the message? IF that is the case, just change the rule.

Remember kids, every time a spam message gets blocked, a nerd gets their glasses. spamhurts/July 15

Dave Kidd Replied

9/17/2015 at 6:46 AM

Thanks for your reply SpamHurts. The current weight for SPF fail is set at 30 (as in Bruce's suggested settings) with all the other settings for that filter set at 0. I'm not sure what setting would cause a bounce of the message unless that is tucked away somewhere else from the spam filter list? (you have to excuse me as I'm not much of a SM expert and have just tried to follow guidelines and suggestions I have read on here!)

What I'm kinda confused about is why MxTools SPF check on that domain says it is fine and therefore I would have thought in theory SM would see it as a pass as well, but not having an understanding of the mechanics of how SM does SPF checks I'm not sure why they come up as fails as I would have thought MxTools is a decent website for these type of domain checks and would highlight an issue there if there was one.

Bruce Barnes Replied

9/17/2015 at 7:41 AM

Please DISABLE SPF checking for the time being. We are investigating a potential issue under which SPF does not properly test in certain circumstances.

You should also setup an account at UNLOCKTHEINBOX.COM and send an e-mail FROM the mailbox in question to see the validity of all of your settings.

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting

Dave Kidd Replied

9/17/2015 at 9:32 AM

Thanks for the advice Bruce, much appreciated as ever :)

Bruce Barnes Replied

9/17/2015 at 9:34 AM

No problem. This is being tested to see where the cause lies and what the solution is as we speak.

Matt Petty Replied

9/17/2015 at 9:35 AM

Employee Post

Make sure to update us if this fixes the issue if so we may need to look into, why.

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

michael~ Replied

9/17/2015 at 9:52 AM

Is this a new problem with a recent SM version, or a persistent bug that's been around a while? Is there an official announcement/explanation about it?

Bruce Barnes Replied

9/17/2015 at 12:38 PM

This may be an issue which is bigger than SmarterMail and an issue with SPF itself.

I do a lot of work and testing with Henry Timmes, of unlocktheinbox.com, and we're seeing about 4% SPF failure from different MX servers, not just SmarterMail.

We're attempting to find out if there's a pattern of any kind, but it takes a whole lot of digging and searching to find discrepancies and patterns.

Dave Kidd Replied

9/18/2015 at 3:13 AM

Hi Bruce, that's interesting that you say that because what I have noticed is that the SPF failures I have seen in our log tend to be linked to our backup mail server operated by a third party here in the UK, as when we receive mail direct from the affected domain to our mail server it seems to go through OK as a trusted sender.

Not sure why our mail sometimes is routed to our back up server when our mail server is active as I only thought it was used when our own server is offline to act as a holding server until it's back online, but as I'm not much of an expert about the mechanics of the email delivery process I guess there are reasons when the backup server is a first port of call even when our main server is online and listening to the outside world.

Hopefully with your efforts you will find a pattern and ultimately a solution in amongst what must be a load of spaghetti! :)

Dave Kidd Replied

10/16/2015 at 6:22 AM

Hi Bruce,

I thought I would just check in with you to see if you may have got to the bottom of the SPF check failures that you have come across? I still have this option disabled as you suggested but wasn't sure to continue to leave as is as I haven't spotted anything on the forums recently about this, so if you do have any kind of update it would be great to know.

Regards,

Dave

Bruce Barnes Replied

10/16/2015 at 11:52 AM

Dave, et al;

We've been working closely with Henry Timmes, of UnlockTheInbox.com, and we've been testing a special build of SmarterMail which resolves two issues - neither of which were specific to SmarterMail software, but both of which are anomalies of the SPF, DKIM, DOMAINKEY and UDP protocols:

one being a situation with DNS queries where 4096 big DKIM sizes cannot be queried by a 512 byte UDP packet. The 512 byte UDP query size is a natural limitation of DNS and requires a TCP query to retry when a UDP query fails.
the second being a situation where a header line contained a single space.

The tests, which have been conducted on multiple SmarterMail installations - approximately 5 that I am responsible for, and Henry's own SmarterMail installation, have, since Friday, 2 October, 2015, been working without further incident on the installations I oversee, have shown a marked improvement in delivery where SPF and DMARC are both enabled.

Here are the SPF and DMARC settings which are being used with the test build of SmarterMail:

***SPF Settings with test build of SmarterMail***

both ENABLE FOR FILTERING and ENABLE FOR SMTP BLOCKING are ENABLED in the ANTISPAM settings.

Since the installation of the test build, we have seen zero issues, and zero false positives, with either SPF or DMARC.

Unless there are other issues which the SmarterTools development team finds, I would look for this to be included in a minor build of SmarterMail 14.3, or higher.

Back to Community Threads

Please leave this box unchecked

12 Replies

Reply to Thread

Tags

Related Knowledge Base Articles