[Top] [All Lists]

Re: Classifying gateways in 2821/ 2821bis

2005-09-07 23:21:10

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".

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?

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.

Chris Haynes