Brian E Carpenter wrote:
My underlying concern is that 2822upd should not appear
ridiculous to anyone who looks at a typical mail header
and sees the X-headers.
2822upd specifies only about twenty mail header fields.
The rest is either registered and specified elsewhere,
or to some degree "unknown" (unregistered, unspecified,
proprietary, private use, experimental, spam, and so on).
John's message reached me with X-Original-To,
A draft about Original-* didn't make it so far, it could
be classified as "could be specified if folks go to the
trouble to try it". IMO it's no bug in 2822upd if nobody
tries it. RFC 3864 would have to be updated for generic
Original-* registrations.
X-Virus-Scanned, X-Spam-Flag, X-Spam-Score, X-Spam-Level,
X-Spam-Status,
Hopefully these header fields are specified in the manual
of anti-spam tools used by MTAs on your side. There are
only two new and specified trace header fields since SMTP
was invented so far. IMO the 2822upd section about trace
header fields was improved.
A draft Authentication-Results header field specification
exists, as next step to tackle this zoo of "private use"
header fields. Two years ago we had no precedence of ever
introducing new trace header fields - carefully extracting
one good thing I can say about the 1st new trace field. ;-)
X-Mailer
An RFC introducing the known HTTP User-Agent also for news
was approved. From there it's in theory straight forward
to adopt it also in mail. Adding a User-Agent to 2822upd
would be sneaky, 2822upd is intended for DS, User-Agent in
mail was never published in a PS.
X-BeenThere
That's a really interesting beast, claiming that it's only
"private use" would miss the point, and specifying it as
"BeenThere" without X- prefix could have disadvantages.
X-Mailman-Version
In the direction of User-Agent and tracing. It's hard to
define what constitutes "potential useful info", and the
security / privacy / I18N considerations for header fields
can be also rather tricky. Maybe an informative reference
to RFC 4249 in 2822upd would be good.
Leaving this completely undocumented harms the relevance
of the standard.
The RFC 3864 reference in 2822upd is informative, would a
normative reference help for your conerns ?
Frank
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf