Internet Draft                                               E. Allman
draft-ietf-msgtrk-trkstat-02.txt                        Sendmail, Inc.
Valid for six months                                      July 6, 2001
Updates: RFC 1893




              The Message/Tracking-Status MIME Extension

                  <draft-ietf-msgtrk-trkstat-02.txt>

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  dis-
tribute 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 document is a submission by the MSGTRK Working Group of  the
Internet  Engineering Task Force (IETF).  Comments should be submitted
to the ietf-msgtrk@imc.org mailing list.  An archive  of  the  mailing
list may be found at

    http://www.imc.org/ietf-msgtrk/index.html


     Distribution of this memo is unlimited.

1.  Abstract

        Message  Tracking is expected to be used to determine the sta-
   tus of undelivered e-mail upon request.  Tracking is used  in  con-
   junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes-
   sage Disposition  Notifications  [RFC-MDN];  generally,  a  message
   tracking request will be issued only when a DSN or MDN has not been
   received within a reasonable timeout period.

        This memo defines a MIME [RFC-MIME] content-type  for  message
   tracking  status  in  the  same spirit as RFC 1894, ``An Extensible
   Message Format for Delivery Status Notifications''  [RFC-DSN-STAT].

Internet Draft          Message/Tracking-Status           July 6, 2001


   It  is to be issued upon a request as described in ``Message Track-
   ing Query Protocol'' [DRAFT-MTRK-MTQP].  This memo defines only the
   format of the status information.  An extension to SMTP [RFC-ESMTP]
   to label messages for further tracking and request tracking  status
   is defined in a separate memo [DRAFT-MTRK-SMTPEXT].

2.  Other Documents and Conformance

        The  model  used  for Message Tracking is described in [DRAFT-
   MTRK-MODEL].

        Message tracking is intended for use as a "last resort" mecha-
   nism.   Normally,  Delivery  Status  Notifications (DSNs) [RFC-DSN-
   SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN]  would
   provide  the  primary  delivery  status.   Only  if  no response is
   received from either of these mechanisms would Message Tracking  be
   used.

        This  document is based on [RFC-DSN-STAT].  Sections 1.3 (Ter-
   minology),  2.1.1  (General  conventions  for  DSN  fields),  2.1.2
   ("*-type"  subfields),  and 2.1.3 (Lexical tokens imported from RFC
   822) of [RFC-DSN-STAT] are included into this  document  by  refer-
   ence.  Other sections are further incorporated as described herein.

        Syntax notation in this document conforms to [RFC-ABNF].

        The following lexical tokens,  defined  in  [RFC-MSGFMT],  are
   used  in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF,
   DIGIT, LF, linear-white-space, SPACE, text.  The date-time  lexical
   token is defined in [RFC-HOSTREQ].

        The  key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL"
   in  this  document  are  to be interpreted as described in RFC 2119
   [RFC-KEYWORDS].


3.  Format of a Message Tracking Status Notification

        A Message Tracking Status Notification (MTSN) is  intended  to
   be  returned as the body of a Message Tracking request [DRAFT-MTRK-
   MTQP].  The actual body MUST be a  multipart/related  [RFC-RELATED]
   with type parameter of "message/tracking-status"; each subpart MUST
   be type "message/tracking-status" as described herein.

   3.1.  The message/tracking-status content-type

           The message/tracking-status content-type is defined as fol-
      lows:









Allman                                                        [Page 2]


