RE: [draft-ietf-opes-smtp-use-cases-01]

On Thu, 13 Jan 2005, Martin Stecher wrote:
>
> I do not see any use case that deals with response modification. Does
> anybody see a use case in which first the MTA should check for the
> response of its peer and then forward that response to the callout
> server for further modification? What can be modified here? Responses
> are only short acknowledgements or error codes. So turning an ok into an
> error would be possible but the callout server does not really need to
> see the ok first, does it?

There are some situations in which an SMTP server may wish to call forward
to another server in order to validate a user's address. For example,
Cambridge University's central email cluster acts as the MX and anti-spam
and anti-virus filter for several departmental email servers. The central
servers do not have a list of the valid email addresses for the
departmental servers. In order to verify the recipient addresses on a
message during the SMTP conversation with a client outside the University,
the central server performs an abbreviated SMTP conversation with the
departmental server to check what response it would give to the RCPT
command. 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.

This call-forward function could perhaps be implemented in the OPES
service application; however this implies that the OPES service has to
know the destination SMTP server of the call-forward. This might not be a
simple matter - MTAs can have quite complicated email address routing
rules - so it would be nice if the OPES service didn't have to have a
duplicate implementation.

On the other hand you do not want to require that message reception and
forward delivery are coupled: the point of SMTP is that it's a
store-and-forward protocol, not real-time like HTTP. This is why the
call-forward SMTP conversation is abbreviated. A result of this is that
the OPES HTTP model still doesn't apply to OPES SMTP, even with
call-forward support.

On balance I think that the model you described is sufficient, despite not
directly supporting SMTP call-forward. It is, after all, a relatively
esoteric requirement which would probably not benefit from the interop
layer that OPES would provide.

Tony.
-- 
f.a.n.finch  <[email protected]>  http://dotat.at/
SOUTH FITZROY: NORTHEAST 4 OR 5, OCCASIONALLY 6 IN SOUTHEAST. MAINLY FAIR.
GOOD.