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
- Re: OPES and Email Tony Hansen
- Re: OPES and Email Frank Ellermann
- Re: OPES and Email SM
- Re: OPES and Email Tony Hansen
- Re: OPES and Email Matti Aarnio
- OPES and Email Tony Hansen
- Re: OPES and Email Bruce Lilly
- Re: OPES and Email John C Klensin
- Re: OPES and Email John Leslie