ietf-822
[Top] [All Lists]

Re: a header authentication scheme

2004-10-28 07:59:38

On Wed October 27 2004 21:19, Laird Breyer wrote:

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.

No.  If they send spam, they are not trustworthy. If they run an
"operating" system with multiple known security vulnerabilities
without a properly-configured external firewall, they are not
trustworthy.

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).

Knowledge of precisely who sent it is a necessary part of a
remedy. [and applies regardless of the specific remedy; whether
e.g. that involves removal of a "virus" or disconnection of the
machine from the Internet or both]
 
If you want to restrict yourself to non-clueless users, then how do
you verify that a person sending you mail isn't clueless?

For a person known to me?  That's a judgment call.

And will you 
blacklist the others?

If the offense is repeated, yes.
 
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. 

That user *is* the spammer -- his machine(s), running software that
he has installed and which is under his administrative control, is the
source of the spam, and the machine(s) involved is/are the ones
that need to be disconnected from the internet to curtail the
problem.

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?"

Bad premises rarely lead to reliable conclusions. Not all Received
fields are "trustworthy".  Flawed logic also rarely leads to
reliable conclusions; there is in fact no guarantee that a
"processed" field or the information that it purports to convey
cannot be forged in the presence of a valid Received field.

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, I did not say that I "don't trust that information"; I said
that there is insufficient information to make any determination.
Citing insufficient information to make a determination is *NOT*
that same as making a particular determination!

That's a straw man. None of the headers in any mail message, ever,
carry full configuration information.

No currently standardized field purports to convey any information
which requires detailed configuration information to be able to
interpret the conveyed 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?

No need to know.  Trace field definitions (RFCs 821, 2821) are
generally clear about what is supposed to appear in those trace
fields; Received fields document the client host name as specified
in the SMTP session HELO or EHLO command, the host name of
the host adding the field, a time stamp in standard format, and
optionally some additional information, most of which is well-defined
(and none of which is essential).  Return-Path documents the sender
envelope address.  No MTA-specific configuration alters or in any
way affects the client's argument to the HELO/EHLO command,
for example.

But you (or anybody) still routinely make decisions based on the
unreliable information written by the above programs.

No, trace fields are examined in rare cases, not routinely.
The specific information in those fields documents facts
about a particular SMTP session (client-supplied identification,
etc.); it does not purport to make a value judgment about
the message content.

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.

Ultimately a human is responsible for setting recipient addresses
and Reply-To fields; they are set by a human user, either directly
or by configuration of an MUA acting on his behalf and for which
he bears responsibility (and for which no recipient needs any
configuration information).  In cases where Reply-To has been
(inappropriately) set by autonomous agents (e.g. misconfigured
list expanders), problems have resulted.

Your proposed "processed" field differs from all of the above;
unlike Return-Path and Received trace fields, its content is
not well-defined.  Unlike Reply-To, it is not set by a human user.
Unlike all of the above, it purports to convey information,
including a value judgment, which is unusable without
additional detailed information which it does not convey.