Messaging Gateway

 View Only

Outbound Mail Validation/Verification (To important to forget about) 

Aug 30, 2013 08:50 AM

Hello,

I wanted to share with you some thoughts and ideas about a common business use case for sending mail that brings a couple of risks that shouldn’t be forgotten as it can have a huge impact on your entire mail infrastructure.

 

As we are all familiar with common security best practice in mail we know that we should NOT be

  • an open email relay!
  • send E-mails with non existing sender addresses!
  • send E-mails with domains not even ours!

 

Nevertheless these three items are very often violated and we don't even know or see it until we experience general problems of your outbound mail flow by having massive queues of non delivered messages or getting complains about messages that were rejected etc..

 

The typical use case for these violations starts with a request from a project or a different group needs to have mail access for their business application. Now what you do on your gateways is to possible allow these application server to send you emails, that you route through your systems. Other than the common E-mail backend solutions like Exchange or Domino (sometimes by nature of the system design), the operators and designer of these business applications are neither familiar with email standards nor security standards. What brings u to the problem that they will only make sure that their mail can be delivered to your system and then their application is working.

 

Often forgotten by the application owners is to take care about the settings like sender domains or even a valid sender address. In purpose I don’t want to start the discussion about message design in accordance to RFCs or other standards, like mime declaration and boarders or even the quality of the recipient data.

 

Beside I also want to mention possible compromized authorized systems that are using your infrastructure for flooding the internet with new spams, that even could be part of a DOS or DDoS attack.

 

This bring us straight to the point that these application servers are sending through your SMTP gateways:

  • E-mails with non-existing sender addresses
  • E-mails with sender domains, that are not even yours
  • E-mails with existing sender addresses, that are not even yours
  • E-mail volumes that leads to a classification of your systems as potential spammer
  • E-mails that are poorly designed that a spam filter will drop these

 

The potential risk is:

  • Bad reputation of your sending IPs or Subnets that harms your entire E-mail infrastructure
  • Being blacklisted by your mail partner, that will impact your entire E-mail flow
  • E-Mail rejects due to SPF validation of sending domain
  • Loss of potential data due to existing mail addresses not in your address space for mail partners replying to the message
  • Accidently initiator of a NDR spam attack or another SMTP based attack.

 

To address these risks often there are procedures and processes designed that require manual steps, that sometimes are considered, but sustainable forgotten, what requires a technical control if you really want to protect your infrastructure from being in purpose or accidently abused.

 

Within the Symantec Messaging Gateway you have a couple of possibilities to address these issues and the following is providing you a step-by-step guidance in how to set it up.

 

1. Verify your sending domains as first improvement to make sure that only messages from your authorized domains will be sent by your systems.

  1. Create a dictionary for authorized sending domainsdomdicScreen Shot 2013-08-29 at 14.03.50.jpg

     
  1. Create a Content Control Policy that is verifying the sending domain and in case bounce the message from the application server
    Screen Shot 2013-08-30 at 19.44.42.jpgScreen Shot 2013-08-30 at 19.44.18.jpg

 

Note. In case you can enable this policy also in pass through mode (deliver normally), just to monitor and get the statistik of violations you have in your environment as maybe malware took over authorized systems that are sending spam through your SMTP gateways, even the best way on that level is to block as if a domain is not even yours, you shouldnt do this anyway and Maybe today you already add your disclaimer information to such emails.

 

2. Enable the outbound spam filter to verify as first instance whether your mails might have potential looking like spam to others.
Screen Shot 2013-08-30 at 14.46.16.jpg

Note. In case you can enable this policy also in pass through mode (deliver normally), just to monitor and get the statistik of spam that you have sent out. This will help you to identify sending systems in your infrastructure if you get complains about your sending behavior from mail recipients.

 

3. Enable the outbound throttling capability to prevent your application server spamming the receiver that may blacklist your SMTP gateways impacting your overall messaging environment
Screen Shot 2013-08-29 at 14.11.25_0.jpg

 

4. Verify your sending addresses to be fully compliant with regards to the sender/receiver part as a follow up to #1 domain validation. (Most difficult part due to possible unknown senders)

  1. Create a dictionary for authorized sending addresses
    adddicScreen Shot 2013-08-29 at 14.05.51.jpg
     
  2. Create a Content Control Policy that is verifying the sending addresses and in case bounce the message from the application server
    Screen Shot 2013-08-30 at 19.45.31.jpgScreen Shot 2013-08-30 at 19.45.16.jpg

 

Hope this makes sense to you and you can apply it fully or partially to either your system/application Messaging Gateways or the full Messaging Gateway infrastructure you have in place.


Please feel free to share your thoughts on this.

Regards,

toby

 

The screenshots and tests have been made with the SMG 10.5 pre-release that you can find here. (In a previous release the functions should be available except the outbound throttling capability.

Statistics
0 Favorited
1 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.