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 :)
