Re: How to send a return receipt
> 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. dgc@xxxxxxxxxxxx NSIT University of Chicago
"Polka music needs to prevail." John Ziobrowski, Polka America Corporation