--On Monday, 14 March, 2005 12:29 +0000 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
On Mon, 14 Mar 2005, John C Klensin wrote:
And like X.400. And, to a limited extent (motivated by trying
to maintain compatibility), like
draft-klensin-email-envelope-00.
It appears to continue the mistake of not allowing extensions
to the trace field syntax and semantics - though the draft
doesn't clearly define the contents of the ENVL .
Again, it was a deliberately half-baked draft that was posted in
a specific context. If there were any interest in going in that
direction --and my belief at this point is that there is not--
then all sorts of refinements are possible and should be
discussed. One of them is clearly a review of what should be in
the trace fields.
Unless there is evidence to refute that conclusion, or at
least a more persuasive draft, the discussion about getting
headers into the envelope is probably a waste of time. In
other words, from my point of view at least, this would be a
good idea, and we could do it --although certainly not
overnight. We just do not, in practice, care.
I think a simpler approach to this problem would be to
encourage sites to append locally defined trace information
(e.g. anti-spam scores) to the start of the header instead of
the end, so that it appears interleaved with the Received:
fields. This makes it much clearer when a field was added. A
fair amount of software already does this, e.g. Delivered-To:
and X-Sieve: fields. It also happens to agree with the logic
of DomainKeys signatures :-)
As pointed out earlier, doing this risks getting a much higher
spam probability score from software that doesn't know about
your particular new headers and hence treats them as evidence of
header-tampering. You will have to determine whether it is
worth it on balance, but, for me, keeping Internet mail globally
interoperable is even more important than techniques that will
provide a delta in the amount of spam.
The advantages of separating MTA-provided in-transit information
from message body ("header") information are pretty obvious. To
move that way, we would then need to address the question of
balancing ease of converting to and from the new mechanism and
format against additional power and flexibility from new
formats. The draft is too preliminary to seriously address
those questions; if someone else feels that the special envelope
plan is worth pursuing, feel free.
john