Re: Last Call: draft-resnick-2822upd (Internet Message Format) to Draft Standard

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf