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

Versions: 00 01 02 03 04 05

Network Working Group                                        M. Schmeing
Internet-Draft                                                      FGAN
Expires: August 5, 2006                                     J. Brendecke
                                             Forschungsgesellschaft fuer
                                          Angewandte Naturwissenschaften
                                                                    e.V.
                                                           February 2006


          SMTP Service Extension for Priority Message Handling
                 draft-schmeing-smtp-priorities-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo defines an extension to the SMTP (Simple Mail Transfer
   Protocol) service whereby messages are sent with a priority to
   achieve a certain order in which the messages are transferred by an
   MTA (Message Transfer Agent).  This priority or precedence order is
   used instead of the first-come-first-serve rule.  This extension is



Schmeing & Brendecke     Expires August 5, 2006                 [Page 1]

Internet-Draft         Priority Extension for SMTP         February 2006


   not to be confused with "Importance of a Message" which is widely
   deployed using an email header such as Importance or even Priority or
   Precedence with common values of HIGH, NORMAL and LOW.  Importance of
   a Message does not affect the priority of the transport itself in any
   way.  Nevertheless, there may be policy defined relations between
   priorities and importance indicators.

   This extension uses the term priority in the meaning of expedited
   treatment of a message by the server according to its priority.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Framework for the Priority Extension . . . . . . . . . . . . .  6
   4.  The Priority Service Extension . . . . . . . . . . . . . . . .  7
     4.1.  Expedited Transfer . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  Preemption of sessions or transactions . . . . . . . .  8
       4.1.2.  Handling of emails with multiple recipients  . . . . .  8
     4.2.  Timely Delivery  . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Resolving conflicts for the sending order of messages
           with the same priority . . . . . . . . . . . . . . . . . .  9
     4.4.  Size Limitation  . . . . . . . . . . . . . . . . . . . . .  9
     4.5.  Further Constraints  . . . . . . . . . . . . . . . . . . . 10
   5.  Recipient Dependent Priority . . . . . . . . . . . . . . . . . 11
     5.1.  Maillists, Aliases and Forwarding  . . . . . . . . . . . . 11
   6.  Priority Policies  . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Conflicts with external constraints  . . . . . . . . . . . 13
     6.2.  The Non-priority . . . . . . . . . . . . . . . . . . . . . 14
     6.3.  Handling Non-priority Servers and Mismatching Policies . . 15
     6.4.  Invalid priority levels  . . . . . . . . . . . . . . . . . 16
     6.5.  Default Policy . . . . . . . . . . . . . . . . . . . . . . 16
       6.5.1.  Number and names of priorities . . . . . . . . . . . . 16
       6.5.2.  Message size constraints . . . . . . . . . . . . . . . 17
       6.5.3.  Delivery time constraints  . . . . . . . . . . . . . . 18
       6.5.4.  Usage of network layer priorities  . . . . . . . . . . 18
       6.5.5.  Delivery Failures  . . . . . . . . . . . . . . . . . . 18
       6.5.6.  Copy and blind copy recipients . . . . . . . . . . . . 19
       6.5.7.  Handling of non-priority servers . . . . . . . . . . . 19
       6.5.8.  Handling servers with different policies . . . . . . . 20
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   10. List of abbreviations  . . . . . . . . . . . . . . . . . . . . 24
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     11.2. Informative Reference  . . . . . . . . . . . . . . . . . . 25
     11.3. Normative References . . . . . . . . . . . . . . . . . . . 25



Schmeing & Brendecke     Expires August 5, 2006                 [Page 2]

Internet-Draft         Priority Extension for SMTP         February 2006


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 28

















































Schmeing & Brendecke     Expires August 5, 2006                 [Page 3]

Internet-Draft         Priority Extension for SMTP         February 2006


1.  Introduction

   Military Message Handling Systems (MMHS) have high requirements in
   their functionality and reliability.  As examinations in [1] show the
   SMTP (Simple Mail Transfer Protocol) [7], including some SMTP
   extensions, provides most of the features requested by the military.
   But one of the most important requirements of MMHS is not provided by
   SMTP.  This is the requirement for priorities or precedences.  This
   document defines an SMTP Service Extension offering such a service
   allowing Mail Transfer Agents (MTAs) to determine which emails
   require expedited handling.








































Schmeing & Brendecke     Expires August 5, 2006                 [Page 4]

Internet-Draft         Priority Extension for SMTP         February 2006


