rfc2505.txt

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

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


   If that next MX host does not have the same refuse-list, it will of
   course accept the mail, only to find that the final host still
   refuses to receive that piece of mail ("MAIL From:"). Our intent was
   to make the offending mail stay at the offending sender's host and
   fill up his mqueue disk, but it all ended up at our friend, the next
   lowest preference MX-host.

   Finally, it has been suggested that one may use a 2xx Return Code but
   nevertheless decide not to forward or receive the spam mail; typical
   alternatives are to store it elsewhere (e.g. /dev/null). This clearly
   violates the intent of RFC821 and should not be done without careful
   consideration - instead of blindly dropping the mail one could re-
   queue it and manually (or automagically) inspect whether it is spam
   or legitimate mail and whether it should be dropped or forwarded.

1.7. Mailing Lists

   An MTA that also has the ability to handle mailing lists and expand
   that to a number of recipients, needs to be able to authorize senders
   and protect its lists from spam. The mechanisms for this may be very
   different from those for ordinary mail and ordinary users and are not
   covered in this memo.

2. Recommendations

   Here we first give a brief list of recommendations, followed by a
   more thorough discussion of each of them. We will also give
   recommendations on things NOT to do, things that may seem natural in
   the spam fight (and might even work so far) but that might wreak
   havoc on Internet mail and thus may cause more damage than good.

   1)  MUST be able to restrict unauthorized use as Mail Relay.

   2)  MUST be able to provide "Received:" lines with enough
       information to make it possible to trace the mail path, despite
       spammers use forged host names in HELO statements etc.

   3)  MUST be able to provide local log information that makes it
       possible to trace the event afterwards.

   4)  SHOULD be able to log all occurrences of anti-relay/anti-spam
       actions.

   5)  SHOULD be able to refuse mail from a host or a group of hosts.

   6a) MUST NOT refuse "MAIL From: <>".

   6b) MUST NOT refuse "MAIL From: <[e-mail]>".



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


   7a) SHOULD be able to refuse mail from a specific "MAIL From:"
       user, <[e-mail]>.

   7b) SHOULD be able to refuse mail from an entire "MAIL From:"  domain
       <.*@domain.example>.

   8)  SHOULD be able to limit ("Rate Control") mail flow.

   9)  SHOULD be able to verify "MAIL From:" domain (using DNS or
       other means).

   10) SHOULD be able to verify <local-part> in outgoing mail.

   11) SHOULD be able to control SMTP VRFY and EXPN.

   12) SHOULD be able to control SMTP ETRN.

   13) MUST be able to configure to provide different Return Codes
       for different rules (e.g. 451 Temp Fail vs 550 Fatal Error).

   The discussion below often ends up with a need to do various forms of
   pattern matching on domain/host names and IP addresses/subnets.  It
   is RECOMMENDED that the data/template for doing so may be supplied
   outside of the MTA, e.g. that the pattern matching rules be included
   in the MTA but that the actual patterns may be in an external file.
   It is also RECOMMENDED that the pattern matching rules (external
   file) may contain regular expressions, to give maximum flexibility.

   Of course string matching on domain/host names MUST NOT be case
   sensitive. Since <local-part> may be case sensitive it may be natural
   to keep that here. However, since <[e-mail]> and
   <[e-mail]> is most probably the same user and since the
   string compares are used to refuse his messages, we suggest that
   <local-part> comparisons be case insensitive too.

   The interpretation that should apply to all these recommendations is
   flexibility - regardless of how well we design anti-spam rules today,
   spammers will find ways around them and a well designed MTA should be
   flexible enough to meet those new threats.

2.1. Restricting unauthorized Mail Relay usage

   Unauthorized usage of a host as Mail Relay means theft of the relay's
   resources and puts the relay owner's reputation at risk. It also
   makes it impossible to filter out or block spam without at the same
   time blocking legitimate mail.

   Therefore, the MTA MUST be able to control/refuse such Relay usage.



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


   In an SMTP session we have 4 elements, each with a varying degree of
   trust:

   1)  "HELO Hostname"           Easily and often forged.
   2)  "MAIL From:"              Easily and often forged.
   3)  "RCPT To:"                Correct, or at least intended.
   4)  SMTP_Caller (host)        IP.src addr OK, FQDN may be OK.

   Since 1) and 2) are so easily and often forged, we cannot depend on
   them at all to authorize usage of our host as Mail Relay.

   Instead, the MTA MUST be able to authorize Mail Relay usage based on
   a combination of:

   o   "RCPT To:" address (domain).
   o   SMTP_Caller FQDN hostname.
   o   SMTP_Caller IP address.

   The suggested algorithm is:

   a)  If "RCPT To:" is one of "our" domains, local or a domain that
       we accept to forward to (alternate MX), then accept to Relay.

   b)  If SMTP_Caller is authorized, either its IP.src or its FQDN
       (depending on if you trust the DNS), then accept to Relay.

   c)  Else refuse to Relay.

   When doing a) you have to make sure all kinds of SMTP source routing
   (both the official [@a,@b:u@c], the '%' hack and uucp-style '!' path)
   is either removed completely before the test, or at least is
   taken into account.

   A site implementing this requirement must also be aware that they
   might block correctly addressed messages, especially such originating
   or terminating in a gateway to a different mail system than SMTP.
   Before implementing such a policy, a careful inventory should be done
   to make sure all routing algorithms used, either by other mail
   systems or ad-hoc, are known. Each one of such systems must be taken
   care of on a case-by-case basis.

   Examples of such mail systems, and their addressing schemes are X.400
   with an address of the type:

       "/c=us/admd= /prmd=xyz/dd.rfc-822=user(a)final/"@x400-gateway

   Another example involves DECnet MAIL-11, which can have addresses in
   the form:



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


       "gateway::smtp%\"user@final\""@mail-11-gateway

   In all cases the configuration MUST support wild cards for FQDNs and
   classful IP addresses and SHOULD support "address/mask" for classless
   IP addresses, e.g. domain.example and *.domain.example; 10.11.*.*,
   192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23.

   The configuration SHOULD allow for the decision/template data to be
   supplied by an external source, e.g. text file or dbm database. The
   decision/template SHOULD be allowed to contain regular expressions.

