RFC2505 - Anti-Spam Recommendations for SMTP MTAs
转自：中国协议分析网
Air Ambulance -www.globalinfoexchange.com
Emergency medical air response Services and information
Network Working Group G. Lindberg
Request for Comments: 2505 Chalmers University of Technology
BCP: 30 February 1999
Category: Best Current Practice
Anti-Spam Recommendations for SMTP MTAs
Status of this Memo
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
3. Future work
3.1. Impact on SMTP UAs and end users
Even though this memo is about MTAs and recommendations for them, some of what is done here also impacts UAs (User Agents, the "ordinary mail programs").
A UA does two things:
1) Reads mail from a mailbox and prints on the screen. This typically uses a protocol like POP, IMAP or NFS.
2) Reads text from the keyboard and hands that over to the mailbox MTA for delivery as a piece of mail. This typically uses the SMTP protocol, i.e. the same protocol that is used between MTAs.
When MTAs now start to implement various anti-relay filters as described above, a UA on a portable laptop host may get a response like "Relaying Denied" just because it happens to use IP addresses within an unknown range or that resolve to unknown FQDNs.
The typical victim of this "Relaying Denied" response is a salesman carrying a laptop on a business trip, or even an IETF delegate at a meeting hotel. The salesman will probably dial his nearest ISP and will get an IP address from that dialup pool; the IETF delegate will use an IP address from the terminal room. In both cases their laptop mail program (the UA; e.g. pine, Netscape, Eudora) will try to send out mail via their home MTA, e.g. SMTP-SERVER=mail.home.example, but unless mail.home.example has been updated to accept that (temporary) IP address it will respond "Relaying Denied" and refuse.
To get around this problem we could simply add the terminal room's or the dialup pool's IP network to the list of accepted networks at mail.home.example. This does open up some minimal risk of spammers using that host as their Mail Relay: If they use the same ISP's dialup pool and they configure to use mail.home.example at the same time as our salesman is on his trip, then the spammers will be authorized to relay their spam through mail.home.example. However, this is not extremely likely and as long as we do not open up for the entire world all the time and we keep the log files under close observation and we stop relaying at once we find we're being used,
this solution is probably good enough.
Another way around is that our salesman uses a Mail Relay provided by
the current dialup ISP, if that service exists. To do so he has to modify SMTP-SERVER= in his UA, which may or may not be reasonable.
The correct way to handle this situation, though, is by some other mail-sending protocol between the UA and the MTA.
Although a separate submission protocol does not exist, a profile of SMTP for this, the "Message Submission" specification, [9], has recently been defined.
Or, we could note that when the SMTP Authentication work, [10], is all in place, it will allow for Authenticated SMTP to serve as The Protocol between the UAs and the home MTA (whether that should be considered a new protocol or "the same old SMTP" is irrelevant here).
This adds one item to the suggested Relay algorithm in section 2.1:
+ If "SMTP Authenticated" then accept to Relay.
3.2. Personal anti-spam filters
Since all users are individuals, there is little hope that any central anti-spam action will suit them all - in fact people can and do argue about Freedom of Speech infringement if some central set of anti-spam rules is enforced without the users' approval. (One could of course also argue whether spam really adds anything to anyone, but that must be up to each individual user to decide, rather than being centrally decided).
Therefore the only reasonable extension is to allow for personal anti-spam filters, i.e. anti-spam filters like the ones described earlier in this memo, but available and configurable on a per user basis. Since most users will not have a strong opinion (except that they want to avoid spam) the mail system should provide a system default and give each user the ability to override or modify that. In a UNIX based environment one could have something like
/etc/mail/rc.spam
~/.spamrc
and rules on how the latter can interfere with the former.
All of this opens up quite a number of unresolved issues, e.g. whether each user himself really should be allowed to decide on SMTP Return Codes (and how it should be described so he understands enough of the implications) and how existing mail systems will deal with different per user responses, especially how they will deal with a mix of 5xx and 4xx codes:
C MAIL From: <usr@spam.example>
S 250 <usr@spam.example>... Sender ok
C RCPT To: <usr@domain.example>
S 250 <usr@domain.example>... Recipient ok
C RCPT To: <foo@domain.example>
S 451 <foo@domain.example>... Denied due to spam list
C RCPT To: <bar@domain.example>
S 550 <bar@domain.example>... Denied due to spam list
Of course one could decide on either "250 OK" or "550 Denied" with no other alternatives for the individual user, but this too has to be explained enough that an ordinary user understands the implications of "Refuse 'MAIL From: <.*@spam.example>'" and that it can do away with, or block out, mail he actually wanted.
3.3. SMTP Authentication
SMTP Authentication, [10], has already been mentioned as a method to authorize Mail Relaying, but of course there is much more to it than that. When that infrastructure and functionality is all in place, spammers will have a much harder time forging addresses and hiding.
3.4. Spam and NATs
With the increased use of Network Address Translators (NATs) may come a need for additional information in log files. As long as there is a 1:1 mapping between the addresses inside the NAT and the addresses used outside it everything is OK, but if the NAT box also translates port numbers (to combine many internal hosts into one external address) we will need to log not only the IP addresses of spam hosts but also the port numbers. Otherwise we will not be able to identify the individual host inside the NAT.
4. Security Considerations
The grassfire-like increase of spam raises several security issues which, in fact, puts the entire Internet mail community at risk:
Several of the methods described in this document increases the load on several support systems to the email system itself. Those support systems can be DNS, logging, databases with lists of local users, authentication mechanisms and others. Implementing the methods described in this document will, because of that, increase the risk of a denial of service attack against the support system by sending spam to a site. Logging facilities must for example be able to handle more logging (what happens when the logfiles fills the disk?). DNS servers and authentication mechanisms must be able to stand the load of more lookups etc.
The functionality of the support systems during high load should be carefully studied before implementing the methods described in this document.
The mail system should be carefully studied, e.g. how it behaves when one or more of the support systems needed for a specific method fails. A mail server MUST NOT respond with "Permanent Failure" (5xx) if there is a temporary problem with one of its support systems.
5. Acknowledgements
This memo is the result of discussions in an ad hoc group of Swedish ISPs and Universities. Without any hope on mentioning everyone we simply give the domain names here: algonet.se, global-ip.net, pi.se, swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, and uu.se.
We want to acknowledge valuable input and suggestions from Andras Salamon, John Myers, Bob Flandrena, Dave Presotto, Dave Kristol, Donald Eastlake, Ned Freed, Keith Moore and Paul Hoffman.
Finally many thanks to Harald Alvestrand and Patrik Faltstrom, both for useful comments and for their support and guidance through the IETF process.
6. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821, August 1982.
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC822, August 1982.
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC1123, October 1989.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC2119, March 1997.
[5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC1034, November 1987.
[6] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC1035, November 1987.
[7] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC2065, January 1997.
[8] sendmail Home Page. http://www.sendmail.org
[9] Gellens, R. and J. Klensin "Message Submission", RFC2476, September 1998.
[10] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.
* Spam (R) (capitalized) is a registered trademark of a meat product made by Hormel. Use of the term spam (uncapitalized) in the Internet community comes from a Monty Python sketch and is almost Internet folklore. The term spam is usually pejorative, however this is not in any way intended to describe the Hormel product.
Editor's Address
Gunnar Lindberg
Computer Communications Group
Chalmers University of Technology
SE-412 96 Gothenburg, SWEDEN,
Phone: +46 31 772 5913
FAX: +46 31 772 5922
EMail: lindberg@cdg.chalmers.se
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.