Re: OPES and Email

["Hector Santos" <[e-mail]>]

----- Original Message -----
From: "John C Klensin" <[e-mail]>


>> ] In SMTP the OPES processor may be any agent participating in
>> SMTP ] exhanges, including MSA, MTA, MDA, and MUA.  This
>> document focues on ] use cases in which the OPES processor is
>> a mail transfer agent (MTA).
>
> Note that, while most of us know, more or less, what all of
> those nice abbreviations mean, there is no consensus definition
> for an MDA (the 2821 definition of a "delivery MTA" may or may
> not be the same thing) nor, IMO, does was the submission
> terminology of RFC 2476 or 2476bis (aka "originating server" in
> 2821) intended to  adequately delimit the "MSA" term.

I always felt there were conflictive usage of MSA, "SUBMIT" "SUBMISSION"
with or without 2476/bis.

In my view,

  MDA  -  Unauthorized Final Delivery Agent
  MSA  -  Authorized Submission Agent (Final or Route)

The MSA implies there is an association with the sender, like the MUA or
authorized MTA.   But if its not unauthorized, then it can only act as a MDA
(based on BCP).

> You know all of this.  The question for me is that, given that
> the OPES doc pushes really close to, or past, the boundary in
> which its recommendations and structure require violating the
> provisions of 2821, how would you like people to respond in a
> way that would be most constructive?  The answer obviously
> interacts with several of the discussion threads on the
> ietf-smtp list during the last few weeks, including such
> questions as the legitimacy or appropriateness of mail relays
> doing virus removal.

And intentionally so, because whether its OPES or not, this is no doubt a
growing reality in the SMTP process for the idea of extending the
functionality either by "shimming" it, hooking it, calling sinks, callouts,
"Web Services",  "RPC"  etc, etc. From the point of view of the "SMTP
receiver"  it is a "blackbox" concept:

       result =  CALLOUT (State, parameters)

What would be nice is to get 2821/bis to being to realize this reality and
begin to define (revisit) the integration standard which from a SMTP
standpoint is:

At a minimum for backward capability:

    - Timeout Considerations
    - Returning Proper Response Codes

New considerations (really revisit, because its already there):

    - Process Variables passing
    - Keep Alive Concepts
    - Call Out Extended Response Concept

We already have systems that have dynamic logic for sinks, hooks, or
callouts.  Exim has ACL,  SendMail has Mfilters,  WildcatSMTP calls them WCX
hooks.  We also have the standard Sieve usages as well, although I believe
most do this on a post SMTP basis, don't know of Sieve is used dynamically
within SMTP.

These ideas are being used more and more, and I will venture it will main
stream once the new email authentication/authorization "extended protocols"
are adopted on a wider basis.

Whatever the SMTP CALLOUT method,  it  would be nice is the standard or
refocus on the SMTP interfacing concept.

Anyway for this draft, OPES SMTP Use Cases,  it is functional outline that
touches base with some technical conflicts.  I am not sure if the details
should be in the document level, but it should be consistent in terminology
and usage of examples.

When I looked this document, I imagine "What if" there existed a Proxy
Service out there that my SMTP server can call out too.  What will it take,
and what will be the issues.

Well,  in the same way a CBV is a Callout to some "remote host/service" to
validation the return path (RPATH):

   result = CBV_RPATH_VALIDATOR(mail from)

the same basic issues that we confronted here, will be the same if it was
plugged and played with something else:

   result = OPES_RPATH_VALIDATOR_SERVICE(parameters)

I already added my comments here about this:

    - How parameters are passed
    - How results are turned
    - Timeout issues

The latter was discussed in this link showing how SMTP 1xy continuation
results codes can be used to Keep Alive a SMTP server during a "Call Out"
session at the receiver:

http://www.imc.org/ietf-openproxy/mail-archive/msg03282.html

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com