Cancel Messages: Frequently Asked Questions


Follow this link for a text-only version of the FAQ.
Archive-name: usenet/cancel-faq/part1
Posting-Frequency: monthly
Last-modified: 1999/09/30
Version: 1.8
This document contains information about cancel messages on Usenet, such as who is allowed to use them, how they operate, what to do if your message is cancelled, and the like. It does not contain detailed instructions on how to cancel a third party's posts. It is not intended to be a fully technical document; its audience is the average Usenet user, up to a mid-level administrator.

This document is not meant to be a comprehensive explanation of Usenet protocols, or of Usenet itself, but a basic knowledge of these concepts is assumed. Please refer to news.announce.newusers, RFC1036, and/or RFC1036bis if you wish to learn them.

Disclaimers: The information contained within is potentially hazardous; applying it without the permission of your news administrator may cause the revocation of your account, civil action against you, and even the possibility of criminal lawsuits. The author of this document is in no way liable for misuse of the information contained within, nor is he in any way responsible for damages related to the use or accuracy of the information. Proceed at your own risk.

Table of Contents

I. What are cancel messages?

A. What are cancel messages?
Cancel messages are a specialized form of message to Usenet that, when they arrive at a server, request that the post bearing the Message-ID contained within be deleted. In essence, a cancel message, if heeded, cancels another post. Hence the name.

B. Are cancel messages the only way to delete a message?
No. Usenet is transitory; not every message will be on all news servers at all times. In fact, cancels are fairly rare; the cause of a missing message is very rarely a cancel.

First of all, it takes some period of time for a message to propagate to all news servers that wish to carry the message. This is inherent in the Usenet system; messages take time to arrive. In some cases, they do not arrive at all.

More commonly, messages are deleted after a certain period of time so that more messages can take their place - this process is known as expiration. The amount of time that a post exists varies from server to server, and is usually based on the size and content-type of the article and the newsgroups to which it was posted; servers typically save posts for anywhere from a day to several weeks. As this happens on all news servers and is not consistent, expiration is the number one cause of "missing" messages.

As time goes on, the software itself has begun to change. Messages posted in HTML, messages containing picture attachments, anything posted more than a few times, even messages with more than about five newsgroups in their headers, all of these are subject to automatic filtering by newer news software; ask your news administrators for details about what is done at your site.

Finally, there are more specific causes for missing messages. Your message may have been replaced by another post using a Supersedes: header; your news administrators may be running NoCeM, which selectively deletes posts when used on a server level; etc. Ask your administrators for more information about your system's policies, expirations times, and so forth.

If your post is missing, do not instantly assume that your message was cancelled. A good rule of thumb is "no cancel message, no cancel". If you can find the cancel, then your post was cancelled; if you can't, it probably wasn't.

C. Where can I find cancel messages?
As you must have a cancel message to show that your message was cancelled, it is a good idea to know where to look for them. The best answer, in the short term, is to search control for the cancel (see section II.A. for details). If you are unable to find them there, the Usenet search engines may be able to help - using Dejanews or AltaVista, search for your email address and the string 'cancel', and you may be able to find any cancels issued for your posts.

It should be noted that, for various reasons, the above methods of finding cancel messages are becoming increasingly ineffective. Any suggestions or technical help in solving this problem would be greatly appreciated by the Usenet community.

D. Who is generally allowed to issue cancels?
In general terms, the only people that are always authorized to issue cancels for a message are the original author of the message and the postmaster at the site the message was posted from. However, there are rules that allow third-party cancels in specific circumstances, such as group moderation, spam and spew cancellations, article forgeries, and a few other limited circumstances; those people in charge of these duties are generally authorized to issue cancels directly relating to the job.

E. When and why are cancel messages allowed?
When Usenet was created, cancels were meant to be only issued by the original poster of a message. They were implemented so that someone could take back their words, remove information that was no longer accurate, replace inaccurate information, and other, similar purposes.

As time went on, more uses for cancel messages have been found. Third party cancellations are now generally allowed if they are not content-based; posting private mail is often more than frowned upon, and newsgroup voting fraud may be stopped with a forged cancel; in the more extreme cases, ads to inappropriate groups are cancelled, threads that are crossposted to too many groups go away, and some even cancel in order to just disrupt a newsgroup. This is not to say that this is accepted; on the contrary, cancelling based on a new criterion is usually more than hotly contested.

RFC1036bis, section 7.1, is the most "authoritative" list of valid reasons for cancel messages; however, because it is not a formal RFC and because Usenet changes so quickly, it should not be considered the final word on such matters. The following reasons are probably the most apt to be considered valid by any random news administrator:

  1. First person cancels are performed by the original poster of a message. They are explicitly allowed by the news system - a user is always authorized to cancel anything that he or she posts, for any reason, within the limits imposed by his or her administrators, the moderators or maintainers of those groups affected by the cancels, and the user's individual moral code. This authority extends to messages written on another system.

  2. Second person cancels are performed by those people officially "in charge" of a user, ie the person's news administrator and the newsgroup moderators and hierarchy administrators affected by the user's posts, or any party authorized to act on their behalf by said user or administrator. These cancels, too, are officially authorized.

  3. Third person cancels are generally frowned upon, unless they are made based on one of the following criteria:

F. How are they issued?
Cancel messages are sent out as a standard Usenet post, except they contain a "Control: cancel " header. If a system that accepts cancels receives the message, the post with the specified message ID is deleted from that system.

