Messaging Gateway

Symantec Messaging Gateway is getting a bad reputation at my site for false positives, resulting in deleted (ie, gone forever) mail.  As a result SMG is about to get quarantined and maybe deleted itself.

About a week ago, we replaced the VM that was running SMG.  The new SMG was reconfigured from scratch.  In doing so, I enabled Symantec Global Bad Senders under Reputation.   I hoped that this would catch spam or viruses that were sent by known, active bots.  That was a mistake.  As a result, many users have had some inbound mail inappropriately deleted, which didn't become obvious until in the last 24 hours.  Now I have to explain why this mail was lost.

The issue is that senders (our users & others) send mail from home or mobile ISPs that wind up at our site.  The bottom-most (oldest) of the Received headers looks like

Received: from mumble-1-2-3-4.example.com ([1.2.3.4]) by mailhost.,.....com with esmpta ... 20 Jun 2013 01:02:03 -0700

If you look up the reputation of the IP at http://ipremoval.sms.symantec.com/lookup/ you see it is marked as

The host is unauthorized to send email directly to email servers

That makes sense.  It is just a mobile or home site (and may be a dynamically assigned to different computers at different times) and should deliver to some mail submission (port 587) host after authentication.   For this mail, it did just that, as indicated by the "with esmtpa" clause in the Received, as per RFC3848.

However, I find that SMG 9.5.1-6 (yes, that's old) deletes this message, with a verdict that indicates OPL (open proxy list) triggered a static delete.  All the other IP addresses do not have bad reputations.

Jun 20 02:25:34 smsinscan smsinscan bmserver: 1371720334|826b4363-b7b1fae0000054c0-08-51c2ca8da569|VERDICT|user@example.com|opl|default|static delete

I see no way to adjust SMG so it obeys RFC3848 for this kind of reputation.  Is there a way to fix this?  Is anyone aware whether this has been fixed in newer versions?

(Oh, and if you aren't thinking, you might suggest just adding 1.2.3.4 to the Local Good Senders IP list, but of course that won't work.  You might send me mail from your home IP address, triggering this mail deletion, and I'd never get it and know I'd have to add your (temporary) IP to that list.)

Then there's the matter of why SMG is deleting the message.  I can't find any policy that would do this.  What enabled this deleting was enabling "Symantec Global Bad Senders" under Reputation > Bad Senders, which has the action "Reject SMTP Connection".     What gives that the right to delete a message is not apparent.  

Seeing no generic way of avoiding losing incoming mail, I'm again disabling Symantec Global Bad Senders.  Too bad, as it threw out a lot of bath water with the baby.

P.S.  I'll be sure to warn our users that tripped over this, that their mail to other sites might just disappear into the ether if those other sites are running SMG with this configuration.  (I hope Symantec's sales department will take note of that.)

The static delete is becuase we saw the IP listed in the Global Bad Senders after we already accepted the email. We look up the connecting IP at the time the sender connects, but we have to get the full email before we can scan for other IPs the message came from listed in the email header. Since we can't reject the email we already accepted, we simply delete it.

How can you have that many emails triggering the Global Bad Sender verdict? False positives for that verdict are very rare.

Thanks for the response!

Re number of Global Bad Sender verdict mails:  Our lab's mail system is separate from our main corporate mail system.  Mail sent to our corporate addresses are forwarded (yes!) to our lab mail system while mail to our lab addresses arrives directly (via MX of course).  Even for our lab's mail system, the SMG system is not an MX, so actually never gets to refuse any bad sender's SMTP connection.

So, processing the Received lines is what we want to happen, and was deleting on the order of 50% of the incoming mail.  We just want to stop processing the Received line when it finds one that authenticated.  

Re improperly deleted emails:

Even if the SMG system was our MX, it would still delete the mail sent from the (mobile, in this case) IP that had the reputation I described above.  I would have to suspect that many false positives would result from such reputations.

The only improperly deleted file I captured in debug logs is the one I described above.  I've confirmed another two deleted emails were sent by another sender that had a similar (but different) IP address (mobile-AAA-BBB-CCC-DDD.mycingular.net), with the same "The host is unauthorized to send email directly to email servers." reputation.  In another deleted email, the sender was using  c-AAA-BBB-CCC-DDD.hsd1.ca.comcast.net as his home network address, with that reputation.

Judging by the list of deleted emails from our corporate mail system to our lab mail system, I'd guess that at least 1/3 of our users have such IP addresses at home or on one of their mobile devices.  If no one sent mail from home or mobile devices, we wouldn't have a problem.  Our users often work from home, and will send mail in the evening or morning from home.  Or from their mobile device when they aren't in their office.   

I know of no easy way to check for legitimate external senders whose mail was lost.  There are way too many illegitimate external senders to wade through even a small sample.  I have to guess that senders (beyond our employees) are also using home or mobile systems that will cause messages to be deleted.

It may be that the older code we are using was buggy and not properly recognizing "with esmtpsa" as an indication that the Received line (and any subsequent ones) should not be processed.   If so, I'd like to know that newer versions handle this properly.

Since the Messaging Gateway is deployed in a non-gateway configuration, you will need to place the IP addresses of any mail servers inside your network that route mail to the Messaging Gateway into the Internal Mail Hosts list so we do not trigger on them by accident.

The Global Bad Senders list is a huge part of our spam detection and rarely presents false positives, about 1 in 1,000,000. It is normally responsible for upwards of 70% of threat emails coming in to our customers' environments.

What you are describing is an inapproriate way to send mail. These users sending mail from home should be routing these emails through their ISP's SMTP servers or sending authenticated email in to the SMG. Most botnets and trojan infections will use home PCs to send out spam. Like I said, this is a huge portion of our spam blocking technology and works very well for our customers becuase of this.

I would not recommend turning off the global bas senders list, I would suggest that you simply change the action to quarantine so you do not continue to lose email.

We are using SMG version 10.0.2. I am unable to see message audit logs Symantec Global Bad Senders verdict. I should see logs  under message audit even if  SMG rejects connections where Symantec Global Bad Senders verdict is enable.

Hello,

The Symantec Messaging Gateway appliance is designed to be used on the gateway. If it is being used behind another MTA, then much of the reputation based verdicts should be disabled (or sometimes configured to not delete/reject).

RFC3848 provides no assurances of security or authorization and therefore should not be used in rendering verdicts. Here is a snippet from the RFC:

   These keywords are not normally protected in transport which means
   they can be modified by an active attacker.  They also do not
   indicate the specifics of the mechanism used, and therefore do not
   provide any real-world security assurance.  They should not be used
   for mail filtering or relaying decisions except in very controlled
   environments.

If you have Reject as a verdict for a message that cannot be rejected at connection time (because the connection server is internal and allowed) then the appropriate option is to delete the message, as it is too late to tell the sending MTA to halt sending.

If you would like full use of reputation features in Symantec Messaging Gateway, the appliance should be positioned at the gateway. Otherwise, disable reputation features or modify their actions to be non-blocking. Lastly, SMG does work in proper accordance with RFC3848.