2.  Terminology

   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
   and "MAY" in this document are to be interpreted as described in "Key
   words for use in RFCs to Indicate Requirement Levels" [5].

   The terms SMTP client and SMTP server are used with the same
   definition as given in section 2.3.2 of RFC 2821 [7]:

   o  The SMTP client is the (computer) process initiating an SMTP
      session and controlling it issuing commands to the server.

   o  The SMTP server is the process waiting for clients to connect and
      executing the commands from the client.

   As this document is concerned with SMTP only, the terms client and
   server may as well be used without the SMTP prefix.

   An email is waiting to be sent, if it resides in the queue of an MTA
   and can be send to the next hop or delivered to its final
   recipient(s) once available resources at the sending MTA allow this.
   Emails having their processing delayed for some reason 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.

   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 to send more emails 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.

   Additionally, this document will use the terms "default policy",
   "custom policy" and "local policy".  These are defined as follows:

   o  The "default policy" is the policy defined in Section 6.5.

   o  A "custom policy" is any other policy regulating the use of
      priorities for emails.

   o  A "local policy" is the policy applicable for an actual client,
      server, MTA, site or network.  It may be either the default policy
      or a custom policy.






Schmeing & Brendecke     Expires August 5, 2006                 [Page 5]

Internet-Draft         Priority Extension for SMTP         February 2006


3.  Framework for the Priority Extension

   o  The textual name of this extension is "Priority Message Handling".

   o  The EHLO-Keyword is PRIORITY.

   o  One optional parameter is used with this keyword.  This parameter
      is an absolute Uniform Resource Identifier (URI) as defined in
      RFC3986 [14] in section 4.3.  The resource thus identified MUST be
      a document which describes the priority policy.  If this parameter
      is not given the default policy defined in Section 6.5 is applied.
      The syntax for this value is:

         priority-policy ::= absolute-URI

      This policy defines the supported levels of priority, their
      semantics and optionally their names.

   o  No new SMTP verbs are defined.

   o  One optional parameter using the keyword "PRIORITY" is added to
      the RCPT TO command.  The value associated with this parameter is
      a decimal integer number greater than or equal to 0 (zero)
      indicating the priority of the email for the given recipient.  The
      syntax of the value is as follows:

         priority-value ::= [1*3DIGIT]

      A value of 0 indicates an email from a client/network not
      supporting priorities or intended to be sent to such a server/
      network.  Any other number identifies a priority level defined by
      the policy.  Higher numbers mean higher priority.  This parameter
      may be set for each recipient independently.

   o  The maximum length of a RCPT TO command line is increased by 12
      characters by the possible addition of the PRIORITY keyword and
      value.

   o  As one of the most likely instances to assign transport priorities
      is the submitting party of an email (i.e. the originator or
      sender), this extension is valid for message submission according
      to RFC 2476 [6].









Schmeing & Brendecke     Expires August 5, 2006                 [Page 6]

Internet-Draft         Priority Extension for SMTP         February 2006


4.  The Priority Service Extension

   The priority of a message expresses itself in the order they are
   transfered from the client to the server.  This is largely
   independent from the order in which they where received by the
   server.  The Priority Service Extension increases the possibilities
   of SMTP service extensions such as Deliver-By [8] and Delivery Status
   Notification [10][13][12][11] or (non-standard) header fields such as
   Importance.

   In military scenarios, priorities usually come with additional
   associated constraints.  Examples are limitations of the message size
   or the allowed delivery time.

4.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 a client that has more than one email to send at
   a given time MUST send those with a higher priority before those with
   a lower one.

   Priorities are assigned on a per-recipient basis.  The priority of an
   email is the highest priority assigned to any of the yet unprocessed
   recipients.  Thus the priority of the email may vary while it is
   processed by an MTA or UA and may be different at different MTAs.
   The priority of any given recipient is nevertheless constant.

   As long as there are emails with higher priorities waiting to be sent
   a client MUST NOT initiate transactions for emails with lower
   priorities.  It MAY however send an email with highest priority even
   to recipients with lower priorities if this can be done within the
   same transaction as the higher priorities.

   The handling of messages with the same priority level is described in
   Section 4.3.

   Especially in networks with limited available data rate the actual
   transfer over the network may create a significant portion of the
   overall delivery time.  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.  One example of such a mechanism is the "Type of Service"
   field defined in the IP (Internet Protocol) header of RFC 791 [2].
   If such services are available, it is a matter of local policy to
   decide whether to use them.  The mapping from the priorities defined
   at the SMTP level to those offered by the underlying network is as
   well to be defined in the local policy.



Schmeing & Brendecke     Expires August 5, 2006                 [Page 7]

Internet-Draft         Priority Extension for SMTP         February 2006


