rfc2505.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,348 行 · 第 1/4 页

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.

Abstract

   This memo gives a number of implementation recommendations for SMTP,
   [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them
   more capable of reducing the impact of spam(*).

   The intent is that these recommendations will help clean up the spam
   situation, if applied on enough SMTP MTAs on the Internet, and that
   they should be used as guidelines for the various MTA vendors. We are
   fully aware that this is not the final solution, but if these
   recommendations were included, and used, on all Internet SMTP MTAs,
   things would improve considerably and give time to design a more long
   term solution. The Future Work section suggests some ideas that may
   be part of such a long term solution. It might, though, very well be
   the case that the ultimate solution is social, political, or legal,
   rather than technical in nature.

   The implementor should be aware of the increased risk of denial of
   service attacks that several of the proposed methods might lead to.
   For example, increased number of queries to DNS servers and increased
   size of logfiles might both lead to overloaded systems and system
   crashes during an attack.

   A brief summary of this memo is:

   o   Stop unauthorized mail relaying.
   o   Spammers then have to operate in the open; deal with them.
   o   Design a mail system that can handle spam.





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


1. Introduction

   This memo is a Best Current Practice (BCP) RFC.  As such it should be
   used as a guideline for SMTP MTA implementors to make their products
   more capable of preventing/handling spam.  Despite this being its
   primary goal, an intended side effect is to suggest to the
   sysadmin/Postmaster community which "anti spam knobs" an SMTP MTA is
   expected to have.

   However, this memo is not generally intended as a description on how
   to operate an SMTP MTA - which "knobs" to turn and how to configure
   the options. If suggestions are provided, they will be clearly marked
   and they should be read as such.

1.1. Background

   Mass unsolicited electronic mail, often known as spam(*), has
   increased considerably during a short period of time and has become a
   serious threat to the Internet email community as a whole. Something
   needs to be done fairly quickly.

   The problem has several components:

   o   It is high volume, i.e. people get a lot of such mail in their
       mailboxes.

   o   It is completely "blind", i.e. there is no correlation between
       the receivers' areas of interest and the actual mail sent out (at
       least if one assumes that not everybody on the Internet is
       interested in porno pictures and spam programs...).

   o   It costs real money for the receivers. Since many receivers pay
       for the time to transfer the mailbox from the (dialup) ISP to
       their computer they in reality pay real money for this.

   o   It costs real money for the ISPs. Assume one 10 Kbyte message
       sent to 10 000 users with their mailboxes at one ISP host; that
       means an unsolicited, unexpected, storage of 100 Mbytes.  State
       of the art disks, 4 Gbyte, can take 40 such message floods before
       they are filled. It is almost impossible to plan ahead for such
       "storms".

   o   Many of the senders of spam are dishonest, e.g. hide behind false
       return addresses, deliberately write messages to look like they
       were between two individuals so the spam recipient will think it
       was just misdelivered to them, say the message is "material you





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


       requested" when you never asked for it, and generally do
       everything they can without regard to honesty or ethics, to try
       to get a few more people to look at their message.

       In fact some of the spam-programs take a pride in adding false
       info that will "make the ISPs scratch their heads".

       It is usually the case that people who send in protests (often
       according to the instructions in the mail) find their mail
       addresses added to more lists and sold to other parties.

   o   It is quite common practice to make use of third party hosts as
       relays to get the spam mail sent out to the receivers. This theft
       of service is illegal in most - if not all - countries (at least
       in the US spammers have been successfully sued).  However, with
       the original sender in the US, the (innocent) relay in Sweden and
       the list of receivers back in the US, the legal process of
       getting damages from the spammers becomes extremely difficult.

1.2. Scope

   This memo has no intention of being the final solution to the spam
   problem.

   If, however, enough Internet MTAs did implement enough of the rules
   described below (especially the Non-Relay rules), we would get the
   spammers out in the open, where they could be taken care of. Either
   pure legal actions would help, or we can block them technically using
   other rules described below (since the Non-Relay rules now make them
   appear openly, with their own hosts and domains, we can apply various
   access filters against them). In reality, a combination of legal and
   technical methods is likely to give the best result.

   This way, the spam problem could be reduced enough to allow the
   Internet community to design and deploy a real and general solution.

   But, please note:

       The Non-Relay rules are not in themselves enough to stop spam.
       Even if 99% of the SMTP MTAs implemented them from Day 1,
       spammers would still find the remaining 1% and use them. Or
       spammers would just switch gear and connect directly to each and
       every recipient host; that will be to a higher cost for the
       spammer, but is still quite likely.

   Even though IPv6 deployment may be near, the spam problem is here
   already and thus this memo restricts itself to the current IPv4.




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


1.3. Terminology

   Throughout this memo we will use the terminology of RFC2119, [4]:

   o   "MUST"

       This word or the adjective "REQUIRED" means that the item is an
       absolute requirement.

   o   "SHOULD"

       This word or the adjective "RECOMMENDED" means that there may
       exist valid reasons in particular circumstances to ignore this
       item, but the full implications should be understood and the case
       carefully weighed before choosing a different course.

   o   "MAY"

       This word or the adjective "OPTIONAL" means that this item is
       truly optional. One vendor may choose to include the item because
       a particular marketplace requires it or because it enhances the
       product, for example; another vendor may omit the same item.

