On Fri April 8 2005 11:30, Tony Finch wrote:
On Tue, 5 Apr 2005, Bruce Lilly wrote:
o Architecturally, all messages must pass through at least one
Gateway (which may be implemented in conjunction with an MTA, MDA,
or even MUA). [this is necessary to accomplish MIME
message/partial reassembly as detailed in RFC 1344]. As reassembly
(RFC 2046) is a rather complex process that involves message
modification, the operative unit is unquestionably a gateway [it
might be useful to differentiate different types of gateways,
though that is not done in the simple diagram above or in the
draft]
I was under the impression that message/partial reassembly is often
implemented by the rMUA rather than some transport-level entity between
the sender and recipient. There's no requirement for a gateway. I don't
think it's helpful to describe the MIME functionality in an MUA as
something to do with gatewaying because the MUA is not a transport-level
entity. It's only necessary for gateways to implement MIME in order for
them to properly handle the mismatch between Internet email and some other
email system, so the MIME handling is a secondary feature rather than
something fundamental to gateways.
Please see RFC 1344 sections "Fragmenting and Reassembling Large
Messages" and "Using or Removing External-Body Pointers" and then
look at http://www.kb.cert.org/vuls/id/836088. My initial response
upon hearing of that supposed "new" "exploit" are recorded at
http://lists.sans.org/pipermail/list/2002-September/054081.html
and I stand by those remarks.
o filtering operates at the Application layer rather than transport
layer
Why? I presume you mean filtering implemented by Sieve or some equivalent,
which can occur in the MDA or MUA. The boundary between transport and
application becomes rather blurry here, so I'm interested in where you
draw the line and why.
Filtering in general, not just Sieve implementations. I say Application
layer because there is no transport involved in filtering per se (though
of course such filtering might be associated with an MTA, MDA, or
gateway). Also because filtering involves examination of message content
(unlike relays (architecturally; aberrant implementations are a separate
matter)).
Note also that this kind of filtering can be used
to implement aliasing and mailing list expansion, which you later say is
a transport level function implemented in the MDA (and I agree with this).
Aliasing and mailing list expansion operate by replacing the SMTP
envelope recipient path with one or more new paths. Aside from
newfangled bumper stickers (List- fields), message content remains
unchanged and need not be examined. It is not uncommon to have
(anti-spam, anti-virus, anti-HTML) filters associated with list
expansion, but the separate functions can be distinguished
architecturally.
o filtering must occur after message reassembly (Again see RFC 1344
and see also http://www.kb.cert.org/vuls/id/836088 to see what can
happen when that architectural principle is ignored)
Not necessarily; this is only required if the filtering is performing some
content-sensitive security function, which is not usually the case for
sieve-style filters. I think it's important to distinguish between sieve
filtering (on behalf of users) and security filtering performed within the
MTS.
Note that Sieve can filter based on arbitrary message header fields;
also note that message/partial fragmentation and reassembly are such
that (unfragmented) message header fields may be buried within the
first fragment body until reassembled. Therefore Sieve cannot operate
on those fields until the message is reassembled. 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?
I don't object to subdividing categories where it makes sense to do do,
but of course that's more effort, should probably be reviewed again,
and might not be beneficial.