Jump to content

Control message: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
→Security considerations: "news servers" is two words
 
(36 intermediate revisions by 21 users not shown)
Line 1: Line 1:
{{short description|Special kind of Usenet post used to control news servers}}
{| align="right"
⚫
'''Control messages''' are a special kind of [[Usenet]] post that are used to control [[news server]]s. They differ from ordinary posts by a [[Header_(computing)|header]] field named <code>Control</code>. The body of the field contains control name and arguments.
| __TOC__
|}


⚫
There are two historical alternatives to header field <code>Control</code>. They are not supported by contemporary software <ref>[[InterNetNews]] never supported {{Mono|all.all.ctl}}{{what|date=February 2021}}. INN version 1.0 was released in 1990.</ref><ref>"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.
⚫
'''Control messages''' are a special kind of [[Usenet]] post that are used to control [[news server]]s. They differ from ordinary posts by a header field named <code>Control</code>. The body of the field contains control name and arguments.
⚫
See [https://web.archive.org/web/20070103213328/http://www.eyrie.org/~eagle/software/inn/docs-2.3/news.html INN Changes and Upgrade Information (Internet Archive)].</ref> and forbidden according to RFC 5537.<ref>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.</ref> However, the traditional format of the subject line is widely used in addition to the <code>Control</code> header: the subject line consists of the word "cmsg" followed by control name and arguments.


==Types==
⚫
There are two historical alternatives to header field <code>Control</code>. They are not supported by contemporary software <ref>[[InterNetNews]] never supported <tt>all.all.ctl</tt>. INN version 1.0 was released in 1990.</ref> <ref>"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 [http://web.archive.org/web/20070103213328/http://www.eyrie.org/~eagle/software/inn/docs-2.3/news.html INN Changes and Upgrade Information (Internet Archive)].</ref> and forbidden according to RFC 5537. <ref>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.</ref> However, the traditional format of the subject line is widely used in addition to the <code>Control</code> header: the subject line consists of the word "cmsg" followed by control name and arguments.


==Types of control messages==
===cancel===
===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.
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 <tt>From:</tt> line (or <tt>Sender:</tt> 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.<ref>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 <tt>From:</tt> line is trivial to forge and with cancelbots the cancel message often arrives before the target article. Option <tt>verifycancels</tt> of INN defaults to false.</ref>
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 {{Mono|From:}} line (or {{Mono|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.<ref>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 {{Mono|From:}} line is trivial to forge and with cancelbots the cancel message often arrives before the target article. Option {{Mono|verifycancels}} of INN defaults to false.</ref>


Anyway, additional hierarchy specific rules (see [[Breidbart Index]]) allow [[cancelbot]]s to send third-party cancels to remove [[Spam (electronic)|spam]].
Additional hierarchy specific rules (see [[Breidbart Index]]) allow [[cancelbot]]s to send third-party cancels to remove [[Spam (electronic)|spam]].


;Example
;Example
Line 21: Line 19:


===newgroup===
===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 <tt>moderated</tt>. The body of the message typically contains tagline, charta and rationale.
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 {{Mono|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.<ref>The manual page of the ''ctlinnd'' utility (part of INN) says: ''If the newsgroup already exists, this is equivalent to the changegroup command.''</ref>
If the group already exists, only the status of the group is changed, i.e. whether it is moderated or nor not.<ref>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.''</ref>


Typically newgroup messages having a correct digital signature are executed automatically. In some hierarchies (<tt>alt.*</tt>, <tt>free.*</tt>, <tt>de.alt.*</tt>) unsigned newgroup messages just serve as formalized proposal to create a new group. Objections to the proposal are then expressed with a <tt>rmgroup</tt>.<ref>*[http://www.gweep.ca/~edmonds/usenet/good-newgroup.html How To Write a Good Newgroup Message]
Typically newgroup messages having a correct digital signature are executed automatically. In some hierarchies ({{Mono|alt.*}}, {{Mono|free.*}}, {{Mono|de.alt.*}}) unsigned newgroup messages just serve as formalized proposal to create a new group. Objections to the proposal are then expressed with a {{Mono|rmgroup}}.<ref>*[http://www.gweep.ca/~edmonds/usenet/good-newgroup.html How To Write a Good Newgroup Message] {{Webarchive|url=https://web.archive.org/web/20080415161939/http://www.gweep.ca/~edmonds/usenet/good-newgroup.html |date=2008-04-15 }}
*[http://nylon.net/alt/ How to create an ALT newsgroup]
*[http://nylon.net/alt/ How to create an ALT newsgroup]
*[http://www.killfile.org/~tskirvin/faqs/free.html free.* FAQ]</ref>
*[http://www.killfile.org/~tskirvin/faqs/free.html free.* FAQ] {{webarchive|url=https://web.archive.org/web/20080315222916/http://www.killfile.org/~tskirvin/faqs/free.html |date=2008-03-15 }}</ref>
<ref name="de.alt">[http://www.kirchwitz.de/~amk/dai/einrichtung Regeln für die Einrichtung, Änderung und Entfernung von Usenet-Gruppen]</ref>
<ref name="de.alt">[http://www.kirchwitz.de/~amk/dai/einrichtung Regeln für die Einrichtung, Änderung und Entfernung von Usenet-Gruppen]</ref>


In any cases newgroup messages are archived by the [[Internet Systems Consortium]].<ref name=autogenerated1>ftp://ftp.isc.org/pub/usenet/control/</ref>
In many cases newgroup messages are archived by the [[Internet Systems Consortium]].<ref name=autogenerated1>ftp://ftp.isc.org/pub/usenet/control/</ref>


;Example
;Example
Line 39: Line 37:
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.
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.
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 <tt>de.alt.*</tt> 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.<ref name="de.alt"/>
In the hierarchy {{Mono|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.<ref name="de.alt"/>


;Example
;Example
Control: rmgroup comp.object.moderated
Control: rmgroup comp.object.moderated
Subject: cmsg rmgroup comp.object.moderated
Subject: cmsg rmgroup comp.object.moderated

In 1995 the [[Church of Scientology]] attempted to [[Scientology versus the Internet#Attempt to remove alt.religion.scientology|silence criticism]] by sending mass "rmgroup" messages to Usenet servers targeting [[alt.religion.scientology]], an example of the church's [[Scientology versus the Internet|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===
===checkgroups===
Line 85: Line 85:
|Whogets
|Whogets
|RFC 5537
|RFC 5537
|No explanation, just declared obsolete
|No description, just declared obsolete
|}
|}


The ihave/sendme protocol was obsoleted by [[NNTP]].
The ihave/sendme protocol was obsoleted by [[NNTP]].


Answering control messages with large emails can be exploited for a [[Denial of service]] attack. Thus contemporary [[news server]]s don't implement <tt>sendsys</tt>, even though its specification makes it mandatory.<ref>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.''</ref>
Answering control messages with large emails can be exploited for a [[Denial of service]] attack. Thus [[news server]]s stopped implementing {{Mono|sendsys}} long before it was declared obsolete by RFC 5537.<ref>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.''</ref>


==Security considerations==
==Security considerations==

===Header field "Approved:"===
===Header field "Approved:"===
Messages of type <tt>newgroup</tt> and <tt>rmgroup</tt> are ignored unless there is an "Approved" line in the same message header.<ref>RFC 1036, sections "3.3. Newgroup" and "3.4. Rmgroup". Section "3.7. Checkgroups" does not contain this clause.</ref> 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.
Messages of type {{Mono|newgroup}} and {{Mono|rmgroup}} are ignored unless there is an [[News_server#Transit_server|"Approved" line]] in the same message header.<ref>RFC 1036, sections "3.3. Newgroup" and "3.4. Rmgroup". Section "3.7. Checkgroups" does not contain this clause.</ref> 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===
===Digital signature===
Line 121: Line 122:
|}
|}


For control message a special format is required since the essential information is in the header fields. Pgpcontrol was originally designed for [[Pretty Good Privacy|PGP]] but also works with [[OpenPGP]].<ref>INN already ships with <tt>pgpcontrol</tt>. The project site ftp://ftp.isc.org/pub/pgpcontrol/
For control message a special format is required since the essential information is in the header fields. Pgpcontrol was originally designed for [[Pretty Good Privacy|PGP]] but also works with [[OpenPGP]].<ref>INN already ships with {{Mono|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.</ref>
additionally provides instructions on how to set up PGP/OpenPGP and a huge archive of hierarchy keys.</ref>


===Hierarchy keys===
===Hierarchy keys===
Newsgroup maintenance of the main Usenet hierarchies ([[Big 8 (Usenet)|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.
Newsgroup maintenance of the main Usenet hierarchies ([[Big 8 (Usenet)|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 [[Newsreader (Usenet)|newsreader]]s.<ref>Cancel-Locks in Usenet articles: [http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01 draft-ietf-usefor-cancel-lock-01.txt], published in November 1998, expired in May 1999</ref>
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]]{{what|date=September 2022}} is much simpler, but neither commonly accepted, nor implemented in popular news servers and [[Newsreader (Usenet)|newsreader]]s.<ref>Cancel-Locks in Usenet articles: [http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01 draft-ietf-usefor-cancel-lock-01.txt], published in November 1998, expired in May 1999</ref>


==Archiving==
==Archiving==
'''Control messages''' are typically not shown in the target [[Newsgroup]]. Instead many servers put them into pseudo newsgroups like <code>control</code>.<ref>INN normally files control messages to the pseudo newsgroup <tt>control</tt>. However, if a subgroup of <tt>control</tt> exists that matches the control command, the control message will be filed into that group instead.</ref>
'''Control messages''' are typically not shown in the target [[newsgroup]]. Instead many servers put them into pseudo newsgroups like <code>control</code>.<ref>INN normally files control messages to the pseudo newsgroup {{Mono|control}}. However, if a subgroup of {{Mono|control}} exists that matches the control command, the control message will be filed into that group instead.</ref>


[[Google Groups]] provides no means to read or write control messages. It does not even execute cancels.
[[Google Groups]] provides no means to read or write control messages. It does not even execute cancels.


The [[Internet Systems Consortium]] archives <tt>newgroup</tt> and <tt>rmgroup</tt> together as a single file per group<ref name=autogenerated1 /> and <tt>checkgroups</tt> as one file per year.<ref>ftp://ftp.isc.org/pub/usenet/control/other.ctl/</ref>
The [[Internet Systems Consortium]] archives {{Mono|newgroup}} and {{Mono|rmgroup}} together as a single file per group<ref name=autogenerated1 /> and {{Mono|checkgroups}} as one file per year.<ref>ftp://ftp.isc.org/pub/usenet/control/other.ctl/</ref>


==References==
==References==
Line 141: Line 142:
[[Category:Usenet]]
[[Category:Usenet]]


[[de:Control-Message]]
[[fr:Message de contrôle]]
[[pl:Anulowanie wiadomości]]

Latest revision as of 21:34, 6 December 2024

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 [1][2] and forbidden according to RFC 5537.[3] 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

[edit]

cancel

[edit]

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.[4]

Additional hierarchy specific rules (see Breidbart Index) allow cancelbots to send third-party cancels to remove spam.

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

newgroup

[edit]

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.[5]

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.[6] [7]

In many cases newgroup messages are archived by the Internet Systems Consortium.[8]

Example
Control: newgroup comp.object.moderated moderated
Subject: cmsg newgroup comp.object.moderated moderated

rmgroup

[edit]

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.[7]

Example
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.

checkgroups

[edit]

A checkgroups message lists all groups of a hierarchy.

Example
Control: checkgroups
Subject: cmsg checkgroups
Example conforming to RFC 5537
Control: checkgroups de !de.alt #2009021301

Obsolete message types

[edit]
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.[9]

Security considerations

[edit]

Header field "Approved:"

[edit]

Messages of type newgroup and rmgroup are ignored unless there is an "Approved" line in the same message header.[10] 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

[edit]

The format of "Arpa Internet Text Messages"[11] is the common base for Usenet[12] and E-mail.[13] 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.[14]

Hierarchy keys

[edit]

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[clarification needed] is much simpler, but neither commonly accepted, nor implemented in popular news servers and newsreaders.[15]

Archiving

[edit]

Control messages are typically not shown in the target newsgroup. Instead many servers put them into pseudo newsgroups like control.[16]

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[8] and checkgroups as one file per year.[17]

References

[edit]
  1. ^ InterNetNews never supported all.all.ctl[clarification needed]. INN version 1.0 was released in 1990.
  2. ^ "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).
  3. ^ 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.
  4. ^ 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.
  5. ^ 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.
  6. ^ *How To Write a Good Newgroup Message Archived 2008-04-15 at the Wayback Machine
  7. ^ a b Regeln für die Einrichtung, Änderung und Entfernung von Usenet-Gruppen
  8. ^ a b ftp://ftp.isc.org/pub/usenet/control/
  9. ^ 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.
  10. ^ RFC 1036, sections "3.3. Newgroup" and "3.4. Rmgroup". Section "3.7. Checkgroups" does not contain this clause.
  11. ^ RFC 822, published in August 1982
  12. ^ RFC 1036, section "2. Message Format"
  13. ^ RFC 2822, obsoleted RFC 822 in April 2001
  14. ^ 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.
  15. ^ Cancel-Locks in Usenet articles: draft-ietf-usefor-cancel-lock-01.txt, published in November 1998, expired in May 1999
  16. ^ 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.
  17. ^ ftp://ftp.isc.org/pub/usenet/control/other.ctl/
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Control_message&oldid=1261584122"