Re: [Evolution] read receipt function in evo

[Not Zed <notzed ximian com>]

On Wed, 2004-06-16 at 09:57 -0700, James D. Ivey wrote:
>     On Tue, 2004-06-15 at 07:16, Jeffrey Stedfast wrote: 
> > On Tue, 2004-06-15 at 04:16 -0500, Ron Johnson wrote:
> > > On Tue, 2004-06-15 at 15:46 +0800, Not Zed wrote:
> > > > 
> > > > > Do you know if there is a special reason why it's not supported by evo yet?
> > > > > I mean, a lot of 'big' mail clients support this, like Mozilla-mail,
> > > > > thunderbird, kmail, a certain out-of-the-windows-look client ;)
> > > > Probably none of us see it as very important.  Its an intrusion on
> > > > personal privacy, and if you can turn it off, which you would have to
> > > > be able to for the reason just mentioned, then it can never actually
> > > > guarantee anything anyway.
> > > > 
> > > > Its like ringing someones phone to see if they're home.  If they
> > > > answer you know they are, but if they don't, it doesn't mean they
> > > > aren't.
> > > 
> > > True.  However, at work, where I must use Lookout, it's useful
> > > with co-workers who forget to reply to emails.  "Hey, you read my
> > > urgent email a week ago.  Why haven't you replied?"
> > > 
> >
> > yea, but you can do this anyway.
> >     
>     
>     Yea, and we can also do without e-mail altogether and just use the telephone.  That's not a legitimate answer to the posted question.
>     
>     And, there's a very real and legitimate reason to ask for a return receipt.  It's not an invasion of privacy.
I wouldn't be the only one who would beg to differ on the privacy issue.  Do you really think a spam with a read receipt request should always be responded to, and isn't an invasion of privacy?
>     Years ago, as a software engineer contractor, I was stiffed by my client.  I had to resort to small claims court to collect.  For all the contractors out there who could find themselves in a similar situation, how do you send "registered" e-mail that has some evidence that it was viewed?
You can't.  And this feature doesn't provide it either.  The only context which is might provide anything remotely of the sort is in a closed coorporate environment where the company owns all email and can enforce such policies.  Otherwise, on the world wild internet, not even close.
>     Just generally, in business, requests get passed around with multiple "hops" before they are satisfied.  It would be really useful to be able to track down breaks in communication to prevent business failures.  For business, this is an important feature.  And, I've posted a request for this feature back with evo 0.8.  Yes, the recipient can refuse the return receipt, but it's still a very useful feature.
If you're relying on it for legal or business reasons then you're simply fooling yourself.  Even if the email client implements it, for which there is no guarantee whatsoever, and even if the user has it turned on, there's nothing to stop the user disabling it external to the client entirely.  Apart from that, there's no integrity mechanism to tell you it was the person you sent it to who actually read it anyway, it could be anyone.  You should be sending physical letters or using the phone.
>     Unless Ximian implements some features that aren't important to Ximian but are important to its users, evo will be relegated to "toy" status.  I'm currently struggling to remain with my current distro of SuSE+Ximian in my business, but the lack of meaningful support in both components is forcing my hand to look around for another solution.

>     So the question to Ximian at this point becomes, do you want to be a toy, or do you want a meaningful presence in industry?  I'm a big fan of Ximian and have been for years.  But I'd really like to see it mature into a business-ready platform.  Responses like the one above indicates that Ximian just isn't quite ready for the office yet.  Pitty.

Oh please, no need to get abusive, if you think its a toy, keep your opinion to yourself around here.  We have to prioritise, we're a tiny team for a giant project.  This has been a potentital future feature for ages.  Despite the developers opinions about it, there has been no great push from the product managers or marketing for it either.

Anyway, i'll heavily quote an rfc again (its not even a standard yet, for that matter), since it so clearly reflects the arguments I made before I even read the details.

RFC 3798            Message Disposition Notification            May 2004


6.  Security Considerations

   The following security considerations apply when using MDNs:

6.1.  Forgery

   MDNs may be forged as easily as ordinary Internet electronic mail.
   User agents and automatic mail handling facilities (such as mail
   distribution list exploders) that wish to make automatic use of MDNs
   should take appropriate precautions to minimize the potential damage
   from denial-of-service attacks.

   Security threats related to forged MDNs include the sending of:

   (a)  A falsified disposition notification when the indicated
        disposition of the message has not actually occurred,

   (b)  Unsolicited MDNs

6.2.  Privacy

   Another dimension of security is privacy.  There may be cases in
   which a message recipient does not wish the disposition of messages
   addressed to him to be known, or is concerned that the sending of
   MDNs may reveal other sensitive information (e.g., when the message
   was read).  In this situation, it is acceptable for the MUA to issue
   "denied" MDNs or to silently ignore requests for MDNs.

   If the Disposition-Notification-To header is passed on unmodified
   when a message is distributed to the subscribers of a mailing list,
   the subscribers to the list may be revealed to the sender of the
   original message by the generation of MDNs.

   Headers of the original message returned in part 3 of the
   multipart/report could reveal confidential information about host
   names and/or network topology inside a firewall.

   An unencrypted MDN could reveal confidential information about an
   encrypted message, especially if all or part of the original message
   is returned in part 3 of the multipart/report.  Encrypted MDNs are
   not defined in this specification.

   In general, any optional MDN field may be omitted if the Reporting
   MUA site or user determines that inclusion of the field would impose
   too great a compromise of site confidentiality.  The need for such
   confidentiality must be balanced against the utility of the omitted
   information in MDNs.




Hansen & Vaudreuil          Standards Track                    [Page 19]

RFC 3798            Message Disposition Notification            May 2004


   In some cases, someone with access to the message stream may use the
   MDN request mechanism to monitor the mail reading habits of a target.
   If the target is known to generate MDN reports, they could add a
   disposition-notification-to field containing the envelope from
   address along with a source route.  The source route is ignored in
   the comparison so the addresses will always match.  But if the source
   route is honored when the notification is sent, it could direct the
   message to some other destination.  This risk can be minimized by not
   sending MDN's automatically.

6.3.  Non-Repudiation

   MDNs do not provide non-repudiation with proof of delivery.  Within
   the framework of today's Internet Mail, the MDNs defined in this
   document provide valuable information to the mail user; however, MDNs
   cannot be relied upon as a guarantee that a message was or was not
   seen by the recipient.  Even if MDNs are not actively forged, they
   may be lost in transit.  The recipient may bypass the MDN issuing
   mechanism in some manner.

   One possible solution for this purpose can be found in RFC 2634
   [SEC-SERVICES].

6.4.  Mail Bombing

   The MDN request mechanism introduces an additional way of mailbombing
   a mailbox.  The MDN request notification provides an address to which
   MDN's should be sent.  It is possible for an attacking agent to send
   a potentially large set of messages to otherwise unsuspecting third
   party recipients with a false "disposition-notification-to:" address.
   Automatic, or simplistic processing of such requests would result in
   a flood of MDN notifications to the target of the attack.  Such an
   attack could overrun the capacity of the targeted mailbox and deny
   service.

   For that reason, MDN's SHOULD NOT be sent automatically where the
   "disposition-notification-to:" address is different from the envelope
   MAIL FROM address.  See section 2.1 for further discussion.

--

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer