Re: "Header Reordering", yet again

At 03:31 PM 5/31/2005 +0100, Paul Smith wrote:
> At 14:58 31/05/2005, Hector Santos wrote:
> > From: "Paul Smith" <paul(_at_)pscs(_dot_)co(_dot_)uk>
> >
> > > >Now you might be able to sort the timestamp lines by their
> > > >timestamps, or more likely by "I know what happens behind
> > > >my MX".  Or you just use `nslookup -q=mx`.
> > >
> > > If you specified that the timestamp on the Received-SPF field MUST be
> > > IDENTICAL to the timestamp on the Received: line added by the same server,
> > > that might solve some problems.
> >
> > Good point,
> >
> > but I'm still scratching my head on this issue,  what's the problem again?
> Not entirely sure.. I've lost the start of this discussion as the subject 
> has changed a few times.. :)
http://www.imc.org/ietf-smtp/mail-archive/threads.html does a good job of 
keeping these long threads in order.
We are still on Header Reordering, I assume.  I started this sub-thread 
with the statement - 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.
I haven't heard anything sufficient to change my mind.  I would only change 
the words "legitimate MTAs" to "Trusted Forwarders".  This business of 
time-stamps seems like a digression.  If we can trust an MTA to add a 
properly synchronized time-stamp, we can trust it to not re-order headers, 
with a lot less effort and opportunity for screw up, I might add.  The 
requirement is simply - DON'T MESS WITH THE HEADERS!!
I know, the temptation to diddle the headers can be irresistible :>), but 
if we are going to change the world, we have to start somewhere.  Nothing 
will ever happen if we follow the Bruce Lilly policy - reject any proposal 
that doesn't have a guarantee that all MTAs will conform.  Even DomainKeys 
will fail that test.  There is no guarantee that some MTA, somewhere on the 
planet, won't alter the message, and DomainKeys cannot tell the difference 
between a forgery and a message altered by a non-conformant MTA.

> > Why would a downlink software assume the headers are or could be out of
> > order?  and why would it assume mediocrity exist or even allow it to be
> > used?    I mean, if a piece of software was doing this,  then you go to the
> > developer and shame them for screwing things up.  If they don't bother to
> > fix it, then you dump it and get something else.  That's how it usually
> > works.
> Unless that other developer is Microsoft or that of any other widely 
> deployed software or used by any big ISP. In that case, they are unlikely 
> to change just for you, and you'll lose customers if you do anything bad 
> because of the faulty data.
Nobody answered my challenge to provide an example of a big forwarder that 
re-orders headers, so I'm coming to the conclusion that this is FUD.

> But - we do get requests for SPF support on incoming SMTP via an ISP's 
> server, or on incoming POP3 mail. At the moment, we're reluctant to do it 
> because of the problem of knowing exactly which mail server in the trace 
> headers was the one we should be checking. This could be handled by a 
> knowledgeable user telling our software which mail server(s) were the 
> recipients' ISPs - but knowledgeable users are few and far between in our 
> market (SMEs) so you need to do it automatically, or not at all..
I agree 100% that the process of scanning headers to locate the domain to 
be rated, should be automatic, simple, and unambiguous.  A standard 
authentication header could do that.
--
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          *
************************************************************     *