Cancel

from Wikipedia, the free encyclopedia

The verb cancel ( Engl. Cancel "cancel") referred to in Usenet conscious, premature deletion of an article. The term is ambiguous.

Newsreaders , i.e. the programs with which one participates in Usenet, generally have a function (menu item, button, etc.) called "Cancel message", "Cancel Usenet message" etc. to generate and send a cancel message .

On the other hand, news servers understand the Cancel function to mean the pure deletion process, i.e. the removal of an article from the news server's article store. The automatic evaluation of incoming cancel messages is an additional functionality. Alternatives to cancel messages are NoCeM and Supersede .

Cancel message

A cancel message is a request that can be automatically evaluated by software to delete a specific item locally. It belongs to the group of control messages and differs from normal postings by a line in the header (which also includes sender, subject, newsgroups, date, etc.) with the following syntax:

Control: cancel <899qh19zehlhsdfa@example.com>

This message does not appear legibly in the relevant newsgroup , but asks you to delete the article with the message ID <899qh19zehlhsdfa@example.com> . Many news servers sort cancel messages into the pseudo newsgroup controlor into control.cancelone.

It is common, but not necessary, to design the subject line of a cancel message as follows:

Subject: cmsg cancel <899qh19zehlhsdfa@example.com>

Third party cancellation

External cancel is the translation of third-party cancel .

According to RFC 1036 , an article may only be canceled by the author or the administrator of the server on which the article was uploaded to Usenet. However, since RFC 1036 appeared in December 1987, practice has changed slightly. Third-party cancels are now tolerated to remove spam . However, the extensive guidelines for this were not raised to the status of an RFC . Formal requirements and requirements (e.g. Breidbart index ) are determined individually by the hierarchies .

According to the currently valid RFC 5537 , the header fields From and Sender no longer have to match the target article (No. 5.3). Authentication should be carried out for all control messages from the server (no. 5.1). See also the section “Cancel-Lock and Cancel-Key”.

But there are also voices who regard every third-party cancellation as an inadmissible interference with the expression of opinion of other participants. For example, free.*all cancel messages are prohibited in the hierarchy .

Current news servers allow you to set which of these recommendations should and should not be followed very flexibly according to a number of different criteria. However, there are also news servers that do not allow any cancels to avoid misuse.

Cancel watch

Cancel-Watch is a simple procedure to send a notification ( e-mail ) to the author of the relevant posting when a cancel message arrives.

A prerequisite is a message ID with a unique, i. H. Fully Qualified Domain Name not used by any other user . This eliminates the need to keep a database of used message IDs .

Cancel-Lock and Cancel-Key

Cancel-Lock is a mechanism to prevent unauthorized canceling and supersedes . It is described in draft-ietf-usefor-cancel-lock-01 (dated November 1998) and now in RFC 8315 (February 2018) and is rarely used.

The method is based on the irreversibility of a hash function . Only Secure Hash Algorithm (SHA-1) is mentioned in the draft . The format of the cancel lock itself is not restricted to a specific hash function. RFC 8315 (Nos. 6 and 8.3) provides for SHA-256 and SHA-512.

Cancel-Lock is easier to implement than the other control messages ( newgroup, rmgroup, checkgroups) Signature used with PGP . Most importantly, no public key database is required.

However, it is not always guaranteed that a cancel message will arrive after the message to be deleted. If a cancel bot is running on a server and it generates a cancel message immediately after receiving a (spam) article , only this will be distributed further. The original message can arrive after the cancel message via detours (slow servers, poor connection, servers that do not cancel at all) .

procedure

When an article is sent, a matching pair of cancel lock and cancel key is generated. The cancel lock is published with the article. The cancel key remains secret for the time being.

If a cancel or supersedes event later becomes necessary, the cancel key that matches the cancel lock of the target posting is also sent. Servers that implement the procedure only delete articles protected by the cancel lock if a correct cancel key is present in the cancel or supersedes .

Few newsreaders implement cancel lock :

However, cancel locks can also be set by the news server software. Since the procedure provides the possibility of adding further locks to existing locks, articles can have more than one cancel lock (or more than one cancel key ). Since only one of the keys has to match one of the locks when checking, server operators keep the option of Admin Cancel open by automatically inserting them.

algorithm

The relationship between key and lock is defined in the draft or in RFC 8315 (no. 2.1).

 lock = encode_base64(hash(key))

Since the key may be published in cancel messages or supersedes , each posting must be protected by an individual lock. Theoretically, you could have the key generated by a random number generator , but then you would have to keep a record of which key fits which post.

RFC 8315 recommends using the HMAC procedure for message ID and a secret instead . Since the message ID differs from article to article by definition, you get an individual lock for each posting and still only have to remember one secret for all postings.

