mxtoolbox "may be an open relay"

As I can see from the logs, your UTM is doing just what it is supposed to do...dropping relaying attempts.
Are you only concerned about that mxtoolbox "May be an open relay" message ?

Yeah. I thought there have to be something like "relaying denied". So the Helo gets a clean quit.

Wish list #3

UTM's SMTP Proxy can do graylisting, while Barracuda cannot.   It has appeal, and others have assured me that it can be very effective for driving spammers away.

But even with graylisting, I want granularity, because delayed mail can be a political issue.   The CEO may not get much mail from the external legal group, but he will want those messages to arrive right away.  If I am fighting a hardware crisis, I want the support tech's emails to arrive right away.   So I want to exempt some companies based on domain.  For popular webmail services like Gmail and Hotmail, graylisting probably won't matter, even if the user account is a spammer.  So graylisting is mostly important for unrecognized domains.

A related issue is whether the asserted domain is valid or fraudulent.   Before UTM follows my advice to exempt "dell.com" from graylisting, it needs to apply SPF rules to validate that the message is probably from Dell.   (I don't think DKIM information is transferred during the hello, so I don't think DKIM can be evaluated before deciding whether to graylist or not.)   But of course, nobody can/should enable SPF because the UTM implementation is too inflexible for use in the real world.

I would love to have a rule that says "Graylist all non-TLS connections" (unless otherwise granted an exception).   This is based on an assumption that spammers will generally not tolerate the overhead of using TLS, for the same reason that they will not tolerate the overhead of retrying a graylisted connection.   Of course, if the bad guys are spearfishing you, they will tolerate whatever inconveniences come your way.   One could even provide a hierarchy that scores connections based on presence of TLS, validity of the certificate chain, and validation level of the certificate (DV, OV, or EV).

 

 

Welllll, I haven't tried it, Doug, but...

First, at the bottom of the 'Antispam' tab, select 'strict RDNS'.  This requires FCrDNS, that is, the FQDN returned by rDNS must resolve to the IP of the sending MTA: 100.245.165.206.in-addr.arpa -> control.emailmarketing.com -> 206.165.245.100.

Next, create a Request Route that will cause failure of strict rDNS - the following prevents name resolution for all domains in the TLD tk:

To do the same for all FQDNs of emailmarketing.com, create a similar one for that domain.  Does that get you where you want to go?

Cheers - Bob

Example 1 - It seems like that level of granularity could quickly become unmanageable, Doug.

Example 2 - I don't see false positives on SPF rejections, but such rejections are only about 0.3% of emails not delivered.  An interesting thing about all of the DKIM failures I saw was that they were all "[verification failed - body hash mismatch (body probably modified in transit)]" and that resulted in the report from ctasd (CommTouch AntiSpam Daemon) guiding the delivery, rejection or quarantining of the message.  The real advantage of DKIM is that successful verification proves the email absolutely came from the sending domain.

(In roughly the order the checks are applied) RDNS and RBL rejections block 85% of emails not delivered.  Then comes SPF.  About 2.5% of rejections are due to recipient verification. That means about 90% of the rejections are done during the EHLO, MAIL FROM and RCPT TO conversation before the body of the email is sent.

After the DATA command, 59% of the remaining emails that won't be delivered are rejected as "confirmed" spam and <1% because of malware.  40+% are quarantined with a ratio of about 3 false positives for every 2 false negatives.

Of the delivered emails, about 0.2% should have been rejected as spam - not bad!

Cheers - Bob

Doug's Wish List #3...

Although some people whom I deeply respect, like BrucekConvergent, are proponents of greylisting, I'm not.  Rather than delay every inbound message by at least five minutes, I prefer to let RBLs, EHLO, strict RDNS and SPF do their stuff as explained above.  This catches 90% of unwanted traffic using an exchange of about 400 characters total between the two devices, several RBL lookups and three name server lookups.  The proxy can handle dozens of these simultaneously without breaking a sweat.  I would challenge you to find even 0.1% of spams blocked by greylisting that were not blocked by these pre-DATA checks.

If you do use greylisting, an Exception for known domains is easy to construct.

Again, I've not seen the problems you suggest with SPF.  Perhaps you could show us the lines from the SMTP log related to one such incorrect rejection.

"Graylist all non-TLS connections" - at present, greylisting occurs prior to EHLO, so that might be a bit of a challenge, but I like the idea and agree with your reasoning.  Interestingly, almost three years ago, the Bayerisches Landesamt für Datenschutzaufsicht (Bavarian State Office for Data Protection Supervision) required using encryption that included PFS.  The fines were really big, so Astaro got busy and made certain that our UTMs could send/receive with that before V9.3.  You have to have a commercial certificate, not the self-signed cert we normally use here in the USA.  So, you could require that by changing your cert, but there's no way to make an Exception except by adding entries to 'Skip TLS Negotiation Hosts/Nets' on the 'Advanced' tab.

Cheers - Bob

I believe I tried Forward-Confirmed Reverse DNS a long while back, and my experience quickly confirmed what I had been led to expect -- that it would expose many legitimate sites where FCDNS did not resolve as expected.

At minimum, will UTM cope with a site where forward DNS returns a list, rather than a single value, and search for the original IP address anywhere in the list? 

I would be curious if others have used FcDNS successfully.

Two points for your creativity, but not a very appealing solution unless I become desparate.

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

"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