Network Working Group A. Melnikov
Internet-Draft Isode Ltd
Intended status: Experimental K. Carlberg
Expires: November 2, 2012 G11
May 1, 2012
Tunneling of SMTP Message Transfer Prioritiesdraft-melnikov-smtp-priority-tunneling-00
Abstract
This memo defines a mechanism for tunneling of SMTP (Simple Mail
Transfer Protocol) Message Transfer Priority values through MTAs
(Message Transfer Agents) that don't support the MT-PRIORITY SMTP
extension.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 2, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Melnikov & Carlberg Expires November 2, 2012 [Page 1]

Internet-Draft Tunneling of Message Transfer Priorities May 20121. Introduction
This document specifies application layer tunneling of message
priority through SMTP servers. The purpose of this tunneling is to
convey the priority of the message through Message Transfer Agents
(MTAs) that do not support the SMTP priority extension specified in
[SMTP-PRIORITY]. The tunneling is done using a new message header
field to Internet message format specified in [RFC5322].
Various Mail User Agents (MUAs) already use various other header
fields that convey a similar meaning, such as message importance.
Example of such header fields are Importance [RFC2156], Priority
[RFC2156] and X-Priority (undocumented). Considering subtle
differences in the meaning of these header fields and widely
different syntax, this document defines a new header field.
This document is motivated by 2 main deployment scenarious: (1) Mail
User Agent (MUA) talking to a non MT-PRIORITY aware Message
Submission Server (MSA), and (2) use of unextended MUA to talk to a
MT-PRIORITY aware MSA. These 2 use cases are discussed in more
details below.
The use case (1) is about a MT-PRIORITY capable MUA talking to a non
MT-PRIORITY capable MSA, which in turn is talking to a MT-PRIORITY
capable MTA. Both MSA and MTA are within the same Administrative and
Management Domain (ADMD) and are on a fast network, however some
recipients are accessible via the MTA which is talking over a slow
link to the next MTA. Communications over that slow link can benefit
from use of MT-PRIORITY SMTP extension.
In the use case (2) a widely deployed client (such as a desktop
client) is talking to MT-PRIORITY capable MSA. The client is
extended via a plugin API provided by the client developers, however
existing APIs frequently allow easy manipulation of email header
fields, while not allowing for addition of SMTP protocol features.
In such a case installing a plugin to the client that can set MT-
Priority header field could provide easier and earlier deployment of
MT-PRIORITY SMTP extension in an organization without requiring
changes to desktop clients.
We note that the above use cases are not exhaustive and that other
use cases, various of the above, may exist. The purpose of this
document is not to consider every scenario, but rather examples that
reinforce the need to consider a tunneling mechanism that can deal
with SMTP capable devices that do not support [SMTP-PRIORITY].
Melnikov & Carlberg Expires November 2, 2012 [Page 3]

Internet-Draft Tunneling of Message Transfer Priorities May 20122. 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.
The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
notation including the core rules defined in Appendix B of RFC 5234
[RFC5234].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. Line breaks that do not start with a new "C:"
or "S:" exist for editorial reasons and are not a part of the
protocol.
This document uses the term "priority" in the meaning of expedited
treatment of a message by the server according to the message's
priority.
3. Handling of messages received via SMTP
This section replaces the corresponding section of [SMTP-PRIORITY]
and its corresponding subsections. It describes how a conforming
SMTP server should handle any messages received via SMTP.
3.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server
The following rules apply to SMTP transactions in which the MT-
PRIORITY parameter is used:
1. A conforming SMTP server MUST NOT refuse a MAIL FROM command
based on the absence of the MT-PRIORITY parameter. However, if
any of the associated <esmtp-value>s (as defined in Section 4.1.2
of [RFC5321]) are not syntactically valid, or if there is more
than one MT-PRIORITY parameter in a particular MAIL command, the
server MUST return an error, for example "501 syntax error in
parameter" (with 5.5.2 Enhanced Status Code [RFC2034]).
2. Additionally, when inserting a Received header field as specified
in Section 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include
the "PRIORITY" clause whose syntax is specified in
[SMTP-PRIORITY].
Melnikov & Carlberg Expires November 2, 2012 [Page 4]

Internet-Draft Tunneling of Message Transfer Priorities May 20123.2. Determining priority of a message
An SMTP server compliant with this specification can determine the
priority of a received message as follows:
1. If the sending SMTP client specified the MT-PRIORITY parameter to
the MAIL FROM command, then the value of this parameter is the
message priority.
2. If the sending SMTP client hasn't specified the MT-PRIORITY
parameter to the MAIL FROM command, but the message has a single
syntactically valid MT-Priority header field (see Section 4),
then the value of this header field is the message priority.
3. 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.
4. Otherwise (if no MT-PRIORITY parameter to the MAIL command was
specified and the message doesn't contain a syntactically valid
MT-Priority header field (or a header field that conveys similar
semantics), or contains multiple MT-Priority header fields) the
message has priority 0.
The SMTP server MUST ignore or downgrade priorities from untrusted
(e.g. unauthenticated) or insufficiently trusted sources. (One
example of an "insufficiently trusted source" might be an SMTP sender
which authenticated using SMTP AUTH, but which is not explicitly
whitelisted to use the SMTP MT-PRIORITY service.) If the SMTP server
ignores or downgrades the priority of a particular message, it SHOULD
use the X.7.TBD3 [RFC2034] enhanced status code.
The SMTP server MAY alter the message priority (both to lower or to
raise it) in order to enforce sender site policy. If the SMTP server
lowers the priority, it SHOULD use the X.7.TBD3 [RFC2034] enhanced
status code. For example the MSA can have a mapping table which
assigns priorities to messages based on authentication credentials.
Alternatively an SMTP server, which is an MSA, MAY reject a message
based on the determined priority. In such case, the MSA SHOULD use
450 or 550 reply code. The corresponding enhanced status code MUST
Melnikov & Carlberg Expires November 2, 2012 [Page 5]

