Anti-Spam Recommendations (RFC 2505)

RFC #2505 gives several implementation recommendations for SMTP MTAs (Mail Transfer Agents) to decrease the impact of spam.

The recommendations are intended to help reduce spamming, if applied on enough SMTP MTAs on the Internet. The authors of the RFC are aware that this is not the final solution, but if these recommendations are used on all Internet SMTP MTAs, things would improve considerably.
The recommendations make it very difficult for the spammers to remain anonymous, and thus expose them to legal procedures.

The following rules are described as MUST Rules :

• Be able to restrict unauthorized use as Mail Relay.

The information provided using the "HELO Hostname" and "MAIL From:"  can be easily forged. Therefore, an MTA will authorize a client based on the combination of the “RCPT To:” command, his IP address and his fully qualified domain name.

• Be able to provide "Received:" lines with enough information to make it possible to trace the mail path.

Each MTA in the path of specific mail message, should append a “Received” line with various information such the as: the IP address & host name of the caller, the time & date and if possible append additional information as described in RFC 822.
The purpose of this requirement is to make it possible to trace the mail path back to the sender.

Example of Return Path and Received Time Stamps

Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
Date: 27 Oct 81 15:01:01 PST
From: JOE@ABC.ARPA
Subject: Improved Mailing System Installed
To: SAM@JKL.ARPA
This is to inform you that ...

• Be able to provide local log information that makes it possible to trace the event afterwards.

• NOT refuse "MAIL From: <>" and “MAIL From: <user@my.local.dom.ain>"

Some servers filter e-mails according to the “MAIL From” command, but sometimes it causes more problems than the spam itself.
The “MAIL From: <>” address is usually used in error messages that are returned to the user.
In addition, at first thought it may seem that mails with “MAIL From: <user@my.local.dom.ain>" shouldn’t arrive to the external MTA (and instead delivered internally), however there are couple of specific cases where legitimate mails will use these addresses and refused as a result.

•  Be able to configure to provide different Return Codes for different rules.

There are 3 basic classes of returns codes: (2xx) for “Success”, (4xx) for “Temporary failure”, and (5xx) for “Permanent failure”. The MTA must be flexible enough to make it possible to configure the return codes for specific rules and policies.

Others rules are described as less important (SHOULD) Rules, and we list them briefly:

• Be able to log all occurrences of anti-relay/anti-spam actions.
• Be able to refuse mail from a host or a group of hosts
• Be able to refuse mail from a specific "MAIL From:" user, <foo@domain.example>, and from an entire "MAIL From:" domain <.*@domain.example>.
• Be able to limit ("Rate Control") mail flow.
• Be able to verify "MAIL From:" domain (using DNS or other means).
• Be able to verify <local-part> in outgoing mail.
• Be able to control SMTP VRFY and EXPN.
• Be able to control SMTP ETRN.