Internet Draft          Message/Tracking-Status           July 6, 2001


          MIME type name:           message
          MIME subtype name:        tracking-status
          Optional parameters:      none
          Encoding considerations:  "7bit" encoding is sufficient and
                                    MUST be used to maintain readability
                                    when viewed by non-MIME mail readers.
          Security considerations:  discussed in section 4 of this memo.


           The  body  of  a  message/tracking-status  is modeled after
      [RFC-DSN-STAT].  That body consists of one or more "fields" for-
      matted  to according to the ABNF of RFC 822 header "fields" (see
      [RFC-MSGFMT]).  The per-message fields appear first, followed by
      a  blank line.  Following the per-message fields are one or more
      groups of per-recipient fields.   Each  group  of  per-recipient
      fields  is  preceded by a blank line.  Note that there will be a
      blank line between the final per-recipient field  and  the  MIME
      boundary,  since  one  CRLF is necessary to terminate the field,
      and a second is necessary to introduce the MIME boundary.   For-
      mally,  the  syntax of the message/tracking-status content is as
      follows:

          tracking-status-content =
                    per-message-fields 1*( CRLF per-recipient-fields )

      The per-message fields are described in section 3.2.   The  per-
      recipient fields are described in section 3.3.

      3.1.1.  General conventions for MTSN fields

              Section  2.1.1  (General  conventions for DSN fields) of
         [RFC-DSN-STAT] is included herein by reference.  Notably, the
         definition of xtext is identical to that of that document.

      3.1.2.  *-type subfields

              Section  2.1.2  (*-type  subfields) of [RFC-DSN-STAT] is
         included herein by reference.  Notably,  the  definitions  of
         address-type,  diagnostic-type, and MTA-name type are identi-
         cal to that of RFC 1894.


   3.2.  Per-Message MTSN Fields

           Some fields of an MTSN apply to all of the addresses  in  a
      single  envelope.   These  fields may appear at most once in any
      MTSN.  These fields are used to  correlate  the  MTSN  with  the
      original  message transaction and to provide additional informa-
      tion which may be useful to gateways.

          per-message-fields =
                    original-envelope-id-field CRLF
                    reporting-mta-field CRLF
                    arrival-date CRLF
                    *( extension-field CRLF )



Allman                                                        [Page 3]


Internet Draft          Message/Tracking-Status           July 6, 2001


      3.2.1.  The Original-Envelope-Id field

              The optional Original-Envelope-Id field is defined as in
         section 2.2.1 of [RFC-DSN-STAT].  This field is REQUIRED.

      3.2.2.  The Reporting-MTA field

              The  Reporting-MTA  field is defined as in section 2.2.2
         of [RFC-DSN-STAT].  This field is REQUIRED.

      3.2.3.  The Arrival-Date field

              The Arrival-Date field is defined as in section 2.2.5 of
         [RFC-DSN-STAT].  This field is REQUIRED.


   3.3.  Per-Recipient MTSN fields

           An  MTSN  contains  information about attempts to deliver a
      message to one or more recipients.  The delivery information for
      any  particular  recipient is contained in a group of contiguous
      per-recipient fields.  Each group  of  per-recipient  fields  is
      preceded by a blank line.

           The syntax for the group of per-recipient fields is as fol-
      lows:

          per-recipient-fields =
                    original-recipient-field CRLF
                    final-recipient-field CRLF
                    action-field CRLF
                    status-field CRLF
                    [ remote-mta-field CRLF ]
                    [ last-attempt-date-field CRLF ]
                    [ will-retry-until-field CRLF ]
                    *( extension-field CRLF )


      3.3.1.  Original-Recipient field

              The optional Original-Recipient field is defined  as  in
         section 2.3.1 of [RFC-DSN-STAT].  This field is REQUIRED.

      3.3.2.  Final-Recipient field

              The required Final-Recipient field is defined as in sec-
         tion 2.3.2 of [RFC-DSN-STAT].  This field is REQUIRED.

      3.3.3.  Action field

              The required Action field indicates the action performed
         by  the  Reporting-MTA  as a result of its attempt to deliver
         the message to this recipient address.  This  field  MUST  be
         present  for each recipient named in the MTSN.  The syntax is
         as defined in section 2.3.3  of  RFC  1894.   This  field  is
         REQUIRED.


Allman                                                        [Page 4]


