| ||
Step | Description |
---|---|
Use a stand-alone MTA. | An organization should use a stand-alone MTA to act as its public e-mail infrastructure. This should be separated from the internal mail store containing users' mailboxes. A viable alternative is to use an MTA or relay service provided by a third party (provided acceptable anti-virus and spam filters are used by the third party). |
Separate MTA and internal mail store. | If economically feasible , an organization should use disparate software packages for its MTA and internal mail store. Both the operating system e-mail packages and the anti-virus program, if possible, should be different to increase attack complexity. |
Enable relay security and blocking lists. | MTA relay security should be implemented to avoid being added to blocking lists such as RBLs, DNSBLs, and URI BLs. |
Enforce SMTP authentication and filtering. | Only allow outgoing e-mail to leave your organization from your outgoing MTA. Filter all other SMTP traffic within your organization (be sure to account for internal mail stores). Authenticate to your outgoing MTA to legitimize users/ clients . |
Enable virus filtering and anti-virus tactics. | Use MTA features to assist in filtering viruses at the MTA (such as subject line blocking and attachment stripping). Use anti-virus options such as heuristics, notifications, and so on to further limit viruses at the MTA. If possible, use disparate anti-virus at the MTA and internal mail store. |
Turn off Non-Delivery Notices (NDNs) from your anti-virus software. | NDNs can cause inadvertent spam because of spoofed "From" addresses. With many of today's viruses, these spoofed addresses cause innocent users to contend with NDNs from e-mail they did not generate. Additionally, NDNs should never include the full text (or attachments) from the original message. This is a good way to cause unnecessary e-mail traffic ( especially with attachments) but also is a great tool for attackers to use to gather information about your organization and its e-mail infrastructure. |
Use spam filtering tactics. | Implement solutions to filter spam such as:
|
Use opportunistic TLS. | Configure MTAs to use TLS when possible (opportunistically), whether connecting clients, interoffice MTAs, or outside organizations supporting TLS as well. |
Provide for MTA redundancy. | MTAs should be made redundant through the following suggestions:
|
Enable remote client security. | Clients connecting to e-mail message store infrastructure should use encrypted protocols. Also, alternate port client connections for sending e-mail (such as the submission protocol port 587) should be considered . |
Enable public role accounts. | Per RFCs 822 and 2142, role accounts should be publicly available for each organization/domain. |
RFCs 821, 822, 974, 1035, 2142, 2476, 2505, 2821, and 3207
http://www.techzoom.net/paper-mailbomb-3.asp
http://www. dnsbl . info /dnsbllist.asp
http://www.sdsc.edu/~jeff/spam/cbc.html
http://cbl.abuseat.org
http://www.mail-abuse.com/
http://www.rhyolite.com/anti-spam/dcc/
http://spamassassin.apache.org
http://nilesh.org/weblog/2004/12/defeating-captchas
http://www.hashcash.org/faq/
http://www.omniti.com/solutions/ecelerity.php
http://spf.pobox.com
http://www.captcha.net
http://www.postfix.org
http://sendmail.com
http://www.microsoft.com/exchange/techinfo/security/EdgeServices.asp
Specific vendor- related URLs for MTAs used within your organization
Slamming Spam: A Guide for System Administrators by Robert Haskins and Dale Nielson (Addison-Wesley, 2004)
| ||