Re: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-13

John C Klensin <john-ietf@jck.com> Tue, 29 May 2012 16:30 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131A521F86C2; Tue, 29 May 2012 09:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level:
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioEt9mg2yHgV; Tue, 29 May 2012 09:30:21 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2C08621F86BB; Tue, 29 May 2012 09:30:21 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1SZPDK-000Cfo-VT; Tue, 29 May 2012 12:24:06 -0400
Date: Tue, 29 May 2012 12:30:00 -0400
From: John C Klensin <john-ietf@jck.com>
To: Pete Resnick <presnick@qualcomm.com>, Barry Leiba <barryleiba@computer.org>
Message-ID: <9C1A8D274D060D87F0E5CC4D@PST.JCK.COM>
In-Reply-To: <4FC4E574.6000408@qualcomm.com>
References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <CALaySJKfcWZYEDeR9_WaLxDM9O-gzwV2cgER0iZRB4Ovy=YOBA@mail.gmail.com> <4FC4E574.6000408@qualcomm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: draft-melnikov-smtp-priority-13.all@tools.ietf.org, S Moonesamy <sm+ietf@elandsys.com>, apps-discuss@ietf.org, iesg@ietf.org
Subject: Re: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-13
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2012 16:30:22 -0000

--On Tuesday, May 29, 2012 10:04 -0500 Pete Resnick
<presnick@qualcomm.com> wrote:

>...
> I think you have to make a decision here: If you think that it
> harms things to have unauthenticated users specifying
> priorities, say "MUST only allow authenticated users". If you
> think that it's OK to set policy to allow anyone, say, "SHOULD
> only allow authenticated users" and explain that policy can
> change that. I have no idea how the current text is reasonably
> actionable.

Yes.

This may just be saying what Pete said in a different way but,
fwiw, it seems to me that the recipient is free to ignore a
priority specification (or (almost ?) any other header field or
piece of the envelope that tells it to do something) and to
apply whatever criteria it likes in deciding whether or not to
do so.  We don't even say "the final deliver server MUST deliver
the message to the RCPT address specified in the envelope" and
that is only in part because local aliases and a whole
collection of delivery system choices might affect that choice.
Even if the sender is authenticated, the relevant server might
decide to ignore priorities specified by anyone with an odd
number of characters in the local-part of the MAIL command or to
accept them if some other information --which we would not
consider authentication-- is present.

Given that issue, it seems to me that specifying a MUST both
implies a requirement on the recipient system that we can't
enforce and possibly creates unreasonable expectations for the
facility.

Ultimately, if one argues that having unauthenticated senders
specify priorities is harmful, one could also argue that it
causes harm to allow unauthenticated users to specify "From:"
fields.  Probably true; not helpful; clearly undesirable if
coupled with the logically-consequent "MUST not accept" such
main requirement on the recipient server.

Maybe this should be a SHOULD.  Maybe it should only be a
careful note in Security Considerations indicating that taking
action on a priority request that might have any disruptive
consequences is a really bad idea unless the sender is
authenticated and possibly even a bad idea unless the sender is
specifically authorized.  It seems to me that it is connected to
another issue, which is whether or not it makes sense to reject
a message for too low a priority when almost no semantics beyond
ordinality are specified for the priority model.  So the server
is forbidden to reject a message because no MT-PRIORITY is
specified (Section 4.1 (1)); the default priority in the absence
of

More generally, we seem to be examining and adding extensions
and headers that are actually useful only within particular
communities that share out-of-band information.  This draft is
sensitive enough to the issue that I don't see a need to
complain, but we should figure out how we want to handle them.
Specifically, one could see the conformity clauses being
organized as (I'm going to write more generally than this spec
requires):

1.  If originator, current hop client, current hop server, and
maybe destination address are all part of the same community,
then there are a bunch of rules that might reasonably include:

	(i) Current hop client, current hop server and, if
	relevant, destination server, must be authenticated and
	identified as part of the same community ("identified"
	is chosen rather than "authorized" because they might
	not be the same).
	
	(ii) Current hop server MUST support the extension.  If
	it doesn't, it is bogus and the message MUST NOT be
	passed to it.
	
	(iii) Current hop client SHOULD specify MT-PRIORITY.  If
	it doesn't, it is retarded and better have specified why
	(perhaps via some out of band related to community
	membership).
	
	(iv) Semantics for priorities are precisely specified
	within the community so there is no need for hand waving
	in the spec about ordinal matching or servers making up
	their own rules.

"Community" is not equivalent to "administrative domain" even
though many administrative domains will be communities.  So will
protected intra-organizational mail whether an administrative
domain exists or not.

(2) If, by contrast, no such community membership exists, then
this extension is pretty close to "this is what the sender might
try, but this is ultimately a "what you get is what you get"
service.

In theory, we would write a spec like that by specifying that
WYGWYG service and conformance to it in the protocol, then
providing a separate Applicability Statement that provides
different definitions and conformance rules for the XYZ
community.

I think it is possible, but hard, to mix the two within a given
draft.  The current draft provides a better approximation than
I'd normally expect.  But I think this "MUST.. authenticated"
issue is just a special case of confusion between the two.

   john