"Return Receipts Requested" does Entorage have the ability to sendand receive them?

[Phillip M. Jones, CE.T.]

1. RFC 2298 which deals with Message Disposition Notifications - MDN
("return receipts") says:

The presence of a Disposition-Notification-To header in a message is
merely a request for an MDN. The recipients' user agents are always
free to silently ignore such a request.

MDNs are _not_ mandated. Entourage does not implement MDN replies to
Disposition-Notification-To headers because it's not required by other
agents either, and thus they are undependable, unreliable and pointless.

Entourage is following RFC 2298 in choosing to ignore requests for MDNs

2. Outlook Windows, which _does_ implement MDNs - is the MS app which is
notorious for not implement many internet standards properly. Entourage, on
the other hand, is absolutely rigorous about implementing internet standards
and adheres to all required RFCs and to RFC-dictated protocols when it
implements any optional protocols.

I dare you to find a single RFC which Entourage breaks. (Someone once found
one they had omitted and they fixed it immediately, in the next update.)

"Return-receipts" are pointless and useless since you can't dictate which
email agent all our correspondents will be using. If you send a
Disposition-Notification-To header and get no reply you have no idea
whether it's because your message did not arrive or because the recipient's
email program does not send MDNs, or because the recipient turned it off.
The only time it would make any sense would be in sending internal mail in
an organization, when you can be certain that every recipient has a
compliant agent and is required to keep replies turned on.

Entourage does NOT ignore W3C specs.

Entourage may or may not follow standards. But I'll try the fellows script and see
what happensI

Thanks to all. who replied pro or con. While some of you find them an irritant. I
find them vital. However; everyone is entitled to their opinion.

--
---------------------------------------------------------------------------
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112-1809 |[email protected], ICQ11269732, AIM pjonescet
---------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://home.kimbanet.com/~pjones/birthday/index.htm>
<http://vpea.exis.net>

 

[Matthew Smith]

If you want Entourage to respond to them, you can write an e-mail rule that
looks for "specific header", and generates an auto-reply. I had such a rule
for a short time with a friend whose emails seemed to be getting lost; she
asked me to turn it off after a few days, so I know it worked. Something
like this:

Mail tab, then click New on the toolbar.

* Execute actions if all criteria are met
IF Specific Header "Disposition-Notification-To" Exists
IF From Is in Address Book

* Action
Reply [specify message]

Of course having a rule that does this does not mean that the person has
actually opened the message. It just means it has been downloaded to
their computer. The person could easily just delete the message before
reading it.

 

[Chris Ridd]

2. Outlook Windows, which _does_ implement MDNs - is the MS app which is
notorious for not implement many internet standards properly. Entourage, on
the other hand, is absolutely rigorous about implementing internet standards
and adheres to all required RFCs and to RFC-dictated protocols when it
implements any optional protocols.

I dare you to find a single RFC which Entourage breaks. (Someone once found
one they had omitted and they fixed it immediately, in the next update.)

Entourage breaks RFC 2047, which describes how to handle non-ASCII text in
headers. From RFC 2047 Section 5:

----
(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)
in any Subject or Comments header field, any extension message
header field, or any MIME body part field for which the field body
is defined as '*text'. An 'encoded-word' may also appear in any
user-defined ("X-") message or body part header field.

Ordinary ASCII text and 'encoded-word's may appear together in the
same header field. However, an 'encoded-word' that appears in a
header field defined as '*text' MUST be separated from any adjacent
'encoded-word' or 'text' by 'linear-white-space'.
----

The second paragraph is the key one. If you try to send a message with a
subject of "Telefónica" (the o has an accent), Entourage will actually send
"Subject: Telef=?ISO-8859-1?B?8w==?=nica", and clearly the 'encoded-word'
isn't separated from the preceding 'text' by 'linear-white-space'.

Entourage *should* send something like "Subject:
=?ISO-8859-1?Q?Telef=F3nica?=".

