Network Working Group A. Melnikov
Internet-Draft Isode Ltd
Intended status: Standards Track K. Carlberg
Expires: September 8, 2012 G11
March 7, 2012
Simple Mail Transfer Protocol extension for Message Transfer Priorities
draft-melnikov-smtp-priority-08
Abstract
This memo defines an extension to the SMTP (Simple Mail Transfer
Protocol) service whereby messages are sent with a priority to enable
receivers to take this into account for onward processing, with the
general goal of processing and/or transferring higher priority
messages first.
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 September 8, 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
Melnikov & Carlberg Expires September 8, 2012 [Page 1]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Definition of the Priority SMTP Extension . . . . . . . . . . 4
4. Handling of messages received via SMTP . . . . . . . . . . . . 5
4.1. Handling of the PRIORITY parameter by the receiving
SMTP server . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Determining priority of a message . . . . . . . . . . . . 5
4.3. Relay of messages to other conforming SMTP servers . . . . 6
4.4. Relay of messages to non-conforming SMTP servers . . . . . 6
4.5. Mailing lists and Aliases . . . . . . . . . . . . . . . . 7
4.6. Gatewaying a message into a foreign environment . . . . . 7
4.7. Interaction with DSN SMTP Extension . . . . . . . . . . . 7
5. The Priority Service Extension . . . . . . . . . . . . . . . . 8
5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 9
5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 10
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Header field: MT-Priority . . . . . . . . . . . . . . . . . . 10
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
10. Pending changes . . . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12.1. Modification of MT-Priority header field and DKIM . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Mapping of PRIORITY parameter values for Military
Messaging . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Mapping of PRIORITY parameter values for MIXER . . . 17
Appendix C. Mapping of National Security / Emergency
Preparedness (NS/EP) Values . . . . . . . . . . . . . 18
Appendix D. Two possible implementation strategies . . . . . . . 19
D.1. Probability . . . . . . . . . . . . . . . . . . . . . . . 19
D.2. Preemption of sessions or transactions . . . . . . . . . . 19
Appendix E. Resource Allocation Models . . . . . . . . . . . . . 20
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Melnikov & Carlberg Expires September 8, 2012 [Page 2]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
1. Introduction
Where resources for switching or transfer of messages are constrained
(e.g., bandwidth, round trip time or processing capability) it is
desirable to process high priority messages first. This is
particularly important during emergencies for first responders and
for environments such as military messaging, where messages have high
operational significance, and the consequences of extraneous delay
can be significant.
In order for an SMTP receiver to be able to send higher priority
messages first, there needs to be a mechanism to communicate (during
both Message Submission [RFC6409] and Message Transfer [RFC5321]) the
priority of each message. This specification defines this mechanism
by specification of an SMTP [RFC5321] extension. It also enables
communication of message priority through Message Transfer Agents
(MTAs) that are not priority aware, by the specification of a new
message header field [RFC5322].
Various 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.
2. 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 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.
This document uses the phrase "an email is waiting to be sent", if it
resides in the outbound queue of an MTA or an Mail Submission Agent
Melnikov & Carlberg Expires September 8, 2012 [Page 3]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
(MSA) and can be sent to the next hop or delivered to its final
recipient(s) once available resources at the sending MTA/MSA allow
this. Emails having their processing delayed for some reason within
the MTA/MSA are not waiting to be sent during this delay. The most
important reason for emails to be delayed is a transient error
response from the next MTA to which the email must be transferred.
This document uses the phrase "an email is ready to be sent", if it
is waiting to be sent and either no emails with higher priority are
waiting to be sent or available resources allow more emails to be
sent in parallel than the number of emails with higher priorities
that are waiting to be sent. Note that an email may be ready to be
sent but the transfer or delivery process can not yet be initiated,
because the number of emails ready to be sent exceeds the number of
emails that can be processed in parallel.
3. Definition of the Priority SMTP Extension
The Priority SMTP service extension is defined as follows:
1. The textual name of this extension is "Priority Message
Handling".
2. The EHLO keyword value associated with this extension is
"PRIORITY".
3. The EHLO keyword has no parameters. Parameters are reserved for
possible future extensions and MUST be ignored by clients that
don't understand them.
4. No additional SMTP verbs are defined by this extension.
5. One optional parameter ("PRIORITY") is added to the MAIL FROM
command. The value associated with this parameter is a decimal
integer number from -9 to 9 (inclusive) indicating the priority
of the email message. The syntax of the PRIORITY parameter is
described by the <priority-value> ABNF non-terminal defined in
Section 6. Higher numbers mean higher priority.
6. The maximum length of a MAIL command line is increased by 13
characters by the possible addition of the PRIORITY keyword and
value.
7. The PRIORITY extension is valid for the submission service
[RFC6409] and LMTP [RFC2033].
Melnikov & Carlberg Expires September 8, 2012 [Page 4]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
4. Handling of messages received via SMTP
This section describes how a conforming SMTP server should handle any
messages received via SMTP.
4.1. Handling of the PRIORITY parameter by the receiving SMTP server
The following rules apply to SMTP transactions in which the PRIORITY
parameter is used:
1. A conforming SMTP server MUST NOT refuse a MAIL FROM command
based on the absence of the 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 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]).
Additionally, when inserting a Received header field as specified in
Section 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the
"PRIORITY" clause which syntax is specified in Section 6.
4.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 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 PRIORITY
parameter to the MAIL FROM command, but the message has a single
syntactically valid MT-Priority header field (see Section 7),
then the value of this header field is the message priority.
3. Otherwise (if no PRIORITY parameter to the MAIL command was
specified and the message doesn't contain a syntactically valid
MT-Priority header field, or contains multiple MT-Priority header
fields) the message has priority 0.
The Importance [RFC2156] header field MUST NOT be used for
determining the priority under this "Priority Message Handling" SMTP
extension. In absence of both the 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.
Melnikov & Carlberg Expires September 8, 2012 [Page 5]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
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 PRIORITY service.) If the SMTP server
does that, 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
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, for example the server
is temporarily operating in a mode where only high priority messages
are accepted for transfer and delivery.
4.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 PRIORITY
SMTP extension:
1. A PRIORITY parameter with the value determined by the procedure
from Section 4.2 MUST appear in the MAIL FROM command issued when
the message is relayed to an MTA/MDA which also supports the
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 PRIORITY
MAIL FROM parameter or the MT-Priority header field).
2. Further processing of the PRIORITY parameter is described in
Section 5.
4.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
PRIORITY SMTP extension:
Melnikov & Carlberg Expires September 8, 2012 [Page 6]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
1. The relaying MTA MUST NOT use the 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 message had a PRIORITY specified in the MAIL FROM
parameter *or* there was an MT-Priority header field removed in
step 2, then the relaying MTA MUST add its own MT-Priority header
field with the value determined by the procedure in Section 4.2.
Syntax of the MT-Priority header field is specified in Section 6.
4.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 original priority for all
expanded and/or translated addresses.
4.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 PRIORITY parameter, the conforming MTA SHOULD behave as if
it is relaying to a non-conformant SMTP (Section 4.4).
2. If the destination environment is capable of providing an
equivalent of the PRIORITY parameter, the conforming MTA SHOULD
behave as if it is relaying to a conformant SMTP (Section 4.3),
converting the PRIORITY parameter to the equivalent in the
destination environment.
4.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.
Melnikov & Carlberg Expires September 8, 2012 [Page 7]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
5. The Priority Service Extension
The priorities of messages affect the order the messages are
transfered from the client to the server. This is largely
independent from the order in which they were originally received by
the server.
A message priority is a decimal integer in the range from -9 to 9
(inclusive). SMTP servers compliant with this specification are not
required to support all 19 distinct priority levels (i.e. to treat
each priority value as a separate priority), but they MUST implement
at least the following 6 distinct priority levels: -4, -2, 0, 2, 4,
9. I.e. an implementation that only supports the 6 priority levels
will internally round up a syntatically valid level that isn't
supported to the next higher supported number. For example, such an
implementation will treat priority values below and including -4 as
priority -4, prioritiy -3 as priority -2, and all priorities starting
from 5 are treated as priority 9. An SMTP server MAY support more
than 6 different priority levels. Decision about which levels to
support in addition to the 6 mentioned above is a local matter.
Irrespectively of the number of distinct priority levels supported by
the SMTP server, when relaying the message to the next hop or
delivering it over LMTP, the SMTP server MUST comminicate the
priority value as determined in Section 4.2.
Note: 19 possible priority levels are defined by this specification
for extensibility. For example, a particular implementation or
deployment environment might need to provide finer-grained control
over message transfer priorities. In such a case, a server
implementation might need an extra priority level beyond the 6 levels
defined above.
Some SMTP servers MAY impose additional maximum message size
contraints for different message transfer priorities, for example
messages with priority 6 might not be larger than 4 Kb. If an SMTP
server chooses to reject a message because it is too big for the
determined priority, it SHOULD use 552 reply codes, together with the
X.3.TBD2 enhanced status code [RFC2034].
Note that rejections based on priority (see Section 4.2) or priority+
message size combination SHOULD only be done by an MSA (i.e. they
SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the
Mail User Agents (MUAs) which generated the message and is in a
position to perform a corrective action, such as resubmission of the
message with lower priority, converting or truncating the message to
make it smaller, etc. Such actions usually require user interaction.
For this reason it is also important for MUAs to support enhanced
Melnikov & Carlberg Expires September 8, 2012 [Page 8]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
status codes specified in this document (see Section 11 for the
summary). Any rejection caused by a downstream MTA is going to
result in a bounce message. Such bounce messages are not friendly to
users and are frequently removed by antispam software.
Implementation Note: If the SMTP server also supports the SMTP SIZE
extension [RFC1870] then an SMTP client can use both SIZE= and
PRIORITY= parameters on the MAIL FROM command. This allows the
server to perform early rejection of a message in case the message
size is too big for the specified priority, thus avoiding wasting
bandwidth by transferring the message first and then rejecting it due
to its size.
The Priority Service Extension can be combined with DELIVERBY
[RFC2852] SMTP service extension, however there is no requirement
that both extensions are always implemented together.
5.1. Expedited Transfer
The main service provided by the Priority Message Handling SMTP
Service Extension is expedited transfer of emails with a higher
priority. Therefore an SMTP client that has more than one email to
send at a given time sends those with a higher priority before those
with a lower one. Additionally, the retry interval and/or default
timeout before non-delivery report is generated can be lower (more
aggressive) for messages of higher priority.
In order to make implementations of this extension easier, this SMTP
extension only allows a single priority for all recipients of the
same message.
Within a priority level, the MTA uses its normal algorithm (the
algorithm used in absence of this SMTP extension) for ordering for
the messages.
In networks with limited available bandwidth or long round trip times
the actual message transfer over the network may create a significant
portion of the overall message delivery time from a sender to a
recipient. Besides the actions taken at the application level it can
thus be important to deploy priority or precedence mechanisms offered
by the network itself to ensure timely delivery of the emails.
Examples would be the use of DiffServ [RFC2474], RSVP [RFC2205] and
the work-in-progress effort extension to RSVP that prioritizes
reservations.
Most current SMTP MTAs are capable of handling several inbound and
outbound connections at once. With this feature it should be
possible to start additional outbound connections for emails with
Melnikov & Carlberg Expires September 8, 2012 [Page 9]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
higher priorities even if there are already several connections
running for other emails. Two possible ways of implementing
expedited transfer are described in more details in Appendix D.
5.2. Timely Delivery
An important constraint (usually associated with higher priority
levels) is that messages with high priority have some delivery time
constraints. In some cases, higher priorities mean a shorter maximum
time allowed for delivery.
Unextended SMTP does not offer a service for timely delivery. The
"Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
[RFC2852] is an example of an SMTP extension providing a service that
can be used to implement such constraints. But note that use of the
DELIVERBY extension alone does not guarantee any priority processing.
6. Syntax
priority-value = (["-"] NZDIGIT) / "0"
; Allowed values are from -9 to 9 inclusive
NZDIGIT = %x31-39
; "1"-"9"
CFWS = <defined in RFC 5322>
; New "clause" that can be used in the Received header field
Pri = CFWS "PRIORITY" FWS priority-value
; Complies with the <Additional-Registered-Clauses>
; non-terminal syntax from RFC 5321.
7. 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): [[anchor11: this document]]
The MT-Priority header field conveys message transfer priority when
relaying a message through MTAs which don't support the PRIORITY SMTP
extension.
ABNF for this header field is defined as follows:
Melnikov & Carlberg Expires September 8, 2012 [Page 10]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
priority-header-field = "MT-Priority:"
[CFWS] priority-value [CFWS] CRLF
where "priority-value" is defined in Section 6
Example:
MT-Priority: -3
Example:
MT-Priority: 4 (ultra)
8. Example
An SMTP transaction with 2 recipients. Note that the example is also
making use of the DELIVERBY [RFC2852] and DSN [RFC3461] SMTP
extensions, even thought there is no requirement that these other
extensions are to be supported when the PRIORITY SMTP extension is
implemented.
S: 220 example.net SMTP server here
C: EHLO example.com
S: 250-example.net
S: 250-DSN
S: 250-DELIVERBY
S: 250-PRIORITY
C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
PRIORITY=3
S: 250 <eljefe@example.com> sender ok
C: RCPT TO:<topbanana@example.net>
S: 250 <topbanana@example.net> recipient ok
C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
ORCPT=rfc822;Dana@Ivory.example.net
S: 250 <Dana@Ivory.example.net> recipient ok
C: DATA
S: 354 okay, send message
C: (message goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
If the receiving SMTP server only supports 6 priority levels as
described in Section 5, it will use the priority value 4 internally
(the next supported priority higher or equal to 3) and will
communicate the priority value 3 when relaying it to the next hop (if
necessary).
Melnikov & Carlberg Expires September 8, 2012 [Page 11]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
9. Deployment Considerations
If multiple DNS MX records are used to specify multiple servers for a
domain in section 5 of [RFC5321], it is advised that either all of
them support the PRIORITY extension, or none do. Otherwise,
unexpected differences in message delivery speed or even rejections
can happen during temporary or permanent failures, which users might
perceive as serious reliability issues.
10. Pending changes
[[anchor15: This section should be removed before publication]]
Rename the PRIORITY extension/MAIL FROM parameter to something like
MT-PRIORITY. Please advise editors of this document if you have an
opinion one way or another.
11. IANA Considerations
This specification requests IANA to add the PRIORITY SMTP extension
to the "SMTP Service Extensions" registry (in
http://www.iana.org/assignments/mail-parameters).
IANA is also requested to add the following list of header field
names to the "Permanent Message Header Field Names" registry (in
http://www.iana.org/assignments/message-headers/perm-headers.html):
Header field: MT-Priority
Applicable protocol: mail
Status: standard
Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) on
behalf of the IETF
Specification document(s): [[anchor16: this document]]
This specification requests IANA to add the following new Received
header field clause to the "Additional-registered-clauses" sub-
registry (in http://www.iana.org/assignments/mail-parameters) to help
with tracing email messages delivered using the PRIORITY SMTP
extension:
Clause name: PRI
Description: Records the value of the PRIORITY parameter specified in
the MAIL command
Syntax of the value: See Section 6 of RFCXXXX
Reference: [[anchor17: RFCXXXX]]
This specification requests IANA to add the following Enumerated
Status Codes to the "Simple Mail Transfer Protocol (SMTP) Enhanced
Melnikov & Carlberg Expires September 8, 2012 [Page 12]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
Status Codes" registry established by [RFC5248] (in http://
www.iana.org/assignments/smtp-enhanced-status-codes/
smtp-enhanced-status-codes.xml):
1.
Code: X.7.TBD1
Sample Text: Priority Level is too low
Associated basic status code: 450, 550 (other 4XX or 5XX codes
are allowed)
Description: The specified priority level is below the lowest
priority acceptable for the receiving SMTP server. This
condition might be temporary, for example the server is
operating in a mode where only high priority messages are
accepted for transfer and delivery.
Reference: RFC XXXX
Submitter: A. Melnikov
Change controller: IESG
2.
Code: X.3.TBD2
Sample Text: Message is too big for the specified priority
Associated basic status code: 552 (other 4XX or 5XX codes are
allowed)
Description: The message is too big for the specified priority.
This condition might be temporary, for example the server is
operating in a mode where only high priority messages are
accepted for transfer and delivery.
Reference: RFC XXXX
Submitter: A. Melnikov
Change controller: IESG
3.
Melnikov & Carlberg Expires September 8, 2012 [Page 13]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
Code: X.3.TBD3
Sample Text: Requested priority was downgraded
Associated basic status code: 250 or 251
Description: The message mas accepted for relay/delivery, but
the requested priority can't be honoured and was downgraded.
The human readable text after the status code contains the new
priority, followed by SP (space) and explanatory human
readable text.
Reference: RFC XXXX
Submitter: A. Melnikov
Change controller: IESG
12. Security Considerations
This document allows a message priority to be tunneled through MTAs
which don't support the PRIORITY SMTP extension by specifying how 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 12.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 can implement a policy that only allows
authenticated users (or only certain groups of authenticated users)
to specify message transfer priorities (whether by using the PRIORITY
parameter to the MAIL command or the MT-Priority header field in the
message itself), and to restrict maximum priority values different
groups of users can request, or 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 12.1 for
more details on when violation of this SHOULD is warranted.
Similarly, MTAs can 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 PRIORITY
parameter to the MAIL command or the MT-Priority header field in the
message itself), and to restrict maximum priority values different
groups of senders can request, or 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 12.1 for
Melnikov & Carlberg Expires September 8, 2012 [Page 14]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
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 12.1.
12.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 PRIORITY MAIL FROM parameter), relying on the
fact that all downstream MTAs are compliant with this specification,
or c) rejecting the message. All of these choices have pros and
cons, which should be carefully considered during deployment.
If the MSA/MTA decides to alter the message, it SHOULD re-sign the
message with DKIM.
13. References
13.1. Normative References
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996.
[RFC2034] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol",
RFC 5321, October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
Melnikov & Carlberg Expires September 8, 2012 [Page 15]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP
Enhanced Mail System Status Codes", BCP 138, RFC 5248,
June 2008.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for
Mail", STD 72, RFC 6409, November 2011.
13.2. Informative References
[RFC1845] Crocker, D. and N. Freed, "SMTP Service Extension for
Checkpoint/Restart", RFC 1845, September 1995.
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10,
RFC 1870, November 1995.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME",
RFC 2156, January 1998.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2852] Newman, D., "Deliver By SMTP Service Extension",
RFC 2852, June 2000.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS)
in IP Telephony", RFC 4190, November 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376,
Melnikov & Carlberg Expires September 8, 2012 [Page 16]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
September 2011.
[ACP123] CCEB, "Common Messaging strategy and procedures",
ACP 123, May 2009.
[STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message
Handling System", STANAG 4406, March 2005.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation
Bandwidth Constraints Model for Diffserv-aware MPLS
Traffic Engineering", RFC 4125, June 2005.
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering",
RFC 4127, June 2005.
[RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP
Extensions for Admission Priority", RFC 6401,
October 2011.
Appendix A. Mapping of PRIORITY parameter values for Military Messaging
Military Messaging as specified in ACP 123 [ACP123] (also specified
in STANAG 4406 [STANAG-4406]) defines six priority values. Where
SMTP is used to support military messaging, the following mappings
SHOULD be used.
Recommended mapping of PRIORITY values for MMHS
+----------------+-----------+
| Priority value | MMHS name |
+----------------+-----------+
| -4 | Deferred |
| -2 | Routine |
| 0 | Priority |
| 2 | Immediate |
| 4 | Flash |
| 6 | Override |
+----------------+-----------+
Table 1
Appendix B. Mapping of PRIORITY parameter values for MIXER
MIXER [RFC2156] defines the Priority header field with 3 values.
Where SMTP is used to support military messaging, the following
mappings SHOULD be used.
Melnikov & Carlberg Expires September 8, 2012 [Page 17]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
Recommended mapping of PRIORITY values for MIXER
+----------------------+----------------+
| MIXER Priority value | PRIORITY value |
+----------------------+----------------+
| non-urgent | -4 |
| normal | 0 |
| urgent | 4 |
+----------------------+----------------+
Table 2
Appendix C. Mapping of National Security / Emergency Preparedness
(NS/EP) Values
Communication systems used during an emergency or disaster are
realized in several forms. The most well known form involves the
many-to-one model of the general public contacting a public safety
access point via 911/999/112 calls through the public telephone
network. Typically, these calls do not require authorization, nor do
they invoke any prioritization.
Another form of emergency communications involves a set of authorized
users or nodes that use prioritized services to help established and
continue communication given limited available resources. [RFC4190]
includes descriptions of several systems that have been developed to
support National Security / Emergency Preparedness (NS/EP). These
deployed systems require a form of authentication and have focused on
prioritization of telephony based services. They have also been
designed as a binary form (on/off) of signaled priority
communications.
[RFC4412] includes examples of a more expansive view of NS/EP
communications in which priority migrates from a single on/off bit
value to one that comprises five priority values. This is shown in
the cases of the ETS and WPS Namespaces. Given a lack of pre-
existing NS/EP values assigned for email, we follow the paradigm of
the ETS and WPS Namespaces and recommend five ascending values shown
in the table below.
+----------------+------------------+
| Priority value | Relational Order |
+----------------+------------------+
| -2 | Lowest Priority |
| 0 | ---------- |
| 2 | ---------- |
| 4 | ---------- |
Melnikov & Carlberg Expires September 8, 2012 [Page 18]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
| 6 | Highest Priority |
+----------------+------------------+
As in the case of Appendix A and B, the gap in numeric values listed
in this table provides room for future changes to expand the set of
priorities at a future date, or in a local and non-standardized
manner.
Appendix D. Two possible implementation strategies
This appendix suggest some implementation strategies to implement the
SMTP extension defined in this document. The list is not exhaustive.
This appendix and its subsections are Informative.
D.1. Probability
As the name suggests, probability involves increasing the chances of
obtaining resources without adversely affecting previously
established connections. One example would involve requesting
resources set aside for specific priority levels. If these
additional resources are exhausted, then the desired connection is
denied. Queues, new timers, or combinations thereof can be used to
facilitate the higher priority requests, but the key is that
mechanisms focus on increasing the probability of message transfer.
D.2. Preemption of sessions or transactions
Preemption is a type of action that focusses only on a comparision of
priorities to determine if previously established transactions must
be displaced in favor of higher priority requests. If no additional
connection is possible, the client aborts a running session for
emails with lower priority no later than directly after the current
transaction. The client even can interrupt an active transaction and
should do so, if other constraints such as delivery time (as
specified in the DELIVERBY SMTP extension [RFC2852]) would be
violated for the email with higher priority. When interrupting an
active transaction, the client should take the total message size and
the size of the transferred portion of the message being interrupted
into consideration. This preliminary termination of sessions or
transactions is called preemption.
If preemption of running transactions occurs, the client must choose
a transaction with the lowest priority currently processed.
If the client has an option (i.e. it is supported by the next hop
MTA) to interrupt transactions in a way that it can be restarted at
the interruption point later, it should deploy it. An example for a
Melnikov & Carlberg Expires September 8, 2012 [Page 19]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
mechanism providing such a service is the "SMTP Service Extension for
Checkpoint/Restart" defined in [RFC1845].
If a client opts for the preemption of sessions instead of
transactions, it must preempt the next session that reaches the end
of a transaction.
Appendix E. Resource Allocation Models
Adding prioritization to a design moves the subject away from
strictly best effort (and a first-come-first-served model) to one
that includes admission control and resource allocation models. Over
the years, a variety of work has been done within the IETF in
specifying resource allocations models. Examples include the Maximum
Allocation Model [RFC4125], the Russian Dolls Model [RFC4127], and
the Priority Bypass Model (Appendix A.3 of [RFC6401]).
While we recognize that these various models have been designed for
other protocols (i.e., MPLS and RSVP), an understanding of their
design characteristics may be beneficial in considering future
implementations of a priority SMTP service.
Appendix F. Acknowledgements
This document copies lots of text from
draft-schmeing-smtp-priorities-04.txt and
draft-schmeing-smtp-priorities-05.txt. So the authors of this
document would like to acknowledge contributions made by the authors
of draft-schmeing-smtp-priorities: Michael Schmeing and Jan-Wilhelm
Brendecke.
Many thanks for input provided by Steve Kille, David Wilson, John
Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba,
Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick,
Chris Newman and Ned Freed.
Special thanks to Barry Leiba for agreeing to shepherd this document.
Melnikov & Carlberg Expires September 8, 2012 [Page 20]
Internet-Draft Message Transfer Priority SMTP Extension March 2012
Authors' Addresses
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Ken Carlberg
G11
1601 Clarendon Blvd, #203
Arlington, VA 22209
USA
EMail: carlberg@g11.org.uk
Melnikov & Carlberg Expires September 8, 2012 [Page 21]