[Top] [All Lists]

Classifying gateways in 2821/ 2821bis

2005-09-07 23:38:50

Alex van den Bogaerdt  sent me a long note that mixed editorial
and substantive issues.  I've suggested that he send the latter
to this list but, while I'm thinking about it and because it
interacts with some of the anti-spam and Resent-* issues, I want
to address one of his comments here.

He wrote...

    Sollicitated comment:  Sometimes a user does not want
others to know     about his real address and uses a
forwarder.  In my opinion, this is     a gateway as well.
Such a user doesn't want his address to be known     and
therefore bounces must not go to the original sender, 

This is part of the "lots of types of gateways" problem.  Once
upon a time, we had serious problems with all sorts of abuses
being committed and then justified as standards-conforming
because their author would say "well, we decided to change
something, so we assert that we are a gateway and gateways can
do anything".   That was a key reason why the definition in 2821
was tightened to clarify what was intended by the language in
821, i.e., that the only justification for a gateway and the
only things that fit within that term were translators between
an SMTP-over-the-Internet environment and something else.  I.e.,
    SMTP -> Server -> Non-SMTP-environment
or its reverse, turn Server into a gateway, but 
    SMTP-on-Internet -> Server -> SMTP-on-Internet 
does not

That leaves one ambiguous case, and it seemed better, at least
when 2821 was written, to not clarify it.  That case is

    SMTP-on-Public-Internet -> Server -> SMTP-on-Private-Network

when the private network is running SMTP over TCP.  

While are other cases of that situation, this matches some of
the "firewall" issues that Ned Freed addressed in RFC 2979.
Whether a firewall-based SMTP implementation that feels free to
alter both envelope and content is a gateway or a final delivery
server that then re-originates the message is an open question.
Ned describes one as a "protocol end point and relay" (first
sentence of section 2 of RFC 2979). I believe the correct answer
is to focus, as Ned does, on behavior, rather than getting hung
up on the assignment of names followed by believing that the
assignment of a name to something changes or determines its
behavior.  So, for me, over-analyzing the "what is a gateway"
question is not very productive.

In any event, there is an historical decision about models that
derives from examination and experience with both systems that
are unambiguously gateways (SMTP-over-TCP to/from
something-else-over-something-else) and with the many flavors of
mailing list expanders/ exploders.  That model has some symptoms
in 2821 and elsewhere, but has never, to my knowledge, been
formally explained in a published spec.  It is conditioned
strongly on the notion of control and handoff of responsibility
for a message.   In essence, there are only the following cases
as far as SMTP is concerned:

        (i) A server that is sufficiently under the control of
        the [original] message originator that the originator
        authorizes and takes responsibility for all of its
        actions, which are presumed to be made on the
        originator's behalf.  We usually call these "submission
        servers", but there are some odd cases.  An anonymizer
        that is selected by the original message originator
        could be seen to fall into this category: it is not a
        gateway, it is really not part of the SMTP-> SMTP
        environment specified in 2821, although it has
        properties that 2821 needed to explain, and it operates
        under a somewhat different set of rules than an
        "ordinary" SMTP server or relay.   These servers may
        behave well or badly, but the rules about good and bad
        behavior do not derive directly from 2821 unless (i)
        they put something SMTP-invalid on the wire or (ii) they
        drop a message for which they have accepted
        responsibility without a really good reason.
        (ii) A server that is sufficiently under the control of
        the user to whom delivery is intended that its actions
        can be presumed to be authorized by that destination
        user and carried out on her behalf. 2821 is willing to
        consider these part of the final delivery server system,
        with the understanding that the final delivery server
        may not actually be a single host or interface.
        Firewall-based servers may or may not be a member of
        this category (see above).  Note that once "final
        delivery" is made, 2821 loses interest: thoughts about
        message stores, MDAs, message retrieval protocols, etc.,
        are part of some other protocol and specification.  As
        with submission servers, these servers may behave well
        or badly, but the rules about good or bad behavior do
        not derive directly from 2821 unless (i) they put
        something SMTP-invalid on the wire or (ii) they drop a
        message for which they have accepted responsibility
        without a really good reason.
        (iii) A gateway, defined as a transition/ translation
        point between an SMTP environment and a non-SMTP
        environment, as noted above.  The expectation is that
        gateways will only make those changes to message bodies
        (including headers) that are actually necessary to
        preserve the maximum amount of information as the
        message passes from one environment to another.
        Gratuitous "improvements" are inappropriate for
        gateways, too. 
        (iv) A relay.  Relays do not mess with either the
        envelope or the message body except to add trace fields
        and as otherwise explicitly directed in 2821.
        (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
(possibly really an agent replacing a user, rather than one that
provides a UI for one) and then re-originated as, essentially, a
new message. Such a new message may have new headers including
Resent-* and List-* ones.  It may drop the trace fields that
were in the message that came to it.  And it may change
From/Sender/To/etc fields: by sending a message to one of these
things, the originator hands off responsibility and authority to
it.  The actions the intermediate MUA takes are specified rather
more in policy statements for lists and about appropriate use,
not protocol specifications, at least IETF protocol
specifications so far.

Now, if there is general agreement with that model, we should
proceed to clarify 2821bis, as needed, to match.   If there is
not, then I suggest we would be better off discussing the model,
rather than suggesting text that may or may not match it.