Re: Last Call: <draft-melnikov-smtp-priority-tunneling-02.txt> (Tunneling of SMTP Message Transfer Priorities) to Experimental RFC

[Alexey Melnikov <[e-mail]>]

Hi SM,
Thank you for the comments.

On 06/06/2012 22:39, SM wrote:
> At 13:05 04-06-2012, The IESG wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Tunneling of SMTP Message Transfer Priorities'
>>   <draft-melnikov-smtp-priority-tunneling-02.txt> as Experimental RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>
> In the Introduction section:
>
> Typo: scenarious.

Fixed, thanks.

> In Section 3.1:
>
>   "This specification inserts the following between steps 3 and 4 in
>    Section 4.1 of [SMTP-PRIORITY]:"
>
> The specification would be updating draft-melnikov-smtp-priority 
> according to the above.
>
>  "3b.  In absence of both the MT-PRIORITY MAIL FROM parameter and the
>         MT-Priority header field, other message header fields, such as
>         Priority [RFC2156] and X-Priority, MAY be used for determining
>         the priority under this "Priority Message Handling" SMTP
>         extension.  But note that the Importance [RFC2156] header field
>         MUST NOT be used for determining the priority under this
>         "Priority Message Handling" SMTP extension, as it has different
>         semantics: the Importance header field is aimed at the user
>         recipient and not at the nodes responsible for transferring the
>         message."
>
> X-Priority, for example, is undocumented.

Yes. Albeit widely used.

> If I understood the above correctly, the MTA chooses some higher 
> priority when it sees any of these header fields.

MT-Priority header field always takes precedence, but in its absence 
other header fields can be used.

> In Section 7:
>
>   "Thus it is important to ensure that an MTA receiving a message
>    containing the MT-Priority header field can trust that it
>    was set by an authorized agent.  Such trust can be realized, for
>    example, by using DKIM Section 7.1 to sign the MT-Priority header
>    field value, S/MIME, or by keeping a list of trusted senders (e.g.
>    within a close environment)."
>
> I don't see how DKIM can be used to ensure that the header field was 
> set by an authorized agent.  I assume that any SMTP client within the 
> (DKIM) signing domain could generate a MT-Priority header field as I 
> don't know the DKIM signing policy.  As an example, I consider that 
> msg-id [e-mail] as was generated 
> by an authorized agent on behalf of the IETF Chair but I would not 
> describe it as trusted.

Ok, this text is wrong, I will try to rewrite it.
DKIM enables binding between a priority value and a signer. Recipient 
still needs to have a policy for deciding which signers are to be trusted.

>   "Message Submission Agents MUST implement a policy that only allows"
>
> I suggest using the same text as in draft-melnikov-smtp-priority.

Yes, I just updated my copy. The change will be in -03.

>   "To protect MT-Priority header field from modification or insertion,
>    MUAs, MSAs and MTAs inserting it into messages SHOULD use message
>    header protection mechanism such as DKIM [RFC6376]."
>
> I read Section 7.1 as a case for not following the above 
> recommendation.  Any attempt to change priority means breaking the 
> DKIM signature.

Correct. It is a trade-off.

> I am not proposing text to avoid a significant rewrite of the proposal.