On Sun October 31 2004 01:54, Laird Breyer wrote:
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.
I'm afraid none of this is yet convincing as a successful attack.
You must be able to forge the Processed field before the message
contains the pertinent Received field, otherwise you're not actually
forging anything of value. In fact, quoting existing Received fields
is legal, and marks your location correctly.
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.
If you forge an appropriate Received field as well, you still have no
control over the Received fields added by the subsequent receiving
systems
Again, you have missed a crucial point; there may be no
"subsequent receiving systems", and even if there are
there might be no added Received fields.
Nor can you assume that
the ultimate reader will trust your forged Received field, whence your
associated Processed field. So your forgery will be trivial to detect
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 good point. I believe the Processed field degrades gracefully
in this respect, since if there is no existing Received field to be
quoted, a Processed field cannot quote it. A later reader of this
Processed field will be immediately alerted to the fact by the absence
of an "auth-received" key value.
You are again ignoring the fact that it is trivial to insert a Received
field, then "quote it".
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.
This makes no sense as an objection. The Processed field is a record
of what some other process computed about the message, it has no
other meaning.
There may well be no "process"; the field can be trivially forged.
It is an assertion that there was a process, which was allegedly
run with unspecified configuration and unspecified run-time
environment and allegedly making some value judgment about
the content of some message (presumably the one containing
the field). 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*.
All you need for interpretion is to know what this other process
intended the fields to mean, and that's to be detailed in a common
standard.
No, one needs to know configuration and run-time environment.
As long as processes follow the standard, the meaning will be clear,
viz. "the process writing this field considers the message to be
spam".
There's no guarantee that there was ever any such "process".
Moreover, the assertion that some entity considers a message
to be spam is useless unless one knows precisely what went
into making that judgment (well not entirely useless; one could
object to a third party eavesdropping on personal communications).
If I may borrow your language: the Processed field is specifically
provided as a means for filter processes to suggest facets of the
message as observed during transit.
Please read carefully RFC 1958 on the Internet Architecture,
paying particular attention to "end-to-end". A Reply-to
field is a conduit for information between endpoints (author(s)
and recipient(s)) in communication. 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.
There are a multitude of X- headers used by filters, each with its own
syntax and interpretations, which are currently unparseable by all the
other filters.
And they're all useless and objectionable, for the same reason
that spam itself is objectionable; unwanted cruft that has cost
in terms of communication bandwidth and storage space.
For the subset of spam filters, a commonly adopted
format will allow better filter cooperation
What "filter cooperation"? In precisely what way do filters
at separate sites need to "cooperate", and how is that practical
without detailed configuration information?
and reduce the need for
future filters to reinvent variations on the same format.
There simply is no "need" to add cruft to messages; that is
a problem (inappropriate consumption of communications
bandwidth and storage space resources, viz. the same problem
caused by spam; beware ostensible "solutions" that are as
bad as the symptoms).
I still don't see it. To paraphrase your request for a complete
record of the filter configuration: the Received line "from" component
is useless unless I have complete information about the state of the
DNS system in the world at the moment of the transaction, as well
as a complete record of which IP addresses are used in the world
at that point in time. So in this sense, the "from" component is
simply not well defined due to lack of information.
You are simply wrong; no matter what "the state of the DNS system
in the world at the moment", and completely independent of
"which IP addresses are used in the world", a record of the argument
used in a particular SMTP transaction is what it is. That fact is
invariant w.r.t. DNS and IP address allocations. It is useful for
the intended purpose of the field, viz. "for humans tracing
mail routes, primarily of diagnosis of faults"; it can be subsequently
used to identify a particular transport transaction performed by
an MTA in the performance of its message transport duties.