Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Mon 22.Oct'07 at 15:37:45 +0200 -=
> 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.
Well, ... your viewpoint is limited to your single specific case.
Taking into consideration that your request is only one among many
makes it a strategical decision how to handle all of them.
Broaden your view.
> > 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.
Ok, "default functionality". Can you accept that even though it
doesn't support it out of the hardcode box, the functionality can be
_added_ by mutt means with the help of basic unix tools?
> 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.
*sigh*
That's a matter of perspective.
The solution given to you is exactly that: use of muttrc commands.
> > 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.
You exaggerate: significantly < 100, and IIRC it was only you and
Derek.
It stands to define what "support a feature" means with a highly
flexible tool like mutt. You (and Derek) seem to take it differently
than several others here.
However, I never denied there is a difference in convenience,
although only at the beginning to implement it once, not to use it
everyday once you "source" the finished solution.
> > 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.
Yes, we are, because you want a little bit, while all the other
likewise only want a little bit. Why is your little bit more useful,
wider used, qualifies in any sense more than any of the others?
> 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.
- "every mua used in business", that would be which?
Lotus, OL, TB, what else?
- again, likewise all other wannabe inclusion candidates _could_ be
used, and some more likely, still they are not in.
- if there were no other way, then let it be.
- if it's just convenience ... compare with other candidates.
> > 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.
No, I mean on the sender side, producing them.
> > 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.
The problem with TOFU, HTML and RR (return-receipts) is not solved
for me when _I_ stop using it! The problem exists because others
sending to me find it's easy to produce it and don't give a ...
about what I think about it (before I can tell them, but worse even
thereafter).
When it's easy to get by, it becomes a quasi standard, and I can't
do anything about it. So I have to step in early before it becomes a
standard, by not making it too easy, so only those really needing it
diehard would implement it for themselves.
> > 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.
Exactly, but this we don't know yet, since they haven't declared
their policy officially so far.
> > 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.
I'm not denying the functionality, I even gave you a solution, since
you have good reason.
I'm only denying to make it too easy for everybody else out there.
> 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.
See above: the solution does exactly that: use of existing muttrc
commands.
> > 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.
You can specify basic unix commands for mutt's interface to the
operating system (external helpers), what's wrong with that?
> > 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.
Ehm, *beep* sorry, rtfm before you use a tool or feature you
"source". If you fail, your fault.
I assume you _know_ what you do when you install such a beast for
yourself.
Quickstart MUAs are better suited then, mutt isn't one of them.
> 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.
If, like you say, this is widely and often used, he'll be confronted
with it all the time, hard to forget then.
> > 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).
Err... have you actually realized what you really need?
All of that can be specified in $editor or $sendmail.
> Which solutions are you speaking off? There is none, that you
> provide. Or if it is, then it is not obvious.
Maybe this explains it then...
I didn't give you the literal final code, I gave you ideas how _you_
could implement it yourself.
> > 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.
Huh, why?
> > 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?
Ouh, ... maybe you're not here long enough ... but mutt changes old
existing features _very slowly and little_ not to worry _this_ would
happen too soon. :)
> Also the solution could be to adapt the patch that someone has
> written to every mutt version.
No.
> 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.
No, once you have your solution (that will never change), publish it
for everybody to use (well documented, of course ;), or have it
included in /contrib.
> > 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.
Heh, "needs" is your subjective opinion.
When it works, it works, you can get used to new ways. It doesn't
require to be identical to other MUAs to be useful.
> > What's your take on SMTP?
> > MUA != MTA, yet it was integrated, you like that?
>
> 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.
Uh, I don't understand this: integration of SMTP actually puts MTA
service into the client (mua, mutt) now?!
> But more then this I think its rather important that you are able
> to let different MTAs handle different accounts
You can do that already with help of $sendmail.
> 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.
Ouh ... I guess you're missing some power of mutt here in
combination with LightSMTPagents. Have a look on the wiki about
ideas: macros, hooks specifying $sendmail on demand.
Even with big pre-installed MTAs you can specify alternative config
files to route your mail as needed different from the default route.
> I know you don't see that. Unfortunately it seems as if you were
> blind to anything that is not *your* opinion.
No, I'm not blind, I'm just giving you opposition where you didn't
expect it, because your view is limited.
--
© 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.