On Oct 20 2004, Bart Schaefer wrote:
What's the point of inserting such a Processed: header anywhere before
final delivery?
Good question. The receiving user/organization may wish to or be forced
to take advantage of external filtering services.
This can be either commercial, such as http://death2spam.com/, where
the point is that people who use that service do not want to handle
filtering themselves.
Or it can be a generic bundled service, for example some mailing lists
(e.g. sourceforge) insert filter tags for the convenience of their
users automatically, and there's really no choice or control a
receiving user has about exactly what gets added and exactly how
trustworthy the data is.
In the event of a message that appears to have traversed A --> M1 -->
M2 --> B, there's no way for B to validate the Processed: headers that
seem to have been added by M1 -- because it may be that M1 is really
the bad guy, and he's just making it look like he's transmitting a
message from A -- so of what use are they?
Correct. The ultimate decision to trust a segment of the mail path is
bigger than looking at Processed: headers only.
What the Processed: header can do is assist this ultimate decision in
a way which doesn't yet exist today, namely: it can point back to
where it lies on the path segment (maybe it tells the truth, maybe it lies),
and there's a simple verification procedure which can be applied.
Existing headers today don't even offer this assurance, let alone a simple
way to verify it.
The user at B still needs to decide independently whether to trust
M1 or not. For example with the sourceforge mailing list, B could
choose to trust every header which can prove it was added after
the list received the message, etc.
Why not just specify that M2 should discard all Processed: headers
that it receives, just as it would do for Return-Path:, and then you
can always trust whatever such headers are present, and there's no
reason to tie them to a token in the Received: line?
That's one way to solve the issue in one case. You're saying M2 should
act like the final arbiter for the user B, removing any information which
M2's configuration considers useless or misleading.
If M2 wants to take advantage of a service like death2spam, then
the headers added by death2spam cannot be removed, while others should
be. This also assumes that M2's sysadmin trusts the death2spam
company to remove or label any forgeries which M2 doesn't want to see.
If B wants to take advantage of the sourceforge mailing list
installation of SpamAssassin, then that may be impossible because
M2 decided to remove those headers when the message arrived there.
Finally, it's actually a good idea to leave forgeries in a message,
because their presence (and recognition) can act as strong clues for
spam. So there might be a spam defense at M2, and whatever gets
through is looked at by some other spam defense at B, and what seems
useless for one may be very valueable for the other, or the software
at M2 is an older generation compared with the software at B, etc.
Or write the spec in terms of trust relationships, such that if M2
trusts M1 then it can accept all Processed: headers, but otherwise it
must discard them. Transitively this means that if the path was A -->
M0 --> M1 --> M2 --> B then M1 must have thown away all Processed:
headers if M0 is untrusted, so it's safe for M2 to accept whatever M1
presents.
Solving the trust problem in general is difficult. What you're proposing
seems nice from the point of view of a single architect who controls the
mail service in an organization, but there are certain practical issues:
How do you communicate to all the software filtering packages in use
within the organization what paths to trust? What if you have two users
(or software packages) with conflicting trust models? One user wants
to trust M0 as well, but the other user only wants to trust from M1 onwards?
What happens when there's a reorganization, or somebody installs new software
which plays by different rules (e.g. convert a newsfeed into a mail feed)?
I'm just making these up, but seems easier to leave each software to
create its trust models however it wants, but give them the tools to
verify trust whenever needed.
(Any untrusted MTA anywhere in the chain could mung the existing
Processed: headers, so there's no point in preserving them across any
hop that isn't known to implement the spec, is there?)
As I said, the munged headers may in fact be valuable spam indicators,
why remove them?
--
Laird Breyer.