Here is an example with the tool canlockfrom the libcanlock library :

$ printf '%s' 'geheimes_passwort' | canlock -a sha256 -k '<plhgpp$v8d$3@mid.news.example>'
sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=

$ printf '%s' 'geheimes_passwort' | canlock -a sha256 -l '<plhgpp$v8d$3@mid.news.example>'
sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=

$ canlock -c 'sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=','sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg='
Good

This is <plhgpp$v8d$3@mid.news.example>the message ID of the posting, and geheimes_passwortis the constant secret. The first command (with the switch -k) creates the cancel key and the second command (with the switch ) creates the cancel -llock. If you canlockuse the option -c(check), you can check whether the cancel key and cancel lock match.

Further examples (implemented with OpenSSL) can be found in Chapter 5 of RFC 8315 .

The following Perl script generates a key / lock pair:

#!/usr/bin/perl -w
use Digest::SHA qw( sha256_base64 hmac_sha256_base64 );

my $secret = "geheimes_passwort";
my $message_id = '<plhgpp$v8d$3@mid.news.example>';

my $cancel_key = Digest::SHA::hmac_sha256_base64($message_id, $secret);

while (length($cancel_key) % 4) {
        $cancel_key .= '=';
}

my $cancel_lock = Digest::SHA::sha256_base64($cancel_key);

while (length($cancel_lock) % 4) {
        $cancel_lock .= '=';
}

printf "cancel secret: \"%s\"\n", $secret;
printf "Message-ID: %s\n", $message_id;

printf "Cancel-Key: sha256:%s\n", $cancel_key;
printf "Cancel-Lock: sha256:%s\n", $cancel_lock;

Output of the script:

$ ./erzeugen.pl 
cancel secret: "geheimes_passwort"
Message-ID: <plhgpp$v8d$3@mid.news.example>
Cancel-Key: sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=
Cancel-Lock: sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=

This script checks a given key / lock pair:

#!/usr/bin/perl -w
use Digest::SHA qw( sha256_base64 );

my $cancel_key = 'sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=';
my $cancel_lock = 'sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=';

my $ck = (split (/:/, $cancel_key))[1];
my $cl = (split (/:/, $cancel_lock))[1];

my $verify = sha256_base64($ck);

while (length($verify) % 4) {
        $verify .= '=';
}

printf "Cancel-Key: %s\n", $cancel_key;
printf "Cancel-Lock: %s\n", $cancel_lock;

if ($cl eq $verify)
  { print "Cancel-Key matches Cancel-Lock.\n"; }
else
  { print "Cancel-Key does not match Cancel-Lock.\n"; }

Output:

$ ./pruefen.pl 
Cancel-Key: sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=
Cancel-Lock: sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=
Cancel-Key matches Cancel-Lock.

NoCeM

NoCeM is a rarely used alternative to third-party cancellation. The made-up word is based on the English word combination No See 'Em and is pronounced as [, nou'si: əm].

NoCeM messages are with asymmetric encryption format PGP / INLINE signed and contain a type specification as SPAM or MMF . This allows server operators to selectively and automatically analyze certain messages from trustworthy senders.

In contrast to a cancel message , a NoCeM message can affect any number of target messages.

NoCeM messages are usually evaluated by external programs. In contrast to cancel messages , subsequent or repeated evaluation is therefore problem-free.

The for rogue cancel established conventions as breidbart index have for NoCeM no relevance. However, the requirements (installation of the software, import of the PGP key and configuration of the type specification) ensure that only a small minority of the servers take NoCeM into account.

Web links

RFC 1036 - Standard for Interchange of USENET Messages (now obsolete)

RFC 5537 - Netnews Architecture and Protocols

RFC 8315 - Cancel-Locks in Netnews Articles

Footnotes

  1. Current Spam thresholds and guidelines
  2. Third-party cancellation FAQ ( Memento from June 25, 2007 in the Internet Archive )
  3. free. * FAQ
  4. Google Groups ignores incoming cancel messages and does not offer the option of sending your own cancel messages .
  5. a b On the news server with the largest share of postings in de. *, News.individual.de , only cancel messages and supersedes with the correct cancel key are executed: FAQ entry
  6. Ralf Döblitz simply calls his implementation for INN cancelwatch
  7. http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01
  8. Cancel Lock vs. Public key signed cancel
  9. The NoCeM FAQ ( Memento of the original from June 17, 2007 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.cm.org
  10. ^ The NoCeM Registry
  11. In an unapproved draft from 1994 (known as "son of 1036") the extension of Control: and Supersedes: to any number of Message-IDs is proposed.
  12. With INN is perl-NoCeM delivered