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: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of
Martin Stecher
Sent: Wednesday, February 23, 2005 1:15 PM
To: ietf-openproxy(_at_)imc(_dot_)org
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