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

From: "Martin Stecher" <[email-masked]>
Date: Sat, 22 Jan 2005 17:03:25 +0100

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-masked]]
> Gesendet: Samstag, 22. Januar 2005 08:12
> An: Martin Stecher
> Cc: [email-masked]
> 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
>

---

From: Tony Finch <[email-masked]>
Date: Sat, 22 Jan 2005 18:40:27 +0000

> SMTP comunication. This can be translated into request satisfaction

I brought it up because I think it's worth thinking about, if only to
conclude that the proposed model is the right one.

The reason I thought it could perhaps be considered as a response
modification scenario is that the destination server's 4xx response is
converted by the MX server into a 2xx response. In addition to that it's
rather ugly to have the OPES callout server implement the SMTP
call-forward, because you have to duplicate knowledge of email address
routing in the MTA and the OPES callout server. Yes, you can fix this
problem by using better ways of distributing knowledge about shared
addresses, but this requires co-operation between the people that run the
two MTAs and this may not be practically feasible. (In the case of
Cambridge the University is run on a rather federal basis, so the
Computing Service can't impose technical requirements on departments.
Another situation in which this technique is useful is when a site has
secondary MXs run by a different organization.)

However as you say it 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.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
EAST CENTRAL SECTION: IN NORTH, WESTERLY 5 OR 6 AT FIRST IN EAST OTHERWISE
EASTERLY OR NORTHEASTERLY 5 OR 6, VEERING SOUTHEASTERLY 5 TO 7. RAIN AT FIRST.
MODERATE BECOMING GOOD. IN SOUTH, SOUTHWESTERLY 4 OR 5 BACKING EASTERLY OR
SOUTHEASTERLY 5 TO 7. OCCASIONAL RAIN. MODERATE OR GOOD.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sat, 22 Jan 2005 11:46:09 -0700

OPES is supposed to enable new services.

The call-forward wouldn't have been a hack if it had been done as
part of an OPES service, using the same architectural model that
we used for HTTP.  Further, we rule out a large number of useful
identity-based services by eliminating the ability to do
response modification.  

Hilarie

On Sat, 22 Jan 2005 at 18:40:27 +0000 Tony Finch announced:

> it doesn't really fit into the OPES model because the