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