john+smtp(_at_)jck(_dot_)com (John C Klensin) wrote on 07.09.05 in
<84A8E979D5A60F5D8FBCA373(_at_)scan(_dot_)jck(_dot_)com>:
In essence, there are only the following cases
as far as SMTP is concerned:
(i) [ submission server: server acting for the sender ]
(ii) [ final delivery: server acting for the receiver ]
(iii) [ gateway: server interfacing to non-SMTP protocol stack ]
(iv) [ relay: strictly 2821 hands-off behaviour ]
(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).
I don't think I want to have your category (v).
I have an alternate proposal, however:
(v) mailing list, alias-style forwarder, whatever: a forwarding virtual
user, where output may but need not have more copies of the mail (or
recipients) than the input. There are all kinds, some modifying messages a
lot, some barely at all. In all cases, however, the virtual user is
explicitely given as a mail recipient by the sender.
(vi) vacation or other autoresponder: a replying virtual user. Again,
there are all kinds. In all cases, however, the virtual user is
explicitely given as a mail recipient by the sender.
(vii) MTA reporter: a virtual user sending mail about a mail that is
supposed to be passing this relay/gateway, or being final-delivered by
this server. In all cases, the virtual user is NOT explicitely given as a
mail recipient by the sender ("MAILER DAEMON").
In any way, then we can talk about what kind of behaviour is appropriate
when with those cases (that would mostly be in a BCP, of course), as
opposed to put various possible behaviours for the same task into
different pots in the model.
MfG Kai