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