Re: OPES and Email

John C Klensin <john+smtp@jck.com> Fri, 08 July 2005 18:24 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68IOJ6s035027; Fri, 8 Jul 2005 11:24:19 -0700 (PDT) (envelope-from owner-ietf-822@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68IOJaN035025; Fri, 8 Jul 2005 11:24:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-822@mail.imc.org using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68IOH98035002; Fri, 8 Jul 2005 11:24:18 -0700 (PDT) (envelope-from john+smtp@jck.com)
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1DqxWF-0008jl-If; Fri, 08 Jul 2005 14:24:11 -0400
Date: Fri, 08 Jul 2005 14:24:11 -0400
From: John C Klensin <john+smtp@jck.com>
To: John Leslie <john@jlc.net>, Tony Hansen <tony@att.com>
cc: ietf-822 <ietf-822@imc.org>, ietf-smtp@imc.org
Subject: Re: OPES and Email
Message-ID: <ADA16AB923761A87D9069FF1@scan.jck.com>
In-Reply-To: <20050708173735.GF10228@verdi>
References: <42CD7B57.1050606@att.com> <20050708173735.GF10228@verdi>
X-Mailer: Mulberry/4.0.1.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>

--On Friday, 08 July, 2005 13:37 -0400 John Leslie
<john@jlc.net> wrote:

> Tony Hansen <tony@att.com> wrote:
>> ... 
>> OPES SMTP Use Cases (draft-ietf-opes-smtp-use-cases-02.txt).
>> ...
>>    The Open Pluggable Edge Services (OPES) framework is
>>    application agnostic.  Application specific adaptations
>>    extend that framework. This document describes OPES SMTP
>>    use cases and deployment scenarios in preparation for SMTP
>>    adaptation with OPES.
> 
>    We should be very careful here. "Open Pluggable Edge
> Services" suggests we're talking only about "edge services";
> and IMHO we should be sure to explain any situations where the
> OPES WG might have a different opinion than others as to what
> an "edge service" is.
> 
> ] 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'm afraid we start out with different opinions. :^(
> 
>    MTAs have a number of functions; some of which we consider
> to be "edge" functions, and some which we don't. (YMMV.)
>...

Tony,

Let me add one impression to John's useful explanation...

In terms of the structure and language of 2821 (and 2821bis,
which I just sent off for posting (!)), the only MTAs (SMTP
clients or servers) that are even vaguely "edge" services or
systems are:

	* The originator (aka the submission server or MSA)
	
	* The destination server
	
	* A gateway

The definitions of the first and second in 2821/ 2821bis are
deliberately a little fuzzy, but most of us think we know one
when we see one and would probably be in 95% agreement on any
given case.  The discriminating definitions for a gateways is
also a bit fuzzy, but there was an effort during the DRUMS
period to keep that definition firm enough to make it hard for
someone to say "I want to do what would otherwise be considered
Bad Things, hence I will claim to be a gateway".

All of the other cases are relays (with some funny edge cases
around what a non-primary MX can do or not do), and actions
committed by them, especially some of the modifications
suggested in the OPES draft, would, from a 2821 perspective,
constitute mucking around in the middle of the mail environment.
Such actions are prohibited to the extent to which 2821 can
prohibit anything.  

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.

best,
     john