Re: Limiting the amount of msg-ids in the References header

Jan Kundrát <[email protected]> writes:

> Hi,

> it seems to me that according to RFC5322 [1], I should never remove the
> earliest message-ids from the References header when producing
> responses. Therefore the References header is supposed to grow
> indefinitely when people keep replying to old messages.

> Is that really the suggested behavior? Shouldn't I use only something
> like twenty most recent msg-ids found in my parent's References?

This is something that email historically hasn't been as sensitive to
since so many email clients don't preserve References at all, don't
thread, or otherwise don't really use this part of the protocol.  It's
been an issue on Usenet, where use of References is far more universal and
is almost always included in databases of metadata that shouldn't grow
without bound, for much longer.  Therefore, the Usenet RFC offers some
specific advice on this topic, which I think is also reasonable advice for
email clients (RFC 5322 nonwithstanding).  RFC 5537 section 3.4.4:

   The following procedure is to be used whenever some previous article
   (the "parent") is to be referred to in the References header field of
   a new article, whether because the new article is a followup and the
   parent is its precursor or for some other reason.

   The content of the new article's References header field MUST be
   formed from the content of the parent's References header field if
   present, followed by the content of the Message-ID header field of
   the parent.  If the parent had a References header, FWS as defined in
   [RFC5536] MUST be added between its content and the Message-ID header
   field content.

   If the resulting References header field would, after unfolding,
   exceed 998 characters in length (including its field name but not the
   final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
   Trimming means removing any number of message identifiers from its
   content, except that the first message identifier and the last two
   MUST NOT be removed.

   An essential property of the References header field, guaranteed by
   the above procedure and REQUIRED to be maintained by any extensions
   to this protocol, is that an article MUST NOT precede one of its
   parents.

The threading algorithms in most common use will correctly cope without
noticable UI degredation with References headers that are missing some
previous message IDs but still have the first and two most recent in the
thread.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822