4.1.1.  Preemption of sessions or transactions

   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
   higher priorities even if there are already several connections
   running for other emails.  If no additional connection is possible, a
   client MUST abort a running session for emails with lower priority no
   later than directly after the current transaction.  The client even
   MAY interrupt an active transaction and SHOULD do this, if otherwise
   constraints such as delivery time would be violated for the email
   with higher priority.  This preliminary termination of sessions or
   transactions is called preemption.

   If preemption of running transactions occurs, the client MUST preempt
   the lowest number of transactions sufficient to process the higher
   priority emails.  It must chose the transactions for the emails with
   the lowest priorities currently processed.  Local policies MAY add
   additional criteria to choose the transaction to be preempted in the
   case that more transactions than required would qualify for
   preemption due to the priority of the emails.  If after applying the
   priority test and all criteria defined by the local policy still the
   number of transactions to preempt is greater than needed, the
   decision is left to the implementation.

   If the client has an option to interrupt transactions in a way that
   it can be restarted at the interruption point later, it SHOULD deploy
   it.  An example for a mechanism providing such a service is the "SMTP
   Service Extension for Checkpoint/Restart" defined in RFC 1845 [3]

   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 independent of the priority of the emails being
   processed.

4.1.2.  Handling of emails with multiple recipients

   If a client has to send an email with multiple recipients bearing
   different priorities to the same server, it SHOULD do so in one
   transaction treating the email according to the highest priority set
   for any of the recipients.

   The reorganization of the transfer order MUST NOT alter or even
   corrupt the emails, therefore allowing safe transmission of all
   emails in dependency of their priority.






Schmeing & Brendecke     Expires August 5, 2006                 [Page 8]

Internet-Draft         Priority Extension for SMTP         February 2006


4.2.  Timely Delivery

   An important constraint usually associated especially with higher
   priority levels is, that messages with that priority have to reach
   its destination within a defined period of time.  Usually, higher
   priorities mean shorter maximum allowed time of delivery.

   As the SMTP does not natively offer a service for timely delivery,
   the decision whether to use delivery time constraints for any or all
   priority levels is left to the local policy.

   The "Deliver By SMTP Service Extension" (Deliver-By Extension)
   defined in [8] is an example of an SMTP extension providing a service
   that can be used to implement such constraints.

   If the local policy does not specify time constraints for a given
   priority, no such constraints are applied.

4.3.  Resolving conflicts for the sending order of messages with the
      same priority

   If two or more emails with the same priority are ready to be sent at
   the same time, clients SHOULD send them in parallel if possible.
   Local policies MAY define rules to determine the order in which
   emails of the same priority are sent if the number of emails ready to
   be sent exceeds the number of emails that can be processed in
   parallel.

   If all applicable rules to determine the sending order from this memo
   and local policy still leave more emails ready to be sent than can be
   processed in parallel, the final decision is left to the
   implementation.

4.4.  Size Limitation

   The larger a message, the longer the time required to send it over a
   given connection.  In constrained networks this can impair the
   possibility of the MTS to deliver large messages with high priorities
   in time.  Therefore, policies governing priorities usually have size
   constraints for the messages at least for higher priorities.

   These constraints can always be enforced independent of the SMTP
   Service Extensions supported by the server receiving the email.  It
   is always possible for the server to count the number of received
   octets after the client indicated the end of the email and base the
   decision to accept or reject the email on this number.

   Therefor, after completely receiving the content of the email the



Schmeing & Brendecke     Expires August 5, 2006                 [Page 9]

Internet-Draft         Priority Extension for SMTP         February 2006


   server MUST check that the actual received size does not exceed the
   lowest size limitation allowed by the priorities set for all
   recipients.  If the actual size is too big for at least one
   recipient, the server MUST NOT send a successful reply but MUST
   reject the email with an error code of "556 Priority defined size
   limit exceeded".  If the client uses an SMTP Service Extension which
   allows to transmit the content in several chunks, such as [9], the
   server SHOULD check the current size after every chunk and SHOULD
   abort the email with the above error code as soon as the size
   constraint applicable for the email is violated.

   In addition to just counting the received octets while the email is
   being transmitted, a client and server may also deploy mechanisms,
   that allow for an earlier detection of size violations.  An example
   for such a service is the "SMTP Service Extension for Message Size
   Declaration" (SIZE Extension) from RFC 1870 [4].

   The SIZE Extension allows a client to declare the size of the email
   with an optional parameter to the MAIL FROM: SMTP command.  This
   parameter can be used for example to decide for each individual
   recipient whether the email fulfils the size constraints.  Whether
   the email or only the recipients for which the priority induced size
   constraint would be violated are rejected is a matter of local
   policy.

   If the server indicated for individual recipients that they can not
   be accepted with the given priority for any reason, local policy MAY
   allow to nevertheless transmit the email to the remaining recipients.

   If the local policy does not address size constraints, the default is
   that emails may be of arbitrary size.  Constraints imposed by other
   circumstances such as available storage space or general limitations
   are, of course, unaffected by this.