Most major newsreaders allow readers to cancel their own posts with a key press. Third-party cancels are more complicated, and must follow several conventions; please refer to section II.B for details.

G. How do I cancel my own post?
Most major newsreaders allow you to cancel your message with a few keypresses. To cancel your own post, press the following key (depending on your newsreader) while reading your message:

Newsreader Command to cancel (case-sensitive)
OS/System Reader
Unix rn/trn C
tin D
nn C
gnus-emacs C
slrn Esc-^C
pine none
Unix/X xrn 'Cancel' button
knews Post/Cancel Article
OpenVMS Anu News 'cancel'
newsrdr 'cancel'
PC/Windows Free Agent (pre-v1.1) Article/Cancel
Free Agent Message/Cancel Usenet Message
Agent (v0.99g,v1.5/32.451,v1.5/32.452) Post/Cancel Usenet Message
Agent Message/Cancel Usenet Message
Waffle type CANCEL at the inter-message prompt
News Xpress Article/Cancel Post
Turnpike Article/Cancel Article
WinVN Article/Cancel
Outlook Express Right-click on article/Cancel
News Xpress Article/Cancel Post
Anawave Gravity Article/Cancel
Internet News File/Cancel Message
PC/OS/2 NR/2 Article/Cancel
Macintosh Nuntius Article/Cancel Article
NewsWatcher Special/Cancel MacSOUP Message/Cancel
most browsers Special/Cancel
Web Browsers Netscape Edit/Cancel This Message
Netscape (pre-v2.0) none
Mosaic none
Lynx none
Internet Explorer 4.0 compose/cancel messages
Generic/Multi-System Yarn c

If you know of any other news readers that allow cancels, have corrections for any of the above readers, or whatever, please mail me with the information.

H. Who decided on these rules?
Usenet is a cooperative venture of many thousands of sites world- wide. It was designed with the principle of mass communication in mind; not much thought was put into security, because it didn't seem necessary at the time. As the need to control the system became evident, so too did the potential for abuse; out of these two needs, these rules grew.

As for who actually designed the rules: each site owns its own machines, and can set set policy over its own systems and users. Each site can decide their own expiration policies, what other sites to accept messages from, what control messages they will accept, and so forth; however, it's generally much easier to have a standard set of rules to work with, to improve efficiency and promote some level of consistency across the network. These rules were designed by the system administrators in charge of the systems that Usenet runs on and the users that Usenet serves, in order to give a framework under which to run Usenet as a whole. In short: the rules were made by your administrators and those that they choose to listen to.

And if you have any problems with this, you should see if you can make your administrators listen to you.

II. How do cancels work?

A. What is control? control.cancel? How do I receive them?
control is a pseudo-newsgroup made up of all posts on a news system containing the Control: header, which is used to create or delete newsgroups, perform internal systems checks, cancel posts, and so forth. It is mostly an administrative convenience.

On many systems, control is broken up into several components automatically by the software. If this is true, there are several newsgroups: control.newgroup (for the creation of new groups), control.rmgroup (for the removal thereof), control.cancel (for cancel messages), and so forth. If the software is configured this way, cancel messages will appear in control.cancel.

All cancels are either recorded in control or control.cancel, depending on the system type. If a post was cancelled recently enough, a record of the cancel will be here - if there is no cancel in the group, then either there was no cancel or the cancel message itself has expired (see section I.B.).

Unfortunately, the latter situation has become more and more common as time passes. Most major news servers have begun to expire control messages after extremely short time periods, ranging from a couple of days to a couple of hours; even the major Usenet search engines have begun to cut short their cancel message archives. The rule of "no cancel message, no cancel" still holds, but more burden for finding the cancel message is being placed on the reader.

If you cannot read control (or control.cancel), ask your news administrator for help.

B. What standards are there for cancelling posts?
When cancelling your own post, the only standards are the software requirements. Third-party cancels, however, have certain standards that should be followed.

There are three main reasons for following these standards when using third-party cancels. First is to identify the canceller, which gives the practice accountability. The second is to make sure that a particular message is only cancelled once. Finally, some news administrators would rather not accept certain cancels, and a standard will allow them to opt out of the system.

The first standard is simple to fulfill; all legitimate third- party cancels include an "X-Cancelled-By:" header, containing the email address where the canceller can be contacted. This also implies that the canceller is willing to respond to comments and complaints; if the mail is simply ignored, the canceller is violating this first standard.

The second problem is solved much more creatively. The $alz convention (named after Richard Salz, the creator of INN), specifies that the message ID for a cancel message prepend the message ID of the original message with the string "cancel.". For example:

Original Message ID: <48u6e8$>
Cancel Message ID: <cancel.48u6e8$>

The third problem, that of sites wanting to opt out certain types of cancels, can be solved by adding certain "pseudo-sites" to the path of the cancel; if a particular site wishes to not accept cancels of that type, they can alias out that pseudo-site. For information on how to do this, see section II.E.

The commonly accepted pseudo-sites are as follows:
Pseudosite Purpose
cyberspam!usenet Spam/EMP cancels (universal)
spewcancel!cyberspam!usenet Spew cancels
mmfcancel!cyberspam!usenet Make.Money.Fast cancels
bincancel!cyberspam!usenet Binary (in a non-Binary group) cancels
adcancel!cyberspam!usenet Ad cancels (for the biz.* hierachy only)
retromod!cyberspam!usenet Retromoderation cancels
The !usenet part denotes that something must come after that part of the path; it is not necessary for it to be usenet. Multiple pseudo-sites may be used in one message.

