Tip of the Day - Fleshing out the details in email policy

Published: 2006-08-19
Last Updated: 2006-08-21 21:29:40 UTC
by Brian Granier (Version: 1)
0 comment(s)

If for nothing else than as a survival reflex, anti-virus programs exist in most corporate environments. Further, anti-spam programs appear to be gaining ground. This is all good, but there are a few common mistakes that are worth considering as we review the way we implement our email policies. Some of these issues have an impact on the effectiveness of security and other issues are purely operational in nature, but in the end it is usually the security group that will hold the keys to ensuring these details are addressed. Without further ado, here's a few of the often overlooked do's and don'ts for the email world:

DO view emails in plaintext only

As discussed in a previous tip of the day, avoiding html has many benefits. It reduces the probability for successful phishing attacks, it avoids propagation of exploits that depend upon flaws in html renderers and it reduces the profitability of many SPAMmers who depend upon hits to their embedded advertising banners for general advertising revenue.

DON'T filter abuse boxes for spam and virus

Okay this tip comes with a disclaimer. If you turn off all filtering for abuse boxes, you need to take very special measures to properly train and protect both the environment and the users who open the abuse email. Theoretically, these users should be trained well above average in security practices and know not to blindly open email attachments, etc..., etc..., etc... That being said, if the goal of abuse emails is to be able to receive and appropriately respond to all events that come in, doing any filtering is dangerous due to the very nature of the types of legitimate emails you might expect to receive. The complication here is that abuse emails are often made publicly available and, as a result, these accounts might be subject to an increased amount of SPAM. If the amount of spam from outside sources just becomes too much, at least create a separate internal abuse email for your internal employees to use that has no filtering of any kind.

DON'T turn on auto-respond features

Auto-responding to an email telling someone it's been blocked because it contains a virus or because it was a spam message is generally not held in high regard. A very high percentage of virus and spam emails have a spoofed source address and it is probable that the reply message being sent is going to an innocent bystander who actually had nothing to do with the original email being sent in the first place. Further, if you chose to ignore this tip, at bare minimum don't bounce the virus back to the sender. Again, they are probably an innocent bystander and if you send the original attachment/virus back to the apparent sender, you could be falling into the trap of propagating the virus even further.

Reader Andrew from Vancouver says this point should be underscored: "As a rule, assume that the virus is NOT honest enough to report the true sender's email address as the From address!  Viruses randomly generate an email address or use a list of discovered addresses in their spoofed From/mailfrom address.  Therefore, your virus alert will NOT go to the user whose workstation is infected.

Again, by sending virus alerts on inbound mail, you WILL be causing backscatter against an innocent bystander who had nothing to do with the virus in the first place or who may not even have an existing account.  By sending unsolicited mail to these innocent bystanders, you may end up getting your own server blocklisted."

Well said...

DON'T send failure to deliver messages

Sending failure to deliver messages due to someone sending an email to an invalid account is bad for two reasons. First, suppose the person who sent the email is using a legitimate from address. If they are an attacker, you've just given them an ability to enumerate your mail server and find out which mail addresses are valid and which aren't. This may take an attacker a little longer, but it's effectively the same as leaving the SMTP VRFY command available. On the other hand, consider that a large amount of spam and viruses are propagated to random email addresses using random email addresses as the spoofed from address. By sending a failure to deliver message to the apparent sender, you may be causing backscatter against an innocent bystander who had nothing to do with the spam/virus in the first place or who may not even have an existing account.

- Credit for this suggestion goes to reader Art.

DO learn how to read SMTP headers

When reporting abusive email, it is very important that the abuse is reported to the right source. Too many times, users (and sometimes even security administrators) will track down the apparent owner of the source email address or the abuse department for the domain of the source email address to complain to someone who is an innocent bystander (see previous tip). For example, in Microsoft Outlook open the email in question and click on View > Options. Look in the box that says "Internet headers" to access the SMTP headers. Further, when users report spam messages or virus messages to your abuse department, require that these SMTP headers are included in the complaint in order for full and appropriate action to be taken.

DON'T setup vacation messaged that will respond to mailing lists.

Okay, maybe this line item will sound like a rant, but it's very annoying to see messages on mailing lists that are a vacation or out of the office automated email. What's worse is when these messages are setup, it's usually because a person is going to gone for quite some time, which means if no action is taken there will be a lot of these messages built up in the list detracting from the purpose of the list in the first place. A good list administrator should identify these people quickly and immediately remove them from list subscription, followed by an independent email that lets them know how to resign up once they've returned from their vacation.

DON'T setup distribution lists without considering who can send to them.

A few weeks ago, I received an email from a certain telecomm provider giving me an updated escalation procedure. This email appears to have gone to a newly created distribution list for a range of customers for this provider. Immediately after receipt, my email box was flooded with the aforementioned vacation messages. In this case, I don't blame the individuals who setup vacation messages. They had no knowledge that they were about to be added to a new distribution group and it is not in their control that the email that was sent to this new distribution group was sent with the "reply to" address being the same as the distribution group. Further, they had no control over the fact that the telecomm provider failed to block the outside world from being able to send messages to this new distribution group.

DO hide the email addresses of members of email distribution lists/groups.

If setup improperly, sometime emailing to an email group will expand the address line to include all of the email addresses of the members inside a group. This might be acceptable for an internal company communication, but it's not a good idea when the email is destined for locations outside of the company. Further, this basically eliminates the effectiveness of who can send to the distribution list as mentioned on the previous tip since they no longer would have to respond to the email address of the distribution list. Instead, they can now do a reply all and communicate directly to everyone in the list.

DO make use of the BCC field.

BCC fields are very useful for quickly sending a message out to multiple people when you do not have the need, time or ability to create a distribution list as described above. Any recipient in the BCC field will receive the message, but their email address will be hidden from anyone who receives the message. If everyone who is meant to receive the message needs to have their email address hidden, you should put your own email address in the "to" field. This is also useful for giving additional people a copy of an email for documentation sake without the receipient being aware of the fact that there is someone else who is privy to the conversation. This useful feature can be used to archive all emails about a certain subject to an undisclosed mailbox for later review and retrieval (such as for a quality control process).

- Credit for this suggestion goes to reader Robert

T. Brian Granier

Keywords: ToD
0 comment(s)


Diary Archives