4.5.  Further Constraints

   Depending on the actual scenario in which this priority extension is
   deployed, it may be necessary to add further constraints to certain
   priority levels.  Although it is strongly believed that limiting the
   delivery time and email size should be sufficient for most if not all
   purposes, local policy may add further constraints such as
   limitations on content types or security classifications.

   For example, in military applications of priorities, messages without
   classification or with low classification may only be sent at the
   lower priority levels.





Schmeing & Brendecke     Expires August 5, 2006                [Page 10]

Internet-Draft         Priority Extension for SMTP         February 2006


5.  Recipient Dependent Priority

   Often, not all recipients need to receive the message with the same
   (high) priority.  For example copy (CC, carbon copy) and blind copy
   (BCC, blind carbon copy) recipients usually can accept a lower
   priority than the primary recipient(s) because they do not have to
   act on the message but receive it only for informational purposes.

   Limiting the high priority messages only to the primary recipient
   complies with the basic principle of using high priorities only if
   really necessary.  So the number of high priority messages is reduced
   to a minimum.  Assigning every recipient an individual priority could
   be realized by sending the same message several times.  This is
   unnecessary, non-practical and a waste of resources.  Binding the
   priority to the recipient allows to deploy the multiple recipient per
   transaction feature of SMTP even when having different priorities for
   different recipients of the message.

   To lower the burden on the network, an MTA SHOULD send any message to
   as many recipients as possible with one transaction, even if the
   recipients have different priorities bound to them.  In this case,
   the MTA MUST treat the email according to the highest priority bound
   to any of the recipients and MUST retain the original priority values
   for each recipient.

   A recipient address, that has a priority other than the non-priority
   (see Section 6.2) set, is called a prioritized recipient (address).

5.1.  Maillists, Aliases and Forwarding

   Several options exist to translate the address of an email recipient
   into one or more other addresses.  Examples for this are aliases,
   maillist or email redirections e.g. via a .forward file.

   Priorities are assigned for a reason.  Therefore, if a prioritized
   recipient address is to be translated or expanded as explained above,
   the translating or expanding entity (maillist manager, MTA etc.)
   SHOULD retain the original priority if possible and SHOULD set it for
   all expanded or translated addresses.  Local policy however MAY
   deviate from this behavior for good reason.











Schmeing & Brendecke     Expires August 5, 2006                [Page 11]

Internet-Draft         Priority Extension for SMTP         February 2006


6.  Priority Policies

   This memo defines a default policy in Section 6.5.  A server
   indicates support for this policy by omitting the optional parameter
   to the PRIORITY EHLO keyword.  An SMTP server MUST NOT use the
   PRIORITY keyword without argument if it does not support the default
   priority.  Servers MUST NOT indicate support for more than one policy
   to a client at a time.  However a server MAY indicate different
   policies to clients coming from different addresses or connecting at
   different times.

   Although the policy identifier must be a syntactically valid URL,
   this memo does not define whether it is a machine readable definition
   or just a textual description meant for implementors of the policy.
   The URL nevertheless MUST point to a document defining the policy in
   some way.

   The following constraints apply to all policies governing priority
   message handling:

   o  A priority policy MUST at least define the supported priority
      levels and SHOULD determine the size constraints for each defined
      level.  If no size constraints are defined for a level, emails of
      that level may be of arbitrary size.

   o  The priorities MUST be denominated by decimal integer numbers
      greater than or equal to 1 but MAY additionally be assigned
      symbolic names.  Higher values mean higher priority.

   o  If a policy defines symbolic names it SHOULD define a name for
      every one but MAY omit any.  If a name is assigned to the non-
      priority, it SHOULD reflect that this priority is not a regular
      one.

   o  Priority values SHOULD be assigned in consecutive order.  The
      total number of defined priority levels MUST be kept to the
      possible minimum to remain manageable.

   o  Priority level 0 (zero) is considered to be the "non-priority"
      value for recipients that can not be reached via MTAs supporting
      priorities or for emails coming in from clients not supporting the
      priority policy of the receiving server or not supporting
      priorities at all.

   o  The definitions and constraints for the special priority 0 are
      explained in Section 6.2.





Schmeing & Brendecke     Expires August 5, 2006                [Page 12]