2.2. Received: lines

   The MTA MUST prepend a "Received:" line in the mail (as described in
   RFC822, [2], and required in RFC1123, [3]). This "Received:" line
   MUST contain enough information to make it possible to trace the mail
   path back to the sender. We have two cases:

2.2.1. Direct MTA-to-MTA connections

   Internet mail was designed such that the sending host connects
   directly to the recipient as described by MX records (there may be
   several MX hosts on a priority list). To assure traceability back to
   the sending host (which may be a firewall/gateway, as described
   later) each MTA along the path, including the final MTA, MUST prepend
   a "Received:" line. For such a "Received:" line we have:

   It MUST contain:

   o   The IP address of the caller.

   o   The 'date-time' as described in RFC822, [2], pp 18.

   It SHOULD contain:

   o   The FQDN corresponding to the callers IP address.

   o   The argument given in the "HELO" statement.

   o   Authentication information, if an authenticated connection
       was used for the transmission / submission.

   It is suggested that most other "Received:" fields described in
   RFC822 be included in the "Received:" lines.

   Basically, any information that can help tracing the message can and
   should be added to the "Received:" line. It is true even when the
   initial submission is non-SMTP, for example submission via a web-based



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


   mail client where http is used between the web client and server, a
   "Received:" line can be used to identify that connection stating what
   IP-address was used when connecting to the http server where the mail
   was created.

   These recommendations are deliberately stronger than RFC1123, [3],
   and are there to assure that mail sent directly from a spammer's host
   to a recipient can be traced with enough accuracy; a typical example
   is when a spammer uses a dialup account and the ISP needs to have his
   IP address at the 'date-time' to be able to take action against him.

2.2.2. Firewall/gateway type devices

   Organizations with a policy of hiding their internal network structure
   must still be allowed and able to do so. They usually make their
   internal MTAs prepend "Received:" lines with a very limited amount of
   information, or prepend none at all. Then they send out the mail
   through some kind of firewall/gateway device, which may even remove
   all the internal MTAs' "Received:" lines before it prepends its own
   "Received:" line (as required in RFC1123, [3]).

   By doing so they take on the full responsibility to trace spammers
   that send from inside their organization or they accept to be held
   responsible for those spammers' activities. It is REQUIRED that the
   information provided in their outgoing mail is sufficient for them to
   perform any necessary traces.

   In the case of incoming mail to an organization, the "Received:"
   lines MUST be kept intact to make sure that users receiving mail on
   the inside can give information needed to trace incoming messages to
   their origin.

   Generally, a gateway SHOULD NOT change or delete "Received:" lines
   unless it is a security requirement to do so. Changing the content
   of existing "Received:" lines to make sure they "make sense" when
   passing a mail gateway of some kind most often destroys and deletes
   information needed to make a message traceable. Care must be taken to
   preserve the information in "Received:" lines, either in the message
   itself, the mail that the receiver gets, or if that is impossible, in
   logfiles.

2.3. Event logs

   The MTA MUST be able to provide enough local log information to make
   it possible to trace the event. This includes most of the information
   put into the "Received:" lines; see above.





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


2.4. Log anti-relay/anti-spam actions

   The MTA SHOULD be able to log all anti-relay/anti-spam actions. The
   log entries SHOULD contain at least:

   o   Time information.

   o   Refusal information, i.e. why the request was refused ("Mail
       From", "Relaying Denied", "Spam User", "Spam Host", etc).

   o   "RCPT To:" addresses (domains).
       (If the connection was disallowed at an earlier stage, e.g.
       by checking the SMTP_Caller IP address, the "RCPT To:"
       address is unknown and therefore cannot be logged).

   o   Offending host's IP address.

   o   Offending host's FQDN hostname.

   o   Other relevant information (e.g. given during the SMTP
       dialogue, before we decided to refuse the request).

   It should be noted that by logging more events, especially denied
   email, one opens the possibility for denial of service attacks, for
   example by filling logs by having a very large amount of "RCPT To:"
   commands. An implementation that implements increased logging
   according to this description must be aware of the fact that the size
   of the logfiles increases, especially during attacks.

2.5. Refuse mail based on SMTP_Caller address

   The MTA SHOULD be able to accept or refuse mail from a specific host
   or from a group of hosts. Here we mean the IP.src address or the FQDN
   that its .IN-ADDR.ARPA resolves to (depending on whether you trust
   the DNS). This functionality could be implemented at a firewall, but
   since the MTA should be able to "defend itself" we recommend it be able
   to as well.

   It is RECOMMENDED that the MTA be able to decide based on FQDN hostnames
   (host.domain.example), on wild card domain names (*.domain.example),
   on individual IP addresses (10.11.12.13) or on IP addresses with a
   prefix length (10.0.0.0/8, 192.168.1.0/24).

   It is also RECOMMENDED that these decision rules can be combined to
   form a flexible list of accept/refuse/accept/refuse, e.g:






Lindberg                 Best Current Practice                 [Page 12]