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