Re: return reciepts
On Sun, Jul 04, 2010 at 03:00:32PM +0200, lee wrote: On Sat, Jul 03, 2010 at 09:51:03AM -0400, Patrick Shanahan wrote: * lee l...@yun.yagibdah.de [07-03-10 09:13]: On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Practice has shown that it is not best practice. Because of poor support, maybe :) Or, more likely, requests for features that most do *not* want presented in a haughty manner What's haughty about this? which would require coding and where work-a-rounds have been presented. Just look at the replies, ppl told me at first that a feature I have use for is useless, troublesome and pointless and that they don't want it because they don't like it. How haughty is that? And keep in mind that nobody would be forced to use this feature if they don't like it. Just look at your own comment and how haughty that is: Apparently the idea that implementing a feature would require some work is horrible to you, so you're telling me that everyone who has use for it should implement the feature by doing the necessary steps for each message manually. Do it manually was the only workaround presented, but that's silly considering that I already said in my OP that I can do it manually but am wondering if there's a better solution available. Besides, it has probably escaped you that there's a difference between solution and workaround. Isn't it amazing that ppl can't say something like hey I don't have use for this feature and I don't like it and I don't know of any implementation, but it would sure be great if you were to come up with a solution everyone could use? I have not responded before, but what is wrong with that. It is my position. I do not use them. I do not like them and do not quite understand why you and others think it solves a problem. However, I am more than happy for a new feature to be available in or with mutt. Do I know of an implementation? I have a vague recollection that there was one on this mailing list 10 or more years ago, but I no longer have details and can not remember anything. You know, I've already been asking myself if I should make such a solution available for everyone who wants it if I ever implement it after seeing the rude comments I got here. Don't be surprised when at some time, you'll find yourself out of free software because you finally managed to piss off everyone who was willing to provide some. Free software is not going to die because you are pissed off. The mutt list is calm and helpful compared with many lists. -- The box said 'Windows 95 or better', so I installed Linux -- Unknown Brian Salter-Duke (Brian Duke) Email: b_duke(AT)bigpond(DOT)net(DOT)au
Re: return reciepts
On Sat, Jul 03, 2010 at 03:12:49PM +0200, lee wrote: [snip] Let me add that you just got me to the idea that a simple yes/no for a combination of recipients won't suffice: It would have to be always/once/no/never, meaning that for the combination of recipients in question, the requesting of reciepts would either always be enabled or for that particular message only or no reciept for the particular message will be requested or reciepts are never requested. No doubt that the kind of support for reciepts I have in mind could be used otherwise, but how someone makes use of a feature is always up to them. The simplest thing (as others have already mentioned) is still using $edit_headers and implement that in your editor. Either directly or in a wrapper script (which could even be in C, but I would use something faster to develop, like Shell, Perl, Python, ..) used in $editor. It would check the mail after you exit the editor, and then ask you - based on a configuration file - if you want to add a request, and if yes add the necessary header. [snip] Wasted effort compared to an editor macro to add some line like please acknowledge receipt and respond ASAP. What makes you think that the recipient would bother to write an answer? It would involve even more overhead for them to manually write and send a response than it is to use a feature of their MUA that reduces the overhead to just pressing a single key --- or doesn't involve any overhead at all for them because they have chosen to always automatically send reciepts when requested. But if the recipient doesn't care about your mail, then how does adding a receipt request help? Practice has shown that it is not best practice. Because of poor support, maybe :) Or because it's a bad idea. Regarding the support of requests in mutt, adding it can (or should be; I haven't tried it and probably never will, I don't like them) easily be done with $display_filter. Just add a wrapper script which checks the mail for the header and if it contains one, displays a message in the mail. Then use a macro which pipes the mail to another script which sends the answer to the recipient. Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 pgpIkxIKkBahQ.pgp Description: PGP signature
Re: return reciepts
On Sun, Jul 04, 2010 at 12:33:22PM +0200, Simon Ruderich wrote: On Sat, Jul 03, 2010 at 03:12:49PM +0200, lee wrote: But if the recipient doesn't care about your mail, then how does adding a receipt request help? Practice has shown that it is not best practice. Because of poor support, maybe :) Or because it's a bad idea. Regarding the support of requests in mutt, adding it can (or should be; I haven't tried it and probably never will, I don't like them) On the flip, return receipts might be a good thing for keeping track of the wife or kids? We should stop thinking about what we dislike or like, and start thinking of others for a change. Evil Grin -- Roger http://rogerx.freeshell.org/
Re: return reciepts
On Sun, Jul 04, 2010 at 12:33:22PM +0200, Simon Ruderich wrote: Either directly or in a wrapper script (which could even be in C, but I would use something faster to develop, like Shell, Perl, Python, ..) used in $editor. It would check the mail after you exit the editor, and then ask you - based on a configuration file - if you want to add a request, and if yes add the necessary header. Yes, other programming languages than C would be better suited for this, but I'd have to learn them first. But if the recipient doesn't care about your mail, then how does adding a receipt request help? In this case, I started to request them because they don't answer --- and guess what, I got a reciept. That way they can't claim they didn't get my mail. It's extremely useful. Besides, do you seriously trust in that every admin involved has set up their mailservers correctly? Do you seriously trust in that email never gets lost? Do you seriously trust in that you will always get an error message sent back to you in case something goes wrong? I've seen servers at ISPs set up so that they don't even accept error messages sent to them ... In this case, the alternative would be to print the message on paper to deliver it in person and have them certify that they recieved it. I like return reciepts better for now. Practice has shown that it is not best practice. Because of poor support, maybe :) Or because it's a bad idea. It's still way better than the alternative. like them) easily be done with $display_filter. Ah, that's cool :) Now I have the pieces I'd need to interface with mutt, thanks.
Re: return reciepts
On Sat, Jul 03, 2010 at 09:51:03AM -0400, Patrick Shanahan wrote: * lee l...@yun.yagibdah.de [07-03-10 09:13]: On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Practice has shown that it is not best practice. Because of poor support, maybe :) Or, more likely, requests for features that most do *not* want presented in a haughty manner What's haughty about this? which would require coding and where work-a-rounds have been presented. Just look at the replies, ppl told me at first that a feature I have use for is useless, troublesome and pointless and that they don't want it because they don't like it. How haughty is that? And keep in mind that nobody would be forced to use this feature if they don't like it. Just look at your own comment and how haughty that is: Apparently the idea that implementing a feature would require some work is horrible to you, so you're telling me that everyone who has use for it should implement the feature by doing the necessary steps for each message manually. Do it manually was the only workaround presented, but that's silly considering that I already said in my OP that I can do it manually but am wondering if there's a better solution available. Besides, it has probably escaped you that there's a difference between solution and workaround. Isn't it amazing that ppl can't say something like hey I don't have use for this feature and I don't like it and I don't know of any implementation, but it would sure be great if you were to come up with a solution everyone could use? You know, I've already been asking myself if I should make such a solution available for everyone who wants it if I ever implement it after seeing the rude comments I got here. Don't be surprised when at some time, you'll find yourself out of free software because you finally managed to piss off everyone who was willing to provide some.
Re: return reciepts
On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Your original request just sounds like reversing the default from mostly no r-r, with manual exceptions to mosty _DO_ r-r, with manual exceptions, it actually requires you still to make a manual choice... That is not at all what I want. The default is NOT to request reciepts, and that won't change. But in some cases I do want to request them --- and that without having to add header lines manually, which is inconvenient and too easy to forget. Let me add that you just got me to the idea that a simple yes/no for a combination of recipients won't suffice: It would have to be always/once/no/never, meaning that for the combination of recipients in question, the requesting of reciepts would either always be enabled or for that particular message only or no reciept for the particular message will be requested or reciepts are never requested. No doubt that the kind of support for reciepts I have in mind could be used otherwise, but how someone makes use of a feature is always up to them. It's a common feature in many MUAs, so mutt could as well support it --- or there could already be a solution. You've been given technical details elsewhere. I once thought it would make things easier for me and worked with it myself, until I realized it didn't improve anything really, just added more overhead for the sender creating and the recipient dealing with it. That's the way it is now, I agree. It is why I'm looking for a better solution that avoids these disadvantages. Wasted effort compared to an editor macro to add some line like please acknowledge receipt and respond ASAP. What makes you think that the recipient would bother to write an answer? It would involve even more overhead for them to manually write and send a response than it is to use a feature of their MUA that reduces the overhead to just pressing a single key --- or doesn't involve any overhead at all for them because they have chosen to always automatically send reciepts when requested. Practice has shown that it is not best practice. Because of poor support, maybe :)
Re: return reciepts
* lee l...@yun.yagibdah.de [07-03-10 09:13]: On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Practice has shown that it is not best practice. Because of poor support, maybe :) Or, more likely, requests for features that most do *not* want presented in a haughty manner which would require coding and where work-a-rounds have been presented. -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org
Re: return reciepts
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. As to comments about the requests being ignored and therefore pointless: Sorry, but these comments are themselves pointless. It's a feature useful to me, and lacking better alternatives, I want to make use of it. 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.
Re: return reciepts
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: ... snip ... Besides, it's hard to believe that noone on this mailing list has use for return reciepts and/or that everyone handles them manually. Return receipts could likely be called a corporate feature or a feature for the Wife. But to step aside from paranoia, it could be considered a politeness feature as it would tell a friend or significant other that you did receive their email. On the side of politics, return receipts mention nothing concerning that the person even read or noticed your sent email. Much less, comprehension is another weak spot. It'd be great if we could program human brains to respond, Yes I understand after sending them instructions. But all I keep getting is this glazed over look and ... Who's that gurl response. :-/ The first scenarios, could likely be easily scripted into mailfilter or elsewhere. As far as coding it into Mutt, would people use it -- and if so, how many would turn it off if it were set. -- Roger http://rogerx.freeshell.org/
Re: return reciepts
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
Re: return reciepts
* On 28 Jun 2010, lee wrote: Hi, how do you handle return reciepts with mutt? I know I can add header lines to request a reciept (with my_hdr), but how do I make it so that reciepts are requested based on, for example, recipients? You could try Werner Koch's rfc2298 MDN patch, but afaik it has not been updated in years and probably needs some love. http://intevation.de/roundup/aegypten/file34/mutt-patch-1.5.6cvs.g10.mdn.1.asc -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago http://www.chicagomaroon.com/2010/5/28/spring-sprout
Re: return reciepts
On Fri, Jul 02, 2010 at 05:15:36PM +0100, Toby Cubitt wrote: 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. That puts the header into every outgoing email, and ppl on mailing lists will complain about it. 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. If you can do what I described in my OP with a little scripting, that's great for you, but I don't see how to do it. I'd have to write a program in C for it and somehow make it work with mutt --- and preferably make it so that it can be used with other MUAs as well. I don't know of any MUA that deals with return reciepts in the way described in my OP. 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). Ok, how so? Refer to to my OP for a more detailed description of how it's supposed to work ... As to comments about the requests being ignored and therefore pointless: Sorry, but these comments are themselves pointless. No, the comments were not pointless. I'm aware of the issues involved with return reciepts but still have use for them. It's not my intention at all to debate the usefulness or privacy concerns of return reciepts in general or in particular. Such a debate wouldn't take me any closer to a solution. I'd find it much more interesting to talk about how a good support for return reciepts should be designed. This is not to say these points aren't valid. I'm not sending return reciepts, either, but that's because there isn't good support for them: None in mutt, apparently, and I've seen only MUAs that offered only to either ask if I want to send a reciept or always send one or don't send any at all. None of these three options is sufficient. If there's a MUA that can do better, I'd be curious to hear about it. And why shouldn't mutt be the MUA that can do better in that than others? Having that said, it comes to mind that more users of mutt might make use of return reciepts if there was well designed support for them ... One way to address privacy concerns could be, for example, to queue the reciepts one wants to send and then send them all at once automatically, perhaps once or twice a day at fixed times. Perhaps that's a poor idea, I don't know.
Re: return reciepts
On Fri, Jul 02, 2010 at 12:11:27PM -0500, David Champion wrote: * On 28 Jun 2010, lee wrote: Hi, how do you handle return reciepts with mutt? I know I can add header You could try Werner Koch's rfc2298 MDN patch, but afaik it has not been updated in years and probably needs some love. http://intevation.de/roundup/aegypten/file34/mutt-patch-1.5.6cvs.g10.mdn.1.asc Thanks, that could be very useful :) However, it makes me think again that something to handle return reciepts that works (mostly) independantly of mutt might be a better approach. Patching a recent mutt version with a patch that's 7 years old and like 14 versions back could turn out to be a little difficult ...
Re: return reciepts
* lee l...@yun.yagibdah.de [07-02-10 13:16]: On Fri, Jul 02, 2010 at 05:15:36PM +0100, Toby Cubitt wrote: 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. That puts the header into every outgoing email, and ppl on mailing lists will complain about it. No, it puts the header in the messages *you* put it in. You do have control of your email client! 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. If you can do what I described in my OP with a little scripting, that's great for you, but I don't see how to do it. I'd have to write a program in C for it and somehow make it work with mutt --- and preferably make it so that it can be used with other MUAs as well. I don't know of any MUA that deals with return reciepts in the way described in my OP. So, what you *really* want is for someone to code/script it for you. The offer of renumeration will more than likely provide you with candidates. -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org
Re: return reciepts
On 2010-07-02, lee l...@yun.yagibdah.de wrote: Having that said, it comes to mind that more users of mutt might make use of return reciepts if there was well designed support for them Doubit it. Well designed support for evil is still evil. 1/2 :) ... One way to address privacy concerns could be, for example, to queue the reciepts one wants to send and then send them all at once automatically, perhaps once or twice a day at fixed times. Perhaps that's a poor idea, I don't know. It's the actual sending of receipts that's a problem. I don't see how queueing them up helps. -- Grant Edwards grant.b.edwardsYow! I have a TINY BOWL in at my HEAD gmail.com
Re: return reciepts
On Fri, Jul 02, 2010 at 07:13:02PM +0200, lee wrote: On Fri, Jul 02, 2010 at 05:15:36PM +0100, Toby Cubitt wrote: 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. That puts the header into every outgoing email, and ppl on mailing lists will complain about it. I know perfectly well what my_hdr does. You ought to know perfectly well that mutt has plenty of facilities (send-hook, send2-hook, reply-hook...) for selectively setting my_hdr based on the recipient. $edit-headers plus a decent text editor provide even more possibilities. 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). Ok, how so? Refer to to my OP for a more detailed description of how it's supposed to work ... I was thinking more of the traditional read receipt behaviour when I wrote that, but I'll bite. Referring to your OP: how do I make it so that reciepts are requested based on, for example, recipients? Use send-hooks (or send2-hook, or reply-hook -- I always forget the details of which does what, and have to look it up in the manual) to set my_hdr based on the recipient. The idea is something like mutt asking me if I want to request a reciept when sending a message to a combination of recipients not yet recognized by mutt. It then would remember my decision and add that particular combination of recipients to some list for later reference as to what decision I have made. Next time when sending messages to that same combination of recipients, mutt would automatically either request a reciept or not, depending on my decision once made --- unless I explicitly instruct mutt otherwise when sending a message. This is obviously trickier. You could try setting $editor to a script that prompts you about send receipts, and writes a new send-hook based on your choice to a mutt config file. You'd then need to make mutt re-source the modified config file, e.g. by replacing the send-message binding with a macro that calls both source and send-message. Just an idea, though. I've done things somewhat like this in mutt, for completely different purposes. But in discoursing from the armchair without actually trying to implement it, there are very quite likely difficulties I'm missing here. Anyway, personally, I would set $edit-headers and implement this in the editor rather than in mutt. I hear vim is reasonably scriptable these days, but I find Lisp to be a more elegant language... ;-) But if you prefer to do your coding in C, that's great too. I just thought you might want to avoid having to hack the mutt source code, as that always takes much more time. (And carries a maintenance burden every time a new version of mutt is released, as I suspect your chances of getting a send-receipt implementation into vanilla mutt are very small indeed...thankfully :) Since it's not a feature I ever want to see in mutt, I'm afraid that exhausts my interest in thinking about how to implement it. Good luck! 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
Re: return reciepts
On Fri, Jul 02, 2010 at 01:45:57PM -0400, Patrick Shanahan wrote: * lee l...@yun.yagibdah.de [07-02-10 13:16]: On Fri, Jul 02, 2010 at 05:15:36PM +0100, Toby Cubitt wrote: 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. That puts the header into every outgoing email, and ppl on mailing lists will complain about it. No, it puts the header in the messages *you* put it in. You do have control of your email client! 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. If you can do what I described in my OP with a little scripting, that's great for you, but I don't see how to do it. I'd have to write a program in C for it and somehow make it work with mutt --- and preferably make it so that it can be used with other MUAs as well. I don't know of any MUA that deals with return reciepts in the way described in my OP. So, what you *really* want is for someone to code/script it for you. The offer of renumeration will more than likely provide you with candidates. Can you read at all?
Re: return reciepts
On Fri, Jul 02, 2010 at 06:23:23PM +, Grant Edwards wrote: On 2010-07-02, lee l...@yun.yagibdah.de wrote: Having that said, it comes to mind that more users of mutt might make use of return reciepts if there was well designed support for them Doubit it. Well designed support for evil is still evil. 1/2 :) There's nothing evil about return reciepts. ... One way to address privacy concerns could be, for example, to queue the reciepts one wants to send and then send them all at once automatically, perhaps once or twice a day at fixed times. Perhaps that's a poor idea, I don't know. It's the actual sending of receipts that's a problem. I don't see how queueing them up helps. Then don't send them if you don't want to. Queueing them could be do done for not to disclose when you handled the message.
Re: return reciepts
On Fri, Jul 02, 2010 at 07:40:45PM +0100, Toby Cubitt wrote: in discoursing from the armchair without actually trying to implement it, there are very quite likely difficulties I'm missing here. See, it's not all that easy :) So before spending a lot of time to figure it out, I thought it a good idea to see if there's already a solution available. Anyway, personally, I would set $edit-headers and implement this in the editor rather than in mutt. I hear vim is reasonably scriptable these days, but I find Lisp to be a more elegant language... ;-) That would be a good approach if I could program emacs. Unfortunately, I'm finding Lisp anything else than elegant --- rather totally unreadable and not at all understandable. But if you prefer to do your coding in C, that's great too. It would only be the easiest way for me. I just thought you might want to avoid having to hack the mutt source code, Yes, that's something I want to avoid. Good luck! Thanks!
Re: return reciepts
On Fri, Jul 02, 2010 at 04:36:18PM +, Grant Edwards wrote: On 2010-07-02, rog...@sdf.org rog...@sdf.org wrote: But to step aside from paranoia, it could be considered a politeness feature as it would tell a friend or significant other that you did receive their email. That's what the r key does. ;) ... LOL -- Roger http://rogerx.freeshell.org/
Re: return reciepts
Ok, some more bashing... ;)
=- lee wrote on Fri 2.Jul'10 at 16:39:53 +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.
No, automatic return-receipts are.
If you don't have the discipline and respect to use requests wisely,
why do you expect such responses from your recipients?
If something is important to you, tell me, and I'll respond if I
care enough.
Why would you want to automatically remind me of something that is
_not_ important to you?
Your original request just sounds like reversing the default from
mostly no r-r, with manual exceptions to mosty _DO_ r-r, with
manual exceptions, it actually requires you still to make a manual
choice...
It's a common feature in many MUAs, so mutt could as well support
it --- or there could already be a solution.
You've been given technical details elsewhere.
I once thought it would make things easier for me and worked with
it myself, until I realized it didn't improve anything really, just
added more overhead for the sender creating and the recipient
dealing with it.
Wasted effort compared to an editor macro to add some line like
please acknowledge receipt and respond ASAP.
If you just want to reverse the default, add such line to your
$signature, and delete it when not desired.
As to comments about the requests being ignored and therefore
pointless: Sorry, but these comments are themselves pointless.
{...}
Besides, it's hard to believe that noone on this mailing list has
use for return reciepts and/or that everyone handles them
manually.
Practice has shown that it is not best practice.
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Re: return reciepts
Сбт, 03 Июл 2010, Rado S писал(а): Wasted effort compared to an editor macro to add some line like please acknowledge receipt and respond ASAP. If you just want to reverse the default, add such line to your $signature, and delete it when not desired. IMO the key to get response is politeness, putting that line in $signature is not enough and some (including me) configure mua to hide signature when reading emails. A better chance of getting receipt would be writing inside email body, such as John, it is very important for me to know that you had read this email. Your help to send me an acknowledge receipt will be highly appreciated. This would make recipient feel a real person or a friend rather than a machine making that request. I think OP can go on writing his patch to automate sending r-r but I doubt that will increase his chance of getting receipts other than annoying more recipients. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: return reciepts
=- 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. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: return reciepts
On 2010-07-01, lee l...@yun.yagibdah.de wrote: On Mon, Jun 28, 2010 at 10:21:31PM +0200, lee wrote: how do you handle return reciepts with mutt? I know I can add header lines to request a reciept (with my_hdr), but how do I make it so that reciepts are requested based on, for example, recipients? [...] Noone using return reciepts? Nope. What's the point? I don't honor them in received mail, and AFAICT enough other people do the same to make requesting them rather pointless. -- Grant Edwards grant.b.edwardsYow! Is something VIOLENT at going to happen to a gmail.comGARBAGE CAN?
Re: return reciepts
Чтв, 01 Июл 2010, lee писал(а): On Mon, Jun 28, 2010 at 10:21:31PM +0200, lee wrote: Hi, how do you handle return reciepts with mutt? I know I can add header lines to request a reciept (with my_hdr), but how do I make it so that reciepts are requested based on, for example, recipients? The idea is something like mutt asking me if I want to request a reciept when sending a message to a combination of recipients not yet recognized by mutt. It then would remember my decision and add that particular combination of recipients to some list for later reference as to what decision I have made. Next time when sending messages to that same combination of recipients, mutt would automatically either request a reciept or not, depending on my decision once made --- unless I explicitly instruct mutt otherwise when sending a message. Handling the sending of return reciepts when requested by incoming messages could work very much the same. How do I configure mutt to do that? Or is there already support for return reciepts? Noone using return reciepts? No, even if/when such feature would be available in mutt, I will certainly disable it. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: return reciepts
On Thu, Jul 01, 2010 at 06:08:43PM +0200, lee wrote: On Mon, Jun 28, 2010 at 10:21:31PM +0200, lee wrote: Hi, how do you handle return reciepts with mutt? I know I can add header lines to request a reciept (with my_hdr), but how do I make it so that reciepts are requested based on, for example, recipients? The idea is something like mutt asking me if I want to request a reciept when sending a message to a combination of recipients not yet recognized by mutt. It then would remember my decision and add that particular combination of recipients to some list for later reference as to what decision I have made. Next time when sending messages to that same combination of recipients, mutt would automatically either request a reciept or not, depending on my decision once made --- unless I explicitly instruct mutt otherwise when sending a message. Handling the sending of return reciepts when requested by incoming messages could work very much the same. How do I configure mutt to do that? Or is there already support for return reciepts? Noone using return reciepts? Not a chance - never festus -- It is not unusual for those at the wrong end of the club to have a clearer picture of reality than those who wield it. Noam Chomsky pgpbcsbTJYvW2.pgp Description: PGP signature
return reciepts
Hi, how do you handle return reciepts with mutt? I know I can add header lines to request a reciept (with my_hdr), but how do I make it so that reciepts are requested based on, for example, recipients? The idea is something like mutt asking me if I want to request a reciept when sending a message to a combination of recipients not yet recognized by mutt. It then would remember my decision and add that particular combination of recipients to some list for later reference as to what decision I have made. Next time when sending messages to that same combination of recipients, mutt would automatically either request a reciept or not, depending on my decision once made --- unless I explicitly instruct mutt otherwise when sending a message. Handling the sending of return reciepts when requested by incoming messages could work very much the same. How do I configure mutt to do that? Or is there already support for return reciepts?
Re: Return reciepts
On 1999-11-17 19:59:24 +0100, Jan Houtsma wrote: Well in netscape you have the choice either a confirmation if the mail has been delivered (so thats the MTA) but the other is that the mail actually has been read. In winblows u always get a popup window in that case where u can say yes or no to confirm. Well, yes. In fact, there are two concepts at work here, namely Delivery Status Notifications (DSN, RFC 1894), and Message Disposition Notifications (MDN, RFC 2298). As far as I understand, the former ones are the classical "Return-Receipts", i.e., a notification that a message has been delivered. The latter ones concern the question what the end user has done to a message. One may consider them an invasion of the reader's privacy. Should I wish to confirm that I read a mesage, I can just reply to it. More simply, I think that adding support for generating MDNs to mutt would be totally unnecesary additional code bloat to a program which tries to get bloated anyways. Thus, it won't happen. -- http://www.guug.de/~roessler/
Re: Return reciepts
++ 17/11/99 18:56 +0100 - Thomas Roessler: However, you may just add a small autoresponse function to your ~/.procmailrc. Make sure you make this robust against mail loops! ...by adding a special field to the header by yourself and check for that field whenever the autoresponder is invoked. So, in the matching lines you would something like: * !^X-Loop: [EMAIL PROTECTED] And the in the action lines you have to add | ($FORMAIL -rt -A "X-Loop: [EMAIL PROTECTED]"; along the other fields. This way the mail never can loop as you'll add a special header and incoming mail with that header is clearly looping. For the full recipe see http://www.mediaport.org/~sister/personal/procmailrc -Rejo. -- = Rejo Zenger [Sister Ray Crisiscentrum] [EMAIL PROTECTED] = http://mediaport.org/~sister PGP: see headers
