[Top] [All Lists]

Re: Classifying gateways in 2821/ 2821bis

2005-09-08 16:48:05

john+smtp(_at_)jck(_dot_)com (John C Klensin)  wrote on 07.09.05 in 

   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