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

From: "Martin Stecher" <[email-masked]>
Date: Thu, 13 Jan 2005 15:50:54 +0100

Hi folks,
 
please have a look at chapter 5, the OPES SMTP based services.
 
We tried to find the similarities and differences to the HTTP case described in RFC 3752.
I believe that this is very essential for this document and will help us a lot when later doing the OCP profile.
 
After writing this first draft, I keep thinking about it and would like to simplify further.
Could I have your comments on the following please?
 
In HTTP we have a request that goes all the way from the client thru proxies to the server and the response going back the same way.
The commands and replies in the SMTP dialog are always just between each hop.
 
While we see the need to involve the callout server on a per-command basis, the commands and replies of one dialog belong together
and services may have the need to refer to earlier commands of the same dialog.
 
In total I see all use cases to deal with SMTP commands. The email message body is also nothing else but the value of a DATA
command.
We see services that want to modify command values and those that want to block commands by defining an error reply that the
MTA should send in response to the reply it received (for receiving mail activation point, see below).
So, we have command modification and command satisfaction, analog to request modification and request satisfaction that we
know from HTTP.
 
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?
 
So, if you agree we can reduce everything to command modification and command satisfaction for every possible command.
Depending on the activation point (receiving or sending email) the OPES processor == MTA will do different things with the
callout server reply:
 
 1. MTA receives email, i.e. it receives SMTP commands and vectors them out to the callout server
       a) callout server modified the command value: MTA will treat the modified value as if it received it that way from its SMTP peer
       b) callout server returns an SMTP error-reply: MTA will send that error code to its SMTP peer
 
 2. MTA sends email, i.e. generates SMTP commands and vectors them out to the callout server
       a) callout server modified the command value: MTA will send modified command to its SMTP peer
       b) callout server returns an SMTP error-reply: MTA does NOT send the command to its SMTP peer but treats the error as if it received it from the SMTP peer
 
I can regroup all use cases to fall into the four categories plus the side effects that we see from some use cases (section 7.3)
Services operating on email message content (section 7.1) are not longer special. They are just the cases where the callout server operates on the DATA command.

Best regards
Martin
 
 -----Original Message-----
From: Abbie Barbir [mailto:[email-masked]]
Sent: Thursday, January 13, 2005 2:55 PM
To: OPES Group
Cc: Markus Hofmann; Martin Stecher; [email-masked]
Subject: [draft-ietf-opes-smtp-use-cases-01]

All, 

attached is the first version of the 
draft-ietf-opes-smtp-use-cases-01. 

This is the time to get engaed and provide feedback on the draft. Let us do that for the next week and then we can update it and send it to the ietf list as a WG draft.

Thanks 
Abbie Barbir 
Nortel Networks

---

From: jfcm <[email-masked]>
Date: Fri, 14 Jan 2005 02:42:07 +0100

Martin,
you may be fully right. But I would suggest that we follow the agenda 
proposed by Abbie. One week to understand and possibly enhance or review 
the existing cases. I understand that you want to continue the work you 
engaged. But for us your document is new and we need to digest your work 
(just to make sure you listed all my cases and I do not see some others 
:-). Or we may lose some thinking (and some Members) if we do not wait for 
everyone to have time to come to speed?
Thank you for the work done.
jfc

At 15:50 13/01/2005, Martin Stecher wrote:

>In HTTP we have a request that goes all the way from the client thru 
>proxies to the server and the response going back the same way.
>While we see the need to involve the callout server on a per-command 
>basis, the commands and replies of one dialog belong together
>In total I see all use cases to deal with SMTP commands. The email message 
>body is also nothing else but the value of a DATA
>command.
>We see services that want to modify command values and those that want to 
>block commands by defining an error reply that the
>So, we have command modification and command satisfaction, analog to 
>request modification and request satisfaction that we
>know from HTTP.
>
>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
>So, if you agree we can reduce everything to command modification and 
>command satisfaction for every possible command.
>Depending on the activation point (receiving or sending email) the OPES 
>processor == MTA will do different things with the
>callout server reply:
>
>        a) callout server modified the command value: MTA will treat the 
> modified value as if it received it that way from its SMTP peer
>        b) callout server returns an SMTP error-reply: MTA does NOT send 
> the command to its SMTP peer but treats the error as if it received it 
> from the SMTP peer
>
>I can regroup all use cases to fall into the four categories plus the side 
>effects that we see from some use cases (section 7.3)
>Services operating on email message content (section 7.1) are not longer 
>special. They are just the cases where the callout server operates on the 
>DATA command.
>
>
>Best regards
>Martin
>
>This is the time to get engaed and provide feedback on the draft. Let us 
>do that for the next week and then we can update it and send it to the 
>ietf list as a WG draft.
>
>Thanks
>Abbie Barbir
>Nortel Networks

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 13 Jan 2005 20:54:50 -0500

All,

just for clarification - submitting a -00 version of the draft does 
*not* imply that the draft is finalized. There's plenty of opportunity 
for suggestions and contributions after submission of the -00, which 
will then result in subsequent versions.

Thanks,
   Markus

