--On Saturday, 05 April, 2008 17:29 +0200 Frank Ellermann
<nobody@xxxxxxxxxxxxxxxxx> wrote:
> Brian E Carpenter wrote:
>
>...
>> 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.
This is precisely the reason why, although I think the sort of
text I suggested would be useful, I don't think we should go
much further down that path. Most of these fields would be
reasonable candidates for the "private use" category -- they are
used to communicate between what SMTP sees as the final delivery
MTA and the message store and/or receiving MUA (either
server-side or client-side in split MUA models). If one tried
to define "private use" (and I suggest that we do not) part of
the process would involve asking the question "could this be
standardized in 2821* or used-on-the-Internet-wire-2822*". For
these things that communicate among modules on the far side of
the final delivery MTA, the answer is that any standardization
would have to occur in IMAP or POP, or in the never-defined
message store standard, but not in SMTP. Maybe LTMP, used as a
message store protocol, changes that and maybe it does not (the
fact that it is Informational and not standards-track doesn't
help), but you see where this line of reasoning is headed.
And, speaking personally, I don't care whether private use
headers use non-X field names and are registered. What I want
to push back against is (i) intentional use of X-headers for
non-private-use applications and (ii) anything (including (i))
that would create a requirement (or strong reason) to register
anything starting with "X-".
In any event, sorting out those special-use header fields is not
a problem for 2822bis.
>...
>> 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 ?
IMO, probably not. More important, I'd really object to
standardizing a version specification for a single type of
redistribution software. If this is needed at all, it should
probably be turned into something like
List-Exploder: <name>, <version>
and that, of course, would be part of a different spec entirely.
john
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf