On Nov 10 2004, Bruce Lilly wrote:
On Sun November 7 2004 22:47, Laird Breyer wrote:
Ok, thanks for the clarification. Can I summarize your position in the
following terms? Mail transport is in essence an end-to-end service which
cannot be trusted by anyone due to the potential for unethical
intermediaries to change the content of messages against user's
wishes.
No, that would be inaccurate. Message content can be signed
(at the originating endpoint, and the signature verified at the
receiving endpoint) to provide protection against undetected
modification in transit.
The message signature could be illegally removed in transit, and the
body appended with some innocuous sentence such as "P.S. My PGP is
temporarily broken", along with other subtle changes. That would be
"social engineering", which we know works for a surprisingly large
number of people.
The message could be modified and resigned with another private key
under the purview of the same certificate authority. Unless you've
actually exchanged public keys with the sender at some earlier date,
you'll be trusting the CA if you intend to obtain the public key and
verify the signature. CAs have been compromised before: VeriSign
signed certificates which purported to belong to "Microsoft".
http://www.pkiforum.com/resources/verisigncerts.html
You simply cannot claim that message modifications are detectable
without some measure of trust in external entities separate from the
sender and receiver.
I'm saying that people may elect to trust certain mail transport
agents. There's no difference between that and electing to trust
VeriSign say.
My assumption which can be
challenged is that all paths to B are covered by a small number of transport
agents which can be reasonably labeled by B as being of type T.
And as I pointed out:
You are assuming an extraordinarily simplistic model which
simply doesn't conform to reality; a model where there are
only "M" and "T" and where each system is either one or the
other, invariant with message content and over time, with no
message transport paths through other mechanisms.
You persist in addressing a non-issue. The sentence preceding the one you
quoted states
I didn't expect this picture to specify a single path from A to
B which must always be used by all messages from A to B, rather it
represents the actual path taken by a given message. "T1" and
"T2" are whatever makes sense for that actual path.
Instead, your examples so far invoke institutionalized corruption by those
computer systems. I don't find that very convincing as a counterexample.
"Corruption" as you are using it is not a technical term. My
examples were intended to illustrate the fact that there may
be cases where some party labels what the recipient might
consider to be spam as non-spam or vice versa. I have
given examples where that may be intentional (specifically
to refute your implication that there is no reason for an
intermediate to do so); it is also possible due to incompetence,
difference in values, etc. If your proposition is that "all birds
are either black or white", I can show that to be a false
My proposition isn't, I don't know which birds you are metaphorically
referring to.
I've addressed your counterexamples already previously. It is
always the responsibility of the recipient to decide what to trust.
If the recipient trusts the whole world willy-nilly, then the
consequences won't be surprising.
Arguing that an intermediate may exist which is trusted by the
recipient but, whether intentionally or otherwise, doesn't deserve
this trust, is not very profound. So what? Show me a counterexample
where the intermediate isn't trusted, but the incorrect Processed
payload is still accepted. Arnt gave such an example, which works
about 1/10 of the times.
Perhaps you would find the following analogy useful: Just as for
cryptographic signing, trust is placed in third party certificate
authorities, here trust is placed in SMTP servers writing Received
lines. There is no ultimate objective justification for trusting a
CA, nor is there for trusting a given MTA.
In cryptographic signing, certificates can be revoked, and here too trust
in particular SMTP servers can be stopped.
As a consequence, all documents subsequently signed by a revoked
certificate are no longer trustworthy, and similarly all Processed
lines associated with an untrusted Received line are untrustworthy.
But if the certificate is trusted, then messages signed with this
certificate are very unlikely be fully forged, because the associated
mathematical problem is extremely difficult to solve. Similarly, if
the Received line's id is "unguessable" (as one example of the
scheme), then a Processed line which quotes this id is very unlikely
to have been written before the associated Received line was written.
You've already noted that sometimes a Received line doesn't contain
an id, and there are difficulties with parsing. Those are good
points, while requiring a recipient to trust an untrustworthy intermediate
just so they can mislead the recipient is not I think.
Use of multiple filters does not require that any of them be
"remote". Having a local filter and a remote filter does not
guarantee different "strengths" (for any definition of that
rather nebulous term).
Unless, for example, one of the filters has access to a relevant
database which other filters, residing in a different network
location, don't have.
Filtering that takes place at the receiving endpoint is consistent
with the Internet Architecture.
I agree. It's just not reflective of reality, unless you pick various
intermediate points and call them endpoints, such as you did with the
example of mailing lists.
In a message sent from blilly(_at_)erols(_dot_)com to
ietf-822(_at_)imc(_dot_)org,
the latter is unquestionably one endpoint of that communication.
With regard to the Internet protocols, it is in no way
"intermediate". Likewise a message sent from
owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org to laird(_at_)breyer(_dot_)com
has those
mailboxes as endpoints. That some message content may be
the same due to re-mailing doesn't change those facts. If
ietf-822(_at_)imc(_dot_)org were to vanish, that would break the first
path because one of the endpoints disappeared. Disappearance
of some intermediate system (in a properly-configured system,
e.g. with at least two MX hosts) would not break that
communication path.
So why again are you opposed to insertion of cruft into the headers by
the list expander? If imc.org say performs a virus scan and inserts a
header detailing the result, or even changes the subject line by
inserting a label such as [ietf-822], this should be entirely
acceptable from the viewpoint of Internet protocols, since the message
originating from owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org is considered
entirely
independent from the message originating from
blilly(_at_)erols(_dot_)com(_dot_) The
sender of the latter can lay no claim to the contents of the former.
MUAs have had spam filtering capabilities for years, starting with
keyword searches in the subject line which had to be entered by hand.
The Subject field is not designed to be a spam indicator; it is
That's irrelevant. A spam filter performs whatever analysis it is
programmed to do. It is not bound by the meanings derived from RFCs.
Adding cruft isn't "filtering". It makes the problems (transmission
bandwidth and storage capacity requirements) worse. True
corporate filters (as opposed to "filters" that do no filtering) can
and do reduce the problems; but neither they nor any other true
filtering method have any need to add the field that you propose.
I've already given you two examples, the sourceforge mailing list and
a commercial service such as death2spam. Filtering cruft exists.
--
Laird Breyer.