ietf-smtp
[Top] [All Lists]

Re: "Header Reordering", yet again

2005-05-31 09:34:20

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