rfc2505.txt

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


RFC 2505               Anti-Spam Recommendations           February 1999


       accept   host.domain.example
       refuse   *.domain.example
       accept   10.11.12.13
       accept   192.168.1.0/24
       refuse   10.0.0.0/8

   The list is searched until first match and the accept/refuse action
   is based on that.

   IP-address/length is RECOMMENDED. However, implementations with wild
   cards, e.g. 10.11.12.* (classful networks on byte boundaries only)
   are of course much better than those without.

   To improve filtering even more, the MTA MAY provide complete regular
   expressions to be used for hostnames; possibly also for IP addresses.

2.6. "MAIL From: <>" and "MAIL From: <[e-mail]>"

   Although the fight against spammers is important it must never be
   done in a way that violates existing email standards. Since spammers
   often forge "MAIL From:" addresses it is tempting to put general
   restrictions on that, especially for some "obvious" addresses. This
   may, however, wreak more havoc to the mail community than spam does.

   When there is a need to refuse mail from a particular host or site
   our recommendation is to use other methods mentioned in this memo,
   e.g. refuse mail based on SMTP_Caller address (or name), regardless
   of what "MAIL From:" was used.

2.6.1. "MAIL From: <>"

   The MTA MUST NOT refuse to receive "MAIL From: <>".

   The "MAIL From: <>" address is used in error messages from the mail
   system itself, e.g. when a legitimate mail relay is used and forwards
   an error message back to the user. Refusing to receive such mail
   means that users may not be notified of errors in their outgong mail,
   e.g.  "User unknown", which will no doubt wreak more havoc to the
   mail community than spam does.

   The most common case of such legitimate "MAIL From: <>" is to one
   recipient, i.e. an error message returned to one single individual.
   Since spammers have used "MAIL From: <>" to send to many recipients,
   it is tempting to either reject such mail completely or to reject all
   but the first recipient. However, there are legitimate causes for an
   error mail to go to multiple recipients, e.g. a list with several
   list owners, all located at the same remote site, and thus the MTA
   MUST NOT refuse "MAIL From: <>" even in this case.



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


   However, the MTA MAY throttle down the TCP connection ("read()"
   frequency) if there are more than one "RCPT To:" and that way slow
   down spammers using "MAIL From: <>".

2.6.2. "MAIL From: <[e-mail]>"

   The MTA MUST NOT refuse "MAIL From: <[e-mail]>".

   By "my.local.dom.ain" we mean the domain name(s) that are treated as
   local and result in local delivery. At first thought it may seem like
   noone else will need to use "MAIL From: <[e-mail]>" and
   that restrictions on who may use that would reduce the risk of fraud
   and thus reduce spam. While this may be true in the (very) short
   term, it also does away with at least two legitimate usages:

   o   Aliases (.forward files).
       <[e-mail]> sends to <[e-mail]> and
       that mail gets forwarded back to <[e-mail]>, e.g.
       since <user2> has moved to my.local.dom.ain and has a .forward
       file at external.example.

   o   Mailing lists.
       RFC1123, [3], gives a clear requirement that "MAIL From:" for
       mail from a mailing list should reflect the owner of the list,
       rather than the individual sender. Because of this fact, and the
       fact that the owner of the list might not be in the same domain
       as the list (list host) itself, mail may arrive to the list
       owner's domain (mail host) from a foreign domain (from a host
       serving a foreign domain) with the list owner's local domain in
       the "Mail From:" command.

   If "MAIL From: <[e-mail]>" is rejected, both these cases
   will result in failure to deliver legitimate mail.

2.7. Refuse based on "MAIL From:"

   The MTA SHOULD be able to refuse to receive mail from a specific
   "MAIL From:" user ([e-mail]) or from an entire "MAIL From:"
   domain (domain.example). In general these kinds of rules are easily
   overcome by the spammers changing "MAIL From:" every so often, but
   the ability to block a certain user or a certain domain is quite
   helpful while an attack has just been discovered and is ongoing.

   Please note that

       "MAIL From: <>"
   and
       "MAIL From: <[e-mail]>"



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


   MUST NOT be refused (see above), except when other policies block the
   connection, for example when the SMTP_Caller IP address of the peer
   belongs to a network which is deliberately refused.

2.8. Rate Control

   The MTA SHOULD provide tools for the mail host to control the rate
   with which mail is sent or received. The idea is twofold:

   1)  If we happen to have an legitimate mail user with an existing
       legitimate account and this user sends out spam, we may want to
       reduce the speed with which he sends it out. This is not without
       controversy and must be used with extreme care, but it may
       protect the rest of the Internet from him.

   2)  If we are under a spam attack it may help us considerably just
       being able to slow down the incoming mail rate for that
       particular user/host.

   For sending mail, this has to be done by throttling the TCP
   connection to set the acceptable output data rate, e.g. reduce the
   "write()" frequency.

   For receiving mail, we could use basically the same technique, e.g.
   reduce the "read()" frequency, or we could signal with a 4xx Return
   Code that we cannot receive. It is RECOMMENDED that the decision to
   take such action be based on "MAIL From:" user, "MAIL From:" domain,
   SMTP_Caller (name/address), "RCPT TO:", or a combination of all
   these.

