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