--On Thursday, 08 September, 2005 07:08 +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
...
Please consider the behaviour below:
(a) A system whose business model is to map inbound envelope
Rcpt To addresses into the same number of outbound Rcpt To
addresses (in unrelated domains) and seek delivery to those
substituted addresses. It uses a pair-wise look-up table to
make the address substitutions. Typical examples: professional
institution or alumnus mail re-direction services.
My reading of your model would classify (a) as an "Anything
else, anything else at all".
Often. Under that model, the system you identify is receiving
the messages and handing them off to an MUA (in this case,
presumably one entity acting as an agent for a number of users),
rewriting the addresses and sending it back up. I note in
passing that a number of those professional institution or
alumni/ae systems (although certainly not all of them) consider
their redirection services an opportunity to add advertising or
equalivalent text to the first textual body part, which is also
an MUA function (as well as a really bad idea for many reasons).
However, you didn't supply the key bits of information: Does the
return-path change? Does any of the header information change
other than adding trace fields? Is the message body changed in
any way? If the answer to all of these questions is "no", then
this is an MTA-level function -- please see the discussion about
address "correction" in 2821/ 2821bis.
As I implied, the key issues are whether the message body
(including headers) are altered and whether responsibility for
the message, for MSNs, etc., shifts. Transparent forwarding,
with acceptance of responsibility for getting the message to the
next hop or getting an error indication back to the sender, is
clearly an MTA function. Things become ambiguous when the
system accepts responsibility for error messages even to the
extent of changing the reverse path to point to itself, normally
because the original sender should not be getting error messages
from parties (not just addresses) it has never heard of, which
messages originate from a server over whose behavior it has
little control. And there is clearly an MUA function being
performed when the message header or body start getting altered.
Now please consider the case of a system (b):
(b) The externally-observable behaviour is that a message
'delivered' with a single inbound Rcpt To addresss re-emerges
as a single message with a new Rcpt To address. No changes are
made to the body of the message.
Is this a mailing list exploder (v) in which the list happens
currently to have only one subscriber?
Or is this a type-(a) system which is re-directing a message
for a single alumnus?
First, see the paragraphs starting "however" above. It is not
clear to me that hair-splitting over characterization in these
two cases is helpful. However, I'd answer based on what the
system doing the rewriting does to the reverse path. If it is
unaltered, it is a system of group (a). If it changes it to
point to itself (or some system or address acting as its MSN
agent), then it is a system of group (v)
Either your model _requires_ mailing list exploders to have
two or more subscribers at all times, or else it appears (to
me) to lead to an ambiguous classification of behaviour (b) as
matching both (v) and (a).
Note: I have intentionally avoided describing
(a) and (b) using the language
of Sect. 3.10 of RFC 2821 as that begs the
question.
Understood.
It appears to me that one way to answer the question you raise
would be to rewrite my expression of the model so that the
principal differentiator between (a) and (v) is "does it change
the reverse-path?"
Note that either expression of the model is consistent with 3.10
of 2821 (3.9 of 2821bis). As it describes the situation, both
"alias" and "list" are instances of (v) in the hastily-written
description I provided last night. The case of one-one mappings
with no return-path change, or even one-several mappings where
the "several" are under the control of the same recipient, is an
instance of (a) and should be covered under the first bullet of
section 3.4 of 2821bis. And the "MUA-behavior" case is, quite
properly, not specified in 2821 (or 2821bis) at all.
That said, it appears to me that 3.4 could use some additional
text to clarify that this case, and not changes of address,
apply and that 3.9 could use a back pointer to it. Text
solicited.
john