For more information on cancel formatting, please refer to the Newsgroup Care Cancel Cookbook by Rosalind Hengeveld.

C. What is the format of a cancel message?
Here's an example, a spam cancel by Chris Lewis, that follows all of the standard conventions (plus a few extras), reformatted to fit into 80 columns):

Date: 8 Jun 1997 15:43:37 GMT
From: (Chris Lewis)
Message-ID: <cancel.5ne625$f2b$>
Newsgroups: alt.recovery.aa
Subject: cmsg cancel <5ne625$f2b$>
Control: cancel <5ne625$f2b$>
X-No-Archive: Yes
Lines: 7

WOODSIDE spam cancelled by
Original Subject: Sell YourPhotosNYC.Agency
Total spams this type to date: 1888
Total this spam type for this user: 1041
Total this spam type for this user today: 503
Originating site:
Complaint addresses:
Points to note: the 'Sender' line matches the original author of the message, while the 'From' line points at the canceller, as does the 'X-Cancelled-By' header. The Message-ID follows the $alz convention, and the proper pseudo-site is present in the 'Path' header. It should also be noted that the 'X-Spam-Type' and 'X-No-Archive' headers are optional, as is all information in the body of the cancel.

D. Do all news sites accept cancels?
No. Many news sites have decided that, for whatever reason, they do not want cancels; others merely do not want certain types of cancels. Dave Hayes, for example, runs a "Site of Virtue", which not only ignores cancels but drops them without distributing them; patches for INN to do this are available from his Freedom Knights Homepage. America Online, Dejanews, Zippo, and many other news sites to not honor cancels of any sort.

E. How do I alias out a pseudosite?
INN v1.5 and beyond include shunning mechanisms out of the box; just edit the newsfeeds file and follow the instructions from the comments. Other, older news server software is less likely to include such mechanisms.

If anyone's got information for other systems, I'd love to include it.

III. So your post was cancelled...

A. Why was my post cancelled?
It probably wasn't.

Unless you can find a copy of the cancel in control, it is very, very unlikely that your post was actually cancelled. Before you begin to worry about a forged cancel, figure out the expiration times for articles on your system and note whether or not your newsreader just refuses to show you articles marked as 'read'; these are the most common causes for "missing" articles.

B. I have the cancel message right in front of me. Why was it cancelled?
Most cancels nowadays are for cleanup of various forms of net-abuse. If you posted your message to too many places, or too many times, it will generally be cancelled, regardless of the content of the post.

For details about what is cancelled and why, read news.admin. net-abuse.usenet, or check the FAQ. Also, if you received a mail on the subject from a spam cancellers, read it carefully; it should probably explain why your message was cancelled.

C. But I wasn't doing anything wrong! Why was it cancelled?
There's still legitimate reasons beyond official net-abuse to cancel posts.

D. Look, pal, I said I wasn't doing anything wrong, and I meant it. I didn't break any rules that I can see. Why was my post cancelled?
I don't know.

E. sigh Then what do I do about it?
Post about it to Make sure to include the full headers and text of the cancel, an explanation of what the article was about, and any possible motives for the cancelling that you can think of. The administrators there will, if you're polite, try to help.

For more information, read section V.

IV. What does it take to cancel messages?

A. I want to cancel posts! How do I do it?
You must be kidding.

B. I'm not kidding; I really do want to do it. How do I do it?
sigh Well, I'll bet you really haven't thought about it very much yet. Read this section before you do anything, alright?


On a small scale, you can issue them by hand - see the Newsgroup Care Cancel Cookbook for the details and warnings you'll need to get started. On a bigger scale, you're going to want a cancelbot.

C. What is a cancelbot?
A cancelbot is a program that searches for messages matching a certain pattern and sends out cancels for them; it's basically an automated cancel program, run by a human operator.

D. Sounds cool. Where do I get one?
If you have to ask, you're probably going to have a hard time getting one, and even if you do you probably won't be impressed with the quality. I wouldn't even consider using a cancelbot unless you've written it yourself or know exactly what it's doing (in which case you might as well have written it yourself anyway).

E. What? Why not?
Giving out a cancelbot is like handing out loaded guns with no safeties. Even if the recipient is well-intentioned, screw-ups are fatal; you need the proper training first. There may be people out there that will still give you that gun without the training, of course, but it's a good idea to question their motives...

In general, until you know exactly how to use a cancelbot, you shouldn't be experimenting with one - and most people that write the 'bots know this. Cancelbots are dangerous, and can be used irresonsibly; more than that, if you screw up with a cancel-bot you can cause large problems, and it's fairly easy to screw up. For these and other reasons, it's generally accepted that only those that are willing and able to write their own cancelbot will ever actually get one.

Sidenote: even if you trust the source of the code, it's not a good idea to trust it blindly. What security holes might it have? What bugs may be in it? Is it optimized for hte ways that you're planning on using it? It's a lot safer to write your own code than to rely upon others; not only is it easier to modify for yourself, at least then you have an idea what's still wrong with it...

F. Fine then, I'll write it myself.
Sure, go right ahead, but a word of wisdom: make sure you know what you're doing.

Richard Depew, Usenet's current major bincanceller, was one of the first people to use cancelbots in a large way. One of the most famous bot-related incidents of all time was his ARMM cascade, in which a simple spelling error on his part caused a large spew in news.admin.policy for several hours before it was turned off. It was generally considered a Big Oops.