Internet Draft          Message/Tracking-Status           July 6, 2001


              Valid actions are:

         failed       The  message  could  not  be delivered.  If DSNs
                      have been enabled, a "failed" DSN should already
                      have been returned.

         delayed      The  message  is  currently  waiting  in the MTA
                      queue for future  delivery.   Essentially,  this
                      action  means "the message is located, and it is
                      here."

         delivered    The message has been successfully  delivered  to
                      the  final  recipient.  This includes "delivery"
                      to a mailing list exploder.  It does  not  indi-
                      cate that the message has been read.  No further
                      information is  available;  in  particular,  the
                      tracking agent SHOULD NOT attempt further "down-
                      stream" tracking requests.

         expanded     The message has been successfully  delivered  to
                      the   recipient  address  as  specified  by  the
                      sender,  and  forwarded  by  the   Reporting-MTA
                      beyond  that  destination to multiple additional
                      recipient addresses.  However, these  additional
                      addresses  are  not  trackable, and the tracking
                      agent SHOULD NOT  attempt  further  "downstream"
                      tracking requests.

         relayed      The  message has been delivered into an environ-
                      ment that does not support message tracking.  No
                      further information is available; in particular,
                      the tracking agent SHOULD  NOT  attempt  further
                      "downstream" tracking requests.

         transferred  The  message  has  been  transferred  to another
                      MTRK-compliant MTA.  The tracking  agent  SHOULD
                      attempt  further "downstream" tracking requests.

         opaque       The message may or may not  have  been  seen  by
                      this  system.   No further information is avail-
                      able or forthcoming.

              There  may  be  some  confusion  between  when  to   use
         "expanded" versus "delivered".  Whenever possible, "expanded"
         should be used when the MTA knows that the  message  will  be
         sent  to  multiple  addresses.   However,  in  some cases the
         delivery occurs to a  program  which,  unknown  to  the  MTA,
         causes  mailing  list  expansion;  in  the  extreme case, the
         delivery may be to a real mailbox that has the side effect of
         list  expansion.  If the MTA cannot ensure that this delivery
         will cause list  expansion,  it  should  set  the  action  to
         "delivered".






Allman                                                        [Page 5]


Internet Draft          Message/Tracking-Status           July 6, 2001


      3.3.4.  Status field

              The  Status  field  is  defined  as  in RFC 1894 section 
         2.3.4.   A  new  code  is  added  to  RFC  1893  [RFC-EMSSC],
         "Enhanced Mail System Status Codes",

             X.1.9   Message relayed to non-compliant mailer"

                 The mailbox address specified was valid, but the mes-
                 sage has been relayed to a system that does not speak
                 this  protocol;  no  further  information can be pro-
                 vided.
         A  2.1.9  Status  field  MUST  be  used  exclusively  with  a
         "relayed" Action field.  This field is REQUIRED.

      3.3.5.  Remote-MTA field

              The  Remote-MTA field is defined as in section Reference
         2.3.5 of [RFC-DSN-STAT].  This field MUST NOT be included  if
         no  delivery  attempts  have been made or if the Action field
         has value "opaque".  If delivery to some agent other than  an
         MTA (for example, a Local Delivery Agent) then this field MAY
         be included, giving the name of the host on which that  agent
         was contacted.

      3.3.6.  Last-Attempt-Date field

              The  Last-Attempt-Date  field  is  defined as in section
         Reference 2.3.7 of [RFC-DSN-STAT].  This field is REQUIRED if
         any  delivery attempt has been made and the Action field does
         not have value "opaque", in which case it will  specify  when
         it  last  attempted to deliver this message to another MTA or
         other Delivery Agent.  This field MUST NOT be included if  no
         delivery attempts have been made.

      3.3.7.  Will-Retry-Until field

              The Will-Retry-Until field is defined as in section Ref-
         erence 2.3.8 of [RFC-DSN-STAT].  If the message is not in the
         local  queue or the Action field has the value ``opaque'' the
         Will-Retry-Until field MUST NOT be included; otherwise,  this
         field is REQUIRED.

   3.4.  Extension fields

           Future  extension  fields may be defined as defined in sec-
      tion 2.4 of [RFC-DSN-STAT].

   3.5.  Interaction Between MTAs and LDAs

           A message that has been delivered to a Local Delivery Agent
      (LDA)  that  understands message tracking (in particular, an LDA
      speaking LMTP  [RFC-LMTP]  that  supports  the  MTRK  extension)
      SHOULD  pass the tracking request to the LDA.  In this case, the
      Action field for the MTA->LDA exchange will look the same  as  a
      transfer  to  a compliant MTA; that is, a "transferred" tracking


Allman                                                        [Page 6]


Internet Draft          Message/Tracking-Status           July 6, 2001


      status will be issued.


