[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT          EXPIRE MARCH 1998       INTERNET DRAFT


Network Working Group                                       A. Steinberg
Internet Draft                                Base Tecnologia e Sistemas
Category: Experimental                                    September 1997



                 Confirmation of Mail Message Reception
                  <draft-rfced-exp-steinberg-00.txt>

Status of This Memo

This document is an Internet-Draft.  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."

To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.




1. Abstract

   Currently, Internet SMTP transport does not allow the sender to know
   if the recipient receive or open a mail message. This limitation
   frequently causes one question: did my message really arrive? This
   proposes a simple solution, that could be easy implemented in the
   mail software.

2. Mail message confirmation mechanism

   A simple and efficient way of confirm a message reception is the fact
   that the mail software generate an automatic reply to sender at the
   time of mail opening. This confirmation message would have date and
   time of the opening event, mail address of the recipient and the
   subject of the original message. These information are, in most
   cases, sufficient to confirm the correct delivery and the exact time
   of opening event.

   The mechanism exposed above solves the problem of confirmation of
   mail delivery and opening, but not all the messages need
   confirmation.

   This proposes a new extension-field to the header section of mail
   messages, "Confirmation". Acceptable values for this field are "Yes"
   and "No". Other values could be an extension to this document.

   A formal BNF notation of RFC 822 is given for the content of
   Confirmation field:

      confirmation := "Confirmation" ":" value
                   ; Case insensitive matching of value

      value := "yes" / "no"
            ; All values case insensitive


Steinberg                     Experimental                      [Page 1]


I/D              Confirmation of Mail Message        September 1997


   When the Confirmation value is "Yes", the mail software would send
   a reply at the opening moment and set this value to "No". This way
   the original sender will not receive several confirmations of same
   message.

3. Suggested implamentation

   To implement confirmation capabilities to the mail software, there
   is some considerations detailed in the next sections.

3.1. Message composition

   In message composition, the mail software may display a check box
   that user could select to ask confirmation of current message.

   If selected, the software will include the line

      Confirmation: Yes

   in the header section of mail message.

3.2. Multiple recipients

   If the message addresses multiple recipients, all people will be
   notified to confirm reception.

3.3. Mail reception list (In Box)

   Recipients would be notified that a message asks confirmation, so
   they can choose the priority of answer.

   This notification could be an alternate color, a sentence (like
   "Confirmation Required"), a flag, etc.

3.4. Mail message opening action

   When the user opens a message that requires confirmation, the
   software would generate an answer including the original subject,
   date, time and the recipient e-mail address.

   This answer could be delivered immediatly if the user is on line
   or stored to later delivery if the user is off line.

3.5. Message identification

   Optionally, the software can include some identification to subject
   field, so the sender could identify the confirmation of a message
   easier.

4. Backward compatibility

   A software without confirmation capabilities unfortunately will not


Steinberg                     Experimental                      [Page 2]


I/D              Confirmation of Mail Message        September 1997


   confirm or tell the user that a confirmation was asked either.

5. Security considerations

   The mechanism proposed here has all security limitations of SMTP
   transport, since all new actions runs under mail software control.

6. Example

   Suppose someone sends the follow mail message:


      From: sender@domain.com
      To: recipient@company.com
      Subject: Our meeting in NY
      Confirmation: Yes

      Hi,

      I'm writing just to confirm my trip to NY next friday.
      I'll arive at 5:00 PM.

      John.


   When the recipient opens his mail, mail software will send an
   automatic reply like:


      From: recipient@company.com
      To: sender@domain.com
      Subject: [Conf] Our meeting in NY
      Date: Mon, 1 Sep 1997 12:17:53 -0400

      Your message was received and opened.


   And change the original message to:


      From: sender@domain.com
      To: recipient@company.com
      Subject: Our meeting in NY
      Confirmation: No

      Hi,

      I'm writing just to confirm my trip to NY next friday.
      I'll arive at 5:00 PM.

      John.



Steinberg                     Experimental                      [Page 3]


I/D              Confirmation of Mail Message        September 1997


7. Conclusion

   The suggested implementation gives the mail client a simple but
   useful way of confirm mail message reception and opening, just
   extending existing standards. It is particularly important to
   business mail messages, frequently used nowadays.
















































Steinberg                     Experimental                      [Page 4]


I/D              Confirmation of Mail Message        September 1997


Author's Address

   Alexandre Steinberg
   Base Tecnologia e Sistemas
   Av.Afranio Peixoto, 347
   Sao Paulo, SP
   Brazil
   05507-000

   Phone:  +55 11 212-3830
   Fax:    +55 11 813-1151
   EMail:  steinberg@base.com.br



Steinberg                     Experimental                      [Page 5]

I/D              Confirmation of Mail Message        September 1997



References

[RFC  822] Crocker, D., "Standard for the Format of ARPA Internet Text
           Messages", STD 11, RFC 822, UDEL, August 1982.

[RFC 1521] Borenstein, N. & Freed, N., "MIME (Multipurpose Internet Mail
           Extensions) Part One: Mechanisms for Specifying and
           Describing the Format of Internet Message Bodies", RFC 1521,
           Bellcore, Innosoft, September 1993.

[RFC 1522] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
           Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
           University of Tennessee, September 1993.

INTERNET DRAFT          EXPIRES MARCH 1998      INTERNET DRAFT