On Sun November 7 2004 22:47, Laird Breyer wrote:
On Nov 04 2004, Bruce Lilly wrote:
So we always have a model of message transport as follows:
A -> M1 -> M2 -> M3 -> ... -> T1 -> T2 -> ... -> B
Not necessarily. There may well be multiple paths to B, N-1
of which do not pass through "T2". "T1", "T2", etc. might
pass some messages w/o change, but may change some
fraction of messages (i.e. those messages not sympathetic
to the interests of the owner/operators of those systems).
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. 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.
Here is another scenario, based on real-world observed behavior
(http://lists.sans.org/pipermail/list/2002-September/054073.html)
which demonstrates that remote filtering (and the proposed cruft
added by remote "filters") is incompatible with existing Internet
mail architecture. Understanding the scenario requires understanding
basic MIME principles (RFCs 1344, 2046) and an understanding of
the roles of gateways, a basic understanding of the role of the DNS
in mail transport, plus knowledge of some basic graph theory.
A message may be split for transport into fragments using the
MIME media type message/partial. Some types of gateways,
specifically gateways that scan content (for viruses, for spam
detection, etc.), require access to a complete message. Message
fragments may take diverse paths enroute to a recipient; a
complete message may be obtained by reassembling fragments
only at a site which is common to the paths of all fragments.
From a graph topology point of view of the network, the host
node performing the gateway function must be on one side of
an edge which is a bridge edge (i.e. an edge which uniquely
connects two graph components which would not be connected
components without that edge) in the directed graph which
describes potential message transport paths from sender to
recipient. Mail transport uses MX DNS records, and a minimum
of two independent MX hosts must be specified. Therefore any
bridge edge must be located on the recipient side of all MX host
nodes for a given domain (from a theoretical point of view, it
would be possible to have a bridge edge attached to some
common node away from the recipient side of the MX host
nodes in some network topologies; aside from such a bridge
node located near the message sender (which is uninteresting
for the scenario of message reassembly for scanning) such
topologies are not representative of the Internet, and in such
topologies the MX hosts would not be truly independent). Any
gateway activities which require message scanning must
therefore reside on the recipient side of the recipient domain's
MX hosts, and is therefore "local" rather than "remote" for all
practical purposes.
Fragmented message reassembly incorporates some fields
from the header of the first fragment and some fields from
the encapsulated message header which is conveyed in that
first fragment. No transport-added (or any other) fields from
any other fragments are preserved by the reassembly process.
If -- contrary to RFC 1344 and the Internet mail architecture --
scanning of message fragments (rather than complete
messages) is performed, there are several predictable results,
none favorable for proponents of "remote" scanning:
1. the content which defines a message (e.g. as virus-laden,
or as "spam") might not be present in the first fragment;
it also might not appear in its entirety in *any* fragment.
2. reassembly involves discarding the message headers of all
fragments but the first, and many fields from the first
fragment header; any information conveyed in any of
those discarded fields is irretrievably lost on reassembly.
That includes any commentary on defining content which
might appear in those fragments.
3. failure of gateways to take responsibility for all gateway
functions WILL be exploited by bad guys (as has been the
case for some products as noted in the CERT advisory
mentioned in the linked message referenced above).
The bottom line is that there are some things that simply
cannot be done within the Internet mail architecture;
misguided efforts to break the rules usually backfire. "Remote"
scanning (i.e. inconsistent with the functions of gateways,
which necessarily must occur near the recipient) is such a
misguided effort which *has* backfired.