Network Working Group A. Melnikov
Internet-Draft Isode Ltd
Intended status: Experimental K. Carlberg
Expires: December 4, 2012 G11
June 2, 2012
Tunneling of SMTP Message Transfer Priorities
draft-melnikov-smtp-priority-tunneling-02
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 December 4, 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 December 4, 2012 [Page 1]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Handling of messages received via SMTP . . . . . . . . . . . . 4
3.1. Handling of the MT-PRIORITY parameter by the receiving
SMTP server . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Relay of messages to other conforming SMTP servers . . . . 5
3.3. Relay of messages to non-conforming SMTP servers . . . . . 5
3.4. Mailing lists and Aliases . . . . . . . . . . . . . . . . 5
3.5. Gatewaying a message into a foreign environment . . . . . 5
3.6. Interaction with DSN SMTP Extension . . . . . . . . . . . 5
4. Header field: MT-Priority . . . . . . . . . . . . . . . . . . 5
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Modification of MT-Priority header field and DKIM . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Melnikov & Carlberg Expires December 4, 2012 [Page 2]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
1. Introduction
This document is an experimental extension to the SMTP Message
Transfer Priorities extension [SMTP-PRIORITY]. It specifies
application layer tunneling of message priority, to convey the
priority of the messages through Message Transfer Agents (MTAs) that
do not support the Message Transfer Priorities extension. The
tunneling is done by adding a new message header field to Internet
message format specified in [RFC5322].
A number of other header fields are already in use, mostly in Mail
User Agents (MUAs), to convey meanings related to importance or
priority of messages. Example of such header fields are Importance
[RFC2156], Priority [RFC2156] and X-Priority (undocumented).
Considering sometimes subtle and sometimes significant 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, variations 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 December 4, 2012 [Page 3]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
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 with a new "C:"
or "S:" exist for editorial reasons and are not a part of the
protocol.
This document uses the term "priority" specifically in relation to
the internal treatment of a message by the server: messages with
higher priorities may be given expedited handling, and those with
lower priorities may be handled only as resources become available.
3. Handling of messages received via SMTP
The subsections of this section update the corresponding subsections
of Section 4 of [SMTP-PRIORITY].
3.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server
This specification inserts the following between steps 3 and 4 in
Section 4.1 of [SMTP-PRIORITY]:
3a. 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.
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.
Melnikov & Carlberg Expires December 4, 2012 [Page 4]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
3.2. Relay of messages to other conforming SMTP servers
This specification inserts the following between steps 1 and 2 in
Section 4.2 of [SMTP-PRIORITY].
1a. Note that rule 1 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.
3.3. Relay of messages to non-conforming SMTP servers
This specification appends the following after step 1 in Section 4.3
of [SMTP-PRIORITY]:
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.1. Syntax of the MT-Priority header field
is specified in Section 4.
3.4. Mailing lists and Aliases
This specification makes no changes to Section 4.4 of
[SMTP-PRIORITY].
3.5. Gatewaying a message into a foreign environment
This specification inserts the following between steps 1 and 2 in
Section 4.5 of [SMTP-PRIORITY].
1a. Note that if the destination environment doesn't support
transport of arbitrary header field, the requirement in
Section 3.3 to add an MT-Priority header field doesn't apply.
3.6. Interaction with DSN SMTP Extension
This specification makes no changes to Section 4.6 of
[SMTP-PRIORITY].
4. Header field: MT-Priority
Applicable protocol: mail [RFC5322]
Status: standard
Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) on
Melnikov & Carlberg Expires December 4, 2012 [Page 5]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
behalf of the IETF
Specification document(s): [[anchor7: 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.
ABNF for this header field is defined as follows:
priority-header-field = "MT-Priority:"
[CFWS] priority-value [CFWS] CRLF
where "priority-value" is defined in [SMTP-PRIORITY].
Example:
MT-Priority: -3
Example:
MT-Priority: 4 (ultra)
5. 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 though there is no requirement that these other
extensions are to be supported when the MT-PRIORITY SMTP extension is
implemented.
Melnikov & Carlberg Expires December 4, 2012 [Page 6]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
S: 220 example.net SMTP server here
C: EHLO example.com
S: 250-example.net
S: 250-DSN
S: 250-DELIVERBY
S: 250 MT-PRIORITY
C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
MT-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 of [SMTP-PRIORITY], 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). When relaying the message to the next hop
which doesn't support the MT-PRIORITY SMTP extension the transaction
might look like this:
Melnikov & Carlberg Expires December 4, 2012 [Page 7]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
S: 220 example.org SMTP server here
C: EHLO example.net
S: 250-example.org
S: 250-DSN
S: 250 SIZE
C: MAIL FROM:<eljefe@example.com> ENVID=QQ314159
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: MT-Priority: 3
C: (the rest of the message goes here)
C: .
S: 250 message accepted
C: QUIT
S: 221 goodbye
6. IANA Considerations
IANA is 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): [[anchor9: this document]]
7. Security Considerations
This document allows a message priority to be tunneled through MTAs
which don't support the MT-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 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
Melnikov & Carlberg Expires December 4, 2012 [Page 8]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
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
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.
8. References
Melnikov & Carlberg Expires December 4, 2012 [Page 9]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
8.1. Normative References
[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, 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.
[SMTP-PRIORITY] Melnikov, A. and K. Carlberg, "Simple Mail Transfer
Protocol extension for Message Transfer Priorities",
draft-melnikov-smtp-priority-14 (work in progress),
2012.
8.2. Informative References
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME",
RFC 2156, January 1998.
[RFC2852] Newman, D., "Deliver By SMTP Service Extension",
RFC 2852, June 2000.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy,
"DomainKeys Identified Mail (DKIM) Signatures",
RFC 6376, September 2011.
Melnikov & Carlberg Expires December 4, 2012 [Page 10]
Internet-Draft Tunneling of Message Transfer Priorities June 2012
Appendix A. 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, Ned Freed and Claudio Allocchio.
Special thanks to Barry Leiba for agreeing to shepherd this document.
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 December 4, 2012 [Page 11]