Richard's incident was also far from the worst; that honor would have to go to the incident where a misconfigured cancelbot was auto- cancelling everything from Bigger Oops. And these examples just scratch the surface of what can go wrong when writing a cancelbot...

Before you test out your cancelbot on actual Usenet stuff, double and triple check to make sure it works. Make sure that you've gone through all the potential bugs and vulnerabilities -- add safeties, redundancies, internal logic checks, and what have you. Start a local group, test the 'bot out in that group only. Whatever. Just remember, you only get one chance at this, so do it right...

While writing a cancelbot, make sure you follow the conventions that you plan on using ($alz, etc). In addition, once you've got the basics down, mail Chris Lewis. He'll give you some more tips.

G. Right; I've got a cancelbot. Now what?
Well, the obvious thing is to start using it. Don't. Before you do anything dumb, make sure you've considered everything; cancels raise plenty of interesting questions, and using a cancelbot isn't something to enter into lightly.

Before you do anything, make sure you've thought a lot about all of the following issues. Trust me, you'll need it.

  1. Who is going to be affected by this, and how will they react?
    Cancelbots tend to affect a lot of people. By running one, you are messing with a lot of people -- and, generally, making them upset. Many are going to complain. Some are going to retaliate.

    Succinctly, before you start up your cancelbot, make sure you can handle any incoming mailbombs, that your network's security is strong enough to stand up to persistent cracking attempts, that you're on good enough terms with your bosses and administrators that they won't fire you or drop your account the second they get any complaints about you, that you've gotten your phone number made unlisted, and that you've got a good lawyer handy.

    That's a start, at least.

  2. What kinds of problems will this cause legally?
    In the USA, at least, the current best information/guess about the legality of cancel messages says that non-content-based third party cancels are legal, and that content-based ones are illegal. However, this has just plain not been tested in anything resembling a court of law, and wouldn't apply to other countries even if it had been tested.

    Even if cancels are legal in your place of work, of course, this doesn't mean that you won't face legal harassment. It's almost trivially easy to find some reason to sue somebody today; if you hork somebody off by cancelling their posts, there is a chance that they'll try this on you. Remember, to many it often doesn't matter if they're going to win or lose the lawsuit; all that is important is that they have forced you to spend money and time to respond to the charges.

    Regardless - there is definitely some legal risk associated with third-party cancels. This risk is probably enough that you should talk with your higher-ups first, or, if possible, a lawyer. It could save you a lot of trouble down the line.

  3. Is this a moral thing to do?
    Even if cancel messages were perfectly legal, they still aren't the nicest thing in the the world. By issuing a cancel you are deleting somebody else's words; many would call this censorship, and, even if their use is justified, they may be right.

    The most commonly used moral argument about cancels is known as the "slippery slope". The use of cancel messages leads down the road to censorship, which is a Bad Thing; however, it may be possible to keep the system under control by staying near the top. The further cancels go, however, the more likely it is that they cannot be controlled - and once that happens, any benefit they may have once held will be gone.

    Common practice says that non-content-based cancels are not censorship. Instead, they are based on how "loud" the message was said; it's not censorship to stop someone from blaring their message out in the middle of the night using a megaphone. This hopefully means spam cancels and their like are not yet out of control, and that we haven't gone so far down that we can't return; then again, this point is certainly up to debate.

  4. Do I really have the time to deal with this?
    Operating a cancelbot takes a lot of time. Just on a technical level, the 'bot has to be written, the parameters have to be set and constantly updated, and the thing watched to make sure it works; that, though, is the least of your worries.

    Once you get the 'bot running, people are going to take notice. Result: you will get comments, you might get praise, and you will probably get complaints. You *must* listen to them if you want to continue running your 'bot responsibly. No, you don't have to respond to everything, especially the more juvenile flames, but you do have to make sure you listen to suggestions and problems; after all, if your 'bot is cancelling something it shouldn't be cancelling, you'll only find out when somebody tells you.

    If you don't have time to deal with these comments and complaints, then just give up now. Trust me, you'll be better off.

  5. Do I know for sure what this program will be used for?
    If people don't accept the purpose of your cancelbot, then your cancelbot will not be effective for anything except getting a whole lot of flames and your account nuked. As such, before you start cancelling you should make sure you won't get rejected from the job. Make yourself some rules:

    (Recap: the standard uses for third-party cancels are spams, spews, moderated group cleanup, binaries in non-binary groups, and forgeries. See section I.D for details.)

  6. Have I double- and triple-checked my code?
    Again, screwing up your code can cause big problems. Before you're ready to go operational, make absolutely sure that you know that the code works 100% of the time. I'd personally recommend asking yourself "could I operate this while drunk?" There are no second tries here; don't give yourself a chance to screw it up.

    This is, of course, especially important if your code is ever going to be viewed by another human being...

  7. Do I know what's happened in the past?
    The history of Usenet and cancels goes back a long, long way; it's not only fairly interesting stuff, but it teaches interesting lessons. Before you start the cancelbots, you should probably know what they were used for before; with knowledge comes power, after all, and this way you won't start repeating the mistakes of your predecessors.

  8. Am I following all of the rules?
    While they may not be conventions, there are certain basic rules that are usually followed by operators of cancelbots that should probably be followed. A notice of the cancels should be posted to; the original poster and their postmaster should be notified; a representative copy, or link to such, should be appended to the notice of cancellation. You should have a reliable contact address, so as to be fully accountable for your actions. And, as usual, all of the official conventions should be followed exactly.

    If you're not doing them "nicely", you're going to get more complaints than otherwise - and rightfully so. And if you aren't capable of doing them nicely, then you probably shouldn't be issuing cancels at all.

    Remember, it has been proven time and again that nice, polite cancel notifications make less enemies than angry, flamish ones. It's probably a good idea to make your notifications as kind as possible - though they should always include as much information (or links to information) as you can possibly fit in.

  9. Do I actually have to do this?
    If you hadn't figured it out already, cancelbots are a pain in the butt. If for no other reason, because of this you should probably reconsider whether this is really necessary.

    If your problem has to do with too much off-topic or irrelevant traffic, maybe cancels aren't the solution. Talk about moderation with the regulars of the newsgroup you're worrying about; someone might be willing to help moderate the group, or maybe they have another idea to solve the problem. Maybe mailing the offenders a polite message saying "your message is off-topic" would help, or perhaps it will take mailing the posters' administrators before they'll stop; either way might be more effective than cancels.

    Even if reasoning with everyone you can think of doesn't work, you can still try other approaches. Post about it to usenet; the regulars there have trained themselves to deal with obnoxious sites, and will help you if necessary. In many cases, you can stop the problem with judicious use of killfiles. And, if all else fails, you can always try NoCeM.

    In general, just make sure you've tried every alternative before you start cancelling anything. It's a pain to start, it's a bigger pain to continue, and the biggest pain comes when you finally want to stop...

