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

[SM <[e-mail]>]

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.

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.  If I understood the above 
correctly, the MTA chooses some higher priority when it sees any of 
these header fields.

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.

   "Message Submission Agents MUST implement a policy that only allows"

I suggest using the same text as in draft-melnikov-smtp-priority.

   "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.

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

Regards,
-sm