Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 01 June 2012 13:23 UTC

Return-Path: <alexey.melnikov@isode.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 BF2BC11E8106; Fri, 1 Jun 2012 06:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.914
X-Spam-Level:
X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=-0.315, 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 iE5m5Hkq0pz9; Fri, 1 Jun 2012 06:23:28 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 64E3611E8089; Fri, 1 Jun 2012 06:23:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338557006; d=isode.com; s=selector; i=@isode.com; bh=vkPlyMXzLw7INl3frsCgq7Br3GPg7TwWqXST2FrLFrM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cu8/o9ICH80O8XfISOdofoG2l07qMqETXALW5GExmPfxfv6aBDRRNxEJUYwphn5jET2JfZ 9zagv6Zzj1lrsA9BOh0kaD+zFt1gpBqe5L+oYMKeSQmPDgFZmXRV7sr2F423NBl92cnVYI AtCOZj+0l+c8xS0Ga+qn8cNKjz4gA2w=;
Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T8jCTAAE40pZ@rufus.isode.com>; Fri, 1 Jun 2012 14:23:25 +0100
X-SMTP-Protocol-Errors: NORDNS PIPELINING
Message-ID: <4FC89931.5060201@isode.com>
Date: Fri, 01 Jun 2012 11:28:01 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: dcrocker@bbiw.net
References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net>
In-Reply-To: <4FC722A2.2050905@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14
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: Fri, 01 Jun 2012 13:23:30 -0000

On 31/05/2012 08:49, Dave Crocker wrote:
> This review is at my own initiative.

Dave,
Thank you for the review.

I've applied most of your editorial changes (and spelling fixes) as is. 
I've deleted them from my reply.
I will reply to different parts of your review in separate messages.

>> 2.  Conventions Used in This Document
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>    document are to be interpreted as described in [RFC2119] when they
>>    appear in ALL CAPS.  These words also appear in this document in
>>    lower case as plain English words, absent their normative meanings.
>
> "when they appear in ALL CAPS".  sigh. In other words, this document 
> is modifying RFC2119.
>
> Does anyone seriously expect this new nuance of usage to be read and 
> remembered by average readers of this document?

> FWIW, it took me about 3 minutes to make the relevant changes, below. 
> Case-sensitivity in semantics invites comprehension problems here. 
> Worse, there is absolutely no need or benefit in creating the problem 
> for this document.  At a minimum, please do not try to modify IETF 
> document writing policy on the fly.

I will let IESG weight in on this. I've implemented what I was told 
earlier. I don't have a strong opinion on this.

>> 4.1.  Handling of the MT-PRIORITY parameter by the receiving SMTP server
>>
>>    The following rules apply to SMTP transactions in a server that
>>    supports the MT-PRIORITY parameter:
>>
>>    1.  A conforming SMTP server MUST NOT refuse a MAIL FROM command
>>        based on the absence of the MT-PRIORITY parameter.
>
>
> hmmm.   For some operational environments, it will be essential to 
> have /all/ handling conform to the priority policy model in force for 
> the environment.  In those cases, the absence of the parameter would 
> be a violation of the spec.

Good point. Deleted.

>>
>>    5.  If no priority has been determined by the above, the server may
>>        use its normal policies to set the message's priority.  By
>>        default, each message has priority 0.
>
> ouch.  This chooses a particular model for meaning of the numbers, and 
> without having defined the model beforehand.
>
> That is, I think the problem with this default is that it really is 
> assuming a particular policy for meaning of the values, namely that 
> average mail is mid-priority, assuming the numbers have linear semantics.

Why is this a problem (commenting on the last sentence quoted above)?

>>    however, allow an untrusted source to lower its own message's
>>    priorities -- consider, for example, an email marketer that
>>    voluntarily sends its marketing messages at low priority.
>
> To beat the point a bit deader:  this assumes a particular policy for 
> the meaning of the priority values.  Worse, it also appears to 
> contradict the earlier default of 0, but perhaps I've misunderstood that.