V. That idiot forge-cancelled my posts!

A. My post is gone; it was forge-cancelled, wasn't it?
Before you do anything, check section III; double-check to make sure that someone really did cancel your post before you get all upset. Remember, no cancel message, no cancel.

B. No, I'm sure, it was cancelled. Why?
There are as many reasons to cancel a post as there are cancel messages. Most cancels are issued for valid reasons (which are detailed in previous sections), but sometimes they are done for what many people would consider illegitimate reasons. The people that issue such cancels are known as "rogue cancellers"; these are the ones to worry about.

Why do they do it? It depends. One popular excuse, started by the infamous Church of Scientology, is that the message was a "Trade Secret" which must be protected. Another excuse has become prevalent in recent years is "if one may cancel, all may cancel" - the theory being that cancel messages themselves are evil and must be stopped, and the way to do this is to abuse the hell out of them so that sites will turn them off. Oddly, both of these excuses generally lead to cancels aimed at those the cancellers have declared "enemy", and usually end up backfiring.

All of those reasons, though, are pretty much just excuses. What are the real reasons that somebody would do something like this? Simple: they want to keep something out from under public scrutiny, they didn't like what you said, or they just want to destroy a few messages.

And yes, those are very bad reasons.

In any case, rogue cancellers such as the above are *not* accepted by the Usenet community. End of story. The hunts to track down rogue cancellers often reach near-epic proportions, the searchers often spanning the globe, and virtually all such quests end with, at the very least, the cancels ending.

C. How do I track the bastard down?
If you have the cancel message, the best first step to tracking down the canceller is to post a (single) copy of the message to with a brief explanation of what's going on. The people on that group are veterans at tracing Usenet messages; they can probably help. While they're at it, they may also explain why your message may have been cancelled legitimately, in case there's anything you missed.

For rudimentary analysis of who cancelled your post, check the NNTP-Posting-Host: header of the cancel. While it is possible to forge this header, it generally will say which machine was used to issue the cancel message. Other, less-forgable headers include the Path: and Sender: headers, and occasionally the Message-ID: header.

D. Who's done this before?
In the past, there have been many rogue cancellers of various skill, competence, and intelligence. Some are gone; others are still on the run, but appear occasionally. Here are a few of the most famous.

E. What, are there only bad guys?
No, of course not; they're just the most prominent. There are plenty of important good guys, too -- the ones that perform the thankless job of cancelling spam, spew, MMF, and all the rest, basically keeping Usenet usable.

Among the most famous spam cancellers include the CancelMoose [the first major spam canceller, author of NoCeM, now retired from cancelling], Chris Lewis [the most prominent spam canceller of all time], and Jonathan Kamens [writer of the best spam detection software to date]. Most of the other cancellers can be find on*.

F. Is there anything I can do on my own?
Of course.

  1. Notify the postmaster at the offending site, or upstream site.
    If you can determine where the cancels are coming form, mail the postmaster at that site (or abuse@site, if present) with your complaints. If this doesn't work, you may want to try notifying the people that give the site its newsfeed; for details on how to determine this, read the Spam Tracking FAQ.

  2. Alias out the offending site.
    Your news administrator may be capable of making your machine not accept posts from a certain other machine. If necessary, this can be used to ignore the cancel messages on your own site.

  3. Ignore the cancels
    Most major cancel attacks are fairly easy to categorize, based on a common header or message body. It is possible to run software, such as Cleanfeed, to ignore those cancels based on the common pattern; if you've got the time to update your filters fairly often, you may even be able to head off further attacks.

  4. Write and run a Resurrection 'bot.
    It is possible to run a 'bot that reposts everything that is cancelled; the most famous example of this is Dave the Resurrector, which protects the news.admin.* hierarchy and is detailed in Appendix A. If you want to do something similar, you can be a great help at stopping rogue cancel attacks.

  5. Call in the official authorities.
    As was previously said, forged cancels are in a legal grey area. If you want to call in the legal authorities, you probably can, and something may be done.

    The general recommendation of this, though, is "don't do it". Any kind of legal judgment on this matter sets a precedent; at this point, we're almost happier without one.

