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