Hi Tony,
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.
[...]
Thank you for this real world use case.
Not sure whether you see this as a response modification example, it's not IMO:
The university's central email server can send the RCPT
command to the callout servers that have access to the departmental
user directories and get the reply for this command in response to its
OCP request.
But it is not necessary to first create a pseudo reply in the central
mail server and to have that modified by the callout server. That
pseudo response would have no meaning to the callout server.
Regards
Martin