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: steve(_at_)sender(_dot_)com
R: 250 2.1.0 steve(_at_)sender(_dot_)com(_dot_)(_dot_)(_dot_)(_dot_)Sender OK
S: RCPT TO: paul(_at_)example(_dot_)com
R: 250 2.1.5 paul(_at_)example(_dot_)com
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: From: steve(_at_)sender(_dot_)com
S: To: sandra(_at_)example(_dot_)com
S: Subject: Test
S:
S: Hi, this is a test!
S: .
R: 250 2.6.0 <MAILYwekrt0Goqm4bVS00005b1f(_at_)mail(_dot_)example(_dot_)com>
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: steve(_at_)sender(_dot_)com
To: sandra(_at_)example(_dot_)com
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 "paul(_at_)example(_dot_)com"
which is
different from the "sandra(_at_)example(_dot_)com" 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: paul(_at_)example(_dot_)com
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
"paul(_at_)example(_dot_)com" into "paul(_dot_)miller(_at_)example(_dot_)com"
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