Network Working Group Julian Onions & Graeme Lunt Request for Comments: DRAFT NEXOR May 30, 2001 SMTP Service Extension for Priority draft-onions-priority-smtpext-00 Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 1. Abstract This memo defines an extension to the SMTP service whereby a client may mark a message with a given priority. 2. Introduction Email messages may get assigned a priority to influence their delivery. Higher priority messages being processed ahead of lower priority messages. Whilst this is used to some extent in commerical environments, it is much more common in military environments to attach grades of service and therefore priority to message types. Some message priorities having very specific delivery time scales. The extension may be used on receipt for a number of possible affects, which include, but are not limited to Onions & Lunt Expires Nov 30, 2001 [Page 1] INTERNET DRAFT SMTP Service Extension for Priority May 30, 2001 o Sorting the mail queue based on priority o Batching up low priority messages o Meeting certain service level agreements. o The message may also be refused early in the SMTP dialog based on the requested priority. There are other mechanisms for relaying the priority in RFC-822 messages, such as the Priority: [MIXER] and Precedence: fields. However these are part of the header fields, are not per-recipient and as content fields, are not possible for early refusal of the message. 3. SMTP Extension Oveview The Priority SMTP service extension uses the SMTP service extension mechanism described in [RFC-ESMTP]. The following service extension is hereby defined: (1) The name of the SMTP service extension is "Priority". (2) The EHLO keyword value associated with this extension is "PRIO". (3) No parameters are allowed with this EHLO keyword value. Future documents may extend this specification by specifying options. (maybe max priority?) (4) One optional parameter using the keyword "PRIO" is added to the RCPT TO command. (5) No SMTP verbs are defined by this extension. 4. The Extended RCPT TO Command The extended RCPT TO command is issued by an SMTP client when it wishes to inform an SMTP server that a priority will be associated with this message. The priority is associated with the given recipient. The RCPT TO is the same as defined in [RFC-SMTP], except that PRIO parameter may appear. If no priority is given, it is SHOULD default to normal. 4.1. The PRIO parameter to the ESMTP RCPT TO command To indicate a given priority to a message, a priority must be set in the RCPT TO command. This is defined as follows: Onions & Lunt Expires Nov 30, 2001 [Page 2] INTERNET DRAFT SMTP Service Extension for Priority May 30, 2001 prio-parameter = "PRIO=" prio-value prio-value = prio-key / prio-level prio-key = "low" / "normal" / "high" ; text priorities prio-level = 1*2digit ; relative prioritites The low, medium and high priorities MUST be taken as values 10, 20, and 30 respectively. As military systems often have a larger range of priorities, these can be labelled by an integer to indicate the relative priority. Higher numbers implying higher levels of priority. Using these values, allows scope for values with lower priority than the normal low priority messages, and interpolation between values too if required. 5. SMTP Server handling The final decision of the handling of the message will be down to the receiving MTA. Based on policy or limitations, it may take several actions. o It may reject messages, or individual recipients based on the priority requested. o It may silently downgrade the priority to another value. o It may discard the priority. THis has to be done when relaying to a non Priory Extension supporting MTA. o When a report or DSN is required, it MAY take the priority value of the recipient(s) it is reporting about to construct the priority of the response. This may be subject to local policies however. When rejecting messages based on the priority given, two new codes are considered 4XX (TBD) This indicates a temporary rejection influenced by the assigned priority of the message. Possible reasons are; high priority messages are not allowed at this time; only high priority messages are allowed now (military MINIMISE conditions). 5XX (TBD) This indicates a permanent rejection influenced by the assigned priority. This might be because the user is not permitted to submit such priority messages. Onions & Lunt Expires Nov 30, 2001 [Page 3] INTERNET DRAFT SMTP Service Extension for Priority May 30, 2001 6. Examples The following show possible dialogs using the new parameter. In this exchange, the default priority is set to normal, and then downgraded to low priority for the second recipient. S: C: S: 220 nexor.co.uk SMTP ready C: EHLO victor.nexor.co.uk S: 250-hello victor.nexor.co.uk S: 250 PRIO C: MAIL FROM: S: 250 OK C: RCPT TO: PRIO=normal S: 250 OK C: RCPT TO: PRIO=low S: 250 OK This example shows a possible military senario. The first recipient being a high priority - higher than the normal high, the second recipient being normal (value 20) and the third recipient being of lower then the normal low priority. S: C: S: 220 nexor.co.uk SMTP ready C: EHLO victor.nexor.co.uk S: 250-hello victor.nexor.co.uk S: 250 PRIO C: MAIL FROM: S: 250 OK C: MAIL FROM: PRIO=normal S: 250 OK C: RCPT TO: PRIO=70 S: 250 OK C: RCPT TO: PRIO=5 S: 250 OK 7. Security Considerations High priority messages are open to possible abuse. Therefore if a system makes use of this extension, it may need to validate that the message is suitable for that level of processing. Onions & Lunt Expires Nov 30, 2001 [Page 4] INTERNET DRAFT SMTP Service Extension for Priority May 30, 2001 8. References [RFC-ESMTP] Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869. November 1995. [RFC-SMTP] J. Postel, ``Simple Mail Transport Protocol.'' RFC 821. August 1982. [RFC-KEYWORDS] S. Bradner, ``Key words for use in RFCs to Indicate Requirement Levels.'' RFC 2119. March 1997. [MIXER] S. Kille, "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. 9. Author's Addresses Julian Onions Graeme Lunt Nexor Rutherford House Nottingham Science Park, University Boulevard, Nottingham, England. Onions & Lunt Expires Nov 30, 2001 [Page 5]