--On Thursday, 08 September, 2005 06:58 +0100 Chris Haynes
<chris(_at_)harvington(_dot_)org(_dot_)uk> wrote:
At 17:56 -0400 on 09/07/2005, John C Klensin wrote about
Classifying
gateways in 2821/ 2821bis:
...
(v) An MTA-level mailing list exploder. These creatures
may make one message into many at the transmission
level, but they do not alter any message header
information other than to insert trace fields. It
remains controversial as to whether they may even change
the MAIL FROM field in the envelope, but the general
consensus, reflected in 2821, has been "yes", as long as
the From/ Sender fields in the headers are not changed
at all (much less adding Resent- fields or making other
header changes).
Anything else, anything else at all, requires that the message
be delivered, handed off to something that acts as an MUA
...
How would you classify an MTA-level mailing list exploder
which additionally modifies the displayed body of the message
(e.g. to append recipient-visible subscription instructions
and archive links)? Would it still be a (v)?
Chris, this illustrates, again, why I think carrying the
building of models too far is not helpful. Models are often
good for descriptive purposes but less helpful for proscriptive
ones and it is possible to have a perfectly good model without
rigid category-boundaries. This case also intersects with the
bane of all attempts to make a really clean model of Internet
mail handling or to digitally sign mail headers: the lack of
clear boundary-separation between envelope/transport information
and header/body/user-agent information.
Now, for this case, I am personally pretty rigid: if the mailing
list exploder starts messing with (including inserting)
non-envelope (i.e., as things are now defined, non-trace)
headers (or body information), it is performing an MUA-level
function and is hence not an MTA-level exploder at all. List-*
headers push me over the edge, as do spam-identification
headers, as does appending pithy comments to the first textual
body part.
However, if you don't like that answer, I have a different one.
RFC 2369 ignored the transport environment entirely -- RFC 821
is not even referenced. If I were inclined to be pedantic about
this, I'd suggest that strengthens the case that these are
MUA-level functions. But 2369 could have been written, or could
now be updated, to designate the List-* headers as trace fields
to be inserted by an MTA-level exploder. That would change the
classification of the relevant actions without making any
fundamental change to the model itself.
john
p.s. to Dave Crocker: while I had trouble identifying it in the
abstract, the sorts of distinctions that Chris is trying to
make, or get me to make, and that he presumably finds useful,
are probably at the core of my discontent with the attempt to
construct even more categories and distinctions in your "mail
model" document. That discontent gets especially strong as one
moves from a model that is basically just descriptive (which is
what I attempted in my note last night) to one in which one
starts to say "this is a foo, therefore it MUST exhibit all of
the following behaviors and MUST NOT exhibit these other
behaviors".