mxtoolbox "may be an open relay"

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

We have gotten into an interesting and hopefully useful discussion that probably deserves its own topic, but I think we have digressed from LittleBird's original topic.

On the question of "might be an open relay":

Is this related to the problem, discussed elsewhere, that UTM opens port 25 on all ip addresses, and that firewall rules will do nothing to block this?   Bob Alfson's clever solutoin to this is to create a DNAT rule -- any traffic to port 25 on an undesired IP address get shunted to a non-existent IP.

Otherwise, perhaps the complaint, as others have suggested, is that they did not receive an "authentication required" error message.

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.