--On Thursday, 08 September, 2005 16:00 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
On Thu, 8 Sep 2005, John C Klensin wrote:
Now, for this case, I am personally pretty rigid: if the
mailing list exploder starts messing with (including
inserting) non-envelope (i.e., as things are now defined,
non-trace) headers (or body information), it is performing an
MUA-level function and is hence not an MTA-level exploder at
all. [...]
But 2369 could have been written, or could now be updated, to
designate the List-* headers as trace fields to be inserted
by an MTA-level exploder.
Is 2822bis going to make the set of trace fields extensible so
that this would be possible?
Tony,
There is no magic here. Could 2821bis and 2822bis be rewritten
to permit this sort of thing? Yes. Is it going to happen by
magic? No -- someone would need to write a real proposal, which
the more or less offhand comment above certainly is not.
And then we would need to ask whether, if we need to tamper with
the envelope/header boundary in a major way, whether it is time
to actually change the model and the implementation to separate
them, as discussed in the long-expired
draft-klensin-email-envelope-00. My guess is that the answer is
"no", but I'd think the question would need to be asked in a
serious way.
john
RFCs 3864 and 4021 would probably
have to be updated so that the IANA registry documents the
trace/non-trace distinction.
Tony.