rfc2635.txt

RFC 的详细文档！

   headers are forged, could be a criminal action depending on the laws
   of the particular jurisdiction(s) involved.  If your site is being
   used as a spam relay, be sure to contact local and national criminal
   law enforcement agencies.  Site operators may also want to consider
   bringing civil actions against the spammer for expropriation of
   property, in particular the computer time and network bandwidth.  In
   addition, when a mailing list is involved, there is a potential
   intellectual property rights violation.

   There are a few law suits in the courts now which claim spammers
   interfered with and endangered network connectivity.  At least one
   company is attempting to charge spammers for the use of its networks
   (www.kclink.com/spam/).

7.  Security Considerations

   Certain actions to stop spamming may cause problems to legitimate
   users of the net. There is a risk that filters to stop spamming will
   unintentionally stop legitimate mail too. Overloading postmasters
   with complaints about spamming may cause trouble to the wrong person,
   someone who is not responsible for and cannot do anything to avoid
   the spamming activity, or it may cause trouble out of proportion to
   the abuse you are complaining about.  Be sure to exercise discretion
   and good judgment in all these cases.  Check your local escalation
   procedure.  The Site Security Handbook [2] can help define an
   escalation procedure if your site does not have one defined.

   Lower levels of network security interact with the ability to trace
   spam via logs or message headers.  Measures to stop various sorts of
   DNS and IP spoofing can make this information more reliable.
   Spammers can and will exploit obvious security weaknesses, especially
   in NNTP servers.  This can lead to denial of service, either from the
   sheer volume of posts, or as a result of action taken by upstream
   providers.

8.  Acknowledgments

   Thanks for help from the IETF-RUN working group, and also to all the
   spew-fighters.  Specific thanks are due to J.D. Falk, whose very
   helpful Anti-spam FAQ proved valuable.  Thanks are also due to the
   vigilance of Scott Hazen Mueller and Paul Vixie, who run
   spam.abuse.net, the Anti-spam web site.  Thanks also to Jacob Palme,
   Chip Rosenthal, Karl Auerbach for specific text: Jacob for the
   Security Considerations section, Chip for the configuration
   suggestions in section 5, Karl for the legal considerations.  Andrew
   Gierth was very helpful with Netnews spam considerations.  And thanks
   to Gary Malkin for proofing and formatting.




Hambridge & Lunde            Informational                     [Page 13]

RFC 2635                       DON'T SPEW                      June 1999


9.  References

   [1] See for example [e-mail]

   [2] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September
       1997.

   [3] "Current Spam thresholds and guidelines," Lewis, Chris and Tim
       Skirvin, http://www.killfile.org/~tskirvin/faqs/spam.html.

   [4] Schwartz, Alan and Simson Garfinkel, "Stopping Spam," O'Reilly
       and Associates, 1998.

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

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

   [7] Crocker, D., "Mailbox Names for Common Services, Roles and
       Functions", RFC 2142, May 1997.

   * Spam is a name of a meat product made by Hormel.  "spam" (no
     capitalization) is routinely used to describe unsolicited bulk
     email and netnews posts.


























Hambridge & Lunde            Informational                     [Page 14]

RFC 2635                       DON'T SPEW                      June 1999