1.4. Using DNS information

   In the memo we sometimes use the term "host name" or "domain name"
   which should be interpreted as a Fully Qualified Domain Name, FQDN.
   By this we mean the name returned from the DNS in response to a PTR
   query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a
   name, or we mean a name with a DNS A or MX record associated to it
   RFC1034, [5], and RFC1035, [6].

   When we suggest use of FQDNs rather than IP addresses this is because
   FQDNs are intuitively much easier to use. However, all such usage
   depends heavily on DNS and .IN-ADDR.ARPA (PTR) information. Since it
   is fairly easy to forge that, either by false cache information
   injected in DNS servers or spammers running their own DNS with false
   information in them, host and domain names must be used with care,
   e.g. verified so that the translation address->name corresponds to
   name->address. With Secure DNS, RFC2065, [7], things will improve,
   since spoofing of .IN-ADDR.ARPA will no longer be possible.

   One of the recommendations is about verifying "MAIL From:" (envelope
   originator) domains with the DNS (assure that appropriate DNS
   information exists for the domain). When making use of this
   capability there are a few things to consider:





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


   (1) One must not forget the increased amount of DNS queries which
       might result in problems for the DNS server itself to cope with
       the load.  This itself can result in a denial of service attack
       against the DNS server just by sending email to a site.

   (2) It should be noted that with negative caching in the DNS, forged
       DNS responses can be used to mount denial of service attacks.
       For example, if a site is known to implement a FQDN validity
       check on addresses in SMTP "MAIL From:" commands, an attacker may
       be able to use negative DNS responses to effectively block
       acceptance of mail from one or more origins. Because of this, one
       should carefully check the DNS server in use, e.g. how it
       verifies that incoming responses correspond to outstanding
       queries, to minimize the risk for such attacks.

   (3) For early versions of spam software FQDN checks provide quite
       some relief, since that software generates mail with completely
       bogus "MAIL From:" that will never get into the system if
       verified with the DNS. This is in active use at many
       installations today and it does reduce spam.

   On the other hand, sites with weak DNS connectivity may find their
   legitimate mail having problems reaching destinations due to DNS
   timeouts when the receivers verify their "MAIL From:". However, since
   DNS information is handled asynchronously and is cached even though
   the initial requester has given up, chances are high that the
   necessary information is there at a later attempt.

   For later versions of spam software, a check of "MAIL From:" is much
   less likely to help, since spam software evolves too and will start
   using existing mail addresses (whether or not that is legal is beyond
   the scope of this memo). But, at least the Internet will benefit from
   the side effect that this test stops typos and misconfigured UAs.

1.5. Where to block spam, in SMTP, in RFC822 or in the UA

   Our basic assumption is that refuse/accept is handled at the SMTP
   layer and that an MTA that decides to refuse a message should do so
   while still in the SMTP dialogue. First, this means that we do not
   have to store a copy of a message we later decide to refuse and
   second, our responsibility for that message is low or none - since we
   have not yet read it in, we leave it to the sender to handle the
   error.








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


1.6. SMTP Return Codes

   SMTP has several classes of Return Codes, see [1] for a discussion:

   o   5xx
       is a Permanent Negative Completion reply (Fatal Error) and
       results in the mail transfer being terminated and the mail
       returned to sender.

   o   4xx
       is a Transient Negative Completion reply (Temporary Error) and
       results in the mail transfer being put back on queue again and a
       new attempt being made later.

   o   2xx
       is a Positive Completion reply and indicates that the MTA now has
       taken responsibility for the delivery of the mail.

   When making use of the options/"knobs" described in this memo there
   are a few things to consider:

   For some events, like "Denied - you're on the spammer's list", 5xx
   may be the correct Return Code, since it terminates the session at
   once and we are done with it (assuming that the spammer plays by the
   SMTP rules, which he may decide not to do - in fact he can put the
   mail back on queue or turn to some other host, regardless of Return
   Code). However, a 5xx mistake in a configuration may cause legitimate
   mail to bounce, which may be quite unfortunate.

   Therefore, we suggest 4xx as the Return Code for most cases. Since
   that is a non fatal error, the mail gets re-queued at the sender and
   we have at least some time to discover and correct configuration
   errors, rather than have mail bounce (typically this is when we
   refuse to Relay for domains that we actually should accept since we
   are on their MX list).

   A 4xx response also makes the spammer's host re-queue the mail and if
   it really is his own host who gets to do this it is probably a good
   thing - fill up his disks with his own spam. If, on the other hand,
   he is using someone else as Relay Host, all the spam mail being
   queued is a fairly strong evidence that something bad is going on and
   should cause attention at that Relay Host.

   However, 4xx Temporary Errors may have unexpected interaction with
   MX-records. If the receiving domain has several MX records and the
   lowest preference MX-host refuses to receive mail with a "451"
   Response Code, the sending host may choose to - and often will - use
   the next host on the MX list.