home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / usenet / cancel-faq / part3 < prev   
Encoding:
Internet Message Format  |  2004-05-15  |  24.1 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!nntp.cs.ubc.ca!news.killfile.org!not-for-mail
  2. From: tskirvin@killfile.org (Tim Skirvin)
  3. Newsgroups: news.admin.net-abuse.bulletins,news.admin.net-abuse.usenet,news.admin.net-abuse.sightings,news.admin.net-abuse.misc,news.answers
  4. Subject: Cancel Messages: Frequently Asked Questions, Part 3/4 (v1.75)
  5. Supersedes: <cancelfaq20030915050002$19d1@news.killfile.org>
  6. Followup-To: news.admin.net-abuse.usenet
  7. Date: Sat, 15 May 2004 00:00:01 -0500
  8. Organization: Killfiles, Unlimited
  9. Lines: 574
  10. Approved: news-answers-request@mit.edu
  11. Expires: Sat, 26 Jun 2004 05:00:01 GMT
  12. Message-ID: <cancelfaq20040515050001$6630@news.killfile.org>
  13. Reply-To: tskirvin@killfile.org
  14. X-Trace: victor.killfile.org 1084597205 26756 216.43.25.138 (15 May 2004 05:00:05 GMT)
  15. X-Complaints-To: usenet@killfile.org
  16. Summary: This is a list of Frequently Asked Question about cancel messages
  17.      on Usenet.  It mainly discusses how cancels work, who issues 
  18.      them, their history, and what to do about them.  It is more of
  19.      a general purpose FAQ than anything else; it's not required 
  20.      reading anywhere, just more of a reference.
  21. X-Auth: PGPMoose V1.1 PGP news.admin.net-abuse.sightings
  22.     iD8DBQFApaPSv1i8LqUfqQURAo75AJ9+XGVOAEO+XOANuwvrgUcR2SUUuACdFD4T
  23.     RLJ4YIp+doXTbucz97nlvZw=
  24.     =Htbs
  25. Xref: senator-bedfellow.mit.edu news.admin.net-abuse.bulletins:34807 news.admin.net-abuse.usenet:610098 news.admin.net-abuse.sightings:1406499 news.admin.net-abuse.misc:222754 news.answers:271285
  26.  
  27. Archive-name: usenet/cancel-faq/part3
  28. Posting-Frequency: monthly
  29. Last-modified: 1999/09/30
  30. Version: 1.75
  31. URL: <URL:http://www.killfile.org/faqs/cancel.html>
  32.  
  33. Cancel Messages 
  34. Frequently Asked Questions
  35. Part 3/4
  36.  
  37. This document contains information about cancel messages on Usenet, such
  38. as who is allowed to use them, how they operate, what to do if your
  39. message is cancelled, and the like.  It does not contain detailed 
  40. instructions on how to cancel a third party's posts.  It is not intended 
  41. to be a fully technical document; its audience is the average Usenet user, 
  42. up to a mid-level administrator.
  43.  
  44. This document is not meant to be a comprehensive explanation of Usenet
  45. protocols, or of Usenet itself, but a basic knowledge of these concepts
  46. is assumed.  Please refer to news.announce.newusers, RFC1036, and/or
  47. RFC1036bis if you wish to learn them.
  48.  
  49. Disclaimers: The information contained within is potentially hazardous;
  50. applying it without the permission of your news administrator may cause
  51. the revocation of your account, civil action against you, and even the
  52. possibility of criminal lawsuits.  The author of this document is in no 
  53. way liable for misuse of the information contained within, nor is he in
  54. any way responsible for damages related to the use or accuracy of the
  55. information.  Proceed at your own risk.
  56.  
  57.  
  58. Table of Contents        > = In other parts of the FAQ
  59. =================        * = Changed since last update
  60. >I. What are cancel messages?
  61. >II. How do cancels work?
  62. >III. So your post was cancelled...
  63. >IV. What does it take to cancel messages?
  64. >V. That idiot forge-cancelled my posts!
  65. >VI. What moral issues are involved with cancel messages?
  66. VII. What's going to happen to cancels in the future?
  67.    A. What are authenticated cancels?
  68.    B. Are there any other Usenet methods to delete messages?    
  69.    C. Why are some people turning off cancels altogether?    
  70.    D. What is NoCeM?
  71.    E. What is PGP?
  72. VIII. What about these other things?
  73.    A. What is Lazarus?
  74.    B. What is Dave the Resurrector?
  75.    C. What was the Judges-L mailing list?            
  76.    D. What is the UDP?                        
  77. IX. What are the current cancel issues?            
  78.    A. What are the cancel-on-sight rules?            
  79.    B. Are HTML postings cancellable?                    
  80.    C. What happened to copyright cancels?            
  81.    D. What should be done about unaccountable spam cancellers?
  82.    E. What should be done about open news servers?
  83.    F. How should hierarchies opt out of spam cancels?
  84.  
  85. Changes
  86. To Do
  87. Contributors
  88. Pointers
  89.  
  90. >Appendix A: Dave the Resurrector
  91. >Appendix B: Retromoderation
  92.  
  93.  
  94. VII. What's going to happen to cancels in the future?
  95. =====================================================
  96.  A. What are authenticated cancels?
  97.  
  98.     Usenet was not built with security in mind; the fact that it's
  99. relatively simple to forge a cancel proves this.  
  100.  
  101.     As time goes on, though, the need for security is becoming more
  102. and more obvious.  One way of making this security would be to change
  103. the software to only accept cancels that include verification of a match
  104. between the poster and the canceller; such verification might take the
  105. form of a PGP-signature or some other similar method.
  106.  
  107.     There have been many methods proposed to accomplish this; at
  108. this point, none are in wide use.  If anyone would like to write some
  109. software to accomplish this, please do so, and discuss it on news.admin.
  110. misc; the CancelMoose has a few suggestions for authenticated cancels on 
  111. his web page at <URL:http://www.cm.org/>.
  112.  
  113.  
  114.  B. Are there any other Usenet methods to delete messages?
  115.  
  116.     Of course.  
  117.  
  118.   1.  How does the Supersedes: header work?
  119.  
  120.     Commonly used for periodic postings and other information
  121. updates, the Supersedes: header replaces an old message with a new one.
  122. It is especially useful for FAQ maintainers, who use it to replace old
  123. versions of the FAQ with more up-to-date ones - this FAQ, for example,
  124. uses it.  To replace the message <4b6uce$ou7@vixen.cso.uiuc.edu>, you would 
  125. want to add the header:
  126.  
  127. Supersedes: <4b6uce$ou7@vixen.cso.uiuc.edu>
  128.  
  129.     The use of Supersedes: is otherwise basically the same as a
  130. cancel message, and third-party superseding should be treated the same
  131. as third-party cancels.  
  132.  
  133.   2.  How does the Expires: header work?
  134.  
  135.     By adding the Expires: header to your post, you can override the
  136. standard expiration time on most systems and make your message be deleted 
  137. from most systems at a time of your choosing.  This is especially useful for 
  138. time-dated information and FAQs which are meant to be reposted on a regular 
  139. basis.  If you want your message to expire at 7:50:06pm (PST) on 2/11/96, add 
  140. the following header (the format must be followed exactly):
  141.  
  142. Expires: Sun, 11 Feb 1996 19:50:06 PST
  143.  
  144.     Your message should expire by this date.  It may expire earlier, 
  145. depending on the system setup and expiry times.
  146.  
  147.   3.  What is the Also-Control: header?
  148.  
  149.     The Also-Control: header acts just like a standard Control:
  150. header, except that the post is also filed in whatever groups it was
  151. posted to, as opposed to being filed in control.  Otherwise, the two are
  152. interchangeable, though the former is very rarely used.
  153.  
  154.  
  155.  C. Why are some people turning off cancels altogether?
  156.  
  157.     Until authenticated cancels catch on, there are no options to 
  158. avoid forged cancels and allow unforged ones.  One option, advocated by 
  159. a few, vocal people that don't want to allow such forgery, is to not 
  160. accept cancels at all.  If you want to do so, you're welcome to, but it 
  161. probably isn't the best option, at least in the near future.  
  162.  
  163.  
  164.  D. What is NoCeM?
  165.  
  166.     NoCeM, pronounced "No See-Umm", is a piece of news software
  167. written to mostly replace cancel messages.  Instead of deleting the
  168. messages automatically, NoCeM works by allowing anyone to send out a
  169. message that basically states "you don't want to read this".  Indiviual
  170. news systems or users may then act on these messages as they see fit,
  171. from deleting the messages or marking them as read, to merely ignoring
  172. the advice altogether, to even marking those messages to be read as soon
  173. as possible.  The idea is being hailed as a worthy replacement for
  174. third-party cancels by many news administrators, and it is slowly gaining 
  175. support.
  176.  
  177.     CancelMoose (moose@cm.org) authored the client software, which is
  178. currently available for most Unix clients that can use PGP (VII.E).
  179. news.lists.nocem has been created for the distribution of NoCeM
  180. messages; discussion of the protocol belongs in news.software.misc.  For
  181. more information on NoCeM, refer to the Moose's homepage at 
  182. <URL:http://www.cm.org/>.
  183.  
  184.  
  185.  E. What is PGP?
  186.  
  187.     PGP stands for "Pretty Good Privacy", and is a greatly heralded
  188. encryption program made for everyday use.  It is at the heart of most
  189. authenticated cancel schemes, NoCeM, and much other Usenet software.
  190. Unfortunately, the import and export laws regarding the software vary,
  191. making its availibility questionable in countries other than the USA.
  192.  
  193.     PGP is a topic on its own, and as such has several FAQs of its
  194. own, as well as several newsgroups.  For more information, I recommend you
  195. read one of these FAQs, such as the comp.security.pgp FAQ (availible at
  196. <URL:http://www.pgp.net/pgpnet/pgp-faq/>).
  197.  
  198.  
  199.  
  200. VIII. What about these other things?
  201. ====================================
  202.  A. What is Lazarus?
  203.  
  204.     Lazarus is a program written for use on alt.religion.scientology
  205. by Homer Wilson Smith (homer@light.lightlink.com).  It monitors control 
  206. and posts a message to a.r.s whenever it finds a message relating to the 
  207. group.  The basic effect of this is that all cancels are *very* visible.  
  208.  
  209.     For more information on why this was necessary, refer to Ron
  210. Newman's "The Church of Scientology vs the Net" page, at <URL:http://www2.
  211. thecia.net/users/rnewman/scientology/home.html>.
  212.  
  213.  
  214.  B. What is Dave the Resurrector?
  215.  
  216.     Dave the Resurrector is a program run in news.admin.* and several
  217. other newsgroups that reposts cancelled articles.  See Appendix A for 
  218. details on its creation and operation.
  219.  
  220.  
  221.  C. What was the Judges-L mailing list?
  222.  
  223.     A while back, a guy named David Stodolsky decided that he was
  224. going to be in charge of cancels on Usenet.  He set up a mailing list to
  225. this effect, Judges-L, and expected to start working.
  226.  
  227.     The rest of the world didn't exactly want him to be Emperor of 
  228. Usenet.
  229.  
  230.     After a short flamewar, an early FAQ on Cancel Messages was
  231. written as a result of the Judges-L list; while technically accurate, it
  232. had little influence on the creation of this FAQ.  In the mean time, the
  233. Judges-L list was dissolved; David Stodolsky is rarely seen on Usenet
  234. anymore.
  235.  
  236.  
  237.  D. What is the UDP?
  238.  
  239.     UDP stands for the "Usenet Death Penalty",  the final weapon 
  240. against those that attempt to abuse Usenet.  It is never entered into
  241. lightly.
  242.  
  243.     Originally, the UDP referred to auto-cancellation of all
  244. messages from a certain site as a final solution to too much abuse.  As
  245. Usenet terms tend to change over time, the meaning mutated into meaning
  246. to refer to the aliasing out of a certain site by many major sites, thus
  247. "shunning" them off of Usenet.  This latter method is now more commonly
  248. called a "passive UDP", and is widely accepted as being only the decision
  249. of the sites involved; the former has been renamed to "active UDP", and is
  250. much more controversial.
  251.  
  252.     Active UDPs are saved for those sites that absolutely refuse to
  253. stop abuse from their systems.  Sites which allow abuse of their system 
  254. for weeks straight are given warnings, culminating in a public discussion
  255. of whether a UDP is warranted.  If a consensus is reached that it is
  256. necessary, the offending site is given a week to fix the problem - after
  257. that, all articles from the site are automatically cancelled until the
  258. abuse stops.  All in all, this tactic is more politically than technically
  259. effective, but that doesn't stop the mere threat of an active UDP from
  260. being enough to make most ISPs clean up their act.
  261.  
  262.     The ethics and morals of active UDPs are, of course, still in
  263. debate.  
  264.  
  265.  
  266.  
  267. IX. What are the current cancel issues?
  268. =======================================
  269.  A. What are the cancel-on-sight rules?
  270.  
  271.     If a message is guaranteed to be spam beyond the cancel thresholds, 
  272. anybody may issue a cancel for it - the problem comes with confirming that 
  273. the post is, indeed, beyond the cancel thresholds.  Usually, this is done
  274. automatically with scanning software by the major spam cancellers; they
  275. are not perfect, however, and sometimes the software misses a few messages.
  276. Individuals, however, must check the thresholds by hand - which takes a
  277. great deal of time and effort.
  278.     
  279.     To solve this problem, a certain class of spam has been declared -
  280. cancel-on-sight.  If a particular spam has stayed above a certain threshold 
  281. daily, and shows no signs of stopping in the immediate future, the spam is
  282. declared cancel-on-sight - from then on, any instances of the spam may be
  283. cancelled on sight, without requiring checking by the canceller, on the
  284. theory that the spam must have passed the thresholds long ago.
  285.  
  286.     Currently, the only spam declared cancel-on-sight is the ongoing
  287. "Make Money Fast!" spam/scam in all its forms.  Details for declaring
  288. other spams cancel-on-sight are still being worked out in news.admin.
  289. net-abuse.policy.  
  290.  
  291.  
  292.  B. Are HTML postings cancellable?
  293.  
  294.     Most modern web browsers allow for posting to Usenet; they also
  295. generally offer an option to post messages in HTML, for easier viewing by
  296. other browsers - at the expense of significantly larger post sizes and
  297. much-increased difficulty of viewing by the rest of the Usenet community.
  298. This poor mixing of HTML and Usenet has been fought tooth-and-nail by
  299. Usenet readers, moderators, and administrators, but the postings continue.
  300.  
  301.     One suggestion to stop HTML posting is to declare HTML posts to be
  302. binary messages, and thus cancellable under the bincancel rules.  This
  303. idea has not been implemented, simply because HTML messages are *not* binary 
  304. messages, under current definitions, and if the definitions were changed
  305. the consensus would probably disappear.  
  306.     
  307.     In short: no, postings are not cancellable merely for being in
  308. HTML.
  309.  
  310.  
  311.  C. What happened to copyright cancels?
  312.  
  313.     Copyright cancels were a rarely-used type of third-party cancel
  314. where messages are cancelled for being copyright violations.  The idea
  315. behind the cancels was to stop the violations from spreading; cancels are
  316. fairly ineffective in this respect, however, because not all sites honor 
  317. cancels.  This ineffectiveness, combined with a desire by most news
  318. administrators to stay out of legal matters, was enough to declare the 
  319. consensus regarding copyright cancels void.  The only remedy for copyright
  320. violations on Usenet has again become the real-world legal system.
  321.  
  322.  
  323.  D. What should be done about unaccountable spam cancellers?
  324.  
  325.     The current winner of the "most cancels issued" award is Cosmo
  326. Roadkill, a 'bot operated by "Uncle Roadkill" that single-handedly cancels
  327. most of Usenet's spam.  This was, for a time, considered a good thing;
  328. still, the 'bot isn't perfect, and over time people have found more and
  329. more problems with Cosmo.  This too would be okay, except for one thing -
  330. Uncle Roadkill never responds to complaints.
  331.  
  332.         There still isn't really a true response to this issue, but at
  333. least people are outraged.
  334.  
  335.     
  336.  E. Whae should be done about open news servers?
  337.  
  338.     Most rogue cancel attacks on Usenet are performed using news
  339. servers that allow public reading and posting.  This was originally done
  340. to allow an "open" Usenet, where people could read and post from other
  341. servers to help guarantee better propagation and a nice atmosphere; now,
  342. though, the potential for abuse is too great, and so most open news
  343. servers are being shut down.  This is generally considered a good thing.
  344.  
  345.     There are, though, a few that will miss the old open system; as
  346. such, there are still ideas floating around for how to allow those servers
  347. to remain open and still not allow any significant abuse.
  348.  
  349.  
  350.  F. How should hierarchies opt out of spam cancels?
  351.  
  352.     On July 18, 1998, the free.* hierarchy was recreated under the
  353. theory of "no control, no cancels, no rmgroups".  One of the unexpected
  354. shocks caused by this creation was from the spam cancellers - they didn't
  355. necessarily want to exclude free.* from their filters, and were outraged
  356. that somebody would tell them what to do on the matter without even
  357. discussing it ahead of time.  Others responded that it was the cancellers'
  358. responsibility to follow the wishes of the hierarchy, and that if they
  359. wouldn't do so how were they better than the rogue cancellers?
  360.  
  361.     While this particular flamewar finally burned out, the underlying
  362. embers of the issue are still burning - how should hierarchies opt out
  363. from spam cancels?  Is it the responsibility of the cancellers to ask
  364. permission to cancel the posts?  Or must hierarchies request such things,
  365. and work with the cancellers to ensure that it works?  
  366.  
  367.  
  368.  
  369. Changes
  370. =======
  371. v1.0  -> v1.01    Updated the style slightly
  372.         Clarified the meanings of EMP and ECP
  373.         Added a section in I, "Where can I find cancel messages?"
  374.         Added some newsreaders' cancel buttons
  375. v1.01 -> v1.1    Updated the addresses to have the HTML version
  376.         Got some information about CNews
  377.         Got approval for posting to news.answers
  378.         Fixed a few errors here and there
  379. v1.1  -> v1.2   Added slrn to the newsreaders' cancel buttons list
  380.         Updated the section on NoCeM
  381.         Added a section on PGP    
  382.         Made a few slight cosmetic changes
  383. v1.2  -> v1.25  Added references to the Bincancel FAQ
  384.          Updated the definition of a spew
  385.         Added "unauthorized copyrighted material" to the list of 
  386.           valid reasons for cancel messages (with disclaimers).  
  387.         Added Agent's cancel button
  388.         Added a disclaimer for the CNews information
  389. v1.25 -> v1.3    Added references to the Spam Thresholds FAQ
  390.         Added references to Dave Hayes' "Site of Virtue" page
  391.         Changed the definition of a 'spew'
  392.         Updated IV.E.
  393.         Added a section on the ellisd and pseudosite cancel 
  394.           incidents
  395. v1.3  -> v1.31  Updated the newsgroups, based on the recent news.admin.
  396.           net-abuse.* reorganization
  397.         Added a link to the news.admin.net-abuse homepage
  398.         Updated the cancelbot section to warn against publicly 
  399.            distributed ones
  400.         Updated the information on the psuedosite cancel attack
  401. v1.31 -> v1.4   Made lots of cosmetic changes
  402.         Removed invalid CNews information, updated INews aliasing
  403.            information
  404.         Virtually re-wrote IV.G.
  405. v1.4  -> v1.5    Added an appendix on Dave the Resurrector
  406.  Jun 11, 1997    Added an appendix on Retromoderation
  407.         Updated the rogue cancellers section (V.D.)
  408.         Clarified the pseudosite section        
  409.         Updated the 'format of a cancel' section (II.C.)
  410. v1.5  -> v1.6   Updated I.C. and II.A. to reflect changes in finding
  411.  Dec 30, 1997     cancel messages
  412.         Removed section on copyright cancels in I.E., to follow
  413.           current consensus
  414.         Added some more readers' cancel buttons
  415.         Changed V.E. to not require me to give a full history of 
  416.           spam cancellers throug the ages
  417.         Clarified and updated the UDP definition in VIII.D.
  418.         Added Section IX. on current cancel issues
  419.         Minor rewordings and updates in I.E., II.B., II.D., IV.B., 
  420.           IV.D., IV.E., IV.G., V.C., VII.B., VII.C.
  421. v1.6  -> v1.7    Standardized the HTML tags to the <URL:[url]> standard in
  422.  Aug 10, 1998     the headers, I.C., II.D., VII.A., VII.D., VII.E., and
  423.           the links section.
  424.         Minor rewordings - IV.B., IV.G.2., IV.G.5., IV.G.7.
  425.         Added mention of server-side filtering in I.B.
  426.         Depreciated the value of RFC1036bis in I.E.
  427.         Updated the rules to include administrator preference -
  428.           for example, you can't cancel your posts in free.* even
  429.           if you want to - in I.E., along with a few other minor
  430.           wording changes.
  431.         Added another reader's cancel button.
  432.         Strengthened the X-Cancelled-By standard to require that 
  433.           the address given must be read by its owner.
  434.         Reworded II.B.'s stuff on pseudosites a bit.
  435.         Changed around III.C. to be more clear on what to do with
  436.           moderators that are "abusing their authority".
  437.         Mentioned how uncustomizable freely available cancelbots 
  438.           are in IV.E.
  439.         Strengthened the importance of responding to email about 
  440.           your cancelbiot in IV.G.4.
  441.         Added "if one may cancel, all may cancel" to the list of 
  442.           popular reasons to cancel in V.B.
  443.         Added "ignore the cancels" and "write and run a resurrection
  444.           'bot" to V.F.'s section on "what can I do?".
  445.         Mentioned that this FAQ is a good example of Supersedes:
  446.           and Expires: headers in VII.B.
  447.         Added IX.[D-F].
  448. v1.7  -> v1.75    Reworded the expiration section of I.B.
  449.  Sep 30, 1999   Reformatted I.E., IV.G., appendix B, and V.D. to just plain 
  450.              look nicer.  
  451.         Changed the wording of I.E.1. to make it more obvious what
  452.           a first-person cancel actually is.
  453.         Updated the spewcancels section of I.E.3.
  454.         Significantly reworded I.H, IV.G.1 - 5
  455.         Added a section on NewsAgent to V.D.
  456.         Added Appendix C.
  457.  
  458. To Do
  459. =====
  460.     At some point, there needs to be a version 2.0 of this FAQ.  While
  461. this will probably happen at some point in the future, it's not going to be
  462. any time soon; as such, most of the real changes for the next while are going
  463. to merely be cosmetic.
  464.  
  465.     Still, for the future:
  466.  
  467.   Fill in the technical sections in general, especially with other 
  468.     software.
  469.   Add a section on things that *shouldn't* be cancelled, and why.
  470.   Expand the UDP and NoCeM sections a *lot*.  Maybe they even deserve 
  471.     their own FAQ...
  472.   Add a "spew" appendix.
  473.  
  474.  
  475. Contributors
  476. ============
  477.     In creating this FAQ, I discovered one important thing: it's a
  478. *lot* of work.  These are the people that have helped me out in doing
  479. it, with suggestions, moral support, or whatever.
  480.  
  481.     Thank you all.  I couldn't have done this without you.  Literally.
  482. And, if I missed anyone, don't hesitate to speak up...
  483.  
  484. Johann Beda            j-beda@uiuc.edu
  485. CancelMoose            moose@cm.org
  486. Ian Collier            imc@comlab.ox.ac.uk
  487. Peter Da Silva            peter@taronga.com
  488. Richard Depew            red@redpoll.mrfs.oh.us
  489. Frans P. de Vries        fpv@xymph.iaf.nl
  490. Ernie Diaz            trebor@slip.net
  491. Arnould Engelfriet        galactus@stack.urc.tue.nl
  492. J.D. Falk            jdfalk@cybernothing.org
  493. Follower of the Clawed Albino    edmcdo01@terra.spd.louisville.edu
  494. The Gentleman            gentlman@alinc.com
  495. Howard Goldstein        hg@n2wx.ampr.org
  496. Dave Hayes            dave@jetcafe.org
  497. Jim Hill            jthill@netcom.com
  498. Jonathan Kamens            jik@mit.edu
  499. Joshua Kramer            jkramer1@swathmore.edu
  500. Don Juneau            djuneau@io.com
  501. Tom Lewis            thomas.lewis@me.gatech.edu
  502. Chris Lewis             clewis@ferret.ocunix.on.ca
  503. Charles H. Lindsey        chl@clw.cs.man.ac.uk
  504. Guy Macon            guymacon@deltanet.com
  505. John Milburn            jem@xpat.com
  506. Bernhard Muenzer        mue@gsf.de
  507. Ron Newman            rnewman@thecia.net
  508. Matthew Paden            mpaden@emory.edu
  509. Joshua Putnam            josh@wolfenet.com
  510. John Rickard            jrr@atml.co.uk
  511. Chris Salter            chris@loncps.demon.co.uk
  512. Wolfgang Schelongowski        [removed by request]
  513. Bill W Smith Jr            bill@srisoft.com
  514. Keith Thompson            kst@thomsoft.com
  515. Jason Untulis            untulis@netcom.com
  516. Dimitri Vulis            dlv@bwalk.dm.com
  517. Matthew P Wiener        weemba@sagi.wistar.upenn.edu
  518. Michael Wise            mjwise@unixg.ubc.ca
  519. Patricia Wrean            wrean@caltech.edu
  520. Dick Yuknavech            rey@mindspring.com
  521.  
  522.  
  523. Pointers
  524. ========
  525.     For more information on cancel messages, or for information on
  526. related issues, try checking some of the following pages:
  527.  
  528. Related FAQs
  529. ------------
  530. news.admin.net-abuse FAQ     
  531.   <URL:http://www.cybernothing.org/faq/net-abuse-faq.html>
  532. Advertising on Usenet FAQ    
  533.   <URL:http://www.danger.com/FAQs/advo.htm>
  534.  
  535.   <URL:http://www.cs.ruu.nl/wais/html/na-dir/net-abuse-faq/spam-faq.html>
  536. The Spam Thresholds FAQ
  537.   <URL:http://www.killfile.org/faqs/spam.html>
  538. The Bincancel FAQ
  539.   <URL:http://www.geniac.net/bincancel/>
  540. The Newsgroup Care Cancel Cookbook 
  541.   <URL:http://www.xs4all.nl/~rosalind/faq-care.html>
  542. The Moderated Newsgroups FAQ
  543.   <URL:http://www.swcp.com/~dmckeon/mod-faq.html>
  544.  
  545.  
  546. Utilities
  547. ---------
  548. Anti-Spam Software
  549.   <URL:http://www.exit109.com/~jeremy/news/antispam.html>
  550. Apollo - News/INN, a set of news related utilities
  551.   <URL:http://www.backplane.com/news/>
  552. Adcomplain shell script        
  553.   <URL:http://www.rdrop.com/~billmc/adcomplain.html>
  554. Purge-binaries, an anti-binary script
  555.   <URL:http://www.tju.edu/~theall1/tools/purge-binaries/>
  556. NoCeM
  557.   <URL:http://www.cm.org/nocem.html>
  558.  
  559.  
  560. RFCs
  561. ----
  562. RFC 1036 -- Usenet Guidelines
  563.   <URL:http://www.cis.ohio-state.edu/htbin/rfc/rfc1036>
  564. RFC 1855 -- Netiquette Guidelines
  565.   <URL:http://www.cis.ohio-state.edu/htbin/rfc/rfc1855>
  566. RFC 1036bis (temporary)    
  567.   <URL:http://www.killfile.org/faqs/rfc1036b>
  568.  
  569.  
  570. Newsgroups
  571. ----------
  572. news.announce.newusers        
  573. news.answers
  574. news.admin.announce
  575. news.admin.nocem
  576. news.admin.net-abuse.bulletins
  577. news.admin.net-abuse.email
  578. news.admin.net-abuse.misc
  579. news.admin.net-abuse.policy
  580. news.admin.net-abuse.sightings
  581. news.admin.net-abuse.usenet
  582. news.admin.misc
  583. news.groups
  584.  
  585.  
  586. Additional/Other
  587. ----------------
  588. Fight Spam on the Internet!
  589.   <URL:http://spam.abuse.net/>
  590. The Jargon File            
  591.   <URL:http://www.ctrl-c.liu.se/~ingvar/jargon/>
  592. net.legends FAQ
  593.   <URL:http://www.killfile.org/faqs/legends.html>
  594. news.admin.net-abuse homepage
  595.   <URL:http://www.killfile.org/~tskirvin/nana/>
  596. The Free.* FAQ
  597.   <URL:http://www.killfile.org/faqs/free.html>
  598. --
  599. Copyright 1999, Tim Skirvin.  All rights reserved.  
  600. <URL:http://www.killfile.org/faqs/cancel.html>
  601.