[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 6758

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 Priorities
               draft-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 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.  Determining priority of a message  . . . . . . . . . . . .  5
     3.3.  Relay of messages to other conforming SMTP servers . . . .  6
     3.4.  Relay of messages to non-conforming SMTP servers . . . . .  6
     3.5.  Mailing lists and Aliases  . . . . . . . . . . . . . . . .  7
     3.6.  Gatewaying a message into a foreign environment  . . . . .  7
     3.7.  Interaction with DSN SMTP Extension  . . . . . . . . . . .  7
   4.  Header field: MT-Priority  . . . . . . . . . . . . . . . . . .  7
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     7.1.  Modification of MT-Priority header field and DKIM  . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 12





























Melnikov & Carlberg     Expires November 2, 2012                [Page 2]

Internet-Draft  Tunneling of Message Transfer Priorities        May 2012


1.  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 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" 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 2012


3.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 2012


3.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


   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.

        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)



Melnikov & Carlberg     Expires November 2, 2012                [Page 8]

Internet-Draft  Tunneling of Message Transfer Priorities        May 2012


   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:


        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

   [[Note to RFC Editor/IANA]] Please replace TBD1, TBD2 and TBD3 with
   values allocated for [SMTP-PRIORITY].

   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): [[anchor10: 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



Melnikov & Carlberg     Expires November 2, 2012                [Page 9]

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]

Internet-Draft  Tunneling of Message Transfer Priorities        May 2012


   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

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-12 (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.



Melnikov & Carlberg     Expires November 2, 2012               [Page 11]

Internet-Draft  Tunneling of Message Transfer Priorities        May 2012


   [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, 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.  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



Melnikov & Carlberg     Expires November 2, 2012               [Page 12]

Internet-Draft  Tunneling of Message Transfer Priorities        May 2012


   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 November 2, 2012               [Page 13]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/