Internet-Draft Tunneling of Message Transfer Priorities May 2012
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.
3.3. Relay of messages to other conforming SMTP servers
The following rules govern the behavior of a conforming MTA (in the
role of an SMTP client), when relaying a message which was received
via the SMTP protocol, to an SMTP server that supports the MT-
PRIORITY SMTP extension:
1. A MT-PRIORITY parameter with the value determined by the
procedure from Section 3.2 MUST appear in the MAIL FROM command
issued when the message is relayed to an MTA/MDA which also
supports the MT-PRIORITY extension. For example, once an MTA
accepts a message, the MTA MUST NOT change a (syntactically
valid) priority value if that value is not supported by the MTA's
implementation of this extension. Note that this rule also
applies to messages which didn't have any priority explicitly
specified using the MT-PRIORITY MAIL FROM parameter or the MT-
Priority header field.
2. Further processing of the MT-PRIORITY parameter is described in
Section 5 of [SMTP-PRIORITY].
3.4. Relay of messages to non-conforming SMTP servers
The following rules govern the behavior of a conforming MTA (in the
role of an SMTP client), when relaying a message which was received
via the SMTP protocol, to an SMTP server that does not support the
MT-PRIORITY SMTP extension:
1. The relaying MTA MUST NOT use the MT-PRIORITY parameter in the
MAIL FROM command issued when relaying the message
2. The relaying MTA MUST first remove any and all existing MT-
Priority header fields from the message.
3. If the incoming message had a MT-PRIORITY parameter specified in
the MAIL FROM command *or* there was an MT-Priority header field
removed in the above step 2, then the relaying MTA MUST add its
own MT-Priority header field with the value determined by the
procedure in Section 3.2. Syntax of the MT-Priority header field
is specified in Section 4.
Melnikov & Carlberg Expires November 2, 2012 [Page 6]

Internet-Draft Tunneling of Message Transfer Priorities May 20123.5. Mailing lists and Aliases
Several options exist to translate the address of an email recipient
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.
3.6. 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 3.4).
Note that if the destination environment doesn't support
transport of arbitrary header field, the requirement in
Section 3.4 to add an MT-Priority header field doesn't apply.
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 3.3), converting the MT-PRIORITY parameter to the
equivalent in the destination environment.
3.7. 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.
4. Header field: MT-Priority
Applicable protocol: mail [RFC5322]
Status: standard
Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) on
behalf of the IETF
Specification document(s): [[anchor8: this document]]
The MT-Priority header field conveys message transfer priority when
relaying a message through MTAs which don't support the MT-PRIORITY
SMTP extension.
Melnikov & Carlberg Expires November 2, 2012 [Page 7]

Internet-Draft Tunneling of Message Transfer Priorities May 2012
it can be represented in the message itself (using the MT-Priority
header field). 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) .
Message Submission Agents MUST implement a policy that only allows
authenticated users (or only certain groups of authenticated users)
to specify message transfer priorities (whether by using the MT-
PRIORITY parameter to the MAIL command or the MT-Priority header
field in the message itself), and MAY restrict maximum priority
values different groups of users can request, or MAY override the
priority values specified by MUAs. Such MSAs SHOULD strip any MT-
Priority header field values that don't satisfy this policy. See
Section 7.1 for more details on when violation of this SHOULD is
warranted.
Similarly, MTAs MUST implement a policy that only allows
authenticated and trusted senders (or only certain groups of
authenticated senders) to specify message transfer priorities
(whether by using the MT-PRIORITY parameter to the MAIL command or
the MT-Priority header field in the message itself), and MAY restrict
maximum priority values different groups of senders can request, or
MAY override the priority values specified by them. Such MTAs SHOULD
strip any MT-Priority header field values that don't satisfy this
policy. See Section 7.1 for more details on when violation of this
SHOULD is warranted.
In the absence of the policy enforcement mentioned above an SMTP
server (whether an MSA or an MTA) implementing this extension might
be susceptible to a Denial of Service attack. For example, malicious
clients (MUAs/MSAs/MTAs) can try to abuse this feature by always
requesting Priority 9.
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]. But see
Section 7.1.
7.1. Modification of MT-Priority header field and DKIM
A MSA/MTA that receives a message with an MT-Priority header field
protected by DKIM, that wants to change the message priority due to
its policy is forced to choose between a) breaking DKIM signatures
(by replacing the MT-Priority header value), b) leaving the message
as is (and using the MT-PRIORITY MAIL FROM parameter), relying on the
Melnikov & Carlberg Expires November 2, 2012 [Page 10]