mxtoolbox "may be an open relay"

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 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.

Hey Bob, your suggestion did not really do anything. The problem I have is that the email protection SMTP server or proxy is using an unencrypted channel for the transmission of data. What I am trying to do is drop the connection on port 25 when telnet is used. I believe the Sophos UTM is blocking with a 550 Relay not permitted but is this the correct approach or am I missing something here?

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).

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).

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

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.

" 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

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.