Internet-Draft         Priority Extension for SMTP         February 2006


   o  If a priority mechanism of the underlying network should be used,
      mappings from the SMTP priority level to the priority levels of
      the network MUST be defined.  If no mapping is defined, servers
      SHOULD use the default level for the network connection but MAY
      use higher ones.  This does not change the SMTP priority level.

   o  In some cases it is possible to determine that an individual
      recipient can not be accepted because of a violation of the
      priority policy directly when the respective RCPT TO SMTP command
      is issued.  A priority policy SHOULD define how to handle the
      emails in this case.  Possible options are to completely reject
      the email or to send it to the remaining recipients.  The default
      is to send the emails to the remaining recipients, if no other
      conditions require the email to be rejected completely.

   o  In other cases the decision to reject an individual recipient can
      only be made after the respective RCPT TO: SMTP command has been
      confirmed with a 2xx SMTP reply code but the final 250 SMTP reply
      code accepting the email has not yet been sent.  In these cases
      the whole email MUST be rejected with an appropriate error code.

6.1.  Conflicts with external constraints

   If there is a conflict between a priority induced constraint and a
   constraint from some other sources (external constraint), the more
   restrictive constraint always has precedence over the less
   constrictive one.  If an email is rejected because of constraints not
   induced by the priority policy, the error message MUST NOT indicate a
   priority policy violation.

   To illustrate this, consider the following example:

   o  An email with a size of 2 M-Byte is to be sent.

   o  The highest priority set for any of the recipients is n >= 1.

   o  The maximum size for emails with priority n is 3 M-Byte.

   o  At the server to which the email should be submitted, the
      parameter to the SIZE EHLO keyword limits emails to 1 M-Byte in
      size due to limited spool storage.

   From the perspective of the priority policy this email would be
   acceptable because it is smaller than the 3 M-Bytes allowed for
   messages with priority n.  Nevertheless, the constraints defined by
   the SIZE Extension set a limit of 1 M-Byte, which is more restrictive
   than the constraint set by the priority policy.  Thus the constraint
   set by the SIZE Extension takes precedence and the email can not be



Schmeing & Brendecke     Expires August 5, 2006                [Page 13]

Internet-Draft         Priority Extension for SMTP         February 2006


   accepted by the server.  The server would respond as defined in RFC
   1870 [4] and send the appropriate error code for overly large
   messages.

   If on the other hand the priority policy would set the 1 M-Byte limit
   and the storage space of the server would allow 3 M-Byte emails, the
   email would still be unacceptable.  But this time it would be a
   priority policy violation that would be indicated with the error code
   defined in section Section 4.4 of this memo.

   If both, external and policy induced constraints would make an email
   unacceptable, the error message must be created according to the more
   restrictive constraint.  If, in the above example, the email would
   have a size of 4 M-Byte, it would not be acceptable due to both the
   limitation defined with the EHLO keyword and the limitation of the
   priority policy.  As the limitation of the EHLO keyword is more
   restrictive the email would still not be a policy violation.

   The determination of what error code to create does not discriminate
   between transient (i.e. error codes in the 4xx range) and permanent
   errors (i.e. error codes in the 5xx range).  If the 1M-Byte
   restriction of the EHLO keyword would be due to a temporary shortage
   of storage space, the 4 M-Byte email from the previous paragraph for
   example could be rejected with a transient error from the EHLO
   keyword while the shortage lasts.  If there would be enough storage
   space afterwards, it would still be rejected, but this time with a
   permanent error from the priority policy.

   Local policy MAY allow for permanent errors to take precedence over
   transient ones to lessen the burden on the network.  In this case the
   4 M-Byte email would be rejected with a permanent error due to a
   policy violation on the first attempt to transfer it to the MTA.

6.2.  The Non-priority

   The priority 0 bears a special meaning: It is the priority
   automatically assigned to emails coming in to a server supporting
   priorities from a client not supporting them.  It is the default
   priority assigned to recipients for which no priority is set
   explicitly.  It is as well the priority that SHOULD be used for
   recipients behind an MTA not supporting priorities.  This priority
   MUST always be used for this purpose.  Policies MUST NOT impose
   constraints such as delivery or size restrictions to this priority
   but MAY assign a name to it.  Other SMTP Service Extensions such as
   the Deliver-By or SIZE Extensions may still define additional
   constraints.

   Servers MUST allow to explicitly set the non-priority for any or all



Schmeing & Brendecke     Expires August 5, 2006                [Page 14]

