John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
--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.
I don't think it's that simple. 2369, IMHO, intentionally avoids
the question of whether a mailing list exploder "is" a gateway or
"is" the sender of a new message.
Is 2822bis going to make the set of trace fields extensible so
that this would be possible?
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.
Agreed.
I think the issue is important enough that I'm willing to write
a real proposal. But I don't think we're ready to discuss any real
proposal yet.
First, IMHO, we need to have a ritual flame-war about the terrible
things that will happen if another trace field should ever be defined.
(I issued an invitation to that flame-war a while back, but nobody
came.)
Second, some of us would have to accept the idea of less ambiguity
whenever the word "envelope" is used. I recognize how precious this
ambiguity is to several folks. I'm not confident I can offer them
sufficient compensation for the loss...
But I will admit to a long-standing belief that expansion of trace
headers, if evil, is a necessary evil.
There are various transient events which may occur during the time
a message is in transit via SMTP. If not recorded, it is likely to
be impossible to determine them later. We are ill-advised to prohibit
recording them in a useful way.
The ease with which MAIL-FROM addresses are being forged suggests
that our whole model of these being a fully-sufficient substitute
for SMTP-time errors has failed. One possible work-around would be
to expand the SMTP-error window beyond the point at which the DATA
command is accepted. I'm not ready to propose such a solution, but
again, we are ill-advised to prohibit one.
We have designed an email system for a network of trustworthy
machines; and this model (of trust) has long since failed. Trust,
IMHO, while never fully transitive, can be partly transitive: thus
a SMTP server could decide whether to trust the client talking to
it to some degree. But without recording the basis for that trust,
the next SMTP server along the way cannot decide how to interpret
it. We are ill-advised to prohibit recording the basis of trust.
Et cetera.
(Flame away!)
--
John Leslie <john(_at_)jlc(_dot_)net>