





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: <wait for connection>
      C: <open connection to server>
      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:<jpo@nexor.co.uk>
      S: 250 <jpo@nexor.co.uk> OK
      C: RCPT TO:<g.lunt@nexor.co.uk> PRIO=normal
      S: 250 <g.lunt@nexor.co.uk> OK
      C: RCPT TO:<martin@nexor.com> PRIO=low
      S: 250 <martin@nexor.com> 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: <wait for connection>
      C: <open connection to server>
      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:<jpo@nexor.co.uk>
      S: 250 <jpo@nexor.co.uk> OK
      C: MAIL FROM:<xyz@nexor.co.uk> PRIO=normal
      S: 250 <xyz@nexor.co.uk> OK
      C: RCPT TO:<g.lunt@nexor.co.uk> PRIO=70
      S: 250 <g.lunt@nexor.co.uk> OK
      C: RCPT TO:<martin@nexor.com> PRIO=5
      S: 250 <martin@nexor.com> 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 <j.onions@nexor.co.uk>
        Graeme Lunt <g.lunt@nexor.co.uk>
        Nexor
        Rutherford House
        Nottingham Science Park,
        University Boulevard,
        Nottingham, England.






















Onions & Lunt             Expires Nov 30, 2001                  [Page 5]


