rfc2505.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,348 行 · 第 1/4 页

RFC 2505               Anti-Spam Recommendations           February 1999


   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: <[e-mail]>
       S  250 <[e-mail]>... Sender ok



Lindberg                 Best Current Practice                 [Page 19]

RFC 2505               Anti-Spam Recommendations           February 1999


       C  RCPT To: <[e-mail]>
       S  250 <[e-mail]>... Recipient ok
       C  RCPT To: <[e-mail]>
       S  451 <[e-mail]>... Denied due to spam list
       C  RCPT To: <[e-mail]>
       S  550 <[e-mail]>... 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:

   o   People may fail to find important mail in their flooded
       mailboxes. Or, they may delete it while cleaning up.

   o   ISPs get overloaded mailbox hosts and filled disk. Cleaning up
       and helping customers requires a lot of human resources.  In
       fact, ISP mail servers have crashed by too much mail.

   o   While disks are unaccessible, either due to being filled or due
       to "mail quota", important mail may be delayed or lost.  Normally
       this would not happen without notice, but if both the sender and





Lindberg                 Best Current Practice                 [Page 20]

RFC 2505               Anti-Spam Recommendations           February 1999


       receiver hosts have their disk flooded, the mail being returned
       may also fail, i.e. the email service may become less trustworthy
       than before.

   o   Hosts used as unauthorized Mail Relays become overloaded.
       Besides the technical implications, this too requires a lot of
       human resources, cleaning up mail queues and taking care of
       furious external users that were spammed through the Relay.

   o   The fight against spammers includes blocking their hosts (which
       is described in this memo). However, there is a great risk that
       Mail Relay hosts may be blocked too, even though they are also
       victims. In the long run, this may cause Internet mail service to
       deteriorate.

   o   The common use of forged "MAIL From:" and "From:" addresses puts
       the blame on innocent persons/hosts/organizations. This is bad
       for reputations and may affect business relations.

   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.





Lindberg                 Best Current Practice                 [Page 21]

RFC 2505               Anti-Spam Recommendations           February 1999


   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, RFC 821,
       August 1982.

   [2] Crocker, D., "Standard for the format of ARPA Internet text
       messages", STD 11, RFC 822, August 1982.

   [3] Braden, R., "Requirements for Internet hosts - application and
       support", STD 3, RFC 1123, October 1989.

   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Level", BCP 14, RFC 2119, March 1997.

   [5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
       13, RFC 1034, November 1987.

   [6] Mockapetris, P., "Domain Names - Implementation and
       Specifications", STD 13, RFC 1035, November 1987.

   [7] Eastlake, D. and C. Kaufman, "Domain Name System Security
       Extensions", RFC 2065, January 1997.

   [8] sendmail Home Page. http://www.sendmail.org

   [9] Gellens, R. and J. Klensin "Message Submission", RFC 2476,
       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.






Lindberg                 Best Current Practice                 [Page 22]

RFC 2505               Anti-Spam Recommendations           February 1999


Editor's Address

   Gunnar Lindberg
   Computer Communications Group
   Chalmers University of Technology
   SE-412 96 Gothenburg, SWEDEN,

   Phone: [phone]
   FAX:   [phone]
   EMail: [e-mail]









































Lindberg                 Best Current Practice                 [Page 23]

RFC 2505               Anti-Spam Recommendations           February 1999


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.
























Lindberg                 Best Current Practice                 [Page 24]