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.