Yes, you misunderstood. The example talking about marketing messages is 
an example of a sender that explicitly requests priority below 0.

>>    450 or 550 reply code.  The corresponding enhanced status code MUST
>>    be X.7.TBD1 [RFC2034] if the determined priority level is below the
>>    lowest priority currently acceptable for the receiving SMTP server.
>>    Note that this condition might be temporary, in cases where the
>>    server is temporarily operating in a mode where only high priority
>>    messages are accepted for transfer and delivery.
>
> Given a range of 0-9, what qualifies as high priority and what 
> qualifies as low?
>
> Perhaps:
>
>    Note that this condition might be temporary.  In some environments, 
> operational policies might permit periods of operation that relay only 
> higher priority messages and defer lower priority ones.  Such handling 
> choices need to be specified for that operational environment..

Ok. I used a slightly modified version of your suggested text.

>> 4.4.  Mailing lists and Aliases
>>
>>    Several options exist to translate the address of an email recipient
>
> "options"?  Perhaps you mean mechanisms or services?

Yes.

> And they really aren't translating an address but are doing a form of 
> message transmission (relaying, or the like).

Suggested replacement?

>>    into one or more other addresses.  Examples for this are aliases and
>>    mailing lists [RFC5321].
>>
>>    If a recipient address is to be translated and/or expanded when
>>    delivered to an alias or a mailing list, the translating or expanding
>>    entity (MTA, etc.)  SHOULD retain the MT-PRIORITY parameter value for
>>    all expanded and/or translated addresses.
>
> This appears to expect the extension's semantics to survive delivery 
> and re-posting via a mailing list.  Remember that a mailing list posts 
> a /new/ message.  Offhand, this requirement seems to go considerably 
> beyond normal SMTP options and beyond most Internet Mail standards 
> services...

This is the same as for the DSN SMTP extension. So no, this is not the 
first time.
>
> At the least, this needs considerably more extensive and careful 
> documentation that it is given here.
>
>
>> 4.5.  Gatewaying a message into a foreign environment
>>
>>    The following rules govern the behavior of a conforming MTA, when
>>    gatewaying a message that was received via the SMTP protocol, into a
>>    foreign (non-SMTP) environment:
>>
>>    1.  If the destination environment is unable to provide an equivalent
>>        of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as
>>        if it is relaying to a non-conformant SMTP server (Section 4.3).
>
> Given the variable semantics that apply here -- per the different 
> policy possibilities -- what does it mean to be an equivalent of the 
> MT-PRIORITY parameter, in specific technical terms?

The point is that if I am trying to gateway to the Royal Pigeon Mail 
Service and it doesn't support anything similar to priorities at the 
protocol level, then this is treated as relaying to a non-conformant 
SMTP server.


>>    2.  If the destination environment is capable of providing an
>>        equivalent of the MT-PRIORITY parameter, the conforming MTA
>>        SHOULD behave as if it is relaying to a conformant SMTP server
>>        (Section 4.2), converting the MT-PRIORITY value to the equivalent
>>        in the destination environment.
>
> Is this really enough technical and operational detail to cover 
> gatewaying?  Perhaps it is, but it feels to me as if it isn't.  Then 
> again, I don't know what more/else to suggest.

I don't know either :-).


>> 4.6.  Interaction with DSN SMTP Extension
>>
>>    An MTA which also conforms to [RFC3461] SHOULD apply the same
>>    priority value to delivery reports (whether for successful delivery
>>    or failed delivery) it generates for a message.
>
> In many operational environments, control messages get higher priority 
> (or lower priority) than payload messages.

What is a control message?

Any suggested text?


