Re: "Header Reordering", yet again

> At 08:05 PM 5/27/2005 -0400, Bruce Lilly wrote:
> >On Fri May 27 2005 18:49, David MacQuigg wrote:
> >
> > > We don't expect every sender to be
> > > compliant, just the ones that want to be trusted as Public Mail
> > > Servers.  This may be a small number at first.  Then others will discover
> > > the benefits of becoming compliant - bypass the spam filtering.
> >
> >Past experience with SPF indicates that spammers -- who have financial
> >incentive -- will be early adopters, and legitimate mailers who don't
> >conform to your preconceived notions will be harmed.  The spammers
> >will claim that because they comply with your scheme, they aren't
> >really spammers at all.  The scheme -- like SPF -- would be doubly
> >harmful.
> We seem to be losing context again.  The question is whether we can specify
> that Trusted Forwarders MUST NOT reorder trace headers, using the same
> language as the words from RFC-2822 that you snipped.
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.

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. 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.

It is all a question of using the right mechanism and having realistic
expectations.

                                Ned