> What you want is an invasion of privacy of every reader. It is not of your > concern if and when a user reads your mail. Such a feature should never be > part of mutt. Besides if you are sending a mail to more than one recipient > or an alias, you will get a notification from every recipient.
You're talking about MDN requests. The OP is asking for MDN reply support. While I agree that there's a privacy exposure in MDN arrangements, it's only an invasion if it's not wanted. If the OP wants to send MDN replies, he's volunteering his own privacy, and then what business is that of anyone else's? In privacy terms, the only thing you gain by disallowing this capability in mutt is the freedom to tell potential MDN requestors "I can't" instead of "I won't". That's easier, but it makes mutt look bad. If your business environment requires MDN replies, then the upshot is that mutt is regarded as unacceptable in the business environment. Nobody wins. Your post brings up an interesting point, though. It's true that you can loosely or fully implement MDN with mutt as it stands, depending on how much work you put into your scripts, macros, and hooks. (That's even true of almost any automation feature currently built into mutt.) But a policy that MDN should not be implemented in mutt per se because of privacy concerns constitutes an acknowledgement that scripts, macros, and hooks are insufficient for certain legitimate interests. If there's a privacy concern, then mutt doesn't support MDN. You can't get both. On to the soapbox: Someone mentioned that support for MDN with current mutt is "trivially simple", I think. That depends on how much support you want. It's fairly easy for an intermediate-level user to set something up that sends an MDN reply on a keystroke, without checking for whether MDN has been sent before, whether an error occurs, etc. For meeting the requirements of a business practice, though, that's not enough. I don't think this is very different from PGP support, except perhaps in how many people want the feature. You could set up a macro and script to PGP/MIME sign your mail, but it would grow wearisome if you sign often. If it's a business practice to sign all mail to customers, eventually you'll forget. What are the consequences? You can put in varying amounts of work to get the varying extent of support for MDN that you want (always MDN for sender X, never MDN for Y, ask for everyone else, etc.), but eventually it becomes a chore and a potential liability in certain environments. Eventually the reliability of the business process depends on better integration, and that leads to greater complexity in your add-ons. I would argue that the net entropy of several people maintaining varying degrees of hook/script based support for a feature as potentially complex (for an unbundled add-on) as good MDN support is greater than the entropy of a single point of maintenance. You can use this argument to defend the add-on model (there's no inherent reason that there should be more than one add-on), but with the differences among various user environments, support for all interests can become chaotic even faster than C code added to mutt, where there's a standard infrastructure that's already present everywhere by definition. Portable and full-featured scripts will tend toward chaos faster than bundled code, and that's why there's almost never a single canonical script to accomplish some task. What's really at stake is only who wants to assume the responsibility. I don't care much either way whether the patch goes upstream into the main code base -- that's a matter of what the maintainers feel is in demand enough to maintain, and either "yes" or "no" would be a reasonable decision in this case. (It's worth noting though that while it's the maintainers' responsibility to oversee the project and make feature decisions, they're not alone in providing support for bugs and extensions.) But I think the argument that it's just as good to do it with hooks and scripts is either very naive about what kind of support people would desire, or it's not very well thought out, no matter how many times the expression "unix philosophy" is invoked like a magical charm. All this can be said of any feature proposal, but it's critical to recognize how much the feature actually benefits from deeper integration with the mail environment. MDN does. Mowing my lawn does not. Mowing my lawn should be done by hooks and scripts. MDN depends on how much you want from it. For the most part, this thread has become a game of attrition, where the winner will be the last one to say "is not" or "is so". Changing people's minds requires logic and empathy -- or radiation emitters -- so unless someone's hiding some creepy isotopes I'm not sure we're getting anywhere anymore. This really is up to the level of being a maintainer decision. Most of the people I've seen posting on this thread are mutt-dev readers, but if anyone still reading is not, and wants the patch, it was posted there last week. -- -D. [EMAIL PROTECTED] NSIT University of Chicago "Polka music needs to prevail." John Ziobrowski, Polka America Corporation