4.  Security Issues

   4.1.  Forgery

           Malicious servers may attempt to subvert  message  tracking
      and return false information.  This could result in misdirection
      or misinterpretation of results.

   4.2.  Confidentiality

           Another dimension of security  is  confidentiality.   There
      may be cases in which a message recipient is autoforwarding mes-
      sages but does not wish to divulge the address to which the mes-
      sages  are  autoforwarded.   The desire for such confidentiality
      will probably be heightened as  "wireless  mailboxes",  such  as
      pagers, become more widely used as autoforward addresses.

           MTA  authors  are  encouraged  to provide a mechanism which
      enables the end user to preserve the confidentiality of  a  for-
      warding  address.   Depending  on  the degree of confidentiality
      required, and the nature of the environment to which  a  message
      were  being forwarded, this might be accomplished by one or more
      of:

      (a)  respond with a "relayed" tracking status when a message  is
           forwarded  to  a  confidential forwarding address, and dis-
           abling further message tracking requests.

      (b)  declaring the message to be delivered,  issuing  a  "deliv-
           ered" tracking status, re-sending the message to the confi-
           dential forwarding address, and disabling  further  message
           tracking requests.

           The  tracking  algorithms  MUST  NOT allow tracking through
      list expansions.  When a message  is  delivered  to  a  list,  a
      tracking request MUST respond with an "expanded" tracking status
      and MUST NOT display the contents of the list.

5.  References

   [DRAFT-MTRK-MODEL]
        T.  Hansen,  ``Message  Tracking  Model  and   Requirements.''
        draft-ietf-msgtrk-model-03.txt.  November 2000.

   [DRAFT-MTRK-MTQP]
        T.  Hansen,  ``Message Tracking Query Protocol.''  draft-ietf-
        msgtrk-mtqp-01.txt.  November 2000.

   [DRAFT-MTRK-SMTPEXT]
        E. Allman, ``SMTP Service Extension  for  Message  Tracking.''
        draft-ietf-msgtrk-smtpext-00.txt.  December 2000.




Allman                                                        [Page 7]


Internet Draft          Message/Tracking-Status           July 6, 2001


   [RFC-ABNF]
        Crocker,  D., Editor, and P. Overell, ``Augmented BNF for Syn-
        tax Specifications: ABNF'', RFC 2234, November 1997.

   [RFC-DSN-REPT]
        G. Vaudreuil, ``The  Multipart/Report  Content  Type  for  the
        Reporting of Mail System Administrative Messages.''  RFC 1892.
        January 1996.

   [RFC-DSN-SMTP]
        K. Moore, ``SMTP Service Extension for Delivery Status Notifi-
        cations.''  RFC 1891.  January 1996.

   [RFC-DSN-STAT]
        K.  Moore and G. Vaudreuil, ``An Extensible Message Format for
        Delivery Status Notifications.''  RFC 1894.  January 1996.

   [RFC-EMSSC]
        G. Vaudreuil, ``Enhanced  Mail  System  Status  Codes.''   RFC
        1893.  January 1996.

   [RFC-ESMTP]
        Rose,  M.,  Stefferud,  E.,  Crocker,  D.,  Klensin, J. and N.
        Freed, ``SMTP Service Extensions.''  STD 10, RFC 1869.  Novem-
        ber 1995.

   [RFC-HOSTREQ]
        R. Braden (ed.), ``Requirements for Internet Hosts -- Applica-
        tion and Support.''  STD 3, RFC 1123.  October 1989.

   [RFC-KEYWORDS]
        S. Bradner, ``Key words for use in RFCs to  Indicate  Require-
        ment Levels.''  RFC 2119.  March 1997.

   [RFC-LMTP]
        J.  Myers, ``Local Mail Transfer Protocol.''  RFC 2033.  Octo-
        ber 1996.

   [RFC-MDN]
        R. Fajman, ``An Extensible Message Format for Message Disposi-
        tion Notifications.''  RFC 2298.  March 1998.

   [RFC-MIME]
        N.  Freed  and  N.  Borenstein,  ``Multipurpose  Internet Mail
        Extensions (MIME) Part One: Format of  Internet  Message  Bod-
        ies.''  RFC 2045.  November 1996.

   [RFC-MSGFMT]
        D.  Crocker,  ``Standard  for the Format of ARPA Internet Text
        Messages.''  RFC 822.  August 1982.

   [RFC-RELATED]
        E. Levinson, ``The MIME Multipart/Related Content-type.''  RFC
        2387.  August 1998.




Allman                                                        [Page 8]


Internet Draft          Message/Tracking-Status           July 6, 2001


6.  Author's Address

       Eric Allman
       Sendmail, Inc.
       6603 Shellmound
       Emeryville, CA  94608
       U.S.A.

       E-Mail: eric@Sendmail.COM
       Phone: +1 510 594 5501
       Fax: +1 510 594 5411















































Allman                                                        [Page 9]