mxtoolbox "may be an open relay"

ON SPF:  As I said above, I have tried SPF twice, and had to rollback fairly quickly each time.  I had a bit of ironic fun when I had to tell Barracuda that their spam filter was blocking their support emails, because their support organization uses Salesforce.com (which sends email claiming to be from whichever client is using their platform)  but no one had updated the Barracuda SPF record to include Salesforce.com.  The other failures that I can remember included a vendor  with national presence and a significant local business partner.

I believe my experience will be representative.  In a big company, the email management group cannot reliably know all of the service bureaus that have been hired to send email under the company's name, so the SPF record is incomplete.

Given my bad experience, I am unwilling to turn it on and see what happens afterward.   I want to know, and create exceptions as needed, before breaking things.

For the record, the way graylisting usually works is that a message is only graylisted if the user has not sent an email in the last 30 days.   The assumption is that 80% of  your important business communication will be graylisted once and perpetually exempt thereafter, and other business correspondents will only be graylisted occasionally.

One of my objections to UTM is that these parameters are not visible in the user interface.   My recollection is that support said UTM used a 15-minute delay which could not be altered.   To my mind, that was too long, and the first time it affected by CEO, he would be livid.   Of course, a verbal comment from a random UTM support person may or may not have been accurate, or I may be remembering incorrectly.   Since the parameters are not in the documentation, and not in the user interface, it is hard to know for sure.

My wife has a small business and we use a hosting service that implements graylisting.   I have memories of a critical email from Dell that was delayed five painful minutes as a result.   Naturally, this particular support person had never talked to me before, so he was tripped by the rule.  As far as I know, I lack any ability to configure graylisting exceptions in that particular system.

In Barracuda, a whitelist entry is not feature-specific -- if I whitelist a domain, everything claiming to be from that domain is exempted from everything except spam attachment filtering.  Since sender information can be forged, I hated the idea of whitelisting a domain simply because of SPF.   UTM has more flexible exception definition, which is really valuable.

My proposal about making graylisting strategies dependent on the encryption quality was based on a desire to avoid configuring a lot of exceptions, since the list of all important exceptions is hard to construct in advance.

I only switched to FCrDNS within about the last year.  When I first tried it, probably over two or three years ago, there were too many unwanted rejections.  I don't think that that's the case anymore.  I just checked 50 rejections for "RDNS invalid" from the middle of the day yesterday - all were spammers. 

Yes, the Proxy handles multiple A records correctly in my experience.

Cheers - Bob

" My recollection is that support said UTM used a 15-minute delay " - No matching message is accepted before 5 minutes has elapsed.  The information (sender/sending IP/recipient) is kept for 30 days after the last confirmation, so that makes me think that the subject is not used after the temporarily-rejected email is received again although that's not stated explicitly anywhere I've seen.  For large organizations with many sending IPs and smaller ones that use services like outlook.com, there will be a lot of rejections of initial messages.  Again, greylisting doesn't stop anything that won't be quickly and cheaply stopped within a tenth of a second or so.

I like the idea of being able to do non-blocking tests to see what would happen.  You might want to vote for and comment on Allow logging of anti-spam feature results without blocking.

Cheers - Bob

"In a big company, the email management group cannot reliably know all of the service bureaus that have been hired to send email under the company's name, so the SPF record is incomplete."

If that's the case, the company should not use "-" in their SPF record.  "?" would be a better choice for them.  If a CEO asks the admin to get rid of the protection offered by SPF, I'm not concerned because, in all likelihood, other anti-spam checks will nail most all of the items that could have been blocked with SPF.

I'm glad we're having this discussion I found one incorrect rejection in our logs by doing the following command:

zgrep 'extra="SPF check failed"' /var/log/smtp/2017/04/*|grep -oP 'from=".*?"'|sort -n|uniq -c|sort -n|more

Cheers - Bob

You are right.   If the source IP changes with almost every message, as it will with some of the larger email hosting services, graylisting will get ugly.  I will abandon hope for that approach. 

From mxtoolbox:

"We were able to connect to your email server on port 25. Your server either disconnected before we sent our final QUIT command or did not respond to one of our other diagnostic commands within 15 seconds.

This may be due to a network problem, or could be an anti-spam feature of your email system. On it's own this warning does not point to any specific problem, but can be helpful in diagnosis when combined with other errors."