Re: How to send a return receipt
On Sun, Oct 21, 2007 at 05:15:10PM +0200, Rado S wrote:
> Before we (you or I) can judge what is harm- or useful to mutt, we
> both would have to know 1st what mutt is about. I don't know it
> (yet), do you?
I don't think that the term 'harmful' needs an explination in whats
mutt about. Harmful is what affects mutt in any negative way. Thats not about
philosophy, but about technical matters.
> A mailer for "freaks and nerds" == willing to adjust it to personal
> needs rather than relying on (hardcoded) defaults; to use it for all
We are not talking about defaults. So this is pointless. Also adjusting
something to someones personal needs is not implementing the whole feature, it
is about setting some settings, like save-hooks, folder-hooks or whatever.
> mail needs, including business.
So, if you want to use something for business you need to support the basic
subset of funtionality that another mail client (already reliable used in
business environments) supports as well. Nothing more, nothing less.
> Using mutt's power which it already provides before hardcoding
> features (mistaken as "adding", because it is already possible).
Arrgh. After about 100 mails about this topic (and with several _different_
posters describing to you the same thing) you have not understood that mutt
does _not_ have the requested feature.
> probably not the missing "killer feature" which makes them not
> change to mutt so far.
Thats not about converting business users to mutt users. It is about letting
mutt users communicate with business users, sharing a basic subset of
functionality.
> a) You're mistaken, there are requests to include a wide range of
> functionality into mutt that wasn't assumed to be part of mutt, so
We are not talking about this, in _this_ discussion. But even if we would:
Groupware Functionality is not comparable to Returen Receipits. See: While the
first is supported by _every_ mua in the business environment, the latter is
only supported by specialized clients (at least properly). As a groupware
solution is normally a business-wide choice thats okay, while return receipts
are common to the programs used by (almost) _every_ company.
> b) It is important to _you_, undoubtly I believe you, given your
> modus operandi, but still I take it as exception. Even among GUI
No. It is not important to _me_. It is important, because it is wideley used in
business environments and supported by _every_ mua used in business
environments, which makes it potentially used, which makes it important if you
want to communicate with other people having the feature. You can only make
assumptions about how many use return receipts in the real world, so you cannot
use numbers to figure who actually uses is and so you need to rely on the fact
that it is there in every mua and _could_ be used.
> mail users I'm unsure people _willingly_ use that feature because
> they see a gain in their everyday usecase rather than being a preset
> default, not caring enough to change.
Ehh. It is not a default. In _no_ known mail client. It is an opt-in feature.
Always. Even if it could nag you with a message, you must not click "Yes" to
send the message.
> non-automated environment they are rather annoying (to me, much like
We are not talking about TOFU posting, so this is pointless. But if you feel
annoyed by return receipts then don't use them. The good thing about this
feature is, that you can choose on a case-by-case basis _or_ disable it at all.
I cannot disable people, that are writing TOFU, to get back to your example.
> It's not that I don't want it to, but because users' demands are too
> different to be satisfied all by a single tool.
Right. But if you can't support *everything* you should support the smallest
supported subset + the things _you_ (as developer) want to support.
> are many piners out there. They're not using pine because of missing
> return-receipt support in mutt. Pine, for example, includes news
It is not of any interest why people use pine over mutt, or thunderbird or
outlook.
> As long as mutt doesn't offer that, people using those tools for
> exactly those features won't switch to mutt until mutt does so, too.
Then let them. They have the free choice, but in _this_ case you decide for
them that mutt isn't the mua of their cause, because you are denying to add
support for a feature that is shared among all other mua arround.
> Heh, wrong, I have the same intention to provide required
> functionality (like your return-receipts automation), but I see them
> already achieved while you don't like the way of doing it.
It isn't that I don't like the way of doing it. It is _not_ supported.
I have to built it from ground up my self. Thats different compared to every
other feature in mutt. E.g. save-hooks: I don't need to implement the logic for
save-hooks to work, but only appropriate configuration for them.
> Huh, what does "completely separate config" mean when you use muttrc
> settings + commands?
I can't. Except a macro nothing of this is integrated into mutt, so I rely on
an external script that is totally independant from mutt and can't be
configured through mutts configuration.
> What's the purpose of asking him?
> To give him a choice.
Right.
> When the user sees such a msg marked, he _knows_ which choice he
> has, he doesn't need to be asked, he can act on his own based on the
> knowledge.
You are wrong. He does not neccessarily know which choice he has, because it is
not obvious. In fact he needs to remember that a specific header asks him for a
return receipts. If he doesn't know or if he forgets.. shit happened. It will
happen often, so a process that has been error _proved_ until yet, will be
error prone.
> But you can enhance the nagging if this isn't sufficient
I don't see a way for this.
> That can happen with hardcode, too.
No, it can't. Because there is already a framework dealing with such problems.
> Well, you have to rely on _some_ standard unix backround tools.
Right.
> Or you want to integrate all the external helpers?
Off course not. But: The script to handle return receipts is _not_ a standard
unix background tool, but relies on some of them + additional tools that are
not necessarily there on the system (or could be removed in the future).
> I don't know what you're speaking of.
> Our "external" solutions provide notifications of different levels
Which solutions are you speaking off? There is none, that you provide.
Or if it is, then it is not obvious.
> versions (works even with pre-1.4) and doesn't need any maintenance,
> but if, then doesn't require C-coder skills.
You are moving the reponsibility about any maintenance from the developers to
the users in this case.
> Uh, once you have it working, there is no maintenance needed
> anymore. What do you expect to change?
Sure? What if something changes in the interface between mutt and the external
solution? Also the solution could be to adapt the patch that someone has
written to every mutt version. That needs a lot of maintenance. Every new
version the patch will break. And it does need to be solved by some hundreds of
users instead of a few developers.
> That's the question to which I have no answer yet. :)
Too bad.
> Maintenance is a non-issue, since it won't change.
False. This cannot be forseen.
> Convenience is a non-issue, since once it works as needed, it will
False. Because it isn't possible to achieve it like it needs to be w/o
implementing changes to the mutt code.
> [...]
> something about some unrelated features
> [...]
I made the mistake replying to this stuff. But it is totally unrelated to the
problem we are discussing.
> What's your take on SMTP?
> MUA != MTA, yet it was integrated, you like that?
It is unrelated to the problem we are discussing, but you are asking about my
statement: Yes, i'm happy with the fact, that SMTP has been integrated into
mutt. Why? Because an MTA is a service and as such its destination is to be
operated on a server and not on a client. But more then this I think its rather
important that you are able to let different MTAs handle different accounts
(because gmx.de is not your domain and it would better the (spam-)situation
if only the mail exchanger at say mx.gmx.[de|net|org|...] would be able to
write mail from
@gmx.de). It is impossible with the most simple MTA replacements and a big
postfix or big exim in its whole complexity has not much to search on a client.
> I don't see why a soft-coded solution is less reliable, lesser than
> any of the other soft-coded (external) solutions.
I know you don't see that. Unfortunately it seems as if you were blind
to anything that is not *your* opinion.
Regards,
Patrick