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 *
************************************************************ *
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: "Header Reordering", yet again, (continued)
- Re: "Header Reordering", yet again, Bruce Lilly
- Re: "Header Reordering", yet again, ned+ietf-smtp
- Re: "Header Reordering", yet again, Frank Ellermann
- Re: "Header Reordering", yet again, Paul Smith
- Re: "Header Reordering", yet again, Hector Santos
- Re: "Header Reordering", yet again, Paul Smith
- Re: "Header Reordering", yet again,
David MacQuigg <=
- Re: "Header Reordering", yet again, Bruce Lilly
- Re: "Header Reordering", yet again, David MacQuigg
- Re: "Header Reordering", yet again, Bruce Lilly
- Is it really FUD? [Re: "Header Reordering", yet again], Hector Santos
- Re: "Header Reordering", yet again, Hector Santos
- Re: "Header Reordering", yet again, Hector Santos
- Re: "Header Reordering", yet again, Hector Santos
- Re: "Header Reordering", yet again, Valdis . Kletnieks
- Re: "Header Reordering", yet again, Frank Ellermann
- Re: "Header Reordering", yet again, Hector Santos
|
|
|