Re: "Header Reordering", yet again

At 01:05 PM 5/23/2005 -0400, Bruce Lilly wrote:
> On Mon May 23 2005 10:30, John Leslie wrote:
> > wayne <wayne(_at_)schlitt(_dot_)net> wrote:
> > >
> > > http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
> >
> > which includes:
> [...]
> > ]  The Received-SPF header is a trace field (see [RFC2822] section
> > ]  3.6.7) and SHOULD be prepended to existing headers, above the
> > ]  Received: header that is generated by the SMTP receiver.  It MUST
> > ]  appear above any other Received-SPF headers in the message.
> >
> > This is a very interesting idea, with some promise of enabling a
> > chain of trust.
>
> Except for a few inconvenient facts:
> a) "It is important to note that the header fields are not guaranteed to
>    be in a particular order.  They may appear in any order, and they
>    have been known to be reordered occasionally when transported over
>    the Internet." RFC 2822, section 3.6
Here is the complete quote:
   """It is important to note that the header fields are not guaranteed to
   be in a particular order.  They may appear in any order, and they
   have been known to be reordered occasionally when transported over
   the Internet.  However, for the purposes of this standard, 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.  See sections 3.6.6 and 3.6.7 for more
   information."""  RFC-2822, section 3.6.

Furthermore:
   """When an SMTP server receives a message for delivery or further
   processing, it MUST insert trace ("time stamp" or "Received")
   information at the beginning of the message content, as discussed in
   section 4.1.1.4.

      <snip definition of line structure>

   An Internet mail program MUST NOT change a Received: line that was
   previously added to the message header.  SMTP servers MUST prepend
   Received lines to messages; they MUST NOT change the order of
   existing lines or insert Received lines in any other location.
   """  RFC-2821, section 4.4 Trace Information.

Seems to me any MTA that re-orders trace headers ought to be in category D 
- one notch below open relays.  They certainly won't be in my trust zone, 
and I don't see any way they can re-order headers above their last one.
Can you give us an example of any forwarder that re-orders headers?  Other 
than hiding spammers, what would be the motive?
> b) it's easy to write "is a trace field", but that won't cause existing
>    deployed MTAs to treat it any differently from any random extension
>    field.
Legitimate MTAs should leave existing headers alone.  Only the final MTA 
will be looking at the trace headers to determine the border MTA (the MTA 
on first entry to our trust zone).  The border MTA will attempt to 
authenticate the prior hop, and before that, we don't care.
--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *