Re: How to send a return receipt
=- David Champion wrote on Wed 17.Oct'07 at 10:42:41 -0500 -=
> If your business environment requires MDN replies, then the upshot
> is that mutt is regarded as unacceptable in the business
> environment. Nobody wins.
Depends on what you want to achieve: do we want mutt to be
acceptable in the business no matter what?
(it's not that I believe this single feature would have a
significant impact on its own ;)
Mutt (as any other MUA) will never suit all, probably not even the
majority of potential users. So who to aim for?
> 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.
Again a simple issue mutated into different directions, all of them
not necessarily closely connected. ;)
> Someone mentioned that support for MDN with current mutt is "trivially
> simple", I think. That depends on how much support you want.
That was I, and yes, I agreed with that elsewhere.
> 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.
Except for error-checking I don't see what is missing.
What error could there be for this case anyway?
> 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.
Certainly, but why is that better?
Let it be bundled then (in /contrib or /samples), with
cross-references to alternatives for alternative needs (if they
exist).
> {...} 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.
So it is when using a mutt-only-features solution.
> 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, ...
Before that comes the question whether to follow demand or lead on.
> ... and either "yes" or "no" would be a reasonable decision in
> this case.
Agree.
> 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, {...}
Hmm, why would the method matter if the exactly same functional
result could be achieved?
Why does it have to be C-code rather than existing mutt features?
If it's mutt, the solution is portable.
> 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.
Right, but please compare it with some "real" equivalents like
listed elsewhere (news, filter, spam, mime): the benefit there would
be much bigger, or not? Based on what?
> 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.
If I didn't provide that, I hope at least it qualifies to produce
such a decision.
--
© 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.