mxtoolbox "may be an open relay"

Did anyone find a solution? I get the same result on my PCI Compliance test and is there a way to disable the clear text authentication method on the SMTP proxy for unencrypted (non-SSL/TLS) sessions.

G.

Dino, what happens if you put *.* in 'Require TLS Negotiation Sender Domains' on the 'Advanced' tab of 'SMTP'?  That should prevent any unencrypted SMTP connections.

UPDATE 2017-04-25: This trick doesn't work.

In any case, if you don't allow relaying except from your internal mail server, you have zero exposure.  Your PCI compliance tester should know that his tool can provide non-negatives that are not positives.  After they're done, ask to see the notes that they have kept for the next scan.  If they hadn't kept any, find a different provider.

Cheers - Bob

I don't recommend requiring TLS for SMTP connections.   You will probably miss traffic that you want.    

In order to determine if this was something safe to implement, you would need:

• A reporting mechanism to tell you which of your non-blocked incoming mail came by HTTP instead of HTTPS
• What certificate integrity rules will be enforced if this feature is enabled
• Whether the correspondents in your mail log had qualifying certificate chains
• After implementation, how you would parse logs to identify sites that need an exception, and
• How that exception would be configured 

UTM comes up lacking on both the documentation and the reporting requirements.

"I don't recommend requiring TLS for SMTP connections.

• "A reporting mechanism to tell you which of your non-blocked incoming mail came by HTTP instead of HTTPS"

Does anyone know how to enable this in exim?

Cheers - Bob

"I don't recommend requiring TLS for SMTP connections.

• "A reporting mechanism to tell you which of your non-blocked incoming mail came by HTTP instead of HTTPS"

Does anyone know how to enable this in exim?

Cheers - Bob

I had to search the forum to infer that "exim" is the UTM mail subsystem.  

If there are known ways to query the mail engine from something other than the UTM user interface, I would love to see a "getting started guide" for doing so.  The UTM user interface is an obstacle to doing any type of global mail analysis.

At present our UTM mail manager sits behind a Barracuda email filter.   I have been presently surprised at UTM's ability to detect spam that Barracuda allows through, and I have not yet had any false positives.

Despite this good experience, I have not been willing to make UTM my only email filter because it does not filter on Reverse DNS of the sending server, and because of the weak management interface.  I would be willing to develop a custom reporting tool if I had enough information to get started.

Doug, you said, "it does not filter on Reverse DNS of the sending server."  What does the barracuda do that the UTM doesn't?

Cheers - Bob

Reverse DNS -- If I get unwanted spam from x.x.x.x at server1.emailmarketing.com, I can blacklist the IP Address, try to guess all of the servers that the sender users, or just block all of the servers named *.emailmarketing.com.   I can block all mail from servers in brazil or Russia, if I feel no need to communicate there, by blocking reverse dns names ending in an .ru

The difference between the latter and country blocking is that country blocking logs no information in the spam filter (what did I miss) and it is not dependent on blocking all other ports.

The Barracuda management interface allows very granular multi-attribute searches on the message logs, then displays a list which I can review individually or download to a CSV file for further analysis.  

There is no way for me to ask UTM for all of the traffic from a particular server (or parent domain), with the disposition of those messages.  That means that I cannot know which servers should be blocked for bad behavior.

Have you tried iview? It does offer a far better reporting experience than the UTM alone.

I did build an IView environment.  It seemed to provide some aggregate reporting, but nothing at the detail level.   My questions tend to be:

"Tell me everything Sally did on the Internet between <date1> and <date2>"
This actually gets complicated, because you want to know whether sally went to all these site, or sally went to aol.com and aol.com went to all of these sites without her knowledge.   The request# and referring URL fields can be used to answer the question in this way, but first you need to extract and understand the raw data.

Tell me all of the uncategorized sites that users visited recently.  (Mine have action "warn").   I only worry about the entries that have the three-entry sequence of warn-proceed-access.   IF the user made a mistake and quit, I don't care.   If the user clicked through to an invalid site name, I don't care.   But if it is a real site, I want to get it categorized, either to save users the warning next time or to do triage if I retroactively learn that the site was dangerous.

Tell me all of the sites that were blocked because of certificate problems, so I can decide what to do. 

I should add that Barracuda had an interesting design 10 years ago, which they have never reimagined.   I don't think Sophos UTM Mail Manager expects to win in a feature-to-feature comparison with a specialized mail product, but it does "check the box" for prospects that do not have a huge mail volume and do want something.

If Sophos does want to reimagine their mail offering, I can offer plenty of ideas.

Example 1

I want to trust mail from company X, but the use hosting service Y.   But spammer can claim to be from company X and other clients of hosting service Y cannot be assumed trustworthy.   I want to trust the combination of email domain for X and server addresses for Y, not "either-or".   Barracuda and UTM both give me "either-or" only.

Example 2

I want to try turning on SPF, but I know a lot of companies mess up their SPF record, and some spammers supply valid SPF information.   Instead of making SPF a block/allow condition, make it an element in the spam weighting decision.  Let me turn on SPF monitoring for a month, then dump the logs for analysis to see whether SPF enforcement would add any value, and more importantly to know which friendly companies need to be exempted from SPF checks.   After doing all of this, I might be ready for SPF checking.

But email also gets forwarded, which means that I want a rule which says "SPF is correct OR DKIM is correct", which is the core concept for DMARC.   Neither Barracuda nor UTM permit this.  I don't know why. 

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