>>    Note that rejections based on priority (see Section 4.1) or priority+
>>    message size combination SHOULD only be done by an MSA (i.e. they
>>    SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the
>
> This presumes that an MSA knows the priority-related policies of 
> downstream MTAs and MDAs.

I don't think so. Why do you say that?


>>    Mail User Agents (MUAs) which generated the message and is in a
>>    position to perform a corrective action, such as resubmission of the
>
> resubmission with lower priority is a big deal but seems to get a 
> rather casual reference here.
>
>
>>    message with lower priority, converting or truncating the message to
>>    make it smaller, etc.  Such actions usually require user interaction.
>>    For this reason it is also important for MUAs to support enhanced
>>
>>
>
>>    with a lower one.  Additionally, the retry interval and/or default
>>    timeout before non-delivery report is generated can be lower (more
>>    aggressive) for messages of higher priority.
>
> oh?  "can be"?

Should have been "MAY be".

> This sort of language looks like it is specifying something but it 
> isn't.  And the reference to what "can be" carries no cautions or 
> directions meaningful to implementers.
>
>
>>    Note that as this SMTP extension requires some sort of trust
>>    relationship between a sender and a receiver and thus some for of
>
>    for -> form  (?)

Yes.

> This is treated as a side comment (by introducing it with "Note") but 
> I believe it is in fact a core predicate for the extension.
>
>
>>    authentication (whether using SMTP AUTH, TLS, IP address whitelist,
>>    etc.), so senders using this SMTP extension will not be subject to
>>    greylisting [GREYLISTING], unless they are unauthorized to use this
>>    SMTP extension, due to an explicit policy decision or a
>>    misconfiguration error.
>>
>>    In order to make implementations of this extension easier, this SMTP
>>    extension only allows a single priority for all recipients of the
>>    same message.
>
> This is quite a good and clear simplification point.  However note 
> that a model which permits selective support of priority values winds 
> up going counter to that goal of simplification.

Well, simplification doesn't apply to everything in this extension. Some 
tradeoffs were made....

>>
>> 5.2.  Timely Delivery
>>
>>    An important constraint (usually associated with higher priority
>>    levels) is that messages with high priority have some delivery time
>>    constraints.  In some cases, higher priorities mean a shorter maximum
>>    time allowed for delivery.
>>
>>    Unextended SMTP does not offer a service for timely delivery.  The
>>    "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
>>    [RFC2852] is an example of an SMTP extension providing a service that
>>    can be used to implement such constraints.  But note that use of the
>>    DELIVERBY extension alone does not guarantee any priority processing.
>
> It seems as if this section introduces an issue but does not actually 
> deal with it.  Perhaps there should be some discussion of the possible 
> (or required?) interaction between the two extensions it discusses?

There is no issue and no real interaction in this specific case. A 
client that wants to use both against a server that supports both should 
consider this issue.


>> 8.  Deployment Considerations
>>
>>    If multiple DNS MX records are used to specify multiple servers for a
>>    domain in section 5 of [RFC5321], it is strongly advised that all of
>
> "strongly advised"?
>
> This seems the sort of thing that needs normative language yet it is 
> carefully avoided.  That is, by saying 'strongly' the issue is moved 
> towards the asking why it is not stated normatively.  I'd guess this 
> needs a SHOULD, possibly with discussion of permissible exceptions 
> (such as the open Internet...?)

This section applies to system administrators. It is quite different 
from the rest of the document which contains mostly protocol level 
requirements. So yes, I avoided usage of RFC 2119 keywords here on purpose.
Suggestions for alternatives are welcomed.

> However note that the 'strongly advised' presumes instantaneous 
> implementation on all hosts within the trust environment.
> Since that isn't possible, it's not clear how the advice of this 
> section is practical.

Nothing is instantaneous, so I am not very concerned ;-).

Once some servers start supporting this extension a sysadmin can remove 
MXes for servers which don't support it. Upgrading all servers nearly 
simultaneously is another option.

>> 10.  Security Considerations
>>
>>    Message Submission Agents MUST implement a policy that only allows
>>    authenticated users (or only certain groups of authenticated users)
>>    to specify message transfer priorities, and MAY restrict maximum
>>    priority values different groups of users can request, or MAY
>>    override the priority values specified by MUAs.
>
> Presumably the normative MSA language is meant "for those MSAs 
> supporting this extension"?

Of course. I don't think this needs saying.