Re: a header authentication scheme

On Mon October 25 2004 23:37, Laird Breyer wrote:

> The problem with full MIME authentication is that we don't have the
> trust networks and ubiquitous public key infrastructures this would need,
> so in practice authentication would simply not be used.
PGP/MIME requires very little.  And authentication can be
a useful tool to fight spam. If i receive an authenticated
message from a known party who isn't clueless, I can be
sure that it isn't spam. If I receive an unauthenticated
message claiming to be from a known party that always
sends signed messages, it's almost certainly spam. If I
receive a signed message that fails signature validation,
I can be fairly confident that it's a forgery. If I receive a
signed message with a valid signature that turns out to
be spam, the credentials associated with the signature
may provide a means of identifying the spammer.

> If you can verify that the header was added after the message went
> through a certain machine, and if you trust your system admin when
> he says he's got SpamAssassin in vanilla configuration along that 
> segment of the message path, then you can trust the header.
He's not necessarily *my* "system admin"!  Or *any* "system
admin". He may in fact be a spammer who has forged Received
fields and your "Processed" field.  I would have to know a great
deal about that "certain machine", and I would require much
stronger authentication than what you're indicating to be certain
that the message in fact "went through" that "certain machine"
and is not simply a message with a few easily-forged fields.

> In a futuristic MUA, you would get a message stating: "I detected
> a filter called SpamAssassin which operates inside the third hop
> from the end, would you like me to use its recommendation?"
My answer would have to be that I cannot make that
determination without knowing details of the configuration
and run-time options, and without knowing exactly what
site is meant by "the third hop from the end" and without a
considerable amount of effort to determine if that site is in
fact what is claimed, and unless I can verify that that site
in fact added the fields that have been claimed to have been
added there, and unless I have absolute trust in that site.
 
> > I have no idea what configuration files were used with it or
> > what run-time options were specified.  In short, purported results
> > of an indeterminate process with indeterminate configuration
> > and indeterminate run-time parameters allegedly run at a
> > remote site are of little value.
> That's the trouble we have today and why a standard filtering header
> (such as the Processed example I ued) would help.
No, because it doesn't provide configuration information.
And I don't really want 400 kB of configuration files added
to a 500 byte message.  Also "no" because it doesn't provide
information about run-time environment and options. Again
"no" because there is no guarantee that any claimed test was
actually performed. Yet again "no" because there is no
guarantee that the claimed results were in fact obtained. And
"no" once more because there is no guarantee that the claims
were inserted by the site where it has been asserted that those
claims have been inserted.  On top of which is a hesitant "maybe"
which is contingent on a great deal of knowledge about remote
sites and their administrative staff.

pgpv5H4EM82K3.pgp
Description: PGP signature