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 of control messages
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. 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.
Control: cancel <email@example.com> Subject: cmsg cancel <firstname.lastname@example.org>
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. 
Control: newgroup comp.object.moderated moderated Subject: cmsg newgroup comp.object.moderated moderated
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.
Control: rmgroup comp.object.moderated Subject: cmsg rmgroup comp.object.moderated
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.
A checkgroups message lists all groups of a hierarchy.
Control: checkgroups Subject: cmsg checkgroups
- Example conforming to RFC 5537
Control: checkgroups de !de.alt #2009021301
Obsolete message types
|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.
Header field "Approved:"
Messages of type newgroup and rmgroup are ignored unless there is an "Approved" line in the same message header. Newsservers 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.
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/MIME||MIME body parts|
|S/MIME||MIME body parts|
|pgpcontrol||body and selected header fields||newgroup, rmgroup, checkgroups|
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 newsservers 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.
Google Groups provides no means to read or write control messages. It does not even execute cancels.
- InterNetNews never supported all.all.ctl. INN version 1.0 was released in 1990.
- "Subject: cmsg" is described only in RFC 1036 (published in December 1987) but not in RFC 850 (published in June 1983). INN dropped this feature with version 2.3. See INN Changes and Upgrade Information (Internet Archive).
- RFC 5537, 5. Control Messages: [...] The presence of a Subject header field starting with the string "cmsg " MUST NOT cause an article to be interpreted as a control message. [...] Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the Newsgroups header field or the presence of an Also-Control header field MUST NOT cause the article to be interpreted as a control message.
- RFC 850 uses the term "local super user" instead of "local news administrator". Son-of-RFC-1036 (this is the colloquial name of an Internet Draft written by Henry Spencer) drops the administrator's cancel altogether. The problem with the verification scheme is that the From: line is trivial to forge and with cancelbots the cancel message often arrives before the target article. Option verifycancels of INN defaults to false.
- Section 5.2.1. of RFC 5537 says: The newgroup control message requests that the specified group be created or, if already existing, that its moderation status or description be changed. The feature is much older, though. For example the manual page of the ctlinnd utility (part of INN) says: If the newsgroup already exists, this is equivalent to the changegroup command.
- *How To Write a Good Newgroup Message
- Regeln für die Einrichtung, Änderung und Entfernung von Usenet-Gruppen
- Section "3.5. Sendsys" of RFC 1036 includes the following clause: This information is considered public information, and it is a requirement of membership in USENET that this information be provided on request, either automatically in response to this control message, or manually, by mailing the requested information to the author of the message.
- RFC 1036, sections "3.3. Newgroup" and "3.4. Rmgroup". Section "3.7. Checkgroups" does not contain this clause.
- RFC 822, published in August 1982
- RFC 1036, section "2. Message Format"
- RFC 2822, obsoleted RFC 822 in April 2001
- INN already ships with pgpcontrol. The project site ftp://ftp.isc.org/pub/pgpcontrol/ additionally provides instructions on how to set up PGP/OpenPGP and a huge archive of hierarchy keys.
- Cancel-Locks in Usenet articles: draft-ietf-usefor-cancel-lock-01.txt, published in November 1998, expired in May 1999
- INN normally files control messages to the pseudo newsgroup control. However, if a subgroup of control exists that matches the control command, the control message will be filed into that group instead.