On Wed November 17 2004 03:34, Laird Breyer wrote:
If T2 is located on a LAN, would this require an open
relay or is this not needed?
In general, an open relay is not necessary. Since your
model presumes that T2 (etc.) handle messages destined
for the domain associated with B, open relays are not an
issue since the message is destined for B regardless of its
origin (an open relay applies when the server in question
is associated with neither the domain of the message origin
nor the domain of its destination; since the message
destination is appropriate, one of the two necessary
conditions for an "open relay" situation is not present).
Also, can the very last SMTP server which
accepts the message on behalf of B be forced to *not* insert its own
Received line?
If T2 transfers by some means other than SMTP, M3 may
very well *be* the last SMTP server involved (if indeed it uses
SMTP).
I must admit that I was under the impression that at least that case
is guaranteed to be unforgeable (ie if the message was transported
through SMTP and none of the subsequent MDAs alter the message
headers, then at least one Received line exists and the top Received
line was written by the last SMTP server along the path).
There are many assumptions implicit in that statement, which
might not reflect reality for some specific cases. For example,
some MDAs do insert Received fields such as:
Received: from mail.blilly.com ([unix socket])
by marty (Cyrus v2.2.3) with LMTP; Wed, 17 Nov 2004 10:15:56 -0500
That was inserted by a Cyrus LMTP MDA process when making
"final" delivery to a mailbox. Other MDAs may also alter message
header fields (e.g. sendmail), some auxiliary filtering processes
associated with an MDA may alter fields, and some MUAs are also
known to alter message headers. Messages can be transferred
without SMTP (e.g. on LANs not using Internet mail protocols,
via uucp, etc.). Received fields might be added by transfer
processes which do not involve SMTP (e.g. sendmail when
transferring via uucp). So it's possible to have a message (w/
or w/o Received fields) which was transferred without use of
SMTP, and it's possible to have a message which has not
been transferred using SMTP contain one or more Received
fields.
Even a "web of trust" alternative as used by PGP must still be trusted on
arbitrary grounds, and compared to a hierarchical system it's more
difficult for the web of trust to scale as I understand it.
[...]
Out of band verification such as with the telephone won't work unless
there's already an out of band relationship to start with. If all you
have is information within the message, you can't verify much.
Requiring an existing relationship means this type of verification is
not scalable to the internet, as much email communication also
initiates new relationships.
Something like "DomainKeys" may be scalable, and does not
require a pre-existing relationship. But now we're getting
somewhat off-topic.
I don't see that. Since trust is entirely a quality originating from
B, the amount of trust attributed to "T" (by B obviously) can be any
shade of gray as well as dependent on time or message content, once B
gets to see the message and analyse it. Of course, B probably applies
simple heuristics wherein "T" is trusted regardless of content or time
of day as you claim, but it's not a necessity.
As you may recall, the discussion that led to that was about
the appropriateness of having a non-filtering remote "filter"
if a local filter is required to determine whether the remote
"filter"'s assessment is reliable. If such a local filter is required
(because one needs to analyze content in order to determine
whether or not to use a remote "filter" value judgment, etc.),
that situation applies. Now, that isn't the case if and only if
a remote judgment's reliability is independent of message
content, etc. With anything other than a content-invariant
black/white reliability, we get back to the inherent problems
with the proposed "processed" field -- there's no indication
of what parameters went into the claimed value judgment.