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:

• DNSBLs/RBLs, the CBL, and other blocking list technologies

• Collaborative spam identification systems (DCC, Razor, etc.)

• Challenge Response (CRAM). Use with extreme caution due to the increase in resources required, including sender time needed to validate

• Whitelists/ blacklists /greylists

• Micropayment and stamp technologies such as Hashcash, which "cost" a sender in some form to send e-mail to recipients

• MTA throttling to reduce the amount of spam that can be sent to your MTA

• Authenticated Sender Protocols such as Sender Policy Framework (SPF). Again, use with caution as this and other technologies may cause functionality concerns.

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:

• Multiple MX records in use

• No internal mail store MX advertisements

• Different subnets and network infrastructure used for multiple MTAs

• Geographic dispersion

• Secondary or backup MX service used (if single MTA is implemented)

• Outsourcing of MTA service to third party, being aware of third-party policies regarding security and spam filtering

• System redundancy

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.