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

Hilary,

I do not want to reject a reasonable respmod scenario, I just do not
understand why this IS a response modification example.

Tony describes how it is being solved today by using abbreviated
SMTP comunication. This can be translated into request satisfaction
in OPES as I described.

And certainly every request satisfaction could also be implemented
as a response modification by ignoring the original response.

But if in all use cases we found so far, the original response is
ignored, why do we need a RESPMOD then at all?

Regards
Martin

> -----Ursprüngliche Nachricht-----
> Von: The Purple Streak, Hilarie Orman [mailto:[email protected]]
> Gesendet: Samstag, 22. Januar 2005 08:12
> An: Martin Stecher
> Cc: [email protected]
> Betreff: RE: [draft-ietf-opes-smtp-use-cases-01]
> 
> 
> I think you are rejecting a reasonable response modification scenario
> by saying "implement your service another way."  I don't see any
> reason to exclude having the response modification done "in the flow".
> 
> Hilarie
> 
> On Fri, 21 Jan 2005 at 22:28:29 +0100 Martin Stecher said:
> >  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
>