10. Appendix - How to Track Down Spammers

   In a large proportion of spams today, complaining to the postmaster
   of the site that is the apparent sender of a message will have little
   effect because either the headers are forged to disguise the source
   of the message, or the senders of the message run their own
   system/domain, or both.

   As a result, it may be necessary to look carefully at the headers of
   a message to see what parts are most reliable, and/or to complain to
   the second or third-level Internet providers who provide Internet
   service to a problem domain.

   In many cases, getting reports with full headers from various
   recipients of a spam can help locate the source. In extreme cases of
   header forgery, only examination of logs on multiple systems can
   trace the source of a message.

   With only one message in hand, one has to make an educated guess as
   to the source. The following are only rough guidelines.

   In the case of mail messages, "Received:" headers added by systems
   under control of the destination organization are most likely to be
   reliable. You can't trust what the source domain calls itself, but
   you can usually use the source IP address since that is determined by
   the destination domain's server.

   In naive mail forgeries, the "Message-ID:" header may show the first
   SMTP server to handle the message and/or the "Received:" headers may
   all be accurate, but neither can be relied on.  Be especially wary
   when the Received: headers have other headers intermixed.  Normally,
   Received: headers are all together in a block, and when split up, one
   or the other blocks is probably forged.

   In the case of news messages, some part of the Path: header may be a
   forgery; only reports from multiple sites can make this clear.  In
   naive news forgeries, the "NNTP-Posting-Host:" header shows the
   actual source, but this can be forged too.

   If a spam message advertises an Internet server like a WWW site, that
   server must be connected to the network to be usable.  Therefore that
   address can be traced.  It is appropriate to complain to the ISP
   hosting a web site advertised in a SPAM, even if the origin of the
   spam seems to be elsewhere.  Be aware that the spam could be an
   attack on the advertised site; the perpetrator knows the site will be
   deluged with complaints and their reputation will be damaged.  Any
   spam with an electronic address in it is suspect because most
   spammers know they're unwelcome and won't make themselves accessible.



Hambridge & Lunde            Informational                     [Page 15]

RFC 2635                       DON'T SPEW                      June 1999


   Here is an example mail header:

----
From [e-mail] Thu Feb 26 20:32:47 1998
Received: from clio.sc.intel.com by Ludwig.sc.intel.com (4.1/SMI-4.1)
        id AA05377; Thu, 26 Feb 98 20:32:46 PST
Received: from 209.214.12.258.com (209.214.12.258.com [208.26.102.16])
        by clio.sc.intel.com (8.8.6/8.8.5) with ESMTP id UAA29637
        for <[e-mail]>; Thu, 26 Feb 1998 20:33:30 -0800 (PST)
Received: ok
X-Sender: [e-mail]
X-Advertisement: <a href="http://www.opt-out.com">
Click here to be removed.
Date: Thu, 26 Feb 1998 23:23:03 -0500
From: Sent By <[e-mail]>
Reply-To: Sent By <[e-mail]>
To: friend@bulkmailer
Subject: Ad: FREE $50 in Sportsbook & Casino
X-Mailer: AK-Mail 3.0b [eng] (unregistered)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Message-Id: <[e-mail]>
Status: R
----

   Doing a traceroute on an IP address or DNS address will show what
   domains provide IP connectivity from you to that address.

   Using whois and nslookup, one can try to determine who is
   administratively responsible for a domain.

   In simple cases, a user of a responsible site may be exploiting an
   account or a weakness in dial-up security; in those cases a complaint
   to a single site may be sufficient. However, it may be appropriate to
   complain to more than one domain, especially when it looks like the
   spammers run their own system.

   If you look at the traceroute to an address, you will normally see a
   series of domains between you and that address, with one or more
   wide-area/national Internet Service Providers in the middle and
   "smaller" networks/domains on either end. It may be appropriate to
   complain to the domains nearer the source, up to and including the
   closest wide-area ISP.  However, this is a judgement call.

   If an intermediate site appears to be a known, responsible domain,
   stopping your complaints at this point makes sense.



Hambridge & Lunde            Informational                     [Page 16]

RFC 2635                       DON'T SPEW                      June 1999


Authors' Information

   Sally Hambridge
   Intel Corp, SC11-321
   2200 Mission College blvd
   Santa Clara, CA 95052

   EMail: [e-mail]


   Albert Lunde
   Northwestern University
   Suite 1400
   1603 Orrington Avenue
   Evanston, IL 60201

   EMail: [e-mail]


































Hambridge & Lunde            Informational                     [Page 17]

RFC 2635                       DON'T SPEW                      June 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Hambridge & Lunde            Informational                     [Page 18]