[Top] [All Lists]

Re: "Header Reordering", yet again

2005-05-28 10:17:52

Ned, I like the tone of this response much better than your last. It's OK to disagree, let's just avoid calling each other idiots.

At 09:13 AM 5/28/2005 -0700, Ned Freed wrote:
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

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.

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.

New header lines *have* been added with no apparent breakage. Almost every email I see has lines like:
X-Persona: <yahoo>
X-Apparently-To: david_macquigg(_at_)xyahoo(_dot_)com via; Sat, 28 May 2005 09:33:48 -0700
Authentication-Results:; domainkeys=neutral (no sig)
X-Originating-IP: []
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed

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.

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. This thread started with Bruce Lilly's statement that we could not depend on header order. The last time we had this discussion, the thread dissolved in noise before reaching a conclusion. I'm attempting to keep this thread on track.

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

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

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

Agreed.  My expectations are:
1) Spammers can't mess with headers prepended after the email is out of their domain.
2) Trusted forwarders will follow the RFC-2821 requirements.
3) Authentication headers added by a Trusted Forwarder will not break downstream MTA's. 4) Header reordering will occur only before the first Trusted Forwarder, or after authentication at the final destination.

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

<Prev in Thread] Current Thread [Next in Thread>