At 11:15 AM 5/27/2005 -0400, Bruce Lilly wrote:
>On Fri May 27 2005 10:09, David MacQuigg wrote:
> > At 01:05 PM 5/23/2005 -0400, Bruce Lilly wrote:
>
> > >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:
>
>That doesn't change the fact that there is no guarantee, and that any
>assumption of a particular order is flawed.
If we expect a guarantee, then no authentication method will work, not even
signatures.
Nonsense. Authentication schemes are possible that don't depend on header
ordering being preserved through multiple hops. Or, to put it another way,
there are enough guarantees in place that workable solutions can be found. The
problem is people persist in either trying to promote stuff that's effectively
unworkable or they try to push workable stuff to the point where it becomes
unworkable.
There will always be systems that don't comply with any standard.
But that's precisely the point: These systems DO comply with what's currently
standardized. You want to change what's standardized after the fact to fit your
preconcieved notions of how things are supposed to work.
The key question is can we expect enough compliance that
authentication will be useful? We don't expect every sender to be
compliant, just the ones that want to be trusted as Public Mail
Servers. This may be a small number at first. Then others will discover
the benefits of becoming compliant - bypass the spam filtering.
The systems I'm talking about tend to be one run by large ISPs with
millions of customers.
Ned