VI. What moral issues are involved with cancel messages?

I'll answer this question succinctly:


The moral issues related to cancel messages are among the most interesting, and distressing, part of the issue. Third-party cancels, spam and binary cancels, retromoderation, moderators in general, the full "slippery slope" argument, the "Usenet is an anarchy" argument, "you're violating my first amendment rights!" and "without cancels, Usenet would have died under the weight of the spam long ago"...

This FAQ, though, isn't really the best place to get into it.

For lack of space and time, I cannot get into these issues in detail here, however important they may be. If you want a start on this matter, read the FAQ, along with the newsgroups. It's at least a start.

VII. What's going to happen to cancels in the future?

A. What are authenticated cancels?
Usenet was not built with security in mind; the fact that it's relatively simple to forge a cancel proves this.

As time goes on, though, the need for security is becoming more and more obvious. One way of making this security would be to change the software to only accept cancels that include verification of a match between the poster and the canceller; such verification might take the form of a PGP-signature or some other similar method.

There have been many methods proposed to accomplish this; at this point, none are in wide use. If anyone would like to write some software to accomplish this, please do so, and discuss it on news.admin.misc; the CancelMoose has a few suggestions for authenticated cancels on his web page.

B. Are there any other Usenet methods to delete messages?
Of course.

  1. How does the Supersedes: header work?
    Commonly used for periodic postings and other information updates, the Supersedes: header replaces an old message with a new one. t is especially useful for FAQ maintainers, who use it to replace old versions of the FAQ with more up-to-date ones - this FAQ, for example, uses it. To replace the message <4b6uce;$>, you would want to add the header:

    Supersedes: <4b6uce$>

    The use of Supersedes: is otherwise basically the same as a cancel message, and third-party superseding should be treated the same as third-party cancels.

  2. How does the Expires: header work?
    By adding the Expires: header to your post, you can override the standard expiration time on most systems and make your message be deleted from most systems at a time of your choosing. This is especially useful for time-dated information and FAQs which are meant to be reposted on a regular basis. If you want your message to expire at 7:50:06pm (PST) on 2/11/96, add the following header:

    Expires: Sun, 11 Feb 1996 19:50:06 PST

    Your message should expire by this date. It may also expire earlier, depending on the system setup and expiry times.

  3. What is the Also-Control: header?
    The Also-Control: header acts just like a standard Control: header, except that the post is also filed in whatever groups it was posted to, as opposed to being filed in control. Otherwise, the two are interchangeable.

C. Why are some people turning off cancels altogether?
Until authenticated cancels catch on, there are no options to avoid forged cancels and allow unforged ones. One option, advocated by a few, vocal people that don't want to allow such forgery, is to not accept cancels at all. If you want to do so, you're welcome to, but it probably isn't the best option, at least in the near future.

D. What is NoCeM?
NoCeM, pronounced "No See-Umm", is a piece of news software written to mostly replace cancel messages. Instead of deleting the messages automatically, NoCeM works by allowing anyone to send out a message that basically states "you don't want to read this". Indiviual news systems or users may then act on these messages as they see fit, from deleting the messages or marking them as read, to merely ignoring the advice altogether, to even marking those messages to be read as soon as possible. The idea is being hailed as a worthy replacement for third-party cancels by many news administrators, and it is slowly gaining support.

CancelMoose authored the client software, which is currently available for most Unix clients that can use PGP. news.lists.nocem has been created for the distribution of NoCeM messages; discussion of the protocol belongs in For more information on NoCeM, refer to the Moose's homepage.

E. What is PGP?
PGP stands for "Pretty Good Privacy", and is a greatly heralded encryption program made for everyday use. It is at the heart of most authenticated cancel schemes, NoCeM, and much other Usenet software. Unfortunately, the import and export laws regarding the software vary, making its availibility questionable in countries other than the USA.

PGP is a topic on its own, and as such has several FAQs of its own, as well as several newsgroups. For more information, I recommend you read one of these FAQs, such as the FAQ.

VIII. What about these other things?

A. What is Lazarus?
Lazarus is a program written for use on alt.religion.scientology by Homer Wilson Smith. It monitors control and posts a message to a.r.s whenever it finds a message relating to the group. The basic effect of this is that all cancels are very visible.

For more information on why this was necessary, refer to Ron Newman's page on the Church of Scientology vs the Net.

B. What is Dave the Resurrector?
Dave the Resurrector is a program run in news.admin.* and several other newsgroups that reposts cancelled articles. See Appendix A for details on its creation and operation.

C. What was the Judges-L mailing list?
A while back, a guy named David Stodolsky decided that he was going to be in charge of cancels on Usenet. He set up a mailing list to this effect, Judges-L, and expected to start working.

The rest of the world didn't exactly want him to be Emperor of Usenet.

After a short flamewar, an early FAQ on Cancel Messages was written as a result of the Judges-L list; while technically accurate, it had little influence on the creation of this FAQ. In the mean time, the Judges-L list was dissolved; David Stodolsky is rarely seen on Usenet anymore.

D. What is the UDP?
UDP stands for the "Usenet Death Penalty", the final weapon against those that attempt to abuse Usenet. It is never entered into lightly.

Originally, the UDP referred to auto-cancellation of all messages from a certain site as a final solution to too much abuse. As Usenet terms tend to change over time, the meaning mutated into meaning to refer to the aliasing out of a certain site by many major sites, thus "shunning" them off of Usenet. This latter method is now more commonly called a "passive UDP", and is widely accepted as being only the decision of the sites involved; the former has been renamed to "active UDP", and is much more controversial.

