Hi,
seems that we first need a common understanding of the wording and
deployment scenario.
Right now I am quite concerned by the wording and the drafts.
I read that the idea is that the OPES _is_ an MTA? Also there
is no interaction between MTAs (or I misread the part on
"previous" commands, which should be read with a wider meaning?).
I think we should not talk about "the OPES".
Please let's stick with the wording we agreed on earlier: There are
two agents: OPES processor and callout server.
The filtering functionality is on the callout server.
No difference between HTTP and SMTP here. The callout server may
even support adaptation of both messages for both protocols.
That is our application agnostic approach. The callout server
is an OCP server with some filtering services.
The OPES processor is a standard device that sits in the data stream
of the protocol we want to handle. That device gets enhanced by an
OCP client that allows to vector out that data to the callout server.
In HTTP the OPES processor is a proxy server; for SMTP we picked
a MTA as the primary device that sits in the SMTP data stream.
If I note UA as U, MTA ad M, MSA as S, MDA as D, Filters as F
and OPES as O, here is the scheme I understand:
[...]
Much too complicated in my view.
Let me try to bring in the other M*A things here and map that to
the normal programs that we see today when sending email:
You start with an email client program such as Outlook. This is your MUA,
allowing you to write the email.
From there you send email to an outgoing email server. In that email
server an MSA (mail submission agent) is waiting for your email and uses a
MTA (mail transfer agent) within the same server to forward this email to
other domains.
(Communication between the MUA and MSA may already be via SMTP or something
else such as MAPI; one reason why we do not concentrate on these devices).
The MTA in your email server may directly contact the email server of the
recipient our use other intermediate email gateways. On the sending email
server, the destination email server and all intermediate gateways MTAs are
running to send/receive/forward the SMTP messages.
That is why we concentrate on MTAs. Nearly all email which is not locally
handled within your domain, is sent this way via SMTP via two or more MTAs.
In the destination email server there is then a MDA (mail delivery agent)
that may put the email in the recipient's mailbox. The email client program
of the recipient will then probably use a different protocol (such as
POP3 or IMAP) to access the mailbox and retrieve/read the messages.
|---------| |----------| |-----------| |----------| |---------|
| email M| |M email M| SMTP |M email M| SMTP |M email M| |M email |
| client U|----|S server T|------|T gateway T|------|T server D|----|U client |
| A| |A A| |A A| |A A| |A |
|---------| |----------| |-----------| |----------| |---------|
| | |
| OCP | OCP | OCP
| | |
|----------| |-----------| |----------|
| callout | | callout | | callout |
| server | | server | | server |
|----------| |-----------| |----------|
So the OPES processor might be the sender's SMTP server, the destination SMTP
server or any intermediate SMTP gateway.
(Which building block belongs to which authorotive domain is an important
question but different from deployment to deployment).
As you can see from the picture above, the MTA is either receiving or sending an
email (or both) within an email server/gateway. These are the two activation
points
that section 5 of the draft wants to tell about.
Do we agree on what I wrote here?
Regards
Martin