jfcm wrote:
> :-). Or we may lose some thinking (and some Members) if we do not wait 
> for everyone to have time to come to speed?
>> I believe that this is very essential for this document and will help 
>> us a lot when later doing the OCP profile.
>>  
>> In total I see all use cases to deal with SMTP commands. The email 
>> message body is also nothing else but the value of a DATA
>> command.
>> We see services that want to modify command values and those that want 
>> to block commands by defining an error reply that the
>> 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
>> Depending on the activation point (receiving or sending email) the 
>> OPES processor == MTA will do different things with the
>> callout server reply:
>>  
>>        a) callout server modified the command value: MTA will treat 
>> the modified value as if it received it that way from its SMTP peer
>>        b) callout server returns an SMTP error-reply: MTA does NOT 
>> send the command to its SMTP peer but treats the error as if it 
>> received it from the SMTP peer
>>  
>> I can regroup all use cases to fall into the four categories plus the 
>> side effects that we see from some use cases (section 7.3)
>> Services operating on email message content (section 7.1) are not 
>> longer special. They are just the cases where the callout server 
>> operates on the DATA command.
>>  
>>  
>> Best regards
>> Martin
>>  
>> *From:* Abbie Barbir [mailto:[email-masked]]
>> *Sent:* Thursday, January 13, 2005 2:55 PM
>> *To:* OPES Group
>> *Cc:* Markus Hofmann; Martin Stecher; [email-masked]
>> *Subject:* [draft-ietf-opes-smtp-use-cases-01]
>>
>>     All,
>>
>>     This is the time to get engaed and provide feedback on the draft.
>>     Let us do that for the next week and then we can update it and
>>     send it to the ietf list as a WG draft.
>>
>>     Thanks
>>     Abbie Barbir
>>     Nortel Networks

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 19 Jan 2005 16:16:49 -0700

I wonder if it is worthwhile noting a particular kind of non-symmetry
that is common today.  Most people run SMTP on their local machine in
order to send messages, but they do not run SMTP to receive messages;
that is done by a remote server, and the user runs a different
protocol (a Mail Retrieval Client?) to fetch the mail.  That means
that and OPES server that is closest to the user will probably be
acting as an SMTP relay, while that same server will be an SMTP
endpoint for messages destined to that user.  Hope that's clear :-)

Parts of the document are difficult to understand, particularly
the part about referring to earlier commands.  What is that about?

Some of the content adaptation use cases seem at odds with the earlier
part of the document that say that these are part of the "mail
delivery agent" which is NOT part of the MTA.  So I'd have expected
those use cases to be out-of-scope.  What am I misunderstanding?

I can see "response modification" use cases that attempt to
deal with "recipient unknown", for example.  It would be a way
of implementing a "universal identity" on a incremental basis.
If delivery fails, you consult the universal identity for
an alternative delivery method.  Yes, the MDA or the MUA could
do it, but it's a nice "in-the-network" kind of service.

Yes, I think that operating on the DATA portion fits into the
architecture without the need for special consideration.

Hilarie

---

From: jfcm <[email-masked]>
Date: Thu, 20 Jan 2005 01:19:37 +0100

>endpoint for messages destined to that user.  Hope that's clear :-)

It is very clear. However please note that MTA cascade on the mail path and 
that we consider OPES on MTA (not on UA), so we do not really know where 
the user end is. Since we are to deal with SMTP and we want to stay with 
MTA only we can say that the end to end finishes at the last MTA?

The full symetry I documented is not for us to document it as symetric and 
to take care of MDA and MSA, but to understand what are the impacts the 
agents sequence implies and where the OPES should return even if we only 
care about MTA.

>those use cases to be out-of-scope.  What am I misunderstanding?

I understood it as the MTA output to the MDA?
This is why I put an OPES filter in each MTA filter.

>do it, but it's a nice "in-the-network" kind of service.

Are some others not too? I objected a lot to the MTA location on this very 
ground because the charter permits it. I repeated it is what I call ONES 
and not what IAB calls OPES.

>architecture without the need for special consideration.

I am not sure I understand this. I need a example. Let say I have in the 
text something a filter should accept as "disregard the rules to apply 
because of the header" or to change the header, etc. Is that supported?

jfc

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Jan 2005 20:13:58 +0000

On Thu, 13 Jan 2005, Martin Stecher wrote:
> 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-masked]>  http://dotat.at/
SOUTH FITZROY: NORTHEAST 4 OR 5, OCCASIONALLY 6 IN SOUTHEAST. MAINLY FAIR.
GOOD.

---

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

On Thu, 13 Jan 2005, Martin Stecher wrote:
>           the command to its SMTP peer but treats the error as if it

Following on from what jfcm said, I can't see any use cases in the
existing draft which fall into the second pair of these categories, and
I'm not sure that anything out in the real world falls into them either.
Current email filtering systems either operate at SMTP time (e.g. the
Sendmail milter system, or Exim's access control lists) or they operate on
messages after reception (e.g. MailScanner) either on the MTA's queue or
by being handed from the MTA to the filter and back again.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
CULLERCOATS: GALE OR SEVERE GALE FORCE NORTHERLY WINDS SLOWLY DECREASING.