ietf-smtp
[Top] [All Lists]

Re: "Header Reordering", yet again

2005-05-27 08:02:30

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?

It depends on what you mean by "reorder". If you mean change the relative order
of fields of the same type, I don't believe I've ever seen that. I have,
however, seen lots of cases where headers, including trace headers, are
stripped of information or outright removed, usually due to fairly bogus
concerns about hiding details of network configurations, standards statements
to the contrary notwithstanding.

Reordering fields of different types relative to each other is another matter.
Our MTA does this routinely - the facility we provide for this is heavily used.
The reason is that there are lots of things out there which are order-sensitive
in one way or another. Of course these things are broken, but when we're
talking about breakage in very popular systems saying they should behave this
way is a waste of time.

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

The real world isn't this simple, and pretending otherwise isn't going to
change it.

                                Ned


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