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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 3D9B1776-6DFD-4B80-97C6-FA8774DB7BA9@xxxxxxxx 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.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]