ietf-822
[Top] [All Lists]

Re: a header authentication scheme

2004-10-30 12:42:29

On Thu October 28 2004 21:29, Laird Breyer wrote:

Now you're trolling ;-)

No, I'm refuting your claim that "ordinary, trustworthy people
send spam".

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]

That's a generality which is as likely true as false depending
on the problem.

No.

In fact, your mention of virus removal gives a simple 
counterexample: there is no need to know who sent a virus to be able
to remove it from an infected system.

One needs to identify the "infected system". In the specific
case of a worm or virus that result in sending of spam after
a user installs that worm or virus, stopping the spew of
spam being sent by that worm or virus requires removing
or disabling it from that "infected system" (or removing
network connections from that system).

There is also no need to know  
who sent it to be able to block it from entering other systems. 

Blocking entry to one system is not a remedy.

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.

It rarely is. The supply of clueless users is big enough that each one
need offend once only, and you'll be blacklisting day in, day out. 

The supply of clueless users known to me is quite limited.
 
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.

Ok, serious point: disconnecting the spamming computer from the internet
is not always an option. Who can disconnect the machine? The relevant ISP.
Why should the ISP do so? 

Because the activity violates the terms of service agreement between
the ISP and the user.  Because it is the ISP's costly and valuable
resources  (network bandwidth, storage space) that are being
consumed, Because the ISP will gain a bad reputation if it knowingly
harbors spammers.
 
Take a provider like AOL, and let's say 30% of its users at one time
are infected with a spam sending trojan. Are they going to cut off 30%
of their customers for the dubious benefit of making life more
pleasant for people who aren't their customers?

In the first place, you are incorrectly assuming that an AOL
user who has installed a spam-sending program will not send
spam to other AOL users.  In reality, AOL users are likely at
least equally affected.  Second, don't ask me what AOL would
do in such a hypothetical situation; ask them.  While you're
at it, you might ask for some realistic numbers.

It's perfectly ok to configure your software to not trust any 
Received lines at all, and therefore none of the Processed lines either.

Some other user, with different configuration, may elect to trust
some Received lines and not others, and therefore some Processed lines
and not others.


All of this blather about hypothetical configuration of hypothetical
software to trust some hypothetical Received lines on some
hypothetical basis ignores the plain fact that Received fields in
practice are frequently unparseable and simply are not intended
for machine parsing.
 
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.

That's the whole point of the discussion we're having. If you know how
to successfully forge the Processed field as I originally described it
and its variations as already discussed with other list members, please
give a concrete scenario.

Given a message with a valid Received field; it's trivial; simply
construct a Processed field accordingly and insert it where
desired, eliding any preexisting "processed" field that corresponds
to the Received field.  W/o any Received field; forge one and
insert it and a corresponding "processed" field where desired.
 
For example, take the variation we discussed where the Received line
is unfolded, and hashed (with md5 say), and the hash is quoted
in the Processed field. Describe a method which succeeds with high
probability in fooling a receiver into thinking a (forged) Processed
line was added after the topmost Received line seen by this receiver.

The "topmost Received line" isn't necessarily the only one, nor
is it necessarily the only one with a corresponding "processed"
field in your scheme. If one has access to the message, one
can add a field with forged information even more easily than
it is to add "legitimate" information.  Bear in mind the fact that
not all message transfer involved SMTP, but that inly SMTP
requires inserting a Received field (and moreover, there is no
enforcement of that requirement).

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!

The MUA is pretty dumb. It only wants to know if it should act in 
predefined ways on the extra information or not. I take it you would
choose the "No" option.

No, I'd get a better MUA.  Would you use an MUA that constantly
asks you "have you stopped beating your wife, yes or no?"?
 
No currently standardized field purports to convey any information
which requires detailed configuration information to be able to
interpret the conveyed information.

Neither does the Processed field. Its keyword/value pairs will have
standard meanings which can be interpreted without the need for
configuration information.

Not so.  Given your example
   Processed: name="SpamAssassin"; location-ip="1.2.3.4";
       version="2.63"; function="spamcheck";
       auth-received="B17C07174B5E4546A2B04EB096E83FD7081936B8"; 
       result-tag="spam";
I cannot interpret (in any meaningful sense) the "result-tag='spam'"
part without knowing specific configuration information and run-time
environment information for the instance of "SpamAssassin" version
"2.63" from which the purported "result-tag" was allegedly obtained.
I know nothing about its spam threshold, the myriad of fudge factors
that are used to weigh various characteristics, whether any address
patterns are used as whitelists or blacklists and if so what those
patterns are, etc.

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.

You're sidestepping the issue. I've given an example (Reply-To) where
you (and I and we all) act based on zero hard facts about the writer
of the Reply-To field. If we can act on unreliable fields such as
Reply-To, why can't we act on fields such as Processed? What's the
fundamental difference you perceive and are pointing out?

The fundamental difference is that the Reply-To field is specifically
provided as a means for the message author(s) to suggest a list
of mailboxes for responses. "Acting on" a Reply-To field presupposes
that one has already decided to make a response (prior to consulting
the field content) and therefore one already presumably already
knows *why* he is responding and therefore has some idea of where
his response should be directed. He can choose to respond directly
to the author(s), completely ignoring Reply-To, he can choose to
send his response to some specific place without consulting Reply-To,
he can choose any number of places to direct his response, one of
which is the author's suggestion.  I.e. one makes a decision (to
respond), another decision (where to respond), and in a subset of
cases, might subsequently consult a Reply-To field which conveyed
the original message author's suggestion; if one does not choose
to respond, the presence, absence, or content of any Reply-To field
is simply irrelevant, and in any event is not involved in the decision
*to* respond or not.  You are proposing that some decision be
based on incomplete and inadequate information contained in a
"processed" field.   I.e. the field must exist and must have some
content before the relevant decision (a guess, really) can be made.

Your proposed "processed" field differs from all of the above;
unlike Return-Path and Received trace fields, its content is
not well-defined.  

Of course not, you'll have to wait for a proper draft.

You have missed the point.  A Received line "from" component
documents the domain name used by a client in an SMTP
transaction. That documents a fact about what was used. It
is not a value judgment and is in no way dependent upon
the configuration of the MTA that documents that fact. That
is the sense in which the existing trace field content is
"well-defined", and is not the case for your "result-tag" etc.
component.

I'm bouncing 
off ideas for how best to deal with a sub-issue (proving writer
location), I thought that was clear.

For messages, the existing MIME security multiparts seen to
have the only hope of providing such proof.  Of course
there's little point in "proving writer location" if what is
written is inadequate or is mere gibberish.

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################


<Prev in Thread] Current Thread [Next in Thread>