This has been reported as a bug against Entourage v.X. I re-reported it
against Entourage 2004. I probably screwed up the examples in both bug
reports :-(

This is a pretty small bug in the grand scheme of things, and in general
you're right and Entourage has pretty good standards support.

Cheers,

Chris

 

[Paul Berkowitz]

Entourage breaks RFC 2047, which describes how to handle non-ASCII text in
headers. From RFC 2047 Section 5:

----
(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)
in any Subject or Comments header field, any extension message
header field, or any MIME body part field for which the field body
is defined as '*text'. An 'encoded-word' may also appear in any
user-defined ("X-") message or body part header field.

Ordinary ASCII text and 'encoded-word's may appear together in the
same header field. However, an 'encoded-word' that appears in a
header field defined as '*text' MUST be separated from any adjacent
'encoded-word' or 'text' by 'linear-white-space'.
----

The second paragraph is the key one. If you try to send a message with a
subject of "Telefónica" (the o has an accent), Entourage will actually send
"Subject: Telef=?ISO-8859-1?B?8w==?=nica", and clearly the 'encoded-word'
isn't separated from the preceding 'text' by 'linear-white-space'.

Entourage *should* send something like "Subject:
=?ISO-8859-1?Q?Telef=F3nica?=".

This has been reported as a bug against Entourage v.X. I re-reported it
against Entourage 2004. I probably screwed up the examples in both bug
reports :-(

This is a pretty small bug in the grand scheme of things, and in general
you're right and Entourage has pretty good standards support.

Thanks for the report, Chris. I'll make sure MacBU know about this. (They're
quite busy in the newsgroups at the moment so they've probably already seen
your post, but I'll make sure of it.)

The question I'd have would be: is the example you've given - where just one
character in a word is encoded by Entourage - a good example? Entourage is
encoding just that "ó" character as =?ISO-8859-1?B?8w==?= inside an
otherwise ASCII word. Reading RFC 2047 I see no examples of that type -
which is perhaps your point. It looks as if the adjacent ASCII characters
are meant to be included within the 'encoded text' part of an 'encoded word'
- which would thus allow the required 'linear-white-space' to be outside the
entire word rather than within it. I wonder if "single-character" encoding
is allowed: I see nothing banning it. There is a length limit for 'encoded
words' whereby everything included between =? and ?= (inclusive) has to be
less than or equal to 75 characters, so maybe Entourage chooses to encode
the minimum number of characters it needs to and leaves the ASCII characters
outside the encoding. Since that would put the white space _outside_ the
encoding it would be read as an ASCII space, which would be wrong. Maybe
that's why all examples given put the entire word within the encoding. But
I'm not sure why you switched from B (base64) encoding to Q
(quoted-printable) in your example. That's surely a red herring? There's no
requirement to use Q encoding. (I suppose because you'd have to encode to
whole word as base64. I can't figure out base64 either - I'm there are
utilities that will do it.)

--
Paul Berkowitz
MVP Entourage
Entourage FAQ Page: <http://www.entourage.mvps.org/faq/index.html>
AppleScripts for Entourage: <http://macscripter.net/scriptbuilders/>

Please "Reply To Newsgroup" to reply to this message. Emails will be
ignored.

PLEASE always state which version of Entourage you are using - **2004**, X
or 2001. It's often impossible to answer your questions otherwise.

 

[Bill Weylock]

<snip>

"Return-receipts" are pointless and useless since you can't dictate which

Whoa!

If they were pointless, smart people would not be debating whether to stay
with Entourage in their absence.

Yes, you do not know what the absence of a receipt means if you request one
from a new correspondent, but you do know that the presence of a receipt
means the message arrived. That is worth plenty to busy people who are
collaborating on something.

Further, most correspondents of consultants tend to be repeaters. We do know
whether they have receipts enabled.

 

[Adam Bailey]

Yes, you do not know what the absence of a receipt means if you request one
from a new correspondent, but you do know that the presence of a receipt
means the message arrived. That is worth plenty to busy people who are
collaborating on something.

Arrived, perhaps. But it doesn't mean that the message wasn't caught
up in a spam filter or accidentally deleted by your recipient's kid or
lost during a server upgrade.

 

[Phillip M. Jones, CE.T.]

On 6/6/04 11:43 AM, in article BCE8B3EC.162C8%[email protected], "Bill

On 6/5/04 5:20 PM, in article
_BCE7B141.21E90%berkowit@spoof_silcom.com_, "Paul Berkowitz"

MDNs are _not_ mandated. Entourage does not implement MDN replies to
Disposition-Notification-To headers because it's not required by other
agents either, and thus they are undependable, unreliable and

pointless.

<snip>

"Return-receipts" are pointless and useless since you can't
dictate which

email agent all our correspondents will be using. If you send a
Disposition-Notification-To header and get no reply you have no idea
whether it's because your message did not arrive or because the recipient's
email program does not send MDNs, or because the recipient turned it off.
The only time it would make any sense would be in sending internal mail in
an organization, when you can be certain that every recipient has a
compliant agent and is required to keep replies turned on.

Whoa!

If they were pointless, smart people would not be debating whether
to stay with Entourage in their absence.

Whose absence?


Yes, you do not know what the absence of a receipt means if you
request one from a new correspondent, but you do know that the
presence of a receipt means the message arrived. That is worth
plenty to busy people who are collaborating on something.

Further, most correspondents of consultants tend to be repeaters. We
do know whether they have receipts enabled.


For futzing around on an ad-hoc basis like this, Entourage is perfectly
well-equipped. Add a "Disposition-Notification-To" header in Advanced
page of your Accounts settings, and you'll get receipts from
correspondents who have receipts enabled. If that's good enough for you,
it will work as well as in any other email program. If you want to rig
up sending receipts yourself, set up a an Auto-Reply rule exactly as
Allen suggested:

Mail tab, then click New on the toolbar.

* Execute actions if all criteria are met
IF Specific Header "Disposition-Notification-To" Exists
IF From Is in Address Book

* Action
Reply [specify message]

Or change the second criterion to be "Is in group" so it replies just to
members of a group you populate, or remove that criterion entirely so
you reply to /everyone/ with a "Disposition-Notification-To" header.
That last will exactly replicate what email clients who have MND replies
do. You'll have full return-receipt functionality, exactly as you wish.

That doesn't change the fact that Entourage does not implement this
feature natively since it's unreliable and undependable and most users
would not realize that. They would assume that if the feature exists
they will get receipts from all recipients.

--
Paul Berkowitz
MVP Entourage
Entourage FAQ Page: <http://www.entourage.mvps.org/faq/index.html>
AppleScripts for Entourage: <http://macscripter.net/scriptbuilders/>

Please "Reply To Newsgroup" to reply to this message. Emails will be
ignored.

PLEASE always state which version of Entourage you are using - **2004**,
X or 2001. It's often impossible to answer your questions otherwise.

I've been using return receipts when needed since Netscape Navigator days.
In the Mozilla products (includes Navigator, Communicator, Mozilla, Thunderbird, and
other using the Mozilla format you have a specific menu choice that says return
receipts. when you invoke it its sent. If you don't, its not.

I stay in contact with several people that use OUTLOOK (not Express) and they
receive my return receipts and I return their's, constantly. They also send non
return receipted email as well. So they know the difference. So it not a Matter of
it unreliable technology. Its a matter of it was left out by choice.

It may be unreliable in the fact that the person on the receiving end chooses not to
send the return receipt. Which they have the right to, if desired. but the
technology to implement the feature is not unreliable and has been around for years.

It is just that MS either made a contious decision to leave it out. Or they
overlooked it.

--
---------------------------------------------------------------------------
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112-1809 |[email protected], ICQ11269732, AIM pjonescet
---------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://home.kimbanet.com/~pjones/birthday/index.htm>
<http://vpea.exis.net>

 

[Bill Weylock]

The whole point is that getting a returned receipt lets you know it did
arrive. Obviously you can't be 100% sure of anything if you get no receipt.

What I didn't say is that a returned receipt also lets you know someone read
your email or at least wants you to think so. That's a lot.

 

[Paul Berkowitz]

It may be unreliable in the fact that the person on the receiving end chooses
not to
send the return receipt. Which they have the right to, if desired. but the
technology to implement the feature is not unreliable and has been around for
years.

It's mostly unreliable, as has been mentioned many times by now, in that
not all email clients can do it, as well as the fact that those which can
may be turned off.

It is just that MS either made a contious decision to leave it out. Or they
overlooked it.

Definitely a conscious decision. Members of MacBU have said so many times
since I first recall its being asked over 5 years ago re Outlook Express
Mac. I have not been _speculating_ in this discussion. I have been
accurately passing on the reasons given by Entourage Program Managers in the
Entourage Mailing List and in other forums as to why they have chosen not to
implement return-receipts: because it's unreliable since not all email
clients can do it, as well as the fact that those which can may be turned
off, and because it gives users a false idea that it is reliable. I don't
know how many more times I can repeat this. I think I'll stop now. Those are
the reasons for their consciously not implementing Message Disposition
Notices (return receipts), as per RFC 2445.

As I just finished explaining, you can roll your own if you wish to.




--
Paul Berkowitz
MVP Entourage
Entourage FAQ Page: <http://www.entourage.mvps.org/faq/index.html>
AppleScripts for Entourage: <http://macscripter.net/scriptbuilders/>

Please "Reply To Newsgroup" to reply to this message. Emails will be
ignored.

PLEASE always state which version of Entourage you are using - **2004**, X
or 2001. It's often impossible to answer your questions otherwise.

 

[Paul Berkowitz]

No, it doesn't. That was Adam's point. It just lets you know your message
arrived. It may well have been filtered by a spam filter, dumped in a Junk
mail folder, deleted and never read by the recipient. Or the other cases
mentioned by Adam. It's not like certified postal mail. It works some of the
time, but not all the time. Not dependable.

--
Paul Berkowitz
MVP Entourage
Entourage FAQ Page: <http://www.entourage.mvps.org/faq/index.html>
AppleScripts for Entourage: <http://macscripter.net/scriptbuilders/>

Please "Reply To Newsgroup" to reply to this message. Emails will be
ignored.

PLEASE always state which version of Entourage you are using - **2004**, X
or 2001. It's often impossible to answer your questions otherwise.

 

[Chris Ridd]

Thanks for the report, Chris. I'll make sure MacBU know about this. (They're
quite busy in the newsgroups at the moment so they've probably already seen
your post, but I'll make sure of it.)

The question I'd have would be: is the example you've given - where just one
character in a word is encoded by Entourage - a good example? Entourage is

I think it is a minimal example of the problem - the case where there's no
possible linear-white-space.

encoding just that "ó" character as =?ISO-8859-1?B?8w==?= inside an
otherwise ASCII word. Reading RFC 2047 I see no examples of that type -
which is perhaps your point. It looks as if the adjacent ASCII characters
are meant to be included within the 'encoded text' part of an 'encoded word'
- which would thus allow the required 'linear-white-space' to be outside the
entire word rather than within it. I wonder if "single-character" encoding
is allowed: I see nothing banning it. There is a length limit for 'encoded
words' whereby everything included between =? and ?= (inclusive) has to be
less than or equal to 75 characters, so maybe Entourage chooses to encode
the minimum number of characters it needs to and leaves the ASCII characters
outside the encoding. Since that would put the white space _outside_ the
encoding it would be read as an ASCII space, which would be wrong. Maybe
that's why all examples given put the entire word within the encoding. But

Eek, I'll have to look at the RFC in a bit more detail before I can sensibly
respond to this...

I'm not sure why you switched from B (base64) encoding to Q
(quoted-printable) in your example. That's surely a red herring? There's no

Yes, I agree that's irrelevant. I picked out the subject from an old mail
thread, and the Mozillas that the other guys were using happened to encode
the subject the quoted-printable way, so I just copied that in and said this
was "something like" what Entourage should send.

requirement to use Q encoding. (I suppose because you'd have to encode to
whole word as base64. I can't figure out base64 either - I'm there are
utilities that will do it.)

No, I couldn't be bothered to work it out either, so used the only correct
example I could find

Cheers,

Chris

 

[Phillip M. Jones, CE.T.]

It's mostly unreliable, as has been mentioned many times by now, in that
not all email clients can do it, as well as the fact that those which can
may be turned off.



Definitely a conscious decision. Members of MacBU have said so many times
since I first recall its being asked over 5 years ago re Outlook Express
Mac. I have not been _speculating_ in this discussion. I have been
accurately passing on the reasons given by Entourage Program Managers in the
Entourage Mailing List and in other forums as to why they have chosen not to
implement return-receipts: because it's unreliable since not all email
clients can do it, as well as the fact that those which can may be turned
off, and because it gives users a false idea that it is reliable. I don't
know how many more times I can repeat this. I think I'll stop now. Those are
the reasons for their consciously not implementing Message Disposition
Notices (return receipts), as per RFC 2445.

As I just finished explaining, you can roll your own if you wish to.

I have, I have turned it on. and installed the Applescript as suggested in aearlier
thread to have it work both ways.

The only ones on on Mac, that didn't use Return receipts that I knew of is AOL and
Entorage, Its so long since I have used OE I didn't remember whether OE did or not.

Anyway I can do so in Mozilla, Thunderbird, Apple Mail, and Eudora, so I can live
with out in Entorage. I have plenty of alternatives.

--
---------------------------------------------------------------------------
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112-1809 |[email protected], ICQ11269732, AIM pjonescet
---------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://home.kimbanet.com/~pjones/birthday/index.htm>
<http://vpea.exis.net>

 

[Phillip M. Jones, CE.T.]

No, it doesn't. That was Adam's point. It just lets you know your message
arrived. It may well have been filtered by a spam filter, dumped in a Junk
mail folder, deleted and never read by the recipient. Or the other cases
mentioned by Adam. It's not like certified postal mail. It works some of the
time, but not all the time. Not dependable.

If there is such a mindset against (almost a contempt for) return receipts. How do
MS people suggest/recommend that "Vital/Critical" be sent so recipient email be read
by the receiver.

If you can't send important information by email and guarantee its read by the party
directed to. What's the point of email. In that case we would well be served to go
back to snail Mail. Or perhaps Faxes, both expensive and slow proposition. :-|

--
---------------------------------------------------------------------------
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112-1809 |[email protected], ICQ11269732, AIM pjonescet
---------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://home.kimbanet.com/~pjones/birthday/index.htm>
<http://vpea.exis.net>

 

[Paul Berkowitz]

I have, I have turned it on. and installed the Applescript as suggested in
aearlier
thread to have it work both ways.

The only ones on on Mac, that didn't use Return receipts that I knew of is AOL
and
Entorage, Its so long since I have used OE I didn't remember whether OE did or
not.

Anyway I can do so in Mozilla, Thunderbird, Apple Mail, and Eudora, so I can
live
with out in Entorage. I have plenty of alternatives.

That's not really the issue. If you have any correspondents who have
Entourage, or AOL, or any others without 'return-receipt', you won't ever
get a receipt back from those people unless you can persuade them to set up
the same workarounds, no matter what email client you're using yourself.
Since you've now set up the two-way methods (I wasn't aware of a script -
the rule seemed good to me) it will now be working for you in Entourage
just the same as it would from any of those other alternatives.

--
Paul Berkowitz
MVP Entourage
Entourage FAQ Page: <http://www.entourage.mvps.org/faq/index.html>
AppleScripts for Entourage: <http://macscripter.net/scriptbuilders/>

Please "Reply To Newsgroup" to reply to this message. Emails will be
ignored.

PLEASE always state which version of Entourage you are using - **2004**, X
or 2001. It's often impossible to answer your questions otherwise.

 

[Paul Berkowitz]

If there is such a mindset against (almost a contempt for) return receipts.
How do
MS people suggest/recommend that "Vital/Critical" be sent so recipient email
be read
by the receiver.

I'm not sure if those are priorities, or something else? You can set the
priority to High (orange exclamation point) or Highest (red exclamation
point) from Message menu/Priority or Options button/Priority. That still
doesn't guarantee it will be read (unless it comes from a correspondent who
almost never sets these priorities. I find that certain correspondents, not
to mention spammers, mark Priority High so often I just ignore it after a
while.) I don't think people would want some sort of protocol that forced
opening-to-read, since that would be a perfect avenue for viruses.

If you can't send important information by email and guarantee its read by the
party
directed to. What's the point of email. In that case we would well be served
to go
back to snail Mail. Or perhaps Faxes, both expensive and slow proposition. :-|

Neither of them guarantees that the letter has been read either. Certified
snail mail with return receipt guarantees that someone at the other end has
signed for the letter (as do courier services). So for anything where it's a
legal necessity, best do it that way.


--
Paul Berkowitz
MVP Entourage
Entourage FAQ Page: <http://www.entourage.mvps.org/faq/index.html>
AppleScripts for Entourage: <http://macscripter.net/scriptbuilders/>

Please "Reply To Newsgroup" to reply to this message. Emails will be
ignored.

PLEASE always state which version of Entourage you are using - **2004**, X
or 2001. It's often impossible to answer your questions otherwise.

 

[Bill Weylock]

As I point out in another reply, I get Adam's point perfectly easily.

Neither of you, however, understands the way receipts are supposed to work.
They are NOT automatic. That is idiotic. They are MANUAL and indicate a
personal response from the recipient that he has opened and is acknowledging
receipt of your email.

It is NOT like certified mail, to be sure.

It does not check the negative. It affirms the positive.

 

[Dave Cortright]

If you can't send important information by email and guarantee its read by the
party directed to. What's the point of email. In that case we would well be
served to go back to snail Mail. Or perhaps Faxes, both expensive and slow
proposition. :-|

There are no guarantees in e-mail, just as there are no guarantees in any
form of asynchronous communications. In fact, the plots to many stories
actually rely on this as a key mechanism. E-mail is no better or worse in
this aspect. You could even receive a return receipt of a message that the
user doesn't end up reading; the mail server will send the "mail delivered"
message, but maybe the client doesn't download it, or an aggressive junk
mail filter trashes it, or the user accidentally deletes it somehow, or the
user just had massive heart attack and is lying dead on the floor when the
message is delivered. You just never know. If you want guaranteed
communications with someone, face to face is the best, followed by phone,
chat and other real-time systems.

 

[Bill Weylock]

That's the reason I figure people are talking past each other on this. If
you figure it's about "landed in mailbox," there is plenty of reason to
eliminate it as an easy option in your mail software.

But when you realize it is simply designed to ask the recipient to send a
receipt, it makes sense and needs to be there.

If you want Entourage to respond to them, you can write an e-mail rule that
looks for "specific header", and generates an auto-reply. I had such a rule
for a short time with a friend whose emails seemed to be getting lost; she
asked me to turn it off after a few days, so I know it worked. Something
like this:

Mail tab, then click New on the toolbar.

* Execute actions if all criteria are met
IF Specific Header "Disposition-Notification-To" Exists
IF From Is in Address Book

* Action
Reply [specify message]

Of course having a rule that does this does not mean that the person has
actually opened the message. It just means it has been downloaded to
their computer. The person could easily just delete the message before
reading it.

 

[Adam Bailey]

That doesn't change the fact that Entourage does not implement this feature
natively since it's unreliable and undependable and most users would not
realize that. They would assume that if the feature exists they will get
receipts from all recipients.

Again, Paul, the reason for sending a receipt is to reassure the sender. It
crosses me off the list of problems. If someone does not return a receipt
for an important memo, that person will require another email specifically
requesting a response or a telephone call to make sure he is on board.[/QUOTE]

Why not go with the much more reliable form: "Let me know when you get
this email. I need to know because _________________________."

When I go into work tomorrow I'll have at least a dozen emails waiting
for me. I will quickly scan through all of them for the most pressing
issues and attend to those first. Then I'll go back and deal with the
rest. Sometimes I forget about an email and might not get back to it
until the next day.

An automated receipt (assuming no technical glitches) tells the sender
that I *viewed* their email, but not that I actually read it,
understood it, and plan on doing something about it.

 

[somedumbguy]

That's the reason I figure people are talking past each other on this. If

you figure it's about "landed in mailbox," there is plenty of reason to
eliminate it as an easy option in your mail software.

But when you realize it is simply designed to ask the recipient to send a
receipt, it makes sense and needs to be there.

I'm with Bill on this one. The way Eudora (for example) implements the
return request is very different from what many people are describing. When
you *open* a message for which a return receipt has been requested, it beeps
and presents you with a button that tells Eudora to send confirmation of
receipt. This button pops up when you view the message, not when it's
delivered, and you have to manually invoke it.

Before I go any further, I should say that I find receipt-requests annoying.
I can, however, see their utility and, in such cases, an imperfect system is
better than none.

Now, back to the story... I agree that a mechanism that simply confirms
delivery is stupid. Any number of things could happen to that message before
it is read, not the least of which is that the local client's spam filter
could get rid of it. Yes, the recipient might not be able to see the request
(depending on their client), or they might choose to ignore it. It doesn't
really hurt to give people the choice, though.

That being said, a rule to segregate the message into a 'Return Receipt'
mailbox, as I originally suggested several days ago, would be more than
sufficient for me.

As an aside, I actually find it kind of amusing that, according to Paul,
Entourage doesn't support this functionality because many individuals use
e-mail clients don't support this functionality. Well, guess what? If
Entourage *did* support it, then many more individuals would be using a
client that supports it, thereby making it worth supporting. Kind of a
chicken and egg thing. Indeed, if everyone took this sort of stance with
regard to innovations in general (not that return-receipts are necessarily
innovative), there would be no progress.

Does this kind of thinking explain why we don't have format=flowed, as well?