> The problem is the language is ambiguous at best as to whether it covers
> relative ordering of two different fields. It is also unclear as to whether
> new fields can be added to the set of trace fields willy-nilly.
I don't know what could be more clear than:
'''header fields SHOULD NOT be reordered when a message is transported or
transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message.
''' RFC-2821, section 3.6.
Well, let's see. It uses "SHOULD NOT" rather than "MUST NOT", which means you
cannot count on reordering not happening. And the statement that trace and
resent fields MUST NOT be reordered doesn't make it clear whether the
reordering is amongst themselves or relative to other fields. Finally, it is
far from clear that additional trace fields like received-SPF can be added to
the set after the fact. This means that received-SPF has to be thought of
as a non-trace field, which puts its order relative to received fields
in jeopardy.
New header lines *have* been added with no apparent breakage. Almost every
email I see has lines like:
This is a strawman. Nobody is claiming that new fields cannot be added. Of
course they can be. The issue is whether or not new fields can be added along
with guarantees that their ordering relative to existing fields be preserved.
The language in the specifications simply doesn't stretch that far.
A new authentication header would be ignored by old systems, and for new
systems, we can require that it have a particular position, at the boundary
of an administrative domain.
Sure, you could make such a rule, although good luck on getting it through the
process. But you cannot call for old systems to honor it, and the majority of
systems will be old ones for a very long time.
> But as I have said before, you are insisting on pursuing a specific
> problematic solution despite the fact that there are other ways to
> deal with this that don't open this particular door.
I haven't proposed a solution.
You haven't, but others have: A solution involving a new Received-SPF
field.
This thread started with Bruce Lilly's
statement that we could not depend on header order.
Unfortunately, he's right.
> Valdis Kletnieks already
> pointed out that SPF information could be piggybacked on existing Received:
> fields. I have yet to see an agent that reorders Received: fields. I have
> seen agents modify or drop Received: fields, but this behavior seems to be
> fairly disjoint from the sorts of forwarders where we want order to be
> preserved.
Well, this is encouraging. Maybe we can at least count on Public Mail
Servers acting as forwarders on the open Internet to not screw with
existing headers.
For the Nth time, you cannot count on any such thing. Your expectations have
to be more limited.
Perhaps you could clarify your earlier example of "large
ISPs with millions of customers". Which ISPs are you talking about? Are
they acting as forwarders, or final destination receivers?
Both.
> It is all a question of using the right mechanism and having realistic
> expectations.
Agreed. My expectations are:
1) Spammers can't mess with headers prepended after the email is out of
their domain.
Hopefully true.
2) Trusted forwarders will follow the RFC-2821 requirements.
Which don't include the guarantees you seem to think they do.
3) Authentication headers added by a Trusted Forwarder will not break
downstream MTA's.
Also hopefully true.
4) Header reordering will occur only before the first Trusted Forwarder, or
after authentication at the final destination.
Again, it depends on the sort of reordering you're talking about,
Ned