Internet Draft                                               E. Allman
draft-ietf-msgtrk-trkstat-00.txt                        Sendmail, Inc.
Valid for six months                                 December 14, 2000
Updates: RFC 1893




              The Message/Tracking-Status MIME Extension

                  <draft-ietf-msgtrk-trkstat-00.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 msgtrk@imc.org mailing list.  An archive of  the  mailing  list
may be found at

    http://www.ietf.org/archive/msgtrk


     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      December 14, 2000


   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 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 of "tracking-status"; each subpart  MUST  be  type  "mes-
   sage/tracking-status" as described herein.

   3.1.  The message/tracking-status content-type

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

          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.


Allman                                                        [Page 2]

Internet Draft          Message/Tracking-Status      December 14, 2000


           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 headers "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.  Formally, 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 )


      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.





Allman                                                        [Page 3]

Internet Draft          Message/Tracking-Status      December 14, 2000


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

              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


Allman                                                        [Page 4]

Internet Draft          Message/Tracking-Status      December 14, 2000


                      here."

         delivered    The  message  has been successfully delivered to
                      the final recipient.  This  includes  "delivery"
                      to a mailing list exploder.  No further informa-
                      tion is available; in particular,  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.

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


Allman                                                        [Page 5]

Internet Draft          Message/Tracking-Status      December 14, 2000


      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].  This field is REQUIRED if
         the message is still in the MTA queue.  This field  MUST  NOT
         be included if the message is not in the local queue.

   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  an  LDA  that  under-
      stands  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 com-
      pliant  MTA;  that  is,  a "transferred" tracking 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.



Allman                                                        [Page 6]

Internet Draft          Message/Tracking-Status      December 14, 2000


           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.

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


Allman                                                        [Page 7]

Internet Draft          Message/Tracking-Status      December 14, 2000


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

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 8]

