It appears that Bron Gondwana <[email protected]> said:
>-=-=-=-=-=-
>
>I'll be raising the "which headers are Trace headers precisely". Once I can
>publish my "email header registry maintenance"
>draft, it'll say:
>
> * "VBR-Info" (mail), [RFC5518], Section 2: "in the terminology of
> RFC 5322, VBR-Info is a 'trace header field'".
Shoulda remembered that one since I wrote it.
> * "Path" (netnews), [NETNEWS-FMT] Section 3.1.5 and [NETNEWS-ARCH]:
> each processing agent prepends to the field, its order is
> significant, and [NETNEWS-ARCH] names it a trace header field
> alongside "Received" ("trace header fields (like Received in Email
> or Path in Netnews)").
A netnews article only has one Path: header, and each hop edits that
header to add its name to the existing header. Nobody to my knowledge
has ever DKIM signed netnews articles other than accidentally when
they come through a mail gateway, but I suppose there's no reason to
forbid it.
> * "Injection-Info" (netnews), [NETNEWS-FMT] Section 3.2.8: it is
> added only by the injecting agent and exists to assist "in tracing
> the article's true origin"; [NETNEWS-ARCH] classes it as trace
> information.
If you're going to add Injection-Info, you should also add Injection-Date,
usually added at the same time.
> * "X400-Trace" and "DL-Expansion-History" (mail), [RFC4021]:
> registered with descriptions that are, respectively, "X400 Trace"
> and "Trace of distribution lists passed"; both derive from the
> X.400 per-hop trace elements of [RFC2156].
Man, there's a stab from the distant past.
>5.2. Fields that behave as trace fields without the label
>
> The following fields are added by handling agents in transit, at a
> defined position, with ordering significance, but their defining
> documents do not use the word "trace". Whether the Trace column
> should be "yes" for these depends on whether IANA reads the column in
> the strict sense of [MAIL] Section 3.6.7 or in the broader
> "designated by the defining document" sense used in Section 5.1.
> This document recommends "yes" and records the evidence so that IANA
> can decide with the facts in hand.
>
> * "ARC-Seal", "ARC-Message-Signature", "ARC-Authentication-Results"
> (mail), [ARC]: added by participating domains as the message
> transits, with "i=" instance tags that encode the order of
> handling ("chain of custody").
>
> * "Delivered-To" (mail, provisional), [RFC9228] Section 4: "MUST be
> placed at the current 'top' of the message's set of header fields
> ... in a fashion similar to the trace fields", and "MUST NOT be
> reordered".
>
> * "Original-Recipient" (mail), [RFC3798] Section 2.3: inserted by
> the delivering MTA "at the beginning of the message (along with
> the Return-Path header)".
How do we feel about Resent-* headers? They're trace headers in everything
but name.
R's,
John
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