2.9. Verify "MAIL From:"

   The MTA SHOULD be able to perform a simple "sanity check" of the
   "MAIL From:" domain and refuse to receive mail if that domain is
   nonexistent (i.e. does not resolve to having an MX or an A record).
   If the DNS error is temporary, TempFail, the MTA MUST return a 4xx
   Return Code (Temporary Error). If the DNS error is an Authoritative
   NXdomain (host/domain unknown) the MTA SHOULD still return a 4xx
   Return Code (since this may just be primary and secondary DNS not
   being in sync) but it MAY allow for an 5xx Return Code (as configured
   by the sysadmin).

2.10. Verify <local-part>

   The MTA SHOULD allow outgoing mail to have its <local-part> verified
   so that the sender name is a real user or an existing alias. This is
   basically to protect the rest of the Internet from various "typos"




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


       MAIL From: <[e-mail]>

   and/or malicious users

       MAIL From: <[e-mail]>

   As always this can be overcome by spammers really wanting to do so,
   but with more strict rules for relaying it becomes harder and harder.
   In fact, catching "typos" at the initial (and official) mail relay is
   in itself enough motivation for this recommendation.

2.11. SMTP VRFY and EXPN

   Both SMTP VRFY and EXPN provide means for a potential spammer to test
   whether the addresses on his list are valid (VRFY) and even get more
   addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed
   to issue these commands. This may be "on/off" or it may use access
   lists similar to those mentioned previously.

   Note that the "VRFY" command is required according to RFC821, [1].
   The response can, though, be "252 Argument not checked" to represent
   "off" or blocked via an access list. This should be the default.

   Default for the "EXPN" command should be "off".

2.12. SMTP ETRN

   SMTP ETRN means that the MTA will re-run its mail queue, which may be
   quite costly and open for Denial of Service attacks. Therefore, the
   MTA SHOULD control who is is allowed to issue the ETRN command.  This
   may be "on/off" or it may use access lists similar to those mentioned
   previously. Default should be "off".

2.13. Return Codes

   The primary issue here is flexibility - it is simply not possible to
   define in a document how to make tradeoffs between returning 5xx and
   make legitimate mail fail at once due to a configuration mistake and
   returning 4xx and be able to catch such configuration mistakes via
   log file inspection.

   Therefore, the MTA MUST be configurable to provide "Success" (2xx),
   "Temporary Failure" (4xx) or "Permanent Failure" (5xx) for different
   rules or policies. The exact return codes, other than the first digit
   (2, 4 or 5) should, however, not be configurable.  This is because of
   the ease of configuring the software in the wrong way, and the fact





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


   that the selection of exactly what error code to use is very subtle
   and that many software implementations do check more than the first
   digit (2, 4 or 5) in the return code.

   However, when the response is the result of a DNS lookup and the DNS
   system returned TempFail, a temporary error, the MTA MUST reflect
   this and provide a 4xx return code. If the DNS response is an
   Authoritative NXdomain (host or domain unknown) the MTA MAY reflect
   this by a 5xx Return Code.

   Please refer to the previous discussion on SMTP Return Codes for
   additional information.

2.13.1. The importance of flexibility - an example

   At Chalmers University of Technology our DNS contains

       cdg.chalmers.se.  IN  MX    0   mail.cdg.chalmers.se.
                         IN  MX  100   mail.chalmers.se.

   and similarly for most subdomains, i.e. a second host to store mail
   to each subdomain, should their mail host be down. This means that
   mail.chalmers.se must be prepared to act as Mail Relay for the
   subdomains ("RCPT To:") it serves and that those subdomains' mail
   hosts have to accept SMTP connections from mail.chalmers.se. Late
   versions of spam software make use of this fact by always using
   mail.chalmers.se to get their mail delivered to our subdomains and by
   doing so they still get Mail Relaying done for them and they prevent
   recipient hosts from refusing SMTP connections based on the sending
   host's FQDN or IP-address.

   As long as we keep our design with a secondary MX host we cannot
   really have mail.chalmers.se refuse Mail Relay, at least not with a
   5xx return code. However, it has been fairly straight forward to
   identify the hosts/domains/networks that make use of this possibility
   and refuse to act as Mail Relay for them them - and only them - and
   do so with a 4xx return code. Legitimate mail from them may be
   delayed if the final recipient host is down but will eventually be
   delivered when it gets up again (4xx Return Code) and this is no
   worse then if we changed our MX design. Spam now faces a "Denied"
   response and have to connect to each and every one of the recipients,
   who may decide to refuse the SMTP connection.

   The bottom line is that this is made possible because of 1) enough
   flexibility in the Relay Authorization code and 2) enough flexibility
   in assigning Return Codes - an MTA with a 5xx Return Code carved in
   stone would have made this absolutely impossible.




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


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.




Lindberg                 Best Current Practice                 [Page 18]