On Oct 22 2004, Bruce Lilly wrote:
Once a message leaves the SMTP transport environment, of
course there can be additional processing. However, if the
message content (header or body) is changed, then one
is no longer dealing with exactly the *same* message.
That's the unfortunate problem with filtering services at present. In
your sense, the messages delivered to end users are practically never
the same messages that were sent. That shouldn't really matter as long
as users receive some RFC 2822 message to read.
What causes headaches in the present context is the decentralized
nature of the modifications. Once the message hits the receiving MUA,
there really is no way to know who did what, but I believe a simple
standard could be useful.
There is an existing mechanism that can be used to allow
addition of arbitrary content, with authentication, and
while permitting the original message to be recovered
intact: simply wrap the original as MIME type message/rfc822,
if there is additional content, it and the wrapped message
can be packaged as multipart/mixed, and if authentication
is desired that can then be signed using the multipart/signed
MIME type (S/MIME and PGP/MIME use that mechanism and
are widely deployed).
That is a nice way of wrapping up the various issues, but I fear it
will never fly in a world where the already implemented alternatives
are flawed, but much simpler (ie who would switch from single-line
X-headers, and why?).
If you ask each filter processor to wrap the original message as it
receives it into a message/rfc822 attachment, then by the time the
fourth filter say looks at the message, the original content will be 3
levels deep. So you're forcing each filter to know how to parse MIME
properly, even if all the filter does is to verify the IP addresses
within the trace headers of the message, say [ie an example filter
which would never look at the message body otherwise].
The problem with full MIME authentication is that we don't have the
trust networks and ubiquitous public key infrastructures this would need,
so in practice authentication would simply not be used.
The header authentication I'm talking about is not very sophisticated,
but it doesn't require any cryptography infrastructure, or managing
shared secrets etc. It's a lightweight refinement intended to help
software decide what to trust, based on message structure.
For example, I would see a future MUA parsing an incoming message, and
displaying to the user a limited list of headers. The user could elect
to ignore headers which weren't added by his organization, by
specifying a subnet mask or similar. Alternatively, he might have his
own custom configuration of some popular filter software, which is
also deployed organization wide. He would not want to use the common
version except in some cases, so would want to limit himself to
headers added by his personal machine. These are personal choices
which need not involve the whole organization.
identifying date-time: unfold the Received line, normalize spaces,
look for the first ';' from the end and take everything after that.
No.
(snip) I knew I was going to regret writing those paragraphs. I accept
your points. I think in a final document, an appropriate parsing
algorithm will have to be given explicitly.
There's a more fundamental issue with the whole scheme; you're
simply trying to authenticate some added content (and as noted
above, there are existing mechanisms that can do so without
running roughshod over the existing transport mechanism). Let's
Again, I would like to say that I am not trying to fully authenticate,
rather I am trying to allow accurate verification of the
content writer's location in the message transport. I'm using
authentication for lack of a better vocabulary.
Whether the added content is trusted by the recipient is a different
issue, although that is blurred because the rule of thumb is
"if it was added inside my computer, I trust it" and variations thereof.
assume for the moment that a 100% foolproof authentication
mechanism is in place and that the field above is guaranteed to
have been inserted by the party that claimed to do so. I submit
that it tells me nothing particularly useful; I have no guarantee
that the claimed processing was performed or that the claimed
results are accurate.
That's true, but is not a show stopping issue.
For example, you might trust that each message in your mail spool was
delivered via the internet if the top Received line checks out,
say. In actual fact, your machine could have been rootkitted, and an
appropriately formatted message was simply delivered directly to your
mailspool, with a fake but authentic looking topmost Received line.
So you have no guarantees about your mailspool, but it doesn't stop you
from acting as if the messages were sent to you in the normal way.
Similarly, how the recipient acts on an added header is up to them,
as is whether they want to trust those headers in the first place.
Even if I have blind trust in the party that claimed to have
inserted that field, I have no way of knowing if the claimed name
"SpamAssassin" is what I think it is, and if it is, I have no idea
whether it was modified at that site or if it is "vanilla"
SpamAssassin. Even if I assume that it is unmodified,
If you can verify that the header was added after the message went
through a certain machine, and if you trust your system admin when
he says he's got SpamAssassin in vanilla configuration along that
segment of the message path, then you can trust the header.
In a futuristic MUA, you would get a message stating: "I detected
a filter called SpamAssassin which operates inside the third hop
from the end, would you like me to use its recommendation?"
I have no idea what configuration files were used with it or
what run-time options were specified. In short, purported results
of an indeterminate process with indeterminate configuration
and indeterminate run-time parameters allegedly run at a
remote site are of little value.
That's the trouble we have today and why a standard filtering header
(such as the Processed example I ued) would help. With a standard,
some common outputs can be formalized, offering a standard interpretation
which anyone can use. It's up to the filter authors to honour the contract
and actually output quantities whose interpretation matches the standard's
mandated interpretation. It works well enough for MIME.
--
Laird Breyer.