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

Hilary,

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

Let's have a look at a typical (minimum) SMTP dialog between two MTAs:

S: - for the sender
R: - for the recipient

R: 220 mail.example.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at  Thu, 20 Jan 2005 11:24:40 +0100
S: HELO ThatsMe
R: 250 mail.example.com Hello [192.168.0.138]
S: MAIL FROM: [email protected]
R: 250 2.1.0 [email protected] OK
S: RCPT TO: [email protected]
R: 250 2.1.5 [email protected]
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: From: [email protected]
S: To: [email protected]
S: Subject: Test
S: 
S: Hi, this is a test!
S: .
R: 250 2.6.0 <[email protected]> Queued mail for delivery
S: QUIT
R: 221 2.0.0 mail.example.com Service closing transmission channel


The sender is generating commands and the recipient is generating replies. Replies
all start with a status code and then some text.
At minimum 4 commands are needed to send an email. All commands and replies to send
a single email message together form "the dialog".

The mail message body is the data sent after the "DATA" command. (It is not really
the DATA command's value as I notice right now because we have one reply for the
DATA command and another reply to ack the body data).

If a callout service wants to adapt the email message body, it is mainly interested
in the this part of the dialog:

   From: [email protected]
   To: [email protected]
   Subject: Test
   
   Hi, this is a test!

Still it may also want to see values of previous commands of the same dialog
(that is what I meant with "earlier commands").
Look at the value of the RCPT command! It is "[email protected]" which is
different from the "[email protected]" that the email client displays in the
visible "To" field.
That might be an important fact for some filters such as Spam Filters.


> 
> 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?

The term "side effects on the mail delivery" is not perfect, I agree.
What I mean here is a number of side effects that a callout service
may want to trigger that influences the next steps within the email
server or gateway. Not all of that is a pure MTA role but typical
things that an email intermediate can do, for example:

   1. Delay the email, don't forward immediatly
   2. Send an additional notification
   3. Exchange the recipients
   4. Don't forward but store email in quarantaine
   5. Use another next hop MTA (routing)

None of this can be done by only modifying the email message body.
#3 can be acchieved by exchanging the RCPT command value (but that
has been handled already before; how to get back?)
#2 can be acchieved by generating another OCP response

But I think that we will need some negotiations between OPES processor
and callout server about which side effects are allowed/supported and a
way to trigger them thru special parameters in the OCP response.


> 
> 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.

Is this really "response modification"?
The sender generates the command
   RCPT TO: [email protected]
The receiver would generate a response 
   550 No such user here
But before replying this, it sends a response modification OCP
message to the callout server?
The callout server cannot change the response: the user will still
be unknown.
It needs to change the command's value and resolve the alias
"[email protected]" into "[email protected]"

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

As noticed above, it is not a real command value, so we need to mention
it explicitly. But still the message content it is "like a command" and
we should be able to treat it the same way.

Regards
Martin