Active UDPs are saved for those sites that absolutely refuse to stop abuse from their systems. Sites which allow abuse of their system for weeks straight are given warnings, culminating in a public discussion of whether a UDP is warranted. If a consensus is reached that it is necessary, the offending site is given a week to fix the problem - after that, all articles from the site are automatically cancelled until the abuse stops. All in all, this tactic is more politically than technically effective, but that doesn't stop the mere threat of an active UDP from being enough to make most ISPs clean up their act.

The ethics and morals of active UDPs are, of course, still in debate.

IX. What are the current cancel issues?

A. What are the cancel-on-sight rules?
If a message is guaranteed to be spam beyond the cancel thresholds, anybody may issue a cancel for it - the problem comes with confirming that the post is, indeed, beyond the cancel thresholds. Usually, this is done automatically with scanning software by the major spam cancellers; they are not perfect, however, and sometimes the software misses a few messages. Individuals, however, must check the thresholds by hand - which takes a great deal of time and effort.

To solve this problem, a certain class of spam has been declared - cancel-on-sight. If a particular spam has stayed above a certain threshold daily, and shows no signs of stopping in the immediate future, the spam is declared cancel-on-sight - from then on, any instances of the spam may be cancelled on sight, without requiring checking by the canceller, on the theory that the spam must have passed the thresholds long ago.

Currently, the only spam declared cancel-on-sight is the ongoing "Make Money Fast!" spam/scam in all its forms. Details for declaring other spams cancel-on-sight are still being worked out in news.admin. net-abuse.policy.

B. Are HTML postings cancellable?
Most modern web browsers allow for posting to Usenet; they also generally offer an option to post messages in HTML, for easier viewing by other browsers - at the expense of significantly larger post sizes and much-increased difficulty of viewing by the rest of the Usenet community. This poor mixing of HTML and Usenet has been fought tooth-and-nail by Usenet readers, moderators, and administrators, but the postings continue.

One suggestion to stop HTML posting is to declare HTML posts to be binary messages, and thus cancellable under the bincancel rules. This idea has not been implemented, simply because HTML messages are not binary messages, under current definitions, and if the definitions were changed the consensus would probably disappear.

In short: no, postings are not cancellable merely for being in HTML.

C. What happened to copyright cancels?
Copyright cancels were a rarely-used type of third-party cancel where messages are cancelled for being copyright violations. The idea behind the cancels was to stop the violations from spreading; cancels are fairly ineffective in this respect, however, because not all sites honor cancels. This ineffectiveness, combined with a desire by most news administrators to stay out of legal matters, was enough to declare the consensus regarding copyright cancels void. The only remedy for copyright violations on Usenet has again become the real-world legal system.

D. What should be done about unaccountable spam cancellers??
The current winner of the "most cancels issued" award is Cosmo Roadkill, a 'bot operated by "Uncle Roadkill" that single-handedly cancels most of Usenet's spam. This was, for a time, considered a good thing; still, the 'bot isn't perfect, and over time people have found more and more problems with Cosmo. This too would be okay, except for one thing - Uncle Roadkill never responds to complaints.

There still isn't really a true response to this issue, but at least people are outraged.

E. What should be done about open news servers?
Most rogue cancel attacks on Usenet are performed using news servers that allow public reading and posting. This was originally done to allow an "open" Usenet, where people could read and post from other servers to help guarantee better propagation and a nice atmosphere; now, though, the potential for abuse is too great, and so most open news servers are being shut down. This is generally considered a good thing.

There are, though, a few that will miss the old open system; as such, there are still ideas floating around for how to allow those servers to remain open and still not allow any significant abuse.

F. How should hierarchies out of spam cancels?
On July 18, 1998, the free.* hierarchy was recreated under the theory of "no control, no cancels, no rmgroups". One of the unexpected shocks caused by this creation was from the spam cancellers - they didn't necessarily want to exclude free.* from their filters, and were outraged that somebody would tell them what to do on the matter without even discussing it ahead of time. Others responded that it was the cancellers' responsibility to follow the wishes of the hierarchy, and that if they wouldn't do so how were they better than the rogue cancellers?

While this particular flamewar finally burned out, the underlying embers of the issue are still burning - how should hierarchies opt out from spam cancels? Is it the responsibility of the cancellers to ask permission to cancel the posts? Or must hierarchies request such things, and work with the cancellers to ensure that it works?


To Do

At some point, there needs to be a version 2.0 of this FAQ. While this will probably happen at some point in the future, it's not going to be any time soon; as such, most of the real changes for the next while are going to merely be cosmetic.

Still, for the future:


In creating this FAQ, I discovered one important thing: it's a lot of work. These are the people that have helped me out in doing it, with suggestions, moral support, or whatever.

Thank you all. I couldn't have done this without you. Literally. And, if I missed anyone, don't hesitate to speak up...

Johann Beda, CancelMoose, Ian Collier, Peter Da Silva, Richard Depew, Frans P. de Vries, Ernie Diaz, Arnould Engelfriet, J.D. Falk, Follower of the Clawed Albino, The Gentleman, Howard Goldstein, Dave Hayes, Jim Hill, Jonathan Kamens, Joshua Kramer, Don Juneau, Charles H. Lindsey, Tom Lewis, Chris Lewis, Guy Macon, John Milburn, Bernhard Muenzer, Ron Newman, Matthew Paden, Joshua Putnam, Chris Salter, Wolfgang Schelongowski, Bill W Smith Jr, Keith Thompson, Jason Untulis, Dimitri Vulis, Matthew P Wiener, Michael Wise, Patricia Wrean, Dick Yuknavech.


