From: Jacob Palme (email@example.com)
Date: Thu Jul 16 1998 - 06:20:09 CDT
A new version of the draft about the Auto-Submitted,
Supersedes and Expires headers is now available. You can
find it at
and, in some days, probably in the IETF drafts directories.
Warning: The IETF secretariat may choose to rename this draft
to something starting with "draft-palme" since the mailext group
is not operative any more.
Changes since version 12:
The syntax for parameters to the Auto-Submitted header is better
The list of examples in section 3.5.1 have been extended with more
The text about the Supersedes header (4.2.2 to 4.2.3) has been modified
to more clearly indicate when soft and hard supersedes are to be
implemented and to reflect current usage.
The text about the Supersedes header (4.2.1) has been modified to more
clearly show who are allowed to issue superseding messages.
Specify that use of digital signatures may be required for Supersedes
messages, but not specify the algorithm to be used for such signatures.
These revisions have been made to accomodate wishes in the Usefor group.
There has been a long discussion, in that group, about requiring
digital signatures for Supersedes and Cancel. To solve all those problems
would unnecessary delay this standard.
Here is the new text of the major rewritten sections:
3.5 Fuller semantics with examples (for auto-submitted)
3.5.1 Syntax examples without private extensions:
Example 1: Auto-Submitted: auto-generated
Example 2: Auto-Submitted: auto-replied
Example 3: Auto-Submitted: no
Example 4: Auto-Submitted: auto-generated; increment=21600
Example 5: Auto-Submitted: (weather-report) auto-generated;
(issued every 6 hours) increment=21600
3.5.2 Possible syntax examples with private or future extensions:
Example 6: Auto-Submitted: x-ibm-transaction
Example 7: Auto-Submitted: auto-replied ; bounced
Example 8: Auto-Submitted: auto-replied ; x-count=8
4.2 Semantics (of Supersedes)
The Supersedes header identifies previous correspondence, which this
message supersedes. Different messaging agents such as user agents,
mailing list expanders, mailing list archives and Usenet News servers
may handle the Supersedes header. A user agent is expected to handle
this field in much the same way as the In-Reply-To and References
Note: The Message-ID of a superseding message MUST be different from the
Message-ID of the superseded message. The Message-ID of the superseded
message is used as value in the "Supersedes:" header, not in the
Message-ID of the superseding message.
4.2.1 Who may supersede a message/article?
Agents receiving superseding messages may ignore, or issue a warning, if
the Supersedes header, if the author of the message is not approved.
Approved authors of superseding messages are:
(1) The author of the message being superseded.
(2) For moderated newsgroups and mailing lists, the moderator. Note that
a moderator may only supersede messages/articles in groups, for
which the moderator is responsible, and such a moderator SHOULD not
send superseding messages/articles to other groups.
(3) Other users given the authority to supersede messages. Such
authority is often local to one particular server only.
An agent may ignore or issue a warning for Supersedes headers if the
Superseding message does not have a digital signature of its author.
Digital signatures are separately standardized (like SMIME  and PGP
 or other standards for digital signatures) and their format and
semantics are not specified in this standard.
4.2.2 Semantic variant 1: Soft supersedes
(a) With soft supersedes this header does not imply any mandatory
deletion of the previous correspondence in mailboxes and user
(b) Agents which provide user commands for getting from a reply to
the replied-to message (or for getting from a replied-to message to
its replies), MAY provide similar commands for getting from a
superseding message to the superseded message (or for getting from a
superseded message to its superseding version).
(c) Agents MAY normally show the recipient both the previous and
the superseding message. If, however, both the previous and the
superseding message have arrived, both having the same author, but
the user has not yet seen either of them, a user agent MAY show only
the superseding message, but also show the supersedes-field to
inform the recipient that this message supersedes a previous
4.2.3 Semantic variant 2: Hard supersedes
With hard supersedes, the arrival of a superseding message or article
will cause the deletion of the superseded message. The new message will
however still have a new Message-ID and will not take over the Message-
ID of the superseded message/article.
4.2.4 When to use soft and hard supersedes
Personal mailboxes and personal message stores SHOULD implement soft
supersedes. Usenet News servers and multi-user message archives MAY
implement HARD supersedes.
If the handler of a message/article storage has a mechanism for
automatic purging of old messages, the fact that there is a superseding
message may be a component in the decision of when to purge the previous
4.2.5 Multiple field values
When this is written (1998) some netnews softwares (servers and clients)
cannot handle Supersedes with more than one previous articles listed as
parameters. They usually ignore the Supersedes header in this case, and
treats the new article as a separate article, not related to the
superseded article. Implementors of netnews softwares SHOULD modify
their software to be able to handle Supersedes with more than one
previous article as parameter, but for some time, many softwares may not
be able to handle Supersedes with more than one parameter. A gateway
from e-mail to news MAY because of this delete all but the first
parameter of this attribute when conveying messages from e-mail to news,
BUT such a practice should be temporary only for one or two years until
news softwares have been modified.
Jacob Palme <firstname.lastname@example.org> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Temporary summer phone No. +46-8-664 77 48 not +46-8-16 16 67