John Leslie wrote:
[trace header fields]
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.)
Received-SPF tests the water. In a similar direction go
Authentication-Results and William's Original-* draft:
draft-leibzon-emailredirection-traceheaders-01
I don't think that we need any _new_ flamewar about this,
if something shuffles header fields it's either broken
or a _real_ gateway (without checking: maybe RfC 2156).
Wannabe-gateways - "what I do is not really illegal because
gatways are allowed to do almost anything" - don't count.
I don't see why 2821bis should be the place to discuss more
details of other trace header fields, that could be done in
a separate document - for 2821bis we only need two pieces:
1 - the "mail data" or "SMTP content" MUST have a header,
minimally CRLF CRLF, a relay adding its timestamp isn't
forced to check / create this.
2 - by adding whatever other trace header fields a relay
is not automagically a gateway.
John's point that the latter might confuse simple antispam
scripts is no 2821bis (SMTP) problem.
We have designed an email system for a network of
trustworthy machines; and this model (of trust) has long
since failed.
+1 Maybe we should move the fine points of this tragedy
(source routes, what they meant, why they were dropped,
etc.) to a separate document, i.e. go from "MUST accept
but SHOULD ignore" to a "MUST accept and MUST ignore" in
the core document (2821bis).
The separate document could contain appendices C and F.2
(incl. the attempt to fix a typo in 821). Just an idea.
(Flame away!)
Not at this point... ;-) For 2821bis I'd like to have it
clear that the MAIL FROM does not always reflect another
address in the header.
But it's still normally an address on the route from the
mail originator to the RCPT TO, assuming that the reverse
route is just the opposite direction.
Where that's not the case the SMTP originator or forwarder
(new RCPT TO third party) must be very careful.
So far I think that John's model...
| if there is general agreement with that model, we should
| proceed to clarify 2821bis, as needed, to match
...is good enough for 2821bis, the controversional point
in (v) could result in (v.a) vs. (v.b), like 1123 5.3.6.
Bye, Frank