<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<!-- ?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ? -->

<rfc category="std"
     updates="3464"
     ipr="trust200902"
     docName="draft-leiba-morg-message-recall-00">
    <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

    <?rfc toc="yes" ?>
    <?rfc tocompact="no" ?>
    <?rfc tocindent="no" ?>
    <?rfc comments="yes" ?>
    <?rfc inline="yes" ?>
    <?rfc symrefs="yes" ?>
    <?rfc sortrefs="yes"?>
    <?rfc iprnotified="no" ?>
    <?rfc strict="yes" ?>
    <?rfc compact="yes"?>
    <?rfc subcompact="no"?>
  <front>
    <title>SMTP Service Extension for Message Recall</title>
    
    <author initials='B.' surname="Leiba" fullname='Barry Leiba'>
        <organization>Huawei Technologies</organization>
        <address>
          <phone>+1 646 827 0648</phone>
          <email>barryleiba@computer.org</email>
        </address>
    </author>
      
    <date year="2009"/>
    <area>Applications</area>
    <workgroup>Message ORGanization Working Group</workgroup>
    <keyword>SMTP</keyword>
    <keyword>email</keyword>
    <abstract>
      <t>
        End users occasionally send email messages that they later want to recall, perhaps
        because they sent incorrect information, or had second thoughts about what
        they said in the message.  Proprietary email systems often provide such a
        recall function.  This document specifies a standard mechanism for providing
        it with Internet email.
      </t>
    </abstract>
    <note title="Note">
      <t>
        A revised version of this draft document will be submitted to the RFC
        editor as a Proposed Standard for the Internet Community.
        Discussion and suggestions for improvement are requested, and should
        be sent to morg@ietf.org.
      </t>
    </note>
  </front>

  <middle>
    <section title="Introduction and Informative Discussion">
      <t>
        End users occasionally send email messages that they later want to recall, perhaps
        because they sent incorrect information, or had second thoughts about what
        they said in the message.  Proprietary email systems often provide such a
        recall function, but providing it on the Internet, with a diversity of software,
        administrative domains, and policies, presents a different set of difficulties.
        This section will describe some of those difficulties, to help in understanding
        the reasoning behind the protocol that follows.
      </t>
      
      <t>
        By "recall", here, we mean that the sender wants to withdraw the message from the
        inbox of one or more recipients, such that those recipients no longer have access
        to the message, nor knowledge of its existence.  We assume that a message already
        seen by a recipient can not be recalled from that recipient.
      </t>
      
      <t>
        A system that resides within one administrative domain can easily do record keeping
        and authentication that will allow it to identify messages and users, and to determine
        authorization to recall a particular message.  It is much harder to do that on the
        Internet, when the sender is not known to the receiving domain, and when the sending
        and receiving domains do not have a mutual trust relationship.  A protocol that allows
        the sender to act on messages that have already arrived at the receiving domain must
        satisfactorily resolve the question of authorization to act on those messages.
      </t>
      
      <t>
        Proprietary systems often request message recall by sending a special message.
        Doing it in that way on the Internet is problematic, because there's no way to
        determine in advance that the receiving server supports the protocol and will
        understand the special message.  If it does not, the message will likely be delivered
        to the actual recipient in addition to the original message that was meant to be
        recalled.
      </t>
      
      <t>
        Further, a new end-to-end protocol to perform this function is not practical.
        Because Internet email <xref target="SMTP"/> uses a store-and-forward mechanism
        to transfer email messages, it might not be possible for the sender to contact
        the receiving server directly.  Indeed, it's often the case that it's not even
        possible for the sender to identify the receiving server at all.
      </t>
      
      <t>
        By defining this protocol as an extension to SMTP, we fit on top of the existing
        store-and-forward mechanism, and we detect when a server in
        the store-and-forward chain does not support this function.  We then report the
        status back to the requester asynchronously, using delivery status notifications
        <xref target="DSN"/>.
      </t>
      
      <t>
        A single email message can be sent to a large number of recipients, possibly
        all at different domains.  Some of the recipients might have already seen the
        message at the time it's being recalled.  These can make the process of recalling
        the message rather difficult.  While it's certainly an easy matter to send a recall
        request to all the receiving domains and have the message recalled from only some
        of them, depending upon support for this extension and "seen" status of the message
        by each recipient, this might not be what the sender wants.
      </t>
      
      <t>
        It's easy to come up with scenarios where it would be very bad to recall it from some,
        but not from all recipients -- perhaps doing so would cause confusion, or even
        embarrassment.  It's also easy to come up with scenarios where it would be awkward
        or embarrassing for anyone to know you were trying to recall the message, in a case
        where the request is ultimately unsuccessful.
      </t>
      
      <t>
        To solve that, we define a two-step process, first putting a "hold" on the message,
        and then either rescinding that hold (if we don't get the desired result) or
        proceeding with the recall.  The "hold" step is optional, and will not always be
        needed.  Of course, any asynchronous multi-step process must have a mechanism for
        resolving hanging requests and missing responses.  The protocol suggests using
        timeouts for those.
      </t>
      
      <t>
        Expectations have to be kept reasonable, given the likelihood that most recalls will
        not be fully successful, and especially not so at first.  Initially, most systems
        won't support this.  Even when more do, the success will be lower the more recipients
        a message has, and the longer the time between send and recall.
        The limitations will have to be explained
        to the users as part of the interface they get when they press the "recall this
        message" button (or whatever the UI mechanism is).  If the user is given the choice of
        "recall what you can" (that is, skip the optional "hold" step) and "all or nothing"
        (do the hold, and only recall if all holds work), that choice must be simply put and
        easy to select.  Most users will have a hard time understanding the finer points here.
      </t>
      
      <t>
        It's probably also a good idea to give the user a summary, probably in the form of
        an email message, when the recall process is done: a message saying something like,
        "Of the 10 recipients, the messages appears to have been recalled from 5.  2 appear
        to have already seen the message, and 3 of the mail systems do not support the
        recall option."  The message might also include the response given for each recipient,
        in detail.  By wording things in terms of "appear to", or the like, and avoiding
        absolute "was recalled" statements, we can avoid troubles in the case of improper
        implementations -- perhaps intentionally so (see <xref target="Security"/>).
      </t>
      
      <t>
        Finally, the Security Considerations section describes issues that need to
        be considered when implementing and deploying this protocol.
      </t>        
    </section>

    <section title="Conventions used in this document">
      <t>
        In examples, "C:" indicates lines sent by a client that is connected
        to a server.  "S:" indicates lines sent by the server to the client.
        In this protocol, both client and server will often be Message Transfer Agents (MTAs),
        but one will be acting as the client and one as the server for the transaction.
      </t>
      
      <t>
        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 <xref target="Kwds"/>.
      </t>        
    </section>

    <section title="SMTP service extension keyword">
      <t>
        An SMTP server that supports this extension includes the extension keyword "RECL"
        in its EHLO response.
      </t>
    </section>

    <section title="The Message-Verification header field">
      <t>
        If the sending side supports this protocol and wants a message to be recallable,
        it MUST include a Message-ID header field <xref target="Format"/> in the message.
        It MUST also include a Message-Verification header field.  The
        Message-Verification header field contains the following required tags, separated
        by semicolons (with no white space within):
        <list style="hanging" hangIndent="17">
        <t hangText="hash=[string] --">the algorithm used to produce the hash value
          in the "guid" tag.
          Current valid values are "SHA1" and "SHA256" <xref target="SHA"/>.
        </t>
        <t hangText="guid=[base64] --">the base64 encoding <xref target="Base64"/> of the hash
          of a globally unique ID (GUID) for the message, using the hash algorithm specified
          in the "hash" tag.  The actual GUID (the pre-image of the hash) is kept secret
          by the sending side.
        </t>
        </list>
        See <xref target="Syntax"/> for the formal syntax of the Message-Verification field.
      </t>

      <t>        
        The Message-Verification header field may be put there by the sender or by
        the sender's domain.  The unhashed GUID MUST be retained and associated with
        the message, and available to the recalling entity, in order for a recall
        request to be sent later.
        To simplify bookkeeping, the GUID MAY be discarded at some time, after which
        the message can no longer be recalled.
      </t>
      
      <t>
        Recall requests will be accompanied by the target message's Message-ID header field
        value and the unhashed GUID of the message.  The receiving server will locate the
        message using the Message-ID, retrieve the message's Message-Verification header
        field, hash the GUID using the hash algorithm specified in that header field, and
        compare the new hashed value with the hashed value in that header field.  The receiving
        server considers the message to have been identified ONLY if these tests match.  If
        they do not match, the receiving server MUST consider the message as not found.
      </t>
    </section>

    <section title="The SMTP RECL command">
      <t>
        When a message is to be recalled, the recalling entity obtains the Message-ID and
        (unhashed) GUID of the message.  If the recalling entity is not the requester
        (the end user, in most cases), it is the responsibility of the recalling entity to
        determine the requester's authorization to recall the message.
      </t>
        
      <t>
        The recalling entity then initiates a recall request using SMTP <xref target="SMTP"/>.
        The recall request is propagated through SMTP's store-and-forward mechanism, just
        as a normal SMTP mail transfer is.
      </t>
        
      <t>
        A recall request starts with EHLO, MAIL FROM, and RCPT TO, as for the original message.
        The recall session MUST use EHLO, and the extension list returned MUST be checked
        to determine that this protocol is supported by the downstream server.  If it is not,
        and the recall request verb is not RELEASE,
        the current server MUST send back a "BAD" DSN (see <xref target="DSN-responses"/>).
        DSNs MUST NOT be returned for RELEASE requests.
      </t>
        
      <t>
        In place of the DATA command, the recall request uses the new RECL command, as        
        one of the following:
        <list style="hanging" hangIndent="12">
        <t hangText="RECL HOLD Message-ID GUID">
        </t>
        <t hangText="RECL RELEASE Message-ID GUID">
        </t>
        <t hangText="RECL RECALL INFORM [NO | FAILURE | SUCCESS | ALL] Message-ID GUID">
        </t>
        </list>
        "Message-ID", above, is the value of the Message-ID field of the original message,
        including the angle-brackets.  "GUID" is the unhashed GUID of the original message.
        See <xref target="Syntax"/> for the formal syntax of the RECL command.
      </t>

      <t>
        The RECL command ends the recall request, and is followed by a QUIT command, to
        terminate the SMTP session, or an RSET command, to start a new SMTP transaction.
      </t>

      <section title="RECL HOLD">
        <t>
          RECL HOLD requests a hold on the message.  For each recipient, a DSN is sent
          back with a status of "OK", "NO", or "BAD" (see <xref target="DSN-responses"/>).
          Note that a receiving server might choose not to implement RECL HOLD
          (see item 1, below).
        </t>

        <t>
          When a RECL HOLD arrives at the receiving server for a particular recipient, the
          receiving server MUST do one of the following:
          <list style="numbers">
          <t>Respond with a "NO" DSN because it does not implement RECL HOLD.</t>
          <t>Determine that the target message is not found, and respond with a
          "NO" DSN.</t>
          <t>Determine that the message is already on hold, and respond with an "OK"
          DSN.  Timeouts associated with the held message (see <xref target="Timing"/>) SHOULD
          be reset the first time this happens.</t>
          <t>Determine that local policy forbids a hold on the target message, and respond
          with a "NO" DSN.  If policy permits a hold, it MUST also permit a subsequent recall.</t>
          <t>Determine that the message is already marked as seen, and respond with a
          "NO" DSN.</t>
          <t>Determine that for some other reason, the message can not be held, and
          respond with a "NO" DSN.</t>
          <t>If none of the above apply, hold the message and respond with an "OK" DSN.
          Holding the message means putting it in a state where neither the contents of
          the message nor its presence can be seen by the user, but where it can be restored
          to its original state when needed.</t>
          </list>
          By holding the message and responding with an "OK" DSN, the receiving server MUST
          guarantee that the message will be successfully recalled if a subsequent RECL RECALL
          is received in a timely manner.
        </t>
      </section>

      <section title="RECL RELEASE">
        <t>
          RECL RELEASE is used to rescind a HOLD, perhaps because they didn't all come back as OK.
        </t>

        <t>
          When a RECL RELEASE arrives at the receiving server for a particular recipient, the
          receiving server MUST do one of the following:
          <list style="numbers">
          <t>Determine that the target message is on hold, and restore it to its original,
          state.</t>
          <t>Otherwise, ignore the request.</t>
          </list>
          No DSNs are returned for RECL RELEASE.
        </t>
      </section>

      <section title="RECL RECALL">
        <t>
          RECL RECALL requests that the message be recalled.  The recall may fail because of
          policy, because the message has already been seen by the recipient, and perhaps for
          other reasons.  The recipient may have been notified of the message, but not actually
          seen the message yet (perhaps through Sieve notifications, or some other mechanism).
          Whether such a message is recallable is a matter of policy.
        </t>
        <t>
          The value of the INFORM option works thus:
          <list style="hanging" hangIndent="11">
          <t hangText="NO      --">Never inform the recipient that a recall was requested.
          </t>
          <t hangText="FAILURE --">Inform the recipient that a recall was requested only if the
          recall fails.  This can advise the recipient that the sender wants to withdraw the
          message, in the event that it could not actually be withdrawn.
          </t>
          <t hangText="SUCCESS --">Inform the recipient that a recall was requested only if the
          recall succeeds.  This can have the effect of replacing the recalled message with a
          notification that the message was withdrawn.
          </t>
          <t hangText="ALL     --">Always inform the recipient that a recall was requested,
          whether it succeeded or not.
          </t>
          </list>
          The mechanism used to inform the recipient is up to the implementation.  It MAY use
          an email message, but MAY use other locally available notification mechanisms.
        </t>

        <t>
          When a RECL RECALL arrives at the receiving server for a particular recipient, the
          receiving server MUST do one of the following:
          <list style="numbers">
          <t>Determine that the target message is not found, and respond with a
          "NO" DSN.</t>
          <t>Determine that the message is already on hold (see above), delete it,
          and respond with an "OK" DSN.</t>
          <t>Determine that local policy forbids recalling this message, and respond
          with a "NO" DSN.</t>
          <t>Determine that the message is already marked as seen, and respond with a
          "NO" DSN.</t>
          <t>Determine that for some other reason, the message can not be recalled, and
          respond with a "NO" DSN.</t>
          <t>If none of the above apply, delete the message and respond with an "OK" DSN.</t>
          </list>
          If the server responds with an "OK" DSN, it MUST remove the message from the recipient's
          mailbox, and never put it back.  However, no guarantee is made for any other recipients
          of the message, and it is, of course, possible that one of them might re-send the message
          to this recipient.  Such action would be independent of the recall process.
        </t>
      </section>
    </section>

    <section title="Delivery Status Notifications (DSNs)" anchor="DSN-responses">
      <t>
        Because the recall protocol is fully asynchronous, all responses come in the form
        of Delivery Status Notifications <xref target="DSN"/>, which are sent back to the
        MAIL FROM address in the recall request.  These DSNs contain action and status codes,
        as described below, which inform the requesting entity of the success status of
        the request.  When constructing the DSN multipart/report <xref target="Report"/>,
        only sections 1 (human-readable message) and 2 (machine parsable report) are used.
        The optional section 3 (returned message) MUST NOT be included.
      </t>

      <t>
        The action code is placed in the "Action" field of section 2, and comprises
        the recall verb ("HOLD" or "RECALL"; DSNs are not sent for RELEASE commands),
        one space character (ASCII 0x20), and one of the following:
        <list style="hanging" hangIndent="9">
        <t hangText="OK    --">The request was successful.  The message has been held or recalled.
        </t>
        <t hangText="NO    --">The request was not successful.  The DSN MAY include human-readable
        text in section 1 that further explains the problem.
        </t>
        <t hangText="BAD   --">A server in the SMTP store-and-forward path does not support
        the RECL protocol.
        </t>
        </list>
        See <xref target="Syntax"/> for the formal syntax of the Action field.
      </t>

      <t>
        The status code <xref target="Codes"/> is placed in the "Status" field of section 2, 
        and relates to the action code as follows:
        <list style="hanging" hangIndent="9">
        <t hangText="2.0.0  --">for "OK" actions.
        </t>
        <t hangText="5.0.0  --">for "NO" actions.
        </t>
        <t hangText="5.3.3  --">for "BAD" actions.
        </t>
        </list>
      </t>
    </section>
    
    <section title="Timing issues with holding messages" anchor="Timing">
      <t>
        <cref>
          Should we suggest "reasonable" time values here?  If so, what?
          One suggestion is that we suggest defaults, and include a mechanism in the
          protocol to specify times -- a time-stamp on the HOLD request, asking for a
          hold until that time; a time-stamp on the response, saying "I'll hold at least
          until this time."  There'd have to be a tolerance for out-of-sync clocks...
          in other words, the times would be approximate, not held to the second.
        </cref>
      </t>

      <t>
        If the requesting entity uses RECL HOLD, it MUST keep track of the asynchronous DSNs
        and decide in a timely manner to RELEASE or RECALL the message.  This means having
        a notion of a timeout period for missing DSNs.  A requesting entity MAY selectively
        re-issue a RECL HOLD once, to those recipients for which no DSN is received within
        a reasonable time, but it MUST NOT continue doing so repeatedly.
      </t>

      <t>
        Similarly, an OK response to a HOLD gives the recipient side the responsibility
        of determining how long to wait for further action.  The message SHOULD <cref>MUST?</cref>
        automatically be released from hold after a reasonable time if no RELEASE or RECALL is
        received.
      </t>
    </section>    

    <section title="Examples">
      <section title="Example of a Message-Verification header field">
        <t>
          This shows an example of partial message headers,
          with a Message-ID field and a Message-Verification field.
          The message's unhashed GUID is "G9Kw8iJ37Q1027msa4NbU".
          <figure>
            <artwork>
  From: alice@example.org
  To: bob@example.com
  Subject: Save the date!
  Message-ID: &lt;411699893-1246577932-871827273@example.org&gt;
  Message-Verification: hash=SHA1;guid=BAv9A56z4M0FU3T/Qn+dw7ck9bA=
            </artwork>
          </figure>          
        </t>
      </section>    
      
      <section title="Example of a SMTP RECL transaction">
        <t>
          This will request a recall of a message with the above headers.  Note that we
          use the Message-ID value as specified in the original header, and the unhashed
          GUID.  Also note that the final "250 2.0.0 OK" does NOT mean that the message
          has been recalled, but only that the recall REQUEST was transmitted successfully.
          A DSN will be sent back to alice@example.org with the actual recall status.
          <figure>
            <artwork>
  C: [connects to mail.example.com]
  S: 220 mail.example.com -- ESMTP (Messaging Server version 1.7a)
  C: EHLO example.org
  S: 250-mail.example.com
  S: 250-PIPELINING
  S: 250-RECL
  S: 250-DSN
  S: 250 ENHANCEDSTATUSCODES
  C: MAIL FROM:&lt;alice@example.org&gt;
  S: 250 2.5.0 OK
  C: RCPT TO:&lt;bob@example.com&gt;
  S: 250 2.1.5 OK
  C: RECL RECALL &lt;411699893-1246577932-871827273@example.org&gt;
     G9Kw8iJ37Q1027msa4NbU
  S: 250 2.0.0 OK
  C: QUIT
  S: 221 2.3.0 Goodbye.
            </artwork>
          </figure>          
        </t>
      </section>
      
      <section title="Example of a message recall DSN">
        <t>
          This might be a response to the example recall request above.
          <figure>
            <artwork>
  To: alice@example.org
  From: postmaster@mail.example.com
  Subject: Recall Notification (RECALL OK) for bob@example.com
  Content-Type: multipart/report; report-type=delivery-status;
      boundary=abcde
  MIME-Version: 1.0

  --abcde
  Content-type: text/plain; charset=us-ascii

  Your message (guid G9Kw8iJ37Q1027msa4NbU)
  was successfully recalled from bob@example.com.

  --abcde
  Content-type: message/delivery-status

  Reporting-MTA: dns; mail.example.com
  Original-Envelope-ID: G9Kw8iJ37Q1027msa4NbU

  Original-Recipient: rfc822;bob@example.com
  Final-Recipient: rfc822;bob@example.com
  Action: RECALL OK
  Status: 2.0.0

  --abcde--
            </artwork>
          </figure>          
        </t>
      </section>    
    </section>

    <section anchor="Syntax" title="Formal Syntax">
      <t>
        The following syntax specification uses the augmented Backus-Naur Form (BNF)
        as described in <xref target="ABNF"/>.
        Terms not defined here are taken from the Simple Mail Transfer Protocol
        <xref target="SMTP"/> and Internet Message Format <xref target="Format"/>
        specifications.
      </t>
      <t>
        <list style="hanging" hangIndent="17">
        <t hangText="action-hold   =">"HOLD" SP ("OK" / "NO" / "BAD")
        </t>
        <t hangText="action-recall =">"RECALL" SP ("OK" / "NO" / "BAD")
        </t>
        <t hangText="action-value /=">action-hold / action-recall
            <vspace />; extends "action-value" from RFC 3464 <xref target="DSN" />
        </t>
        <t hangText="base64string  =">1*(ALPHA / DIGIT / "+" / "/")
        [ "=" [ "=" ] ] CRLF
        </t>
        <t hangText="guid          =">dot-atom-text
        </t>
        <t hangText="guid-hash     =">"guid=" base64string
        </t>
        <t hangText="hash-alg      =">"hash=" ("SHA1" / "SHA256")
        </t>
        <t hangText="message-verification =">"Message-Verification:" [CFWS]
        hash-alg ";" guid-hash [CFWS] CRLF
        </t>
        <t hangText="recl          =">"RECL" SP recl-verb SP message-id SP guid
        </t>
        <t hangText="recl-hold     =">"HOLD"
        </t>
        <t hangText="recl-recall   =">"RECALL" SP "INFORM" SP ("NO" / "FAIL" / "ALL")
        </t>
        <t hangText="recl-release  =">"RELEASE"
        </t>
        <t hangText="recl-verb     =">recl-hold / recl-release / recl-recall
        </t>
      </list>
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
        It's possible for an intermediate MTA to add or replace a Message-Verification
        header field during the transmission of an original message, which could later allow
        an unauthorized party to recall the message.
        Since intermediate MTAs can do plenty of other nasty things, including not relaying
        the message in the first place (but saying they did), this is probably not a real issue.
      </t>
      
      <t>
        If the sending domain (as opposed to the sending user agent) creates the
        Message-Verification header field, it will also be the sending domain that will
        have to supply the GUID on the RECL command.  There will then be no in-band
        authentication of the user requesting the recall.  In this case, it's the
        responsibility of the sending domain to ensure that the user is authorized to do this.
      </t>
      
      <t>
        Timeouts are required, as noted above (see <xref target="Timing" />).
      </t>
      
      <t>
        It's possible for the receiving end to ignore the INFORM option, and to inform the
        recipient when the sender would not want that.  It's possible for the receiving end
        to send an "OK" DSN but fail to recall the message (perhaps also informing the recipient
        of this).  While these behaviours are contrary to this specification, they are a fact of
        life when asking for such things on the Wild, Wild Internet.
        Those who would try to recall messages quietly should bear this in mind.
      </t>      
    </section>

    <section anchor="iana" title="IANA Considerations">
      <section title="SMTP service extension registration">
        <t>
          This document defines an SMTP service extension, and IANA is asked to add an entry
          to the SMTP Service Extensions registry, as follows:
          <figure>          
            <artwork>
  Keyword: RECL
  Description: Message recall
  Reference: [[IANA: Insert this RFC number.]]
  Parameters: (none)
            </artwork>
          </figure>          
        </t>      
      </section>    
      
      <section title="Message header field registration">
        <t>
          This document defines a new message header field, and IANA is asked to add an entry
          to the Permanent Message Header Field Names registry, as follows:
          <figure>          
            <artwork>
  Header field name: Message-Verification
  Protocol: mail
  Status: standard
  Reference: [[IANA: Insert this RFC number.]]
            </artwork>
          </figure>          
        </t>
      </section>    
      
      <section title="DSN actions registry creation">
        <t>
          This document defines a new DSN action field value, and there is currently no
          registry for those values.  IANA is asked to create a "DSN Actions" sub-registry
          in the Mail Parameters registry ( http://www.iana.org/assignments/mail-parameters ).
          New values will be registered using the "Specification Required" policy <xref target="IANA"/>.  The template to be used to register new values is as follows:
          <figure>          
            <artwork>
  To: iana@iana.org
  Subject: Registration of new DSN action field value
  Value: [the text value of the field]
  Reference: [identifies the specification that defines this value]
            </artwork>
          </figure>          
        </t>
        <t>
          IANA is asked to enter the following initial values in this registry, all taken from
          RFC 3464:
          <figure>          
            <artwork>
    Value: failed
    Reference: RFC 3464
            </artwork>
          </figure>          
          <figure>          
            <artwork>
    Value: delayed
    Reference: RFC 3464
            </artwork>
          </figure>          
          <figure>          
            <artwork>
    Value: delivered
    Reference: RFC 3464
            </artwork>
          </figure>          
          <figure>          
            <artwork>
    Value: relayed
    Reference: RFC 3464
            </artwork>
          </figure>          
          <figure>          
            <artwork>
    Value: expanded
    Reference: RFC 3464
            </artwork>
          </figure>          
        </t>
      </section>    
      
      <section title="DSN actions value registrations">
        <t>
          This document defines new DSN action field values, and IANA is asked to add the
          following entries to the DSN Actions registry, created above:
          <figure>          
            <artwork>
    Value: hold [ok/no/bad]
    Reference: [[IANA: Insert this RFC number.]]
            </artwork>
          </figure>          
          <figure>          
            <artwork>
    Value: recall [ok/no/bad]
    Reference: [[IANA: Insert this RFC number.]]
            </artwork>
          </figure>          
        </t>
      </section>    
    </section>
    
    <section title="Acknowledgements">
      <t>
        The author gratefully acknowledges feedback provided by Ned Freed
        and Nathaniel Borenstein on the initial version of this specification.
      </t>
    </section>    
  </middle>

  <back>
    <references title="Normative References">

      <reference anchor="Kwds">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner">
            <organization>Harvard University</organization>
          </author>
          <date month="March" year="1997" />
        </front>
        <seriesInfo name="RFC" value="2119" />
      </reference>
        
      <reference anchor="Report">
        <front>
          <title>The Multipart/Report Content Type for the Reporting of
          Mail System Administrative Messages</title>
          <author initials="G." surname="Vaudreuil" fullname="Greg Vaudreuil">
            <organization>Lucent Technologies</organization>
          </author>
          <date month="January" year="2003" />
        </front>
        <seriesInfo name="RFC" value="3462" />
      </reference>

      <reference anchor="Codes">
        <front>
          <title>Enhanced Mail System Status Codes</title>
          <author initials="G." surname="Vaudreuil" fullname="Greg Vaudreuil">
            <organization>Lucent Technologies</organization>
          </author>
          <date month="January" year="2003" />
        </front>
        <seriesInfo name="RFC" value="3463" />
      </reference>

      <reference anchor="DSN">
        <front>
          <title>An Extensible Message Format for Delivery Status Notifications</title>
          <author initials="K." surname="Moore" fullname="Keith Moore">
            <organization>University of Tennessee</organization>
          </author>
          <author initials="G." surname="Vaudreuil" fullname="Greg Vaudreuil">
            <organization>Lucent Technologies</organization>
          </author>
          <date month="January" year="2003" />
        </front>
        <seriesInfo name="RFC" value="3464" />
      </reference>
        
      <reference anchor="Base64">
        <front>
          <title>The Base16, Base32, and Base64 Data Encodings</title>
          <author initials="S." surname="Josefsson" fullname="Simon Josefsson">
            <organization>SJD</organization>
          </author>
          <date month="October" year="2006" />
        </front>
        <seriesInfo name="RFC" value="4648" />
      </reference>

      <reference anchor="IANA">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
          <author initials="T." surname="Narten" fullname="Thomas Narten">
            <organization>IBM</organization>
          </author>
          <author initials="H." surname="Alvestrand" fullname="Harald Alvestrand">
            <organization>Google</organization>
          </author>
          <date month="May" year="2008" />
        </front>
        <seriesInfo name="BCP" value="26" />
        <seriesInfo name="RFC" value="5226" />
      </reference>
        
      <reference anchor="ABNF">
        <front>
          <title>Augmented BNF for Syntax Specifications: ABNF</title>
          <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
            <organization>Brandenburg InternetWorking</organization>
          </author>
          <author initials="P." surname="Overell" fullname="Paul Overell">
            <organization>THUS plc.</organization>
          </author>
          <date month="January" year="2008" />
        </front>
        <seriesInfo name="RFC" value="5234" />
      </reference>
    
      <reference anchor="SMTP">
        <front>
          <title>Simple Mail Transfer Protocol</title>
          <author initials="J." surname="Klensin" fullname="John Klensin" role="editor">
            <organization></organization>
          </author>
          <date month="October" year="2008" />
        </front>
        <seriesInfo name="RFC" value="5321" />
      </reference>

      <reference anchor="Format">
        <front>
          <title>Internet Message Format</title>
          <author initials="P." surname="Resnick" fullname="Pete Resnick" role="editor">
            <organization>Qualcomm Incorporated</organization>
          </author>
          <date month="October" year="2008" />
        </front>
        <seriesInfo name="RFC" value="5322" />
      </reference>

      <reference anchor="SHA">
        <front>
          <title>Secure Hash Standard</title>
          <author fullname="National Institute of Standards and Technology">
            <organization>U.S. Department of Commerce</organization>
          </author>
          <date month="October" year="2008" />
        </front>
        <seriesInfo name="FIPS" value="PUB 180-3" />
      </reference>

    </references>
  </back>
</rfc>
