s-o-1036 June 1994
[< Prev]
[TOC] [ Next >]
7.1. cancel
The cancel message requests that one or more previous arti-
cles be "cancelled":
cancel-arguments = message-id *( space message-id )
cancel-body = body
The argument(s) identify the articles to be cancelled, by
message ID. The body is a comment, which software MUST
ignore, and SHOULD contain an indication of why the cancel-
lation was requested. The cancel message SHOULD be posted
to the same newsgroup(s), with the same distribution(s), as
the article(s) it is attempting to cancel.
NOTE: Using the same newsgroups and distributions
maximizes the chances of the cancel message propa-
gating everywhere the target articles went.
NOTE: RFC 1036 permitted only a single message-id
in a cancel message. Support for cancelling mul-
tiple articles is highly desirable, especially for
use with Supersedes (see section 6.14). If sev-
eral revisions of an article appear in fast suc-
cession, each using Supersedes to cancel the pre-
vious one, it is possible for a middle revision to
INTERNET DRAFT to be NEWS sec. 7.1
be destroyed by cancellation before it is propa-
gated onward to cancel its predecessor. Allowing
each article to cancel several predecessors
greatly alleviates this problem. (Posting agents
preparing a cancel of an article which itself can-
cels other articles might wish to add those arti-
cles to the cancel-arguments.) However, posters
should be aware that much old software does not
implement multiple cancellation properly, and
should avoid using it when reliable cancellation
is vitally important.
When an article (the "target article") is to be cancelled,
there are four cases of interest: the article hasn't arrived
yet, it has arrived and been filed and is available for
reading, it has expired and been archived on some less-
accessible storage medium, or it has expired and been
deleted. The next few paragraphs discuss each case in turn
(in reverse order, which is convenient for the explanation).
EXPIRED AND DELETED. Take no action.
EXPIRED AND ARCHIVED. If the article is readily accessible
and can be deleted or made unreadable easily, treat as under
AVAILABLE below. Otherwise treat as under EXPIRED AND
DELETED.
NOTE: While it is desirable for archived articles
to be cancellable, this can easily involve rewrit-
ing an entire archive volume just to get rid of
one article, perhaps with manual actions required
to arrange it. It is difficult to envision a sit-
uation so dire as to require such measures from
hundreds or thousands of administrators, or for
that matter one in which widespread compliance
with such a request is likely.
AVAILABLE. Compare the mailing addresses from the From
lines of the cancel message and the target article, bearing
in mind that local parts (except for "postmaster") are case-
sensitive and domains are case-insensitive. If they do not
match, either refer the issue to an administrator for a
case-by-case decision, or treat as if they matched.
NOTE: It is generally trivial to forge articles,
so nothing short of cryptographic authentication
is really adequate to ensure that a cancel came
from the original article's author. Moreover, it
is highly desirable to permit authorities other
than the author to cancel articles, to allow for
cases in which the author is unavailable, uncoop-
erative, or malicious, and in which damage and/or
legal problems may be minimized by prompt cancel-
lation. Reliable authentication that would permit
INTERNET DRAFT to be NEWS sec. 7.1
such administrative cancels would be a worthwhile
extension to this Draft, and experimental work in
this area is encouraged.
NOTE: Meanwhile, a simple check of addresses is
useful accident prevention and catches at least
the most simple-minded forgers. Since the intent
is accident prevention rather than ironclad secu-
rity, use of the From address is appropriate, all
the more so because in the presence of gateways
(especially redundant multiple gateways), the
author may not have full control over Sender head-
ers.
NOTE: The "refer... or treat as if they matched"
rule is intended to specifically forbid quietly
ignoring cancels with mismatched addresses.
If the addresses match, then if technically possible, the
relayer MUST delete the target article completely and imme-
diately. Failing that, it MUST make the target article
unreadable (preferably to everyone, minimally to everyone
but the administrator) and either arrange for it to be
deleted as soon as possible or notify an administrator at
once.
NOTE: To allow for events such as criminal
actions, malicious forgeries, and copyright
infringements, where damage and/or legal problems
may be minimized by prompt cancellation, complete
removal is strongly preferred over merely making
the target article unreadable. The potential for
malice is outweighed by the importance of really
getting rid of the target article in some legiti-
mate cases. (In cases of inadvertent copyright
violation in particular, the ability to quickly
remedy the violation is of considerable legal
importance.) Failing that, making it unreadable
is better than nothing.
NOTE: Merely annotating the article so that read-
ers see an indication that the author wanted it
cancelled is not acceptable. Making the article
unreadable is the minimum action.
NOTE: There have been experiments with making can-
celled articles unreadable, so that local news
administrators could reverse cancellations. In
practice, administrators almost never find cause
to do so. Removal appears to be clearly prefer-
able where technically feasible.
NOT ARRIVED YET. If practical, retain the cancel message
until the target article does arrive, or until there is no
INTERNET DRAFT to be NEWS sec. 7.1
further possibility of it arriving and being accepted (see
section 9.2), and then treat as under AVAILABLE. Failing
that, arrange for the target article to be rejected and dis-
carded if it does arrive.
NOTE: It may well be impractical to retain the
control message, given uncertainty about whether
the target article will ever arrive. Existing
practice in such cases is to assume that addresses
would match and arrange the equivalent of dele-
tion. This is often done by making a spurious
entry in a database of already-seen message IDs
(see section 9.3), so that if the article does
arrive, it will be rejected as a duplicate.
The cancel message MUST be propagated onward in the usual
fashion, regardless of which of the four cases applied, so
that the target article will be cancelled everywhere even if
cancellation and target article follow different routes.
NOTE: RFC 1036 appeared to require stopping cancel
propagation in the NOT ARRIVED YET case, although
the wording was somewhat unclear. This appears to
have been an unwise decision; there are known
cases of important cancellations (in situations
of, e.g., inadvertent copyright violation) achiev-
ing rather poorer propagation than the target
article. News propagation is often a much less
orderly process than the authors of RFC 1036
apparently envisioned. Modern implementations
generally propagate the cancellation regardless.
Posting agents meant for use by ordinary posters SHOULD
reject an attempt to post a cancel message if the target
article is available and the mailing address in its From
header does not match the one in the cancel message's From
header.
NOTE: This, again, is primarily accident preven-
tion.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../rfc1036/Cancel.out December 1987
+++ ../s-o-1036/Cancel.out June 1994
@@ -1,21 +1,187 @@
-3.1. Cancel
+7.1. cancel
- cancel <Message-ID>
+The cancel message requests that one or more previous arti-
+cles be "cancelled":
+ cancel-arguments = message-id *( space message-id )
+ cancel-body = body
- If a message with the given Message-ID is present on the local
- system, the message is cancelled. This mechanism allows a user to
- cancel a message after the message has been distributed over the
- network.
-
- If the system is unable to cancel the message as requested, it
- should not forward the cancellation request to its neighbor systems.
-
- Only the author of the message or the local news administrator is
- allowed to send this message. The verified sender of a message is
- the "Sender" line, or if no "Sender" line is present, the "From"
- line. The verified sender of the cancel message must be the same as
- either the "Sender" or "From" field of the original message. A
- verified sender in the cancel message is allowed to match an
- unverified "From" in the original message.
+The argument(s) identify the articles to be cancelled, by
+message ID. The body is a comment, which software MUST
+ignore, and SHOULD contain an indication of why the cancel-
+lation was requested. The cancel message SHOULD be posted
+to the same newsgroup(s), with the same distribution(s), as
+the article(s) it is attempting to cancel.
+
+ NOTE: Using the same newsgroups and distributions
+ maximizes the chances of the cancel message propa-
+ gating everywhere the target articles went.
+
+ NOTE: RFC 1036 permitted only a single message-id
+ in a cancel message. Support for cancelling mul-
+ tiple articles is highly desirable, especially for
+ use with Supersedes (see section 6.14). If sev-
+ eral revisions of an article appear in fast suc-
+ cession, each using Supersedes to cancel the pre-
+ vious one, it is possible for a middle revision to
+
+INTERNET DRAFT to be NEWS sec. 7.1
+
+
+ be destroyed by cancellation before it is propa-
+ gated onward to cancel its predecessor. Allowing
+ each article to cancel several predecessors
+ greatly alleviates this problem. (Posting agents
+ preparing a cancel of an article which itself can-
+ cels other articles might wish to add those arti-
+ cles to the cancel-arguments.) However, posters
+ should be aware that much old software does not
+ implement multiple cancellation properly, and
+ should avoid using it when reliable cancellation
+ is vitally important.
+
+When an article (the "target article") is to be cancelled,
+there are four cases of interest: the article hasn't arrived
+yet, it has arrived and been filed and is available for
+reading, it has expired and been archived on some less-
+accessible storage medium, or it has expired and been
+deleted. The next few paragraphs discuss each case in turn
+(in reverse order, which is convenient for the explanation).
+
+EXPIRED AND DELETED. Take no action.
+
+EXPIRED AND ARCHIVED. If the article is readily accessible
+and can be deleted or made unreadable easily, treat as under
+AVAILABLE below. Otherwise treat as under EXPIRED AND
+DELETED.
+
+ NOTE: While it is desirable for archived articles
+ to be cancellable, this can easily involve rewrit-
+ ing an entire archive volume just to get rid of
+ one article, perhaps with manual actions required
+ to arrange it. It is difficult to envision a sit-
+ uation so dire as to require such measures from
+ hundreds or thousands of administrators, or for
+ that matter one in which widespread compliance
+ with such a request is likely.
+
+AVAILABLE. Compare the mailing addresses from the From
+lines of the cancel message and the target article, bearing
+in mind that local parts (except for "postmaster") are case-
+sensitive and domains are case-insensitive. If they do not
+match, either refer the issue to an administrator for a
+case-by-case decision, or treat as if they matched.
+
+ NOTE: It is generally trivial to forge articles,
+ so nothing short of cryptographic authentication
+ is really adequate to ensure that a cancel came
+ from the original article's author. Moreover, it
+ is highly desirable to permit authorities other
+ than the author to cancel articles, to allow for
+ cases in which the author is unavailable, uncoop-
+ erative, or malicious, and in which damage and/or
+ legal problems may be minimized by prompt cancel-
+ lation. Reliable authentication that would permit
+
+INTERNET DRAFT to be NEWS sec. 7.1
+
+
+ such administrative cancels would be a worthwhile
+ extension to this Draft, and experimental work in
+ this area is encouraged.
+
+ NOTE: Meanwhile, a simple check of addresses is
+ useful accident prevention and catches at least
+ the most simple-minded forgers. Since the intent
+ is accident prevention rather than ironclad secu-
+ rity, use of the From address is appropriate, all
+ the more so because in the presence of gateways
+ (especially redundant multiple gateways), the
+ author may not have full control over Sender head-
+ ers.
+
+ NOTE: The "refer... or treat as if they matched"
+ rule is intended to specifically forbid quietly
+ ignoring cancels with mismatched addresses.
+
+If the addresses match, then if technically possible, the
+relayer MUST delete the target article completely and imme-
+diately. Failing that, it MUST make the target article
+unreadable (preferably to everyone, minimally to everyone
+but the administrator) and either arrange for it to be
+deleted as soon as possible or notify an administrator at
+once.
+
+ NOTE: To allow for events such as criminal
+ actions, malicious forgeries, and copyright
+ infringements, where damage and/or legal problems
+ may be minimized by prompt cancellation, complete
+ removal is strongly preferred over merely making
+ the target article unreadable. The potential for
+ malice is outweighed by the importance of really
+ getting rid of the target article in some legiti-
+ mate cases. (In cases of inadvertent copyright
+ violation in particular, the ability to quickly
+ remedy the violation is of considerable legal
+ importance.) Failing that, making it unreadable
+ is better than nothing.
+
+ NOTE: Merely annotating the article so that read-
+ ers see an indication that the author wanted it
+ cancelled is not acceptable. Making the article
+ unreadable is the minimum action.
+
+ NOTE: There have been experiments with making can-
+ celled articles unreadable, so that local news
+ administrators could reverse cancellations. In
+ practice, administrators almost never find cause
+ to do so. Removal appears to be clearly prefer-
+ able where technically feasible.
+
+NOT ARRIVED YET. If practical, retain the cancel message
+until the target article does arrive, or until there is no
+
+INTERNET DRAFT to be NEWS sec. 7.1
+
+
+further possibility of it arriving and being accepted (see
+section 9.2), and then treat as under AVAILABLE. Failing
+that, arrange for the target article to be rejected and dis-
+carded if it does arrive.
+
+ NOTE: It may well be impractical to retain the
+ control message, given uncertainty about whether
+ the target article will ever arrive. Existing
+ practice in such cases is to assume that addresses
+ would match and arrange the equivalent of dele-
+ tion. This is often done by making a spurious
+ entry in a database of already-seen message IDs
+ (see section 9.3), so that if the article does
+ arrive, it will be rejected as a duplicate.
+
+The cancel message MUST be propagated onward in the usual
+fashion, regardless of which of the four cases applied, so
+that the target article will be cancelled everywhere even if
+cancellation and target article follow different routes.
+
+ NOTE: RFC 1036 appeared to require stopping cancel
+ propagation in the NOT ARRIVED YET case, although
+ the wording was somewhat unclear. This appears to
+ have been an unwise decision; there are known
+ cases of important cancellations (in situations
+ of, e.g., inadvertent copyright violation) achiev-
+ ing rather poorer propagation than the target
+ article. News propagation is often a much less
+ orderly process than the authors of RFC 1036
+ apparently envisioned. Modern implementations
+ generally propagate the cancellation regardless.
+
+Posting agents meant for use by ordinary posters SHOULD
+reject an attempt to post a cancel message if the target
+article is available and the mailing address in its From
+header does not match the one in the cancel message's From
+header.
+
+ NOTE: This, again, is primarily accident preven-
+ tion.