On Fri, Jul 02, 2010 at 04:39:53PM +0200, lee wrote: > On Thu, Jul 01, 2010 at 11:09:22PM +0200, Rado S wrote: > > =- lee wrote on Thu 1.Jul'10 at 18:08:43 +0200 -= > > > > > Noone using return reciepts? > > > > No, because if you want that, just write it in your eMail. > > That's awfully annoying and too easy to forget. It's a common feature > in many MUAs, so mutt could as well support it --- or there could > already be a solution. > > If there isn't, I might go ahead and write something for the > purpose. But I don't want to re-invent the wheel unnecessarily.
If what you're talking about is the mechanism described in RFC 2298, then a cursory glance indicates that read receipts are requested by setting the Disposition-Notification-To: header. So to request receipts, it may be sufficient to add this header to your outgoing emails using mutt's my_hdr command. As for automatically sending a read receipt when you open a mail in mutt, I imagine it should be possible to cook something up using message-hooks and a little scripting. So, with a little effort, what you want can probably already be done using standard mutt features (plus maybe some external tools for automatically sending receipts). If you're talking about server delivery receipt requests, I believe most servers simply ignore these anyway. (Servers are almost always configured to send failure reports, so the lack of a failure report indicates successful delivery to the recipient's mailbox.) > As to comments about the requests being ignored and therefore > pointless: Sorry, but these comments are themselves pointless. No, the comments were not pointless. Read receipts by definition have to be implemented in the MUA in order to work at all. You cannot force your recipients to use an MUA that implements them. Even if the MUA does implement read receipts, you cannot force your recipients to choose to send them. (Even RFC 2298 takes the unusual step of strongly recommending that MUAs make sending of read receipts optional, and AFAIK this is indeed the case in all MUAs that implement them.) Read receipts are therefore inherently unreliable. The fact that you haven't received one tells you nothing about whether your email has been read or not. If you do receive one, it does at least tell you that the recipient has opened the email. Whether they've actually read it is another question entirely. In many mail clients, simply scrolling through the message in a mailbox will mark it as read and trigger sending the receipt. So it's debatable whether read receipts are more or less useful than simply asking the recipient to reply to let you know they've read your message. At least that way, if you do receive a reply, you can be sure they've actually read what you've written. > It's a feature useful to me, and lacking better alternatives, I want to > make use of it. A number of people suggested a perfectly reasonable alternative: ask the recipient to acknowledge that they've read your message. This is all that a read receipt does, in any case. It doesn't in any way *compel* them to acknowledge that they've read it. And a polite request in your message has the advantage of working irrespective of which MUA your recipient is using, as well as providing you with a much more useful and reliable indication about whether the recipient has actually read your message. > Unfortunately, mutt doesn't have this feature, so I'm asking what's > available before putting my time into creating support for it myself. > > Besides, it's hard to believe that noone on this mailing list has use > for return reciepts and/or that everyone handles them manually. Read receipts raise troubling privacy concerns (the RFC acknowledges this explicitly), and the kind of technically-savvy people who use mutt tend to care deeply about privacy. It's not at all surprising to me that you can't find any mutt users that want to use them. I always make sure I disable them when forced to use a mail client that implements them. Toby -- Dr T. S. Cubitt Quantum Information Theory group Department of Mathematics University of Bristol United Kingdom email: ts...@cantab.net web: www.dr-qubit.org
