On Sat April 9 2005 11:54, Tony Finch wrote:
That all addresses reassembly when gatewaying. I'm talking about a
situation without filtering and using only Internet protocols, where the
only place that needs to perform reassembly is the MUA, and there is
nothing performing the architectural role of gateway.
Reassembly is architecturally a gateway function (and technically takes
place at the Application layer for reasons given earlier), regardless
of what sort of product implements that function.
If a hypothetical product implements that gateway functionality in an
rMUA with a local message store, then it is not possible for filtering
to take place other than in that rMUA or another rMUA that accesses the
same MS (local MS formats are typically non-interoperable and
product-specific), unless of course that product never "sees" fragment
messages because an "upstream" gateway performs reassembly first. In
particular, if there is a remote MS that stores only individual
fragments, no (reliable, arbitrary) filtering based on content can take
place, and no rMUA that does not also incorporate the gateway
functionality of reassembly will be able to present any complete
messages which were received at that MS as fragments (unless an RMUA
with said gateway functionality uploads the reassembled complete
message to the remote MS prior to such filtering).
Now a note that that architecture wasn't strictly necessary prior to
MIME might be appropriate. As might be the case for a note that absent
filtering, searching, and sorting considerations it might not matter --
however, the fact is that almost all rMUAs have searching and sorting
functionality, most have filtering, and most moderately sized
organizations employ some sort of content filtering due to spam and
malware concerns.
The architectural principle is important given various schemes for
"remote filtering" whereby some party is contracted to perform content-
based filtering for a recipient. That works only if
1. all MX records result in all messages passing through that filter
and
2. the "filter" properly implements message reassembly (so as to
preclude the problems which occur when that doesn't happen, as noted
in the CERT vulnerability notice previously cited).
I.e. the conditions stated apply (all messages pass through a gateway
(for reassembly) where that gateway catches all messages routed via MX
hosts, and where the reassembly performed by that gateway takes place
prior to content-based filtering).
Sieve continues to evolve; there is a recent proposal for
"vacation"-like functionality; would you really like to receive a dozen
notifications because a message was fragmented in transit?
Sieve requires that a correspondent does not receive multiple copies of
the vacation notification within a reasonable period of a time (e.g. a
week) which deals with that problem.
Not if the fragments are processed by separate implementations which
have no way of communication information about separately-sent
notifications. Which might very well happen if messages are not
funneled through a single choke point as is required for reassembly.
I.e. in order for the (Sieve or similar) "vacation" restriction on
notifications, and for filtering for security issues, and for filtering
(by Sieve or other mechanisms) on arbitrary message header fields, it
is a necessary condition that fragmented message reassembly take place
before such filtering.