Internet-Draft         Priority Extension for SMTP         February 2006


   recipients of an email.

   Clients MUST be able to set the non-priority for a recipient.  It
   MUST be able to set priorities for only some of the recipients.  If
   priorities have been set for any recipients, clients SHOULD set the
   non-priority for any recipient, for which no priority has been set.
   They MAY always set the non-priority to recipients for which no
   priority has been set if the receiving server indicates support for
   this extension, even if the supported policies of the client and
   server do not match.

   Emails in which no other priority than the non-priority has been set
   MUST always be delivered normally, even if this means transfer to
   servers that do not support priority handling or have a different
   policy.

   If an email is not rejected for other reasons, sending it to non-
   compliant servers for recipients that have the non-priority set MUST
   NOT be considered an error.  Instead the email MUST be delivered.  In
   this context a non-compliant server is one not supporting this
   extension at all or having a different policy.

   Recipients, for whom no priority or the non-priority is set, are
   called non-priority recipients.  Emails, that have only non-priority
   recipients are called non-priority emails.

6.3.  Handling Non-priority Servers and Mismatching Policies

   Not all servers will support the Priority Message Handling Extension
   nor will all that do have the same policy.  Servers that support a
   different policy than the client are called mismatching servers;
   servers not indicating support for priorities (independent of whether
   they actually do or do not support them) are called non-priority
   servers.

   By default, only emails for non-priority recipients are delivered to
   non-priority or mismatching servers.  If recipients with priorities
   other than the non-priority require sending the email to mismatching
   on non-priority servers, this is treated as an error.  The email MUST
   NOT be relayed but the MTA MUST send a error code of "557 Receiving
   server not supporting compliant priority policy".

   The local policy of a client MAY however define priorities other than
   the non-priority to be routable to non-priority servers.  It MAY
   define arbitrary actions to be taken in this case or define it as
   normal operation.  This can be defined for each priority
   independently.  An example for an action to take is the sending of
   warning emails to the originator and/or recipient of the email



Schmeing & Brendecke     Expires August 5, 2006                [Page 15]

Internet-Draft         Priority Extension for SMTP         February 2006


   informing them of the loss of priorities.  Another example is to
   write log information to the system protocol.

   A policy at a client MAY as well define a mapping to another policy,
   thus enabling transfer of emails to a server using this policy.  As
   with non-priority servers, it MAY define arbitrary actions to be
   taken in this case or define it as normal operation.

   It is impossible for a server to know the policy used by a client.  A
   server thus can not refuse accepting emails based on the client's
   (mismatching) policy.

   A server MUST always accept emails, where no priority is set or where
   only the non-priority is set.

6.4.  Invalid priority levels

   If a client provides an invalid value to the PRIORITY argument to the
   RCPT TO: command, the server MUST reject that recipient with an error
   code of "558 Invalid priority value" and MAY reject the complete
   email with the same error code.

   An invalid priority level may be a non-numeric value, a negative
   value or a value not defined in the local policy.

6.5.  Default Policy

   If the policy identifier of the PRIORITY EHLO keyword is omitted, the
   default policy set out in this section is applied.  Servers MUST NOT
   use the PRIORITY keyword without an argument if they do not support
   this policy but support for this policy is OPTIONAL.

6.5.1.  Number and names of priorities

   o  This policy defines the priority levels 1, 2, 3 and 4.

   o














Schmeing & Brendecke     Expires August 5, 2006                [Page 16]

Internet-Draft         Priority Extension for SMTP         February 2006


      The following names are assigned to the different priority levels:

                         +----------+-----------+
                         | Priority | Name      |
                         +----------+-----------+
                         |     0    | NONE      |
                         |          |           |
                         |     1    | ROUTINE   |
                         |          |           |
                         |     2    | PRIORITY  |
                         |          |           |
                         |     3    | IMMEDIATE |
                         |          |           |
                         |     4    | FLASH     |
                         +----------+-----------+

   o  The names are case-insensitive.

6.5.2.  Message size constraints

   o  The message size for ROUTINE and PRIORITY is unlimited by this
      policy.

   o  The message size for the priority level IMMEDIATE MUST NOT exceed
      4096 bytes.

   o  The message size for the FLASH priority is limited to 2048 Bytes.

   For calculating the message size the complete email including all
   control characters and header fields is considered but servers MAY
   exclude any trace header fields as defined in RFC 2821 [7].

   According to section Section 4.4 these size constraints can always be
   enforced.  Servers MUST always determine the size of the email and
   check against the lowest size constraint introduced by any of the
   applied priorities prior to finally accepting an email.  Servers
   SHOULD abort a transaction cleanly as soon as possible with the error
   code defined in section Section 4.4.

   If both, the client and server implement the SIZE Extension the SIZE
   parameter for the MAIL FROM SMTP command MUST be used and its value
   MUST be set to be greater than or equal to the actual relevant size
   of the email as defined above.  If for any recipient the indicated
   size of the email exceeds the limit associated with the priority set
   for this recipient, the recipient MUST be rejected with the
   appropriate error code for size constraint violations defined in
   section Section 4.4.  Delivery to the remaining recipients is not
   affected by this.



