Re: How to send a return receipt
Hi,
On Wed, Oct 17, 2007 at 07:52:03AM -0600, Charles Cazabon wrote:
> > Being able to say, "Mutt can do that, if you write a script to do it,
> > and write a macro to invoke the script and..." does not constitute
> > support for a feature in Mutt.
>
> Not sure why not. The particular script or hook in question is trivially
> simple -- it's not like it requires writing hundreds of lines of code or
> anything like that.
You find it trivially simple? It seems so on the first sight, but actually a
true implementation (one that actually is reliable) takes more then just "grep
Return-Receipt-To foo && MAILTO="grep Return-Receipt-To foo|awk '{print $2}'
mutt ...". You have to grep consider different cases, trap errors, make sure
that every prerequisites are met, enable the user to configure this one to his
wishes, ask the user if he wants to send the receipt (in a sane way).
After all its not too hard to achieve all this, but its wasted effort, as with
a lot of care you cannot guarantee that this will run in a few days, weeks or
months because admin could decide to remove just one of the tools you need to
achieve what you need. Remember: Not every user of mutt is the admin of the
machine.
> Unix users commonly automate various tasks with a few lines of shellscript,
> and they don't complain that the task is therefore "not supported by my
> OS/shell". I would say this situation is analogous.
No it isn't. Usually one automates rather complex processes, while we are
talking about a pretty simple function if integrated into mutt, but a
rather complex if you need to establish the functionality standalone. It is
like removing 'ls' from a shell and saying: You could write your own ls,
because thats possible and a shell really should not implement a ls command on
its own. And don't tell me that implementing return receipts adds so much bloat
to exim. The whole patch (with smtp support added by David Champion) is a 35K
big diff file that eventually adds about 10k of code to mutt. Given that mutt
source code is about 12M thats really _nothing_.
> it *doesn't* have additional hundreds of little-used "features" to cause
You keep claiming that it is "little-used" but thats just not true. It is
wideley supported, wideley used and commonly expected. So all your arguments
that
are based on this wrong premises actually are _wrong_.
> As a related example, I'm still disappointed SMTP support got added.
Well, feel free to not compile it with SMTP support, then. Thats far easier
then maintaining a patch outside of upstream for years. YOU are disappointed
about it, while I am quiet happy about this, because I don't like the idea to
configure a bloated MTA on every system (including laptops and workstations)
for no added benefit.
Regards,
Patrick