Network Working Group M. Schmeing Internet-Draft J. Brendecke Expires: March 25, 2006 FGAN September 21, 2005 SMTP Service Extension for Priority Message Handling draft-schmeing-smtp-priorities-01 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 March 25, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 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 Schmeing & Brendecke Expires March 25, 2006 [Page 1] Internet-Draft Priority Extension for SMTP September 2005 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Framework for the Priority Extension . . . . . . . . . . . . . 5 4. The Priority Service Extension . . . . . . . . . . . . . . . . 6 4.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 6 4.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Resolving conflicts for the sending order of messages with the same priority . . . . . . . . . . . 8 4.3. Size Limitation . . . . . . . . . . . . . . . . . . . . . 8 4.4. Content Types . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Classification . . . . . . . . . . . . . . . . . . . . . . 9 5. Recipient Dependent Priority . . . . . . . . . . . . . . . . . 10 5.1. Maillists, Aliases and Forwarding . . . . . . . . . . . . 10 6. Priority Policies . . . . . . . . . . . . . . . . . . . . . . 11 6.1. The Non-priority . . . . . . . . . . . . . . . . . . . . . 12 6.2. Handling Non-priority Servers and Mismatching Policies . . 13 6.3. Invalid priority levels . . . . . . . . . . . . . . . . . 14 6.4. Default Policy . . . . . . . . . . . . . . . . . . . . . . 14 6.4.1. Number and names of priorities . . . . . . . . . . . . 14 6.4.2. Delivery time constraints . . . . . . . . . . . . . . 15 6.4.3. Message size constraints . . . . . . . . . . . . . . . 15 6.4.4. Usage of network layer priorities . . . . . . . . . . 16 6.4.5. Delivery Failures . . . . . . . . . . . . . . . . . . 16 6.4.6. Copy and blind copy recipients . . . . . . . . . . . . 16 6.4.7. Handling of non-priority servers . . . . . . . . . . . 17 6.4.8. Handling servers with different policies . . . . . . . 17 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. List of abbreviations . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Schmeing & Brendecke Expires March 25, 2006 [Page 2] Internet-Draft Priority Extension for SMTP September 2005 1. Introduction Military Message Handling Systems (MMHS) have high requirements in their functionality and reliability. As examinations in [8] show the SMTP (Simple Mail Transfer Protocol) [3], 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 a SMTP Service Extension offering such a service allowing Mail Transfer Agents (MTAs) to determine which emails require expedited handling. Schmeing & Brendecke Expires March 25, 2006 [Page 3] Internet-Draft Priority Extension for SMTP September 2005 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" [1]. The terms SMTP client and SMTP server are used with the same definition as given in section 2.3.2 of RFC 2821 [3]: 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. 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.4. 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 March 25, 2006 [Page 4] Internet-Draft Priority Extension for SMTP September 2005 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 indicates the supported priority policy by referring to a URL which describes this policy. If it is not given the default policy defined in Section 6.4 is applied. The syntax for this value is: priority-policy ::= [1*CHAR] 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*DIGIT] 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. A higher number means a higher priority. This parameter may be set for each recipient independently. o The maximum length of a RCPT TO command line is increased by 9 characters plus the number of digits used for the indication of the priority level by the possible addition of the PRIORITY keyword and value. Schmeing & Brendecke Expires March 25, 2006 [Page 5] Internet-Draft Priority Extension for SMTP September 2005 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 [7] and Delivery Status Notification [5][6][10][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. 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 fuer emails with higher priorities even if there are already several connections running for other emails. If no additional connection is possible, a server MUST abort a running session for emails with lower priority no later than directly after the current transaction. The server even MAY interrupt the current 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 the client implements the "SMTP Service Extension for Checkpoint/ Restart" defined in RFC 1845 [2] it SHOULD abort a running transaction in a way that a later restart is possible. 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 reorganisation of the transfer order MUST NOT alter or even corrupt the emails, therefore allowing safe transmission of all emails in dependency of their priority. Priorities are assigned on a per-recipient basis. The priority of an Schmeing & Brendecke Expires March 25, 2006 [Page 6] Internet-Draft Priority Extension for SMTP September 2005 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. Emails waiting for some transient error to be resolved are not regarded as waiting to be sent. 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 [12]. The Handling of messages with the same priority level is described in Section 4.2.1. 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. A server and client implementing this extension SHOULD as well implement the "Deliver By SMTP Service Extension" (Deliver-By Extension) defined in [7]. This extension provides a service to request a certain maximum time by which an email must be delivered. If certain priorities are associated with a maximum delivery time, these constraints MUST be implemented using the "Deliver By SMTP Service Extension". Unless explicitly specified otherwise by the local policy, all time constraints are hard constraints. If, for any reason, an email can not be delivered in this time frame, this is to be considered a permanent error and an error code of "555 Priority defined time limit exceeded" is to be created. A local policy MAY however specify that the time frames for certain priority levels are "soft" constraints only eliciting a delay report to the originator. Schmeing & Brendecke Expires March 25, 2006 [Page 7] Internet-Draft Priority Extension for SMTP September 2005 4.2.1. Resolving conflicts for the sending order of messages with the same priority If two or more emails with the same priority are waiting to be sent at the same time, clients SHOULD send them in parallel if possible. If it is not possible to send all emails but the Deliver-By SMTP Service Extension is used on any of them, the emails the shortest remaining Deliver-By time MUST be sent first. Local policies MAY define additional rules to determine the order in which emails are sent if the priority and (if applicable) Deliver-By time criteria are not sufficient. They MUST NOT overrule either of these criteria. If all applicable rules to determine the sending order from this memo and local policy still leave more emails to be sent than possible, the final decision is left to the implementation. 4.3. 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. RFC 1870 [4] specifies a "SMTP Service Extension for Message Size Declaration" (SIZE Extension). A client or server implementing the Priority extensions SHOULD as well implement the SIZE Extension. If a client implementing the SIZE and Priority Extensions sends an email to a similar server, it MUST use the SIZE parameter for the MAIL FROM command and MUST set its argument to be greater than or equal to the actual size of the email. If a server receives an email with the SIZE parameter to the MAIL FROM command set, it MUST check for each recipient that the size constraint for the priority associated with the recipient is satisfied. If the size constraint can not be satisfied for any recipient the server MUST reject that recipient with an error code of "556 Priority defined size limit exceeded" and MAY reject the entire email with the same error code. After completely receiving the content of the email the 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 Schmeing & Brendecke Expires March 25, 2006 [Page 8] Internet-Draft Priority Extension for SMTP September 2005 code of "556 Priority defined size limit exceeded". If the client uses a 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 an appropriate error code as soon as the size constraint applicable for the email is violated. The requirements from the previous paragraph MUST be supported, even if the SIZE extension is not present. 4.4. Content Types Due to the priority of an email its content may be limited. Again common sense urges us to keep high priority messages to a minimum in number and size, just containing the most important facts. Thus implying that audio, video, images, etc. should not be part of a high priority message. On the other hand, on certain occasions an image or similar can by very useful or even required. Since there is already a Size Limitation for high priority messages a content limitation may not be required at all. The final decision on this matter can only be made knowing the local circumstances and is thus left to the local policy. If a local policy does not address this issue, the default is that there are no limitation to the content type(s) for any priority. 4.5. Classification Sometimes the classification of a message (e.g. unclassified, confidential, restricted, secret or top secret) is seen in context with the priority. Nevertheless, a message classified as secret does not necessarily have to be sent with a higher priority than a confidential or unclassified one. It may be true that the content of a message requires a high priority as well as a high classification, but classification and priority are not linked directly. It is common though to restrict unclassified messages to the lowest priority. Again, as with the content type, the final decision can only be made in the local policy. If classification is not address in a local policy, no restrictions apply. Schmeing & Brendecke Expires March 25, 2006 [Page 9] Internet-Draft Priority Extension for SMTP September 2005 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 in sending the same message several times. This is unnecessary and non-practical. 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, a MTA SHOULD additionally 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.1) set, is called a prioritised 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 prioritised 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 behaviour for good reason. Schmeing & Brendecke Expires March 25, 2006 [Page 10] Internet-Draft Priority Extension for SMTP September 2005 6. Priority Policies This memo defines a default policy in Section 6.4. A server indicates support for this policy by omitting the optional parameter to the PRIORITY EHLO keyword. A 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. However a server MAY indicate different policies to clients coming from different addresses. 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 The priorities MUST be denominated by decimal numbers of arbitrary size starting with 1 (one) as the lowest possible priority. A higher number means a higher priority. 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 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 A priority policy SHOULD define how to handle emails where some but not all recipients have been rejected due to priority reasons. Possible options are to completely reject the email or to send it to the remaining recipients. o Priority 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.1. Schmeing & Brendecke Expires March 25, 2006 [Page 11] Internet-Draft Priority Extension for SMTP September 2005 o A priority policy MUST at least define the number of priorities supported and MUST specify for each priority level * the maximum acceptable delivery time and * the maximum acceptable size of an email. For any priority level the maximum delivery time and/or email size MAY be defined to be unlimited. If the time or size limits set by a priority policy conflict with other constraints such as those defined by the SIZE- or Deliver-By-Extensions the more restrictive setting always takes precedence overruling the less restrictive one. 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. 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 accepted by the server. A priority policy MAY assign symbolic names to any priority including the non-priority. 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. Section 6.2 defines the rules applicable if an email with priorities other than the non-priority have to be transferred to a server that either does not support priorities or supports another policy. 6.1. 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 Schmeing & Brendecke Expires March 25, 2006 [Page 12] Internet-Draft Priority Extension for SMTP September 2005 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 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. 6.2. Handling Non-priority Servers and Mismatching Policies Not all MTAs will support the Priority Message Handling Extension nor have the same policy. By default, only emails, where only the non- priority is used or no priorities are set at all are delivered to servers with mismatching policies or without support for priorities. If recipient with priorities other than the non-priority require sending the email to non-compliant servers, this is treated as an error. The email MUST NOT be relayed unless the policy of the client explicitly allows this. A policy governing the use of priorities in a client MAY define priorities other than the non-priority to be routable to servers not supporting priorities. 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 Schmeing & Brendecke Expires March 25, 2006 [Page 13] Internet-Draft Priority Extension for SMTP September 2005 the sending of warning emails to the originator and/or recipient of the email 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. 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.3. 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 "557 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.4. 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.4.1. Number and names of priorities o This policy defines the priority levels 1, 2, 3 and 4. o Schmeing & Brendecke Expires March 25, 2006 [Page 14] Internet-Draft Priority Extension for SMTP September 2005 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.4.2. 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. 6.4.3. 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 but excluding any trace header fields are considered. Schmeing & Brendecke Expires March 25, 2006 [Page 15] Internet-Draft Priority Extension for SMTP September 2005 The actual size of an email can always be determined after the client has indicated the end of the transmission. Therefore, the size constraints can be enforced independently of the SIZE Extension. A server receiving an email with priorities set thus MUST check that the size constraints are satisfied prior to finally accepting an email. If any size constraint is violated, the server MUST refuse the email with a permanent error code of "556 Priority defined size limit exceeded". 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 an error code of "556 Priority defined size limit exceeded" and an appropriate error message MUST be presented to the originator of the email. Delivery to the remaining recipients is not affected by this. 6.4.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. 6.4.5. Delivery Failures If an email can not be delivered to one or more of its (prioritised) 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. 6.4.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. Schmeing & Brendecke Expires March 25, 2006 [Page 16] Internet-Draft Priority Extension for SMTP September 2005 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. 6.4.7. Handling of non-priority servers If an email must be transferred to a server not supporting priorities to be delivered to any or all recipients the following rules apply: o The email MUST be sent to the non-priority server 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 The email MUST NOT be sent to the non-priority server for any recipients with priorities of IMMEDIATE or FLASH. For these recipients a reply code of "558 Priority level violation" MUST be generated. 6.4.8. Handling servers with different policies Emails for recipients with a priority level that would allow sending the email to a non-priority server are sent to servers with different policies as well. All priority levels MUST be mapped to NONE in this case and any actions defined in Section 6.4.7 for sending an email of that priority to a non-priority server must be executed as well. Schmeing & Brendecke Expires March 25, 2006 [Page 17] Internet-Draft Priority Extension for SMTP September 2005 7. Example This example shows a 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: S: 250 OK C: RCPT TO: PRIORITY=2 S: 250 OK C: RCPT TO: PRIORITY=4 S: 250 OK C: DATA S: 354 Start mail input; end with . 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 March 25, 2006 [Page 18] Internet-Draft Priority Extension for SMTP September 2005 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 [3]. 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 March 25, 2006 [Page 19] Internet-Draft Priority Extension for SMTP September 2005 9. 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 Organisation RFC Request For Comment SMTP Simple Mail Transfer Protocol TTY Teletypewriter UA User Agent URL Uniform Resource Locator 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and N. Freed, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995. [3] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [4] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995. [5] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [7] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000. [8] Schmeing, M. and N. Haak, "Applicability of Internet-email for military High-grade Messaging", FKIE-Bericht 93, February 2005. [9] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000. Schmeing & Brendecke Expires March 25, 2006 [Page 20] Internet-Draft Priority Extension for SMTP September 2005 [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. [11] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. [12] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Schmeing & Brendecke Expires March 25, 2006 [Page 21] Internet-Draft Priority Extension for SMTP September 2005 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. Neuenahrer Strasse 20 Wachtberg 53343 DE Phone: +49 228 9435 211 Email: brendecke@fgan.de URI: http://www.fgan.de Schmeing & Brendecke Expires March 25, 2006 [Page 22] Internet-Draft Priority Extension for SMTP September 2005 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 (2005). 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 March 25, 2006 [Page 23]