Keep your mail servers off blacklisting sites and avoid being flagged as spam!
by Moonshi Mohsenruddin, CEO CommGate, Inc.
Greetings! This blog will be shared by my fellow team mates - Mr. Tan Hock Chye, Technical Manager, Mr. Ramesh Raman, Chief Technology Officer and Mr. Abhik Biswas, Chief Marketing Officer of CommGate. We will be posting alternately, in attempt to bring mind blowing technology thoughts to you on a regular basis. If you would like to read more about who we are and what we do, please do check out our profile on our corporate website.
These days, it seems like every other email servers/hosts are tightening the screws on their email servers just a little bit more in order to battle against spam and viruses. Generally speaking, having more servers out there tightening their security and policies is a good thing. However, if you do not follow some basic precautions on your own email server(s), valid email from your hosted email domains may start to be flagged as spam, returned, or you may even become blacklisted if your servers are not RFC compliant. Essentially, if your servers do not comply to the various standards surrounding how an SMTP server is supposed to function and be configured, an angry mob of clients awaits you (assuming they are not already beating down your door.)
Why must we be RFC compliant, you may ask? You must comply because most spammers do not. Spammers function by using quick and dirty setups, and by taking advantage of scripts, trojan horses, and any other number of nasty tricks. Because of this, spammers will send email from servers that are often very outdated, or from scripts that simulate SMTP sessions. The spam and virus sources of the world are, for the most part, much more concerned about quantity than they are about quality. Thus, you can distinguish yourself and appear less and less likely to be a spam host to others, by focusing on quality. The easiest way others can identify spam is by determining that the sending end is doing something that a modern SMTP service is not supposed to do. Thus, by being standards compliant, you will be less likely to be mistaken for a spammer.
Here is a list of EIGHT things that we highly encourage all our clients to do:
1. DNS (Domain Name System): Check http://dnsreport.com for domains that you host. Having your DNS correctly configured for each domain is vitally important! Many email servers will reject mail from your server entirely if your DNS is incorrectly configured. This tool will also check the mail server for the domain with a few basic tests for obvious issues.
2. Sender Policy Framework: Publish an SPF record in DNS. Many major mail services will automatically flag emails from domains that do not have an SPF record as spam or potential spam. You can find out more about how to do this at http://en.wikipedia.org/wiki/Sender_Policy_Framework and http://openspf.org.
3. If at first you don't succeed, try, try again: Make sure that your mail server will try to send again if it gets a failure the first time. Many mail servers use greylisting (http://en.wikipedia.org/wiki/Greylisting), and will not ever let a message through on the first try. If you configure your mail server to fail after one try (possibly to reduce server load) or your SMTP service does not properly handle retries, it is not RFC compliant. Refer to http://tools.ietf.org/html/rfc2821#section-4.5.4
4. Update: Ensure that your mail servers have updated and patched operating systems, as well as that the actual SMTP service or daemon that you use is updated or patched as well. Not only will this protect you from security holes, but older mail software is often not standards compliant and will cause problems.
5. Do not trust your users: Scan outgoing messages from your server for spam and virus issues. Block messages going outbound that score too high. Limit sending to huge recipient lists. Many people implicitly trust all of their users and do not check their outgoing messages. Unfortunately, accounts are easily compromised due to weak user passwords and viruses. It is all too easy for a mail user to unwittingly send spam and viruses. If you allow to much spam out from your own servers, no matter how valid they are, you will find yourself turning up on blacklists. Usually these blocks are temporary, unless you never do anything about the problem. If the blocks do not go away after making your changes, you will have to spend countless hours trying to contact the blacklist sites that have you listed and working with them to resolve these blocks. They will probably refuse to unblock you if you are continuing to allow spam out from your mail server.
6. Abuse and Postmaster email: Make sure that for each email domain you host, you have both an abuse@example.com address defined and a postmaster@example.com. These addresses must actually go somewhere useful (such as to your support system or IT staff) so that other administrators can contact you if they find a problem that has to do with your domain.
7. Open Source: Use an open source SMTP server. Often proprietary software is not RFC compliant, because no one can easily fix small problems. Also, with proprietary software, people often do not upgrade to newer versions as often as they should, because there is a cost associated with each service pack (in many cases.) In general, open source mail servers tend to be more secure, up to date, and standards compliant. If you must go with a proprietary solution, find out from the sales representative what testing the product has gone under to prove it's RFC compliance, and if they have a guide for configuring the server service so that it is compliant.
8. Use SMTP Authentication: Since you shall not trust all your network users explicitly, using SMTP Authentication is very encouraged as it makes sure only legitimate users sends out emails through your SMTP servers.
There are many more things that you can do, but these steps should help point you in the right direction. If you don't know what the proper setting is for something, you can always check and see if the RFC has a recommendation for it. I suggest you go to this site; http://tools.ietf.org/html/rfc2821
Happy improving! System administrators around the world thank you for your effort to make the Internet safer and email more pleasant to use.
by Moonshi Mohsenruddin, CEO CommGate, Inc.
Greetings! This blog will be shared by my fellow team mates - Mr. Tan Hock Chye, Technical Manager, Mr. Ramesh Raman, Chief Technology Officer and Mr. Abhik Biswas, Chief Marketing Officer of CommGate. We will be posting alternately, in attempt to bring mind blowing technology thoughts to you on a regular basis. If you would like to read more about who we are and what we do, please do check out our profile on our corporate website.
These days, it seems like every other email servers/hosts are tightening the screws on their email servers just a little bit more in order to battle against spam and viruses. Generally speaking, having more servers out there tightening their security and policies is a good thing. However, if you do not follow some basic precautions on your own email server(s), valid email from your hosted email domains may start to be flagged as spam, returned, or you may even become blacklisted if your servers are not RFC compliant. Essentially, if your servers do not comply to the various standards surrounding how an SMTP server is supposed to function and be configured, an angry mob of clients awaits you (assuming they are not already beating down your door.)
Why must we be RFC compliant, you may ask? You must comply because most spammers do not. Spammers function by using quick and dirty setups, and by taking advantage of scripts, trojan horses, and any other number of nasty tricks. Because of this, spammers will send email from servers that are often very outdated, or from scripts that simulate SMTP sessions. The spam and virus sources of the world are, for the most part, much more concerned about quantity than they are about quality. Thus, you can distinguish yourself and appear less and less likely to be a spam host to others, by focusing on quality. The easiest way others can identify spam is by determining that the sending end is doing something that a modern SMTP service is not supposed to do. Thus, by being standards compliant, you will be less likely to be mistaken for a spammer.
Here is a list of EIGHT things that we highly encourage all our clients to do:
1. DNS (Domain Name System): Check http://dnsreport.com for domains that you host. Having your DNS correctly configured for each domain is vitally important! Many email servers will reject mail from your server entirely if your DNS is incorrectly configured. This tool will also check the mail server for the domain with a few basic tests for obvious issues.
2. Sender Policy Framework: Publish an SPF record in DNS. Many major mail services will automatically flag emails from domains that do not have an SPF record as spam or potential spam. You can find out more about how to do this at http://en.wikipedia.org/wiki/Sender_Policy_Framework and http://openspf.org.
3. If at first you don't succeed, try, try again: Make sure that your mail server will try to send again if it gets a failure the first time. Many mail servers use greylisting (http://en.wikipedia.org/wiki/Greylisting), and will not ever let a message through on the first try. If you configure your mail server to fail after one try (possibly to reduce server load) or your SMTP service does not properly handle retries, it is not RFC compliant. Refer to http://tools.ietf.org/html/rfc2821#section-4.5.4
4. Update: Ensure that your mail servers have updated and patched operating systems, as well as that the actual SMTP service or daemon that you use is updated or patched as well. Not only will this protect you from security holes, but older mail software is often not standards compliant and will cause problems.
5. Do not trust your users: Scan outgoing messages from your server for spam and virus issues. Block messages going outbound that score too high. Limit sending to huge recipient lists. Many people implicitly trust all of their users and do not check their outgoing messages. Unfortunately, accounts are easily compromised due to weak user passwords and viruses. It is all too easy for a mail user to unwittingly send spam and viruses. If you allow to much spam out from your own servers, no matter how valid they are, you will find yourself turning up on blacklists. Usually these blocks are temporary, unless you never do anything about the problem. If the blocks do not go away after making your changes, you will have to spend countless hours trying to contact the blacklist sites that have you listed and working with them to resolve these blocks. They will probably refuse to unblock you if you are continuing to allow spam out from your mail server.
6. Abuse and Postmaster email: Make sure that for each email domain you host, you have both an abuse@example.com address defined and a postmaster@example.com. These addresses must actually go somewhere useful (such as to your support system or IT staff) so that other administrators can contact you if they find a problem that has to do with your domain.
7. Open Source: Use an open source SMTP server. Often proprietary software is not RFC compliant, because no one can easily fix small problems. Also, with proprietary software, people often do not upgrade to newer versions as often as they should, because there is a cost associated with each service pack (in many cases.) In general, open source mail servers tend to be more secure, up to date, and standards compliant. If you must go with a proprietary solution, find out from the sales representative what testing the product has gone under to prove it's RFC compliance, and if they have a guide for configuring the server service so that it is compliant.
8. Use SMTP Authentication: Since you shall not trust all your network users explicitly, using SMTP Authentication is very encouraged as it makes sure only legitimate users sends out emails through your SMTP servers.
There are many more things that you can do, but these steps should help point you in the right direction. If you don't know what the proper setting is for something, you can always check and see if the RFC has a recommendation for it. I suggest you go to this site; http://tools.ietf.org/html/rfc2821
Happy improving! System administrators around the world thank you for your effort to make the Internet safer and email more pleasant to use.
Comments