On Oct 27 2004, Bruce Lilly wrote:
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
I think you underestimate the problem. Building and maintaining a
public key infrastructure, offering verification and revocation
facilities, making sure that all programs that need it have access to
it, setting up central internet wide root authorities acceptable to
all, keeping complex authority hierarchies up to date, reloving
conflicts...
PGP between two people who exchange public keys on a diskette is one
thing, PGP for ubiquitous use by mail transport systems and associated
filtering and viewing progams, even if it is only within a large
organization, is a heavyweight administration problem.
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.
I doubt that. The current trend is well on its way to the following
model: ordinary, trustworthy people send spam to strangers without
knowing it. How does authentication help in that model? You'll know
*who* sent the spam, but you can't stop them all (for if you did, you
will have solved a good part of the virus problem).
If you want to restrict yourself to non-clueless users, then how do
you verify that a person sending you mail isn't clueless? And will you
blacklist the others?
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.
I don't see why it should. A trojan on a Windows box has access to
both the system API, if it wants to send mail programmatically, and
also access to the GUI by simulating mouse and keypresses. Together,
these two methods can bypass most protections, ie anything a user can
do a trojan can do, too.
So in particular it can sign its messages with the user's private key
if the user has one. Then you could trace the spam back to the user
and that's it.
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.
The method proposed is not an oracle. It doesn't give a truth value
to the proposition "is the Processed field trustworthy?", instead
it gives a truth value to the proposition "given that the Received
line is trustworthy, is the Processed field trustworthy?"
With the latter proposition, you have full control, on a case by case
basis, over which Received lines you want to trust, and consequently
which Processed lines you can trust. How could this be improved?
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.
That is an excellent answer. The MUA told you it found a
piece of information you might wish to use, and you told it
that you don't trust that information. Mission accomplished!
No, because it doesn't provide configuration information.
That's a straw man. None of the headers in any mail message, ever,
carry full configuration information. Do you or any recipient know how
exim or Postfix were configured when they added their trace fields to
transported messages? How about the sender's MUA configuration when the
message was composed?
But you (or anybody) still routinely make decisions based on the
unreliable information written by the above programs. For example, you
decide to read messages addressed to you, you decide to reply to the
mailbox listed in a Reply-To fields etc. even though you have no idea
what configuration the software which created those fields was in.
--
Laird Breyer.