On Nov 01 2004, Bruce Lilly wrote:
You have missed the points; at any point a party can
a) s/result-tag="spam"/result-tag="ham"/
b) insert a Received field, then insert a "processed" field referring
to that Received field, with any desired "processed" field content
N.B. neither tactic would be effective if MIME security multiparts
were used.
Perhaps you have a concrete example where you think a) or b) occurs,
the only examples I can think of are compromised systems, for which
the problem is moot. I'll detail my thinking below in case you can see
which assumptions you disagree with, sorry if it looks like I'm
repeating myself (I am).
a) requires modifying some existing Processed field. No well behaved
filter needs to modify existing fields in a message. If a modification
occurs, then the process doing this modification is doing something
prohibited (tampering with the message), and the computer system which
is running this process has therefore been hacked or belongs to an
untrustworthy party.
b) requires inserting a new Received field. The sequence of Received
fields added close to the message destination is predictable by the
recipient, and can only be changed by an attacker if one of the
computers in the recipient's organization is compromised.
So we always have a model of message transport as follows:
A -> M1 -> M2 -> M3 -> ... -> T1 -> T2 -> ... -> B
A is the sender of the message, B is the destination, M represents
computers which are untrusted by B, and T represents computers which
are trusted by B and add a Received field. None of the computers of
type T will ever perform either a) or b) above, unless they have been
compromised. Computers of type M may well perform a) or b). It is up
to B to only trust Processed fields associated with computers of type
T.
If the recipient's MTA doesn't add a Received field of its own (ie
there are no T type computers at all), then the recipient B must already know
not to trust any Received fields at all in a message.
Evidently you have little experience in examining Received fields;
detecting forgeries is not always trivial (in part because legitimate
fields are often screwed up, in part because sometimes fields
are reordered, in part due to host aliases, etc.).
That's a fair statement. But are you really saying that a given user B
cannot, by examining a sample of past mail messages he personally received,
deduce the form of the Received fields added by the computers I've labeled
T above? I must admit I find that hard to believe.
For a concrete example, suppose that some recipient
is interested in a home mortgage. A spam filter that is configured
to treat all messages containing the word "mortgage" as spam is
worse than useless to that recipient; it is counter-productive. And
on the basis of the (lack of) information in your proposed
"processed" field, no recipient is able to determine whether or not
configuration of any alleged process is appropriate *for him*.
Obviously such a user will learn to not accept the supplied spam label
as authoritative. He will either ignore the Processed field's
recommendation completely, or configure his other filters if he has
any to lower the weight of that particular field so as to let through
mortgage mails but not other spam.
For example, statistical content filters already perform this exact
adjustment automatically, ie giving more weight to tokens which correlate
well with the user's personal idea of spam say, and reducing the weight of
tokens which don't. This is done by asking users to mark incorrectly
filtered messages, i.e. without the need to understand the internals of the
particular spam filter which marks all messages containg "mortgage" as spam.
An assertion made by some
intermediate system which is supposed to be providing transport
services simply fails to fit into the Internet Architecture on many
levels:
a) is is not an end-to-end process
b) eavesdropping on private communications is immoral and
offensive (and may be illegal in some places)
c) it is not under control of either party in the end-to-end
communication
etc.
Would you say that current mail practices such as providing spam filtering
fit into the Internet Architecture described by RFC 1958 ?
For example, a) is broken by spam filters set at the level of SMTP
servers rather than filters set up at the individual MUA level. Also,
b) is obviously broken by spam filters and virus checkers. c) is
broken by spam filtering services offered at the server level, and
also by spam filtering offered by mailing list software.
What can be done to make spam filtering Internet Architecture compliant?
What "filter cooperation"? In precisely what way do filters
at separate sites need to "cooperate", and how is that practical
without detailed configuration information?
As a means of reducing the cruft which is currently added by all these
filters. A standardized syntax with known semantics (whatever it
turns out to be) stops people from reinventing their own X- headers again
and again for a standard service.
It makes it easier for other software to pick and choose which
headers to ignore and which headers to read. It gives software writers
a way of adding their own bits in controlled ways.
Which bits they will otherwise add anyway regardless of the damage it
might do to the mail system.
--
Laird Breyer.