RE: Activation points and callout modes (full consensus check)

Hi all,

I looked up again comments/suggestions on the list in order to finish up the
summary I made and to check whether we have consensus in all points.

This is what I forget to quote yesterday:

Tony wrote on Jan 22:
 > However as you say it [the reply mod use case] doesn't really fit into the
 > OPES model because the call-forward is not a full SMTP conversation (it's a hack),
 > so it's probably too much of a strain to support something that's fairly esoteric.

and Hilarie wrote on Feb 1:
 > Go with 1A and 1B as MANDATORY.  Those have always made sense.  Don't
 > have anything OPTIONAL; if their importance becomes obvious later then
 > they can be added as extensions.

To me it seems that we have full consensus on this subject now.

Allow me to double check, we may be able to cross this subject off now.

In summary again:

  OPES/SMTP will handle the SMTP send/receive activation points only.
  It only handles command modification and command satisfaction.
  Email message body modification will be handled as a command modification.

  Other activation points and SMTP reply modification will be either
  handled in a later extension of OPES/SMTP or by another OPES profile
  such as OPES/MIME. We will not further handle these for the first
  version of OPES/SMTP.


Please speak up now if you have another opinion and/or think that this
is not the consensus of this working group.

Thanks a lot.

Regards
Martin



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Martin Stecher
> Sent: Wednesday, February 23, 2005 1:15 PM
> To: [email protected]
> Subject: RE: Activation points and callout modes
> 
> 
> 
> 
> > 
> > >   1. Receiving email
> > >      Do a SMTP dialog with the peer, receiving email from it,
> > >      usually storing the emails in a queue and maybe 
> > sending on later
> > >  2. Stored email in queue
> > >      Operate on an email that has been received earlier. Their is
> > >      no current SMTP dialog going on
> > >  3. Sending email
> > >      Do a SMTP dialog with a peer, sending email to it.
> > >  4. Proxy (receive and forward)
> > >      Having two SMTP dialogs at the same time. Mostly forwarding
> > >      commands and replies; often no own email queue
> > 
> > FWIW, it looks to me that, *from OPES point of view*, 1 and 3 are  
> > essentially the same, and 4 is essentially a combination (or 
> > concurrent  
> > application) of 1 and 3. Number 2 is out of OPES/SMTP scope; 
> > it could be  
> > in some future OPES/MIME scope.
> 
> Seems that we have consensus here :-)
> 
> > 
> > This makes the situation essentially equivalent to the one we 
> > have in  
> > OPES/HTTP: The difference between 1, 3, and possibly 4 can be 
> > accomodated  
> > by two or possibly three OCP profiles that share most of 
> > their properties.
> 
> Yes :-)
> 
> > 
> > > In addition to that there are four modes
> > >
> > >   A. SMTP command modification
> > >      The command is modified by the callout server
> > >  B. SMTP command satisfaction
> > >      Callout server responds with a SMTP reply (usually an error
> > >      message).
> > >  C. SMTP reply modification
> > >      The SMTP reply is modified by the callout server
> > >  D. Email message body modification
> > >
> > > Re C: SMTP reply modification seems to make sense for
> > >     - reply logging (so no real modification)
> > >     - At activation point 4, when commands and replies are proxied
> > 
> > I do not yet understand why SMTP reply modification is 
> > essential for AP#4  
> > if it is not essential for other APs. Did I miss an example 
> > posted earlier  
> > (I did go through all the messages on the list)?
> 
> I do not think that reply modification is essential. I said I see it
> as an option for AP#4 which is again more an optional 
> activation point.
> So, why it is on the list at all and why do I see it as an option for
> AP#4 and not for any other activation point?
> 
> Hilary proposed on Jan 22 that we use "the same architectural 
> model that
> we used for HTTP". And that means AP#4. We get a request 
> forward it, get
> the reply and forward it again. Proxy style as in HTTP.
> That is why I added this AP.
> And then we have REQMOD and RESPMOD as in HTTP. Reason to add 
> the reply mod mode?!?
> 
> One use case that we had for reply modification in an AP#4 
> like deployment
> came from Tony on Jan 21:
>   > Success and failure responses (250 and 550) are passed to the
>   > external client, but temporary failures (4xx) are 
> modified to success
>   > responses so that we take responsibility for a message if 
> the departmental
>   > server is having problems
> The OPES use case for this is: The callout server is 
> implementing the queues
> that are missing in the SMTP proxy thing and is able to store 
> messages when
> it received temporary error replies from the next hop.
> 
> That makes no sense in AP#3, when the sender has its own queues.
> 
> Other uses cases are implicit by Hilaries comment from Jan 23:
>   > When the response comes back indicating that there's a 
> problem with
>   > the recipient name, the OPES processor sends that to the callout
>   > server, and at that time, the callout server can pick an 
> alternative
>   > method for finding the recipient.
> 
> Means to me that the callout server sees the reply coming 
> from the next
> hop MTA. It then instructs the OPES processor in the OCP response to
> retry with another SMTP command to the same next hop server 
> or to start
> another dialog with another server or by doing something 
> directly within
> the callout server (open a SMTP session itself, store email) and to
> MODIFY the ORIGINAL SMTP REPLY which is then send to previous MTA.
> 
> Similar callout server functionality can be done in AP#3 but there
> the MODIFICATION of the REPLY is not needed, IMO. The MTA tries to
> send something, gets an error back, and asks the callout server to
> MODIFY the COMMAND in order to retry. Response modification is not
> really RESPONSE MODIFICATION here but an SMTP reply in the OCP request
> and an alternate SMTP command in the OCP response or a OCP 
> status "handled
> by myself". The ability to instruct the MTA to retry with a different
> command for RESPMOD only complicates things.
> 
> So again, IMO: Response modification makes somehow sense in 
> AP#4, still
> optional and makes not much sense in other activation points.
> 
> If we can agree to not further handle AP#4 as a special case then we
> could also agree to forget about reply modification.
> Can we find a consensus here?
> 
> 
> > > Re D: When part of OCP/SMTP (not OCP/MIME or alike) this can be
> > > seen as command modification, i.e. it falls back to mode A.
> > 
> > Yes, at this level of abstraction there is no difference.
> 
> Consensus. :-)
> 
> 
> Regards
> Martin
> 
>