Schmeing & Brendecke     Expires August 5, 2006                [Page 17]

Internet-Draft         Priority Extension for SMTP         February 2006


6.5.3.  Delivery time constraints

   If the MTA supports the Deliver-By Extension, the following delivery
   time constraints are associated with the priorities:

      Four hours for ROUTINE,

      one hour for PRIORITY,

      30 minutes for IMMEDIATE and

      10 minutes for FLASH.

   These constraints MAY be ignored if a client or server does not
   support the Deliver-By Extension but MUST be applied otherwise.  They
   MUST be retained if emails for recipients with priority levels
   ROUTINE or PRIORITY are sent to non-compliant or non-priority servers
   that support the Deliver-By Extension.

6.5.4.  Usage of network layer priorities

   The default policy doesn't use network layer priorities.  For this
   reason no mapping of priority levels is defined here.

   Administrators of actual installations MAY however define local
   mappings to network priorities.  Routing of emails to other servers
   implementing SMTP priorities SHOULD NOT be impaired even if the
   transfer through networks without network priorities is required.

6.5.5.  Delivery Failures

   If an email can not be delivered to one or more of its (prioritized)
   recipients, an appropriate error message MUST be presented to the
   originator of the email.  Delivery to the remaining recipients MUST
   be processed independently.

   Error or warning message caused by failures associated with priority
   handling under this Default Policy MAY be generated individually for
   each recipient or MAY be aggregated to contain all errors associated
   with a single email.  They MUST NOT contain error messages from more
   than one email.  Additionally, they MAY take the form of an email
   being sent to the originator or MAY be presented in some other way.
   An example for an alternative presentation can be a window shown to
   the originator by his user agent.  If the error message has the form
   of an email it MUST be delivered to the originator with the highest
   priority of any recipient that caused the error or warning message.





Schmeing & Brendecke     Expires August 5, 2006                [Page 18]

Internet-Draft         Priority Extension for SMTP         February 2006


6.5.6.  Copy and blind copy recipients

   o  Copy recipients MUST NOT receive the email at a higher priority
      than the highest set for any primary recipient.

   o  The default priority for copy recipients is ROUTINE if the highest
      priority of the primary recipients is ROUTINE or higher and NONE
      otherwise.

   o  The priority for copy recipients may be as high as PRIORITY, if
      the highest priority set for a primary recipient is PRIORITY or
      higher.

   o  The priority for blind copy recipients MUST be set to NONE.

   These constraints MUST be enforced by the submitting UA or MTA and
   MUST be ignored by any other MTA or the receiving UA(s).

6.5.7.  Handling of non-priority servers

   If emails must be transferred to non-priority servers to be delivered
   to any or all recipients the following rules apply:

   o  Emails MUST be sent to non-priority servers for recipients with
      priorities NONE, ROUTINE or PRIORITY.  If the server and client
      both support the Deliver-By Extension the client MUST deploy it to
      ensure timely delivery of the email.

   o  It is strongly believed that this email will reach its destination
      in time.  A deliver-by-time from one or even four hours is
      certainly no problem for todays Internet.

   o  The sending client SHOULD write a log message to record loss of
      priority handling for those recipients and MAY as well inform the
      originator of this fact.

   o  Emails MUST NOT be sent to non-priority servers for any recipients
      with priorities of IMMEDIATE or FLASH.  For these recipients a
      reply code of "558 Priority level violation" MUST be generated.

   o  If an email must be sent to a non-priority server for both,
      recipients with priorities not higher than PRIORITY and those with
      priorities of IMMEDIATE or FLASH, it must be transferred for the
      recipients with priorities not higher than PRIORITY and error
      messages must be created for the other recipients.






Schmeing & Brendecke     Expires August 5, 2006                [Page 19]

Internet-Draft         Priority Extension for SMTP         February 2006


6.5.8.  Handling servers with different policies

   Mismatching servers are considered to be non-priority servers when
   deciding whether to send emails to them or not.  If emails are sent
   to them, all priorities MUST be set to NONE, but otherwise the
   handling is exactly as if the servers were non-priority servers.













































Schmeing & Brendecke     Expires August 5, 2006                [Page 20]

Internet-Draft         Priority Extension for SMTP         February 2006


