Tony, Martin,
please consider my initial proposition (repeated in my yesteray analysis)
and how it fits to this? We are in a store and complex forward system
(while http was a single forward one). This is true of the whole MTA but
also true for most of the modules building the MTA. RFC 1958 says that we
should proceed simple step by simple step.
What are the objections to consider filtering the stored data, without
considering the forwarding data flow? So the SMTP mechanism are fully
respected (not touched) and the maximum complexity can be supported (one
step at a time) where ever the filtering and return occurs.
1. with HTTP we have a logic for acting on a live traffic.
2. with SMTP we will have a logic for acting on files.
3. data handling is the same.
4. whatever the complexity, we just look at the status of the file, change
it or not; the server bears the complexity, but this is out of the OPES design?
jfc
At 22:28 21/01/2005, Martin Stecher wrote:
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