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