# Control message

Control messages are a special kind of Usenet post that are used to control news servers. They differ from ordinary posts by a header field named Control. The body of the field contains control name and arguments.
There are two historical alternatives to header field Control. They are not supported by contemporary software and forbidden according to RFC 5537. However, the traditional format of the subject line is widely used in addition to the Control header: the subject line consists of the word "cmsg" followed by control name and arguments.

## Types
### cancel

A cancel message requests the deletion of a specific article. The body of the Control field contains one argument, the Message-ID of the article to delete.
According to RFC 1036 only the author of the target message or the local news administrator is allowed to send a cancel (cancels not meeting this condition are called "rogue cancels"). To verify authorization the From: line (or Sender: line, if it exists) of the cancel message must match the target article. This verification does not work well in modern day Usenet and is rarely used.
Additional hierarchy specific rules (see Breidbart Index) allow cancelbots to send third-party cancels to remove spam.

#### Example
### newgroup

A newgroup message is issued to create a new Usenet newsgroup. The body of the Control field contains one mandatory argument, the name of the new group. The second argument is optional. If present it consists of the keyword moderated. The body of the message typically contains tagline, charter and rationale.
If the group already exists, only the status of the group is changed, i.e. whether it is moderated or nor not.
Typically newgroup messages having a correct digital signature are executed automatically. In some hierarchies (alt.*, free.*, de.alt.*) unsigned newgroup messages just serve as formalized proposal to create a new group. Objections to the proposal are then expressed with a rmgroup.
In many cases newgroup messages are archived by the Internet Systems Consortium.

#### Example
### rmgroup

A rmgroup message is issued to remove a newsgroup. The body of the Control field contains one mandatory argument, the name of the group to remove.
Typically rmgroup messages having a correct digital signature are executed automatically. In some hierarchies unsigned rmgroup messages are used to veto a preceding newgroup.
In the hierarchy de.alt.* removal and creation of groups is handled symmetrically, i.e. an unsigned rmgroup message is used as formalized proposal. Objections to the proposal are then expressed with a newgroup.

#### Example

In 1995 the Church of Scientology attempted to silence criticism by sending mass "rmgroup" messages to Usenet servers targeting alt.religion.scientology, an example of the church's continuing efforts to suppress material critical of Scientology on the Internet. Most servers discarded the message, and those that did not were quickly sent "newgroup" messages reestablishing the newsgroup.

### checkgroups

A checkgroups message lists all groups of a hierarchy.

#### Example conforming to RFC 5537
### Obsolete message types

| Name | Definition | Description |
| Ihave | RFC 850, RFC 1036, RFC 5537 | Announce arrival of particular message |
| Sendme | RFC 850, RFC 1036, RFC 5537 | Request transmission of particular message |
| Sendsys | RFC 850, RFC 1036, RFC 5537 | Request email with list of newsgroups sent to each neighbor |
| Senduuname | RFC 850, RFC 5537 | Request email with list of all uucp neighbors |
| Version | RFC 850, RFC 1036, RFC 5537 | Request email with name and version of Usenet software |
| Whogets | RFC 5537 | No description, just declared obsolete |
The ihave/sendme protocol was obsoleted by NNTP.
Answering control messages with large emails can be exploited for a Denial of service attack. Thus news servers stopped implementing sendsys long before it was declared obsolete by RFC 5537.

## Security considerations
### Header field "Approved:"

Messages of type newgroup and rmgroup are ignored unless there is an "Approved" line in the same message header. News servers traditionally allow only selected users to send articles with these lines. As long as there were only a handful of Usenet sites this provided sufficient protection against abuse.

### Digital signature

The format of "Arpa Internet Text Messages" is the common base for Usenet and E-mail. The format provides no means of authentication. Various extensions adding a digital signature were developed to prevent forgeries.
| Signature format | Covered data | Usage |
| PGP/INLINE | arbitrary text | NoCeM |
| PGP/MIME | MIME body parts | E-mail |
| S/MIME | MIME body parts | E-mail |
| pgpcontrol | body and selected header fields | newgroup, rmgroup, checkgroups |
For control message a special format is required since the essential information is in the header fields. Pgpcontrol was originally designed for PGP but also works with OpenPGP.

### Hierarchy keys

Newsgroup maintenance of the main Usenet hierarchies (Big 8 and regional hierarchies) is done through signed control messages. Each hierarchy has unique key that is guarded by the hierarchy founders (or their successors). Most news servers are configured to both automatically execute controls signed with the right key and ignore anything else.
Theoretically this system is also applicable to cancel messages. However, it would not only require a key pair for every Usenet user but also that the respective public key is known to every news server. Cancel-lock is much simpler, but neither commonly accepted, nor implemented in popular news servers and newsreaders.

## Archiving

Control messages are typically not shown in the target newsgroup. Instead many servers put them into pseudo newsgroups like control.
Google Groups provides no means to read or write control messages. It does not even execute cancels.
The Internet Systems Consortium archives newgroup and rmgroup together as a single file per group and checkgroups as one file per year.