For more information on cancel messages, or for information on related issues, try checking some of the following pages:

Appendix A: Dave the Resurrector

1. What is Dave the Resurrector?
Dave the Resurrector is a program written and run by Chris Lewis that reports on and reposts messages cancelled in the* hierarchy. Dave's code was written after a particularly obnoxious run of cancels in sent by Kevin Lipsitz (since charged with fraud and other offenses); the name was suggested by Tim Skirvin, and Chris accepted the name in honor of Dave Hayes, of news.admin.* fame.

Dave's reposting activities are occasionally extended to include the rest of news.* and other hierarchies, to resurrect messages removed by large-scale rogue cancellers. From time to time Dave's presence has also been requested in other newsgroups.

2. Why is Dave necessary?
The news.admin.* hierarchy has always been the target of massive forged cancel attacks, (see section V.D. for details). Dave neutralizes these attacks, though at the cost of allowing people to cancel their own posts effectively. Most agree that the price is worthwhile.

3. What cancels are 'authorized'?
In the context of Dave, an "unauthorized cancel" is a cancel by someone other than the originator, the originator's system administration, the moderator of the group, or an accepted spam canceller. Of necessity, given the ease in which cancels can be forged, Dave cannot determine the authenticity of cancels per-se, so will resurrect all cancelled articles except those which:

Dave's operator routinely scans Dave's normal haunts, and will manually recancel articles that appear to have been resurrected in error. Other spam cancellers who've been introduced to Dave can do this as well.

When Dave is armed to cope with a rogue canceller cancelling in other groups, a best-effort attempt will be made to avoid reposting spam and other postings that are undesirable to resurrect.

4. What messages are reposted?
According to the* charters, "All messages removed by unauthorized cancels in the hierarchy will be automaticly reposted by Dave the Resurrector or a similar program, at the discretion of the group moderator or, for the unmoderated groups, the operator of the resurrector program."

Every cancel message in the news.admin.* hierarchy prompts Dave to create a repost of the original message; however, not every repost is injected into the news system. Before Dave submits an article to be reposted, the bot runs a few extra checks:

If the circumstances warrant it, some or all of these heuristics may be turned off - for instance, the maximum reposts per run section may be taken out to stop a massive forged-cancel bomb. Also, all articles not submitted by Dave are still subject to later perusal (and possible posting) by Dave's operator, as he sees fit.

5. What is the format of the reposts?

In the past, Dave modified the body and headers of the message to allow for easy notice of rogue cancels. It was eventually pointed out, however, that this policy broke PGP signatures (VII.E.) and the pseudo- headers used by FAQ maintainers; to solve this, Dave's policy has been changed to 'least-disturbance'. As such, reposts of cancelled messages are as similar to the original message as possible:

6. So how do I cancel my own posts when Dave is around?

If it were possible, Dave would let you cancel any article that you wrote without a repost; however, due to the practical problem of cancels being trivially easy to forge, this can't happen without removing Dave's use. As such, Dave errs on the side of caution, and reposts most articles it sees cancels for. However, there are ways around Dave, if you really want to cancel your posts.

  • The presence of an 'X-No-Archive: yes' header will prevent Dave from reposting your article (excepting attacks by targeted rogue cancellers); see your newsreader's manual for instructions on how to automatically add this header to your messages.

  • If you cancel or supersede your article soon enough after the original posting, you _may_ be able to remove the message before a copy is saved by Dave. Of course, it should be noted that cancel messare are rarely going to be fast enough to keep anybody from reading the message anyway.

    Mail to Dave's operator is not encouraged when a cancel is required; even in the case of forgeries in your name, a post to the proper news.admin.* group indicating that the messages are forged will do more good.

    7. What about other Resurrector bots?

    As previously noted, DtR can be extended to other newsgroups and hierarchies by request. Astute observes might note that the* charters allow for other Resurrector bots if the situation warrants it. This was done on purpose, to allow for a replacement for Dave if necessary. At this time, however, no other Resurrector bots seem to be necessary.

    Appendix B: Retromoderation

    1. What is retromoderation?
    Technically, retromoderation is moderation that takes place after the messages are posted. All posts are initially distributed normally, either through standard Usenet channels or through a simple mail-to-news gateway; the moderator later checks the group, and deletes those messages that were inappropriate.

    2. Why is retromoderation so popular?
    In a normally moderated newsgroup, the combination of a simple moderator-bot and retromoderation allows for focused and on-topic discussions and keeps the group (mostly) spam-free, all while not requiring large workloads for a moderator and allowing message distribution to be kept high. In an otherwise unmoderated newsgroup, retromoderation allows for some level of topic and spam control, while not forcing the centralization required by standard moderation and not requiring a formal moderation process.

    In short, retromoderation is a quick and easy way of accomplishing most of the benefits of standard moderation, and people appreciate this.

    3. What's wrong with retromoderation?
    Though it may be tempting, retromoderation should never be entered into lightly. It is plagued with problems, affecting everything from its effectiveness to the long-term future of Usenet.

    4. When is retromoderation alright?
    Even though retromoderation has its problems, it is still widely accepted and used in several circumstances.

    Copyright 1999, Tim Skirvin. All rights reserved.
    [Last Updated: September 30, 1999]