s-o-1036 June 1994
[< Prev]
[TOC] [ Next >]
5.3. Message-ID
The Message-ID header contains the article's message ID, a
unique identifier distinguishing the article from every
other article:
Message-ID-content = message-id
message-id = "<" local-part "@" domain ">"
As with From addresses, a message ID's local part is case-
sensitive and its domain is case-insensitive. The "<" and
">" are parts of the message ID, not peculiarities of the
Message-ID header.
NOTE: News message IDs are a restricted subset of
MAIL message IDs. In particular, no existing news
software copes properly with MAIL quoting conven-
tions within the local part, so they are forbid-
den. This is unfortunate, particularly for X.400
gateways that often wish to include characters
which are not legal in unquoted message IDs, but
it is impossible to fix net-wide. See the notes
on gatewaying in section 10.
The domain in the message ID SHOULD be the full Internet
domain name of the posting agent's host. Use of the ".uucp"
pseudo-domain (for hosts registered in the UUCP maps) or the
".bitnet" pseudo-domain (for Bitnet hosts) is permissible,
but SHOULD be avoided.
Posters and posting agents MUST generate the local part of a
message ID using an algorithm which obeys the specified syn-
tax (words separated by ".", with certain characters not
INTERNET DRAFT to be NEWS sec. 5.3
permitted) (see section 5.2 for details), and will not
repeat itself (ever). The algorithm SHOULD not generate
message IDs which differ only in case of letters. Note the
specification in section 6.5 of a recommended convention for
indicating subject changes. Otherwise the algorithm is up
to the implementor.
NOTE: The crucial use of message IDs is to distin-
guish circulating articles from each other and
from articles circulated recently. They are also
potentially useful as permanent indexing keys,
hence the requirement for permanent uniqueness...
but indexers cannot absolutely rely on this
because the earlier RFCs urged it but did not
demand it. All major implementations have always
generated permanently-unique message IDs by
design, but in some cases this is sensitive to
proper administration, and duplicates may have
occurred by accident.
NOTE: The most popular method of generating local
parts is to use the date and time, plus some way
of distinguishing between simultaneous postings on
the same host (e.g. a process number), and encode
them in a suitably-restricted alphabet. An older
but now less-popular alternative is to use a
sequence number, incremented each time the host
generates a new message ID; this is workable, but
requires careful design to cope properly with
simultaneous posting attempts, and is not as
robust in the presence of crashes and other mal-
functions.
NOTE: Some buggy news software considers message
IDs completely case-insensitive, hence the advice
to avoid relying on case distinctions. The
restrictions placed on the "alphabet" of local
parts and domains in section 5.2 have the useful
side effect of making it unnecessary to parse mes-
sage IDs in complex ways to break them into case-
sensitive and case-insensitive portions.
The local part of a message ID MUST not be "postmaster" or
any other string that would compare equal to "postmaster" in
a case-insensitive comparison. Message IDs MUST be no
longer than 250 octets, including the "<" and ">".
NOTE: "Postmaster" is an irksome exception to
case-sensitivity in local parts, inherited from
MAIL, and simply avoiding it is the best way to
deal with it (not that it's likely, but the issue
needs to be dealt with). The length limit is
undesirable, but is present in widely-used exist-
ing software. The limit is actually 255, but a
INTERNET DRAFT to be NEWS sec. 5.3
small safety margin is wise.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../rfc1036/Message-ID.out December 1987
+++ ../s-o-1036/Message-ID.out June 1994
@@ -1,36 +1,97 @@
-2.1.5. Message-ID
+5.3. Message-ID
- The "Message-ID" line gives the message a unique identifier. The
- Message-ID may not be reused during the lifetime of any previous
- message with the same Message-ID. (It is recommended that no
- Message-ID be reused for at least two years.) Message-ID's have the
- syntax:
-
- <string not containing blank or ">">
-
- In order to conform to RFC-822, the Message-ID must have the format:
-
- <unique@full_domain_name>
-
- where full_domain_name is the full name of the host at which the
- message entered the network, including a domain that host is in, and
- unique is any string of printing ASCII characters, not including "<"
- (left angle bracket), ">" (right angle bracket), or "@" (at sign).
- For example, the unique part could be an integer representing a
- sequence number for messages submitted to the network, or a short
- string derived from the date and time the message was created. For
- example, a valid Message-ID for a message submitted from host ucbvax
- in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
- Programmers are urged not to make assumptions about the content of
- Message-ID fields from other hosts, but to treat them as unknown
- character strings. It is not safe, for example, to assume that a
- Message-ID will be under 14 characters, that it is unique in the
- first 14 characters, nor that is does not contain a "/".
-
- The angle brackets are considered part of the Message-ID. Thus, in
- references to the Message-ID, such as the ihave/sendme and cancel
- control messages, the angle brackets are included. White space
- characters (e.g., blank and tab) are not allowed in a Message-ID.
- Slashes ("/") are strongly discouraged. All characters between the
- angle brackets must be printing ASCII characters.
+The Message-ID header contains the article's message ID, a
+unique identifier distinguishing the article from every
+other article:
+
+ Message-ID-content = message-id
+ message-id = "<" local-part "@" domain ">"
+
+As with From addresses, a message ID's local part is case-
+sensitive and its domain is case-insensitive. The "<" and
+">" are parts of the message ID, not peculiarities of the
+Message-ID header.
+
+ NOTE: News message IDs are a restricted subset of
+ MAIL message IDs. In particular, no existing news
+ software copes properly with MAIL quoting conven-
+ tions within the local part, so they are forbid-
+ den. This is unfortunate, particularly for X.400
+ gateways that often wish to include characters
+ which are not legal in unquoted message IDs, but
+ it is impossible to fix net-wide. See the notes
+ on gatewaying in section 10.
+
+The domain in the message ID SHOULD be the full Internet
+domain name of the posting agent's host. Use of the ".uucp"
+pseudo-domain (for hosts registered in the UUCP maps) or the
+".bitnet" pseudo-domain (for Bitnet hosts) is permissible,
+but SHOULD be avoided.
+
+Posters and posting agents MUST generate the local part of a
+message ID using an algorithm which obeys the specified syn-
+tax (words separated by ".", with certain characters not
+
+INTERNET DRAFT to be NEWS sec. 5.3
+
+
+permitted) (see section 5.2 for details), and will not
+repeat itself (ever). The algorithm SHOULD not generate
+message IDs which differ only in case of letters. Note the
+specification in section 6.5 of a recommended convention for
+indicating subject changes. Otherwise the algorithm is up
+to the implementor.
+
+ NOTE: The crucial use of message IDs is to distin-
+ guish circulating articles from each other and
+ from articles circulated recently. They are also
+ potentially useful as permanent indexing keys,
+ hence the requirement for permanent uniqueness...
+ but indexers cannot absolutely rely on this
+ because the earlier RFCs urged it but did not
+ demand it. All major implementations have always
+ generated permanently-unique message IDs by
+ design, but in some cases this is sensitive to
+ proper administration, and duplicates may have
+ occurred by accident.
+
+ NOTE: The most popular method of generating local
+ parts is to use the date and time, plus some way
+ of distinguishing between simultaneous postings on
+ the same host (e.g. a process number), and encode
+ them in a suitably-restricted alphabet. An older
+ but now less-popular alternative is to use a
+ sequence number, incremented each time the host
+ generates a new message ID; this is workable, but
+ requires careful design to cope properly with
+ simultaneous posting attempts, and is not as
+ robust in the presence of crashes and other mal-
+ functions.
+
+ NOTE: Some buggy news software considers message
+ IDs completely case-insensitive, hence the advice
+ to avoid relying on case distinctions. The
+ restrictions placed on the "alphabet" of local
+ parts and domains in section 5.2 have the useful
+ side effect of making it unnecessary to parse mes-
+ sage IDs in complex ways to break them into case-
+ sensitive and case-insensitive portions.
+
+The local part of a message ID MUST not be "postmaster" or
+any other string that would compare equal to "postmaster" in
+a case-insensitive comparison. Message IDs MUST be no
+longer than 250 octets, including the "<" and ">".
+
+ NOTE: "Postmaster" is an irksome exception to
+ case-sensitivity in local parts, inherited from
+ MAIL, and simply avoiding it is the best way to
+ deal with it (not that it's likely, but the issue
+ needs to be dealt with). The length limit is
+ undesirable, but is present in widely-used exist-
+ ing software. The limit is actually 255, but a
+
+INTERNET DRAFT to be NEWS sec. 5.3
+
+
+ small safety margin is wise.