7.  Example

   This example shows an SMTP session with one transaction using the
   priority extension.  Lines starting with C are sent by the client,
   lines starting with S by the server.


           S: 220 foo.com Simple Mail Transfer Service Ready
           C: EHLO bar.com
           S: 250-foo.com greets bar.com
           S: 250-SIZE
           S: 250-DSN
           S: 250-PRIORITY
           S: 250 HELP
           C: MAIL FROM:<Smith@bar.com>
           S: 250 OK
           C: RCPT TO:<Jones@foo.com> PRIORITY=2
           S: 250 OK
           C: RCPT TO:<Brown@foo.com> PRIORITY=4
           S: 250 OK
           C: DATA
           S: 354 Start mail input; end with <CRLF>.<CRLF>
           C: Blah blah blah...
           C: ...etc. etc. etc.
           C: .
           S: 250 OK
           C: QUIT
           S: 221 foo.com Service closing transmission channel























Schmeing & Brendecke     Expires August 5, 2006                [Page 21]

Internet-Draft         Priority Extension for SMTP         February 2006


8.  Security Considerations

   This memo does not discuss security issues and is not believed to
   raise any security issues not already endemic in electronic mail and
   present in fully conforming implementation of RFC 2821 [7].

   Possible Denial-of-Service (DoS) attacks through extensive use of
   high priorities are outside the scope of this memo.  It is believed
   that they are best dealt with by access control and careful design of
   local policies.









































Schmeing & Brendecke     Expires August 5, 2006                [Page 22]

Internet-Draft         Priority Extension for SMTP         February 2006


9.  IANA Considerations

   The IANA Mail Parameters registry documents SMTP service extensions.
   The "PRIORITY" service extension has to be added to this registry in
   accordance with the specifications of section Section 3.














































Schmeing & Brendecke     Expires August 5, 2006                [Page 23]

Internet-Draft         Priority Extension for SMTP         February 2006


10.  List of abbreviations


         BCC     Blind Carbon Copy
         CC      Carbon Copy
         DSN     Delivery Status Notification
         IETF    Internet Engineering Task Force
         IP      Internet Protocol
         MMHS    Military Message Handling System
         MTA     Message Transfer Agent
         MTS     Message Transfer System
         NATO    North Atlantic Treaty Organization
         RFC     Request For Comment
         SMTP    Simple Mail Transfer Protocol
         TTY     Teletypewriter
         UA      User Agent
         URL     Uniform Resource Locator


































Schmeing & Brendecke     Expires August 5, 2006                [Page 24]

Internet-Draft         Priority Extension for SMTP         February 2006


11.  References

11.2.  Informative Reference

   [1]  Schmeing, M. and N. Haak, "Applicability of Internet-email for
        military High-grade Messaging", FKIE-Bericht 93, February 2005.

11.3.  Normative References

   [2]   Postel, J., "Internet Protocol", STD 5, RFC 791,
         September 1981.

   [3]   Crocker, D. and N. Freed, "SMTP Service Extension for
         Checkpoint/Restart", RFC 1845, September 1995.

   [4]   Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
         for Message Size Declaration", STD 10, RFC 1870, November 1995.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [6]   Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
         December 1998.

   [7]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.

   [8]   Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
         June 2000.

   [9]   Vaudreuil, G., "SMTP Service Extensions for Transmission of
         Large and Binary MIME Messages", RFC 3030, December 2000.

   [10]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
         Extension for Delivery Status Notifications (DSNs)", RFC 3461,
         January 2003.

   [11]  Vaudreuil, G., "The Multipart/Report Content Type for the
         Reporting of Mail System Administrative Messages", RFC 3462,
         January 2003.

   [12]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
         January 2003.

   [13]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
         Delivery Status Notifications", RFC 3464, January 2003.

   [14]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform



Schmeing & Brendecke     Expires August 5, 2006                [Page 25]

Internet-Draft         Priority Extension for SMTP         February 2006


         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

11.  References















































Schmeing & Brendecke     Expires August 5, 2006                [Page 26]

Internet-Draft         Priority Extension for SMTP         February 2006


Authors' Addresses

   Michael Schmeing
   Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V.
   Neuenahrer Strasse 20
   Wachtberg  53343
   DE

   Phone: +49 228 9435 593
   Email: schmeing@fgan.de
   URI:   http://www.fgan.de


   Jan-Wilhelm Brendecke
   Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V.
   Flerzheimer Strasse 36
   Rheinbach  53359
   DE

   Phone: +49 2226 913760
   Email: brendecke@gmx.de






























Schmeing & Brendecke     Expires August 5, 2006                [Page 27]

Internet-Draft         Priority Extension for SMTP         February 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Schmeing & Brendecke     Expires August 5, 2006                [Page 28]


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