Howto run a command in message hooks (was: Re: How to send a return receipt)
Hi, as it does not seem to be integrated into mutt upstream (at least not in a forseeable timeline) I'm currently trying to figure who a scripted solution to my problem would look like. On Tue, Oct 23, 2007 at 06:14:48PM +0200, Rado S wrote: It appears complex to you, but in fact it _is_ simple. If thats true, then the problem I am currently stuck on should be fairly simple to solve. So some explanations, then my question: I want to write a script that _asks_ the user, if he wants to send a return receipt (note how that differs from your assumption that a macro would be suffice. For me it wouldn't because w/o the question _I_ would forget to send the return receipt). Something like this can automatically be triggered only by message hooks. But as the solution is extern (= a script), how do i call it from within the message hook? I added a hook like this: message-hook ~h Return-Receipt-To: |/home/schoenfeld/.mutt/return_receipt And even though the specified file is a valid executable script mutt says (when I open this mail in the pager): |/home/schoenfeld/.mutt/return_receipt: Unknown command Why? According to what I read this works for macros, why shouldn't it work for message hooks? Regards Patrick
Re: Howto run a command in message hooks (was: Re: How to send a return receipt)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Patrick Schoenfeld [EMAIL PROTECTED] [10-24-07 10:42]: I want to write a script that _asks_ the user, if he wants to send a return receipt (note how that differs from your assumption that a macro would be suffice. For me it wouldn't because w/o the question _I_ would forget to send the return receipt). Something like this can automatically be triggered only by message hooks. But as the solution is extern (= a script), how do i call it from within the message hook? I added a hook like this: message-hook ~h Return-Receipt-To: |/home/schoenfeld/.mutt/return_receipt And even though the specified file is a valid executable script mutt says (when I open this mail in the pager): |/home/schoenfeld/.mutt/return_receipt: Unknown command first *guess* w/b that ~/.mutt/return_receipt script was not executable, but you have really presented little information. - -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn4472 (GNU/Linux) iD8DBQFHH1sdClSjbQz1U5oRAoShAJ0RkvztBrLo1jW8fqfKCWtR1EgaaQCgpm9x 7rhYW+Z8Cfdy2Tku3GQovZU= =uIe1 -END PGP SIGNATURE-
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Mon 22.Oct'07 at 20:45:53 +0200 -=
HTML mails, hmm. Bad thing. I don't like, nor do I write them
myself, but receiving them (because some suppliers think they
don't have to follow my wish if I ask them to not do so) is very
uncomfortable in mutt. But its just that. Whereas I repeatedly
explained why an external application does not work for return
receipts. It does not very good for HTML mails, but it at least
_does_.
You make a difference, we don't: for us it has the same annoyance
level as well as functional solution for those needing it
desperately nevertheless (and sufficiently convenient once it works).
{...}
But if it is featured by _every_ mail client in business
environments then it should probably be supported.
{...}
BTW. this whole discussion again does not have anything to do,
with what this all is about.
You're mistaken, because for us it has.
You want a more convenient solution for what is already possible as
it is now. The same is for all the other given examples: they
_could_ be more convenient, but need not be for either there are
better external tools for it (news, mailcap conversion, ...) or some
muttrc construct works well enough.
Not all that is popular in numbers in business means good in general
to make it convenient to use with mutt, see TOFU (which is range in
the same level as return-receipt for me: exceptionally necessary,
but not generally desired, same with HTML).
--
© 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.
Re: How to send a return receipt
=- Derek Martin wrote on Mon 22.Oct'07 at 11:46:26 -0400 -= But still, I want my mailer to do everything related to the normal processing of mail, mostly without any fuss from me. I should only have to make a fuss if what I want to do is unusual -- which this isn't. a) how to determine usual factor? b) not everything that is usual is desirable (but even annoying). c) the fuss is ... required for mostly anything advanced that you want to do, because very little (i.e. basic functionality) works with defaults, and even that not in all environments. If it does, then you happen to be lucky to have admins who prepared everything well enough. This then leads to: what is basic, what is advanced? What should work out of the box and what will/ should always require tweaking? -- © 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.
Re: How to send a return receipt
=- Derek Martin wrote on Wed 17.Oct'07 at 10:58:52 -0400 -= On Wed, Oct 17, 2007 at 07:52:03AM -0600, Charles Cazabon wrote: Actually, one of the things that makes mutt suck less than other MUAs is that it *doesn't* have additional hundreds of little-used features to cause bloat, bugs, user confusion, and UI complication for no real added benefit. Actually I think this is a fine example of why that argument is total nonsense. Since SMTP support has been added, in what measurable way has it caused Mutt to suck more? Is the memory footprint *substantially* larger? Has it caused mutt to become noticably slower? Note, Charles wrote about hundreds of little-used features, while you counter with a single example. Add up all the hundreds little-used features waiting to be included, then tell again. Nobody denies that any _single_ such feature means little impact, but why add this SMTP or return-receipt and not all the other little goodies? Convenience applies for all equally. -- © 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.
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Wed 17.Oct'07 at 16:48:24 +0200 -= 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. Yes, but I think you're too paranoid or haven't noticed the required tools for such a solution: they are _basic_ unix tools like ls, which no sane admin would consider removing. If your admin is not sane, then you have bigger problems than this. Usually one automates rather complex processes, while we are talking about a pretty simple function ... Your assumption is wrong: automation is not a matter of size but of repetition. Especially simple stuff can be quickly implemented easily without having to hardcode. ... if integrated into mutt, but a rather complex if you need to establish the functionality standalone. It appears complex to you, but in fact it _is_ simple. 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. Nobody is removing anything, actually you're being given something that didn't exist before: ls2. 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_. Little used, wildly used, no side can prove its point by numbers. We only have gut feelings about our personal experience. So this can't ever be a valid argument, for either side. 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. No patching would ever be needed if you accepted that SMTP functionality doesn't belong to mutt and is _safely_ handled by whatever you specify in $sendmail. 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. It has no benefit for _you_! :) Anyway, you don't need to use bloated MTAs, you can use http://WIKI.mutt.org/?LightSMTPagents -- © 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.
Re: How to send a return receipt
=- Derek Martin wrote on Wed 17.Oct'07 at 7:33:46 -0400 -=
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. Mutt should implement
features that are commonly implemented in other mailers so that
users of Mutt can interoperate with people who don't use Mutt,
which is by far the majority of mail users.
Hmm, why should mutt aim for the masses rather than the quality?
Mutt's claim is that it sucks less than all other mailers, which was
once true; but IMO with each new feature that other mailers implement
that Mutt does not, this becomes less and less the case, and I'm not
sure if that is still true anymore.
I say it depends on what those features are.
Not all that is popular demand is desirable to make it a habit for all.
{...} I think the ONLY reason I still use mutt is because I do
most of my personal mail reading remotely, and Mutt still DOES
suck less than the rest of TEXT-BASED mailers... But I wonder if
it isn't only a matter of time before even that isn't true
anymore.
Maybe you're expecting too much from mutt, as much as I am in the
other direction.
--
© 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.
Re: How to send a return receipt
=- Derek Martin wrote on Tue 16.Oct'07 at 18:32:00 -0400 -= If your pet feature is minimal code, but the developers don't want to include it because what you're asking is already possible another way -- just maintain a local patch for it. So have I, and it sucks. I agree, in general. But for this specific case, no code patch is even required, it works with the current code. -- © 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.
Re: How to send a return receipt
=- Derek Martin wrote on Tue 16.Oct'07 at 17:39:49 -0400 -=
If a function is e-mail related, and commonly supported by other
mailers, then it seems to me Mutt should have built-in support for
it too. Mutt is a Mail USER Agent (not a mail DEVELOPER agent),
and it should interoperate with other mailers, and should do
everything that users commonly want to do with mail without a lot
of fuss.
Including spam management, sorting/ filtering, mime handling, ...?
News is so similar to mail, and all the other mailers do that, too,
why not mutt? It's not mail-related enough for you? But it's sooo
close...
You mistake configurability and the need to do so with the users
having to be somehow special. If a little rtfm disqualifies users
for mutt ... that's sad, but they shouldn't use mutt then, and mutt
shouldn't change to become a product for a mindless mass, that's
what OL is for. ;)
The only things that should require fuss are things that are not
commonly wanted by common mail users. And don't forget that just
because YOU don't find any value in a feature, that doesn't mean
it's not a feature that common users want...
Common here, value there, no proof anywhere.
{...}
especially if you have to deploy 1000 Unix workstations that don't
come with any of the helper programs you need to make your
application work in your environment (and most especially if they
need different configurations, preventing one from easily
creating, say, a tarball with all the required software).
The same can happen with hardcode: it sucks when you have no ssl,
curses or other libs installed. Want that all built-in?
--
© 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.
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_
Re: How to send a return receipt
On Tue, Oct 23, 2007 at 06:14:48PM +0200, Rado S wrote: Yes, but I think you're too paranoid or haven't noticed the required tools for such a solution: they are _basic_ unix tools like ls, which I don't know who you process headers with basic unix tools, but I don't care. Because i face the fact that it is _impossible_ to convince you. You exepect us to prove that the feature request is valid, but you don't prove what you use to tell that we are wrong. You ignore arguments being said, but you always repeat the nonsense that it is just a matter of configuration, what it isn't. You are not even possible to tell how it is configurable, without reinventing the wheel (by recoding whats already implemented in mutt), but you keep teelling this. So all you've done until now is: Saying that _you_ don't like the feature and that it it will not be included for this reason. Thats all. You did not really argue, but you are in an authoritive position, so this discussion could be endless or one of us could give up. A consense is impossible to reach. And its impossible that you would give up. So I do it. EOT from me. Regards, Patrick
Re: How to send a return receipt
=- Derek Martin wrote on Sun 21.Oct'07 at 20:55:07 -0400 -=
{...} with its major goal being to suck less than the other mail
clients. It says the latter explicitly on its home page. Inasmuch
as it does not implement standard features offered by other
clients, it is a failure in that goal.
Uhm ... not all that is widely supported is good.
PLEASE NOTE: a power user of e-mail is not necessarily a power
user of *anything else*.
Aye, agree, but then ... mutt is not for the faint of heart
either. :)
If a not hardcoded solution is offered ready to source, let them
have it.
... as stated elsewhere: adding up has more of an effect than
just the sum of its parts.
This is not a reason not to do something.
Right, that's why I gave solutions.
And this total effect can be bad despite all the partial good
effects.
This also is not a reason not to do something... It is, however, a
good reason not to do something badly. Integrating support for
this feature into Mutt is, from the user's standpoint,
unquestionably the better way than relying on hacks which are not
well-implemented or poorly integrated into Mutt.
Remeber the mh solution?
Actually, if mutt were a complete CORBA constructable tool, I'd be
happy with it letting everybody construct it's components as
desired, all hardcoded if you prefer.
That is, if CORBA were anywhere practicable or in wide use.
That's not the point at all. The point is that the feature being
missing in Mutt is forcing some people who use Mutt in business,
and want to continue to do so, to move to something else, because
the features they NEED -- features supported by virtually every
other mailer in the known universe -- are missing from Mutt.
Ok, they _are_ missing, until somebody implements my (and other
mutters') suggestions.
Some of those users might be willing and able to implement the
needed functionality themselves... But you would (obviously) be
surprised by the number of people who use Mutt who can not or
don't want to.
Can not: why? Once the solution is published, simply source.
Want not: tough luck for them, no loss when they switch.
They exist so that the receiver can say, I know you saw my
e-mail, I have the return receipt. It's about accountability...
it's the same reason the post office offers registered/certified
mail. Mail (both kinds) is inherently unreliable -- you send off
your e-mail, and you have no way to know if the recipient actually
received it... unless they're using some return receipt feature.
Then, the recipient can not say, hey, I never received your
mail. The sender has proof that he did.
... if this were about legal cases, easy forging such
return-receipts makes it vulnerable, you'd need more for that.
But then DSN and server logfiles do the same service.
MUTT DOES NOT HAVE RETURN RECEIPT SUPPORT. Mutt has support for
letting the user customize and extend mutt in a variety of ways. This
is very much NOT the same thing as having return receipt support.
Has mutt complete ssl and curses support? Is relying on external
binary libs any better than relying on external unix tools?
It means it's already there, waiting for the user to use it. If it
requires the user to code logic (as opposed to simply turning on
settings), then it is not supported.
source path-to/contrib/rr.mutt
done
That's how it works with pgp, too.
On an individual (per-solution) basis, it needs roughly as much
maintenance as it would need if it were implemented in Mutt directly;
Right, so this no reason to switch to hardcode.
But, your method will not require just 2 or 3 developers to
maintain it... instead it will require hundreds or perhaps
thousands of users to maintain it individually.
Uh, when you have to upgrade the mutt binary for RR, this isn't
anything less of a burden than to adjust a little source'ed script
included in /contrib.
This discussion is not about those features. It's about return
receipts. Decisions about whether to add a feature can only
logically be made on a case-by-case basis.
Discussions about drawing lines are pointless and fruitless. From
the standpoint of the user, none of your arguments against
allowing this feature to be added to mutt are compelling.
By this line all other features should be included, too.
Definitely a no-go.
Once you look at every individual case isolatedly, mutt will
eventually become a cross-breed clone of all the other bulky
software out there: Lotus, OL, TB, Pine all in one.
You haven't come up with a single technical or logical reason
besides this why Mutt shouldn't have this feature.
You've nailed it: there is more to coding than just code.
It appears that the only valid concern you have is that you simply
don't like the feature. But this is not a defensible reason for
denying the feature from the portion of the user community who
NEED it.
I don't like it: true.
I deny it for those needing: false.
I deny it being hardcoded: true.
Just because stuff
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Tue 23.Oct'07 at 20:28:41 +0200 -= Because i face the fact that it is _impossible_ to convince you. You exepect us to prove that the feature request is valid, No, I see your point, you don't have to convince me nor prove anything. I'm absolutely clear about your position, and that is nothing more or less than I have: an opinion, a preference. It's just different from yours. You've given reasons why the rulers should do it your way, I have given mine for my. I hope they'll choose mine, I fear your chances are better though (argumentatively judging from the past), but most probably nothing will happen too soon either way. but you don't prove what you use to tell that we are wrong. You are not wrong with your opinion, it is valid and alright. Just not for me and other mutters. If you mean the final implementation with what you use, then you're right, I haven't so far, because I left it to the do-it-yourself guys to try. You are not even possible to tell how it is configurable, without reinventing the wheel (by recoding whats already implemented in mutt), but you keep teelling this. It's not needed to reinvent the wheel, because it doesn't have to work as you are used to it, as long as it works. So all you've done until now is: Saying that _you_ don't like the feature and that it it will not be included for this reason. No. You did not really argue, but you are in an authoritive position, so this discussion could be endless or one of us could give up. Well, I gave you my reasons, just they don't mean much to you, because you pay more attention to other aspect than I do. A consense is impossible to reach. And its impossible that you would give up. So I do it. EOT from me. No need to give up. Accepting to disagree is a valid result. -- © 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.
Re: How to send a return receipt
On Sun, Oct 21, 2007 at 08:55:07PM -0400, Derek Martin wrote: Just because you know when somebody has seen a mail 1st time, it doesn't mean it will be processed faster thereafter. This is not why return receipts exist. They exist so that the receiver can say, I know you saw my e-mail, I have the return receipt. It's about accountability... it's the same Then you don’t want a delivery notfication, you want read-it notification. That is in my eyes a very big difference. A delivery notification will send you the information when the MTA has put the mail into the mbox of the recipient (no matter, if the recipient will sent your mail to /dev/null or read it). reason the post office offers registered/certified mail. Mail (both This is a delivery notification. You don’t know, if the recipient has read the letter or through it away. The MUA is the wrong place for a delivery notification. The notification will always be sent a certain time later (sometimes less, more often much later). Mutt does not have return receipt support. Let me emphasize that: Yes, in my eyes this is good. Like always if certain features for surveillance or monitoring are available, people want to use it. So it is far better to not implement them. And in business environments you will probably get in far more trouble with mutt besides missing the notification options. Mutt doesn’t support any groupware features like calendar. Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
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
Re: How to send a return receipt
On Mon, Oct 22, 2007 at 03:37:45PM +0200, Patrick Schoenfeld wrote: 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 Say, like HTML mails, vCards, vacation messages, address books? Nothing of this sort is supported by mutt but relies on external programs. Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: How to send a return receipt
Am 2007-10-11 11:28:46, schrieb David Champion: This is correct. Mutt doesn't internally support MDNs. A patch has been posted by Werner Koch, but it might not be current. Check the mutt-dev archives. Does this only mean, sending of MDN's or receiving? I use mutt from Debian and sometimes it ask me whethere I want to send the confimation back... Thanks, Greetings and nice Day Michelle Konzack Tamay Dogan Network -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: How to send a return receipt
On Mon, Oct 22, 2007 at 11:46:26AM -0400, Derek Martin wrote: Yes, in my eyes this is good. Like always if certain features for surveillance or monitoring are available, people want to use it. So it is far better to not implement them. You did know that Mutt is one of the most configurable mail clients in existence, and lets you turn off features you don't want to use, didn't you? I know this. But if your boss asks you, if your client can do MDNs and if yes, you must activate it, it is far easier to say, no, it can not do this. I have used Mutt in every business environment I've worked in for the I am using Mutt in my business environment, too. But we don’t do things like MDNs (sending or answering). We don’t send HTML mails, too. Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: How to send a return receipt
On Mon, Oct 22, 2007 at 06:20:41PM +0200, Stephan Seitz wrote: I know this. But if your boss asks you, if your client can do MDNs and if yes, you must activate it, it is far easier to say, no, it can not do this. If your boss is going to ask you that question, then the next thing out of is mouth is going to be Use Outlook. This is not a valid concern. Just compile it without support and truthfully say no.' And then wait for the punch line... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpC1oHS5KrPh.pgp Description: PGP signature
Re: How to send a return receipt
On Mon, Oct 22, 2007 at 06:20:41PM +0200, Stephan Seitz wrote: I know this. But if your boss asks you, if your client can do MDNs and if yes, you must activate it, it is far easier to say, no, it can not do this. I don't believe that a boss that *asks* weither your MUA supports something that *he* finds worth using is typical. Most of them (bosses) will either force you to use a specific application or force you to use an application that supports what *he* wants to use. I am using Mutt in my business environment, too. But we don’t do things like MDNs (sending or answering). We don’t send HTML mails, too. Fine for you. But this isn't about what you don't do, but about what others do. You know that not everybody has the same needs and so this I don't use argument is more then invalid. Regards, Patrick
Re: How to send a return receipt
On Mon, Oct 22, 2007 at 04:39:55PM +0200, Stephan Seitz wrote: Say, like HTML mails, vCards, vacation messages, address books? Nothing of this sort is supported by mutt but relies on external programs. HTML mails, hmm. Bad thing. I don't like, nor do I write them myself, but receiving them (because some suppliers think they don't have to follow my wish if I ask them to not do so) is very uncomfortable in mutt. But its just that. Whereas I repeatedly explained why an external application does not work for return receipts. It does not very good for HTML mails, but it at least _does_. I don't know what you mean by vCards, because I never got one. But if it is featured by _every_ mail client in business environments then it should probably be supported. Vacation Messages are common and comfortable to be used on MDA or even MTA-level so i don't care for them (even in the Microsoft world it seems to be common to implement vacation messages there). And mutt features an addressbook in form of aliases. BTW. this whole discussion again does not have anything to do, with what this all is about. -Patrick
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Thu 18.Oct'07 at 20:52:22 +0200 -=
Depends on what you want to achieve: do we want mutt to be
acceptable in the business no matter what?
if we were talking about anything thats very harmful to mutt in
general I would say: No.
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?
But we are talking about a mini feature, thats quiet useful in
business, so in this single case: Yes.
... as stated elsewhere: adding up has more of an effect than just
the sum of its parts. And this total effect can be bad despite all
the partial good effects. Again, before judging this correctly, we'd
1st have to know mutt's nature/principle to relate good or bad.
Where it's useful doesn't matter much then, since mutt is not
limited in use.
(it's not that I believe this single feature would have a
significant impact on its own ;)
Well, what do you consider mutt to be? A mailer for some freaks
and nerds that just communicate with each other, or a solution for
communicating via email, what includes business needs.
A mailer for freaks and nerds == willing to adjust it to personal
needs rather than relying on (hardcoded) defaults; to use it for all
mail needs, including business.
Using mutt's power which it already provides before hardcoding
features (mistaken as adding, because it is already possible).
But regarding my comment whether or not this particular
return-receipt feature is hardcoded or not, it won't make many
business mail users change to mutt, because (my guess) that's
probably not the missing killer feature which makes them not
change to mutt so far.
Off course it is a mailer and not a PIM or something, so one would
never expect mutt to support groupware functionalites but in this
case we are talking about a quiet important just mail-related
function.
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
not to need to become a freak or nerd to make the separate tools
play nicely together to achieve a given goal, but to turn it into
the single communications killer-application that does all they
want/ need at one place.
b) It is important to _you_, undoubtly I believe you, given your
modus operandi, but still I take it as exception. Even among GUI
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.
Just because you know when somebody has seen a mail 1st time, it
doesn't mean it will be processed faster thereafter. In a
non-automated environment they are rather annoying (to me, much like
TOFU posting, which also is well established in the business world,
mostly because of lazyness to edit properly, because there only the
sender's time/ desire count's, not the receivers).
Mutt (as any other MUA) will never suit all, probably not even
the majority of potential users. So who to aim for?
Why? It is a mail program. Why shouldn't it support a majority of
potential users? {...} but at least every console-affine user
should be able to communicate with a gui-using-mua-user without
significant impact in functionaly.
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.
mutt communicates with GUI mailers alright already (and can be
expanded to do what is still missing without hardcode), still there
are many piners out there. They're not using pine because of missing
return-receipt support in mutt. Pine, for example, includes news
support and a GUI-like menu oriented TUI. TB has built-in filter/
sort features. Seamonkey + OL have integrated HTML support.
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.
Well, thats my opinion. As far as it seems, its not yours. Thats
sad, but it is as it is.
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.
Except for error-checking I don't see what is missing.
Well, its all about integration into mutt. You need a completely
seperate configuration, ...
Huh, what does completely separate config mean when you use muttrc
settings + commands?
... you can't ask the user properly if he wants to send a mdn, etc.
What's the purpose of asking him?
To give him a choice.
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.
But you can enhance the nagging if this isn't sufficient
for you.
What error could there be for this case anyway?
I could imagine a lot of things that could go wrong, when using an
external script for MDN. To name a few: Problems with
Re: How to send a return receipt
Hi, On Wed, Oct 17, 2007 at 10:30:07PM +0200, Rado S wrote: Depends on what you want to achieve: do we want mutt to be acceptable in the business no matter what? if we were talking about anything thats very harmful to mutt in general I would say: No. But we are talking about a mini feature, thats quiet useful in business, so in this single case: Yes. (it's not that I believe this single feature would have a significant impact on its own ;) Well, what do you consider mutt to be? A mailer for some freaks and nerds that just communicate with each other, or a solution for communicating via email, what includes business needs. Off course it is a mailer and not a PIM or something, so one would never expect mutt to support groupware functionalites but in this case we are talking about a quiet important just mail-related function. Mutt (as any other MUA) will never suit all, probably not even the majority of potential users. So who to aim for? Why? It is a mail program. Why shouldn't it support a majority of potential users? Okay, lets not say a majority of users, because that would mean mutt would need a graphical gui and be fully integrated into desktop environments, but at least every console-affine user should be able to communicate with a gui-using-mua-user without significant impact in functionaly. Well, thats my opinion. As far as it seems, its not yours. Thats sad, but it is as it is. Again a simple issue mutated into different directions, all of them not necessarily closely connected. ;) You are right. But thats the cause of people argumentating in a way, thats far from reality. I'm sorry, but those arguments came mainly from the opposites of this feature-request. Except for error-checking I don't see what is missing. Well, its all about integration into mutt. You need a completely seperate configuration, you can't ask the user properly if he wants to send a mdn, etc. What error could there be for this case anyway? I could imagine a lot of things that could go wrong, when using an external script for MDN. To name a few: Problems with the mail headers, missing or errornous utils outside of mutt that are needed etc. All in all its neccesary to rebuilt a common framework inside of a script again, which is already a part of mutt. Causing duplication and possibly reintroducing problems that were already solved in mutt. Certainly, but why is that better? Because the external solution will always hink after mutt, the maintainance needs are a lot higher, as a one-time integration into mutt source (because further changes are just streamlined into the normal development process), etc. It is simple: Offcourse it is possible, but there are a lot more cons about implementing it outside of mutt, then pros to keep it out of mutt. Let it be bundled then (in /contrib or /samples), with cross-references to alternatives for alternative needs (if they exist). That makes it easier to get it, but not to maintain it. So it is when using a mutt-only-features solution. That actually speaks for an integration into mutt, because what you suggest, is _not_ a mutt-only-features solution. Before that comes the question whether to follow demand or lead on. In practice the best is a compromise between the one and the other. In the end the mutt developers decide, but they don't develop for themselves, right? If there is a demand and its possible without a big effort, what really speaks against integrating it? Hmm, why would the method matter if the exactly same functional result could be achieved? See above. You shouldn't ignore the arguments that were told, then you would know that. Why does it have to be C-code rather than existing mutt features? If it's mutt, the solution is portable. Again. 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? You are comparing apples and bananas anyway. Reading news is not the job of a MUA (and there are clients doing that better), filters are already part of mutt through save-hooks etc., spam solutions is not directly related to what a mail _client_ should do and mutt already has good interfaces to it. So there is mime left over: What exactly do you expect from mutt to do in this direction? If I didn't provide that, I hope at least it qualifies to produce such a decision. Is your talking representative to all people activeley involved into mutt development? If so, then this dicussion has no sense to continue. But thats sad, because I can't see a single valid argument for double effort for a less reliable solution brought in this thread. :( Regards, Patrick
Re: How to send a return receipt
=- Jing Xue wrote on Wed 17.Oct'07 at 22:38:05 -0400 -=
Because coders are supposed to code solutions into a tool, not
to code their ideology into it.
Why is that so?
It's not like you're forced such a ideology-loaded tool or are
entitled to use the work of somebody else against his will, or
are you? ;)
Don't like it as it is? Do it yourself.
//sigh, why is it that at the end of every one of these debates,
there is always this boiler plate answer that awaits?
Maybe because it's a fundamental position diametrically opposed to
its rival, and it expresses best where the difference in
expectations and commitment are?! ;)
There is more to tools than just producing them.
I thought OSS was about the freedom of choice, and about letting
(not forcing) more and more people realize that they do have more
choices.
Whatever OSS is about, I don't feel limited to OSS nor what
individual personal opinions like Linus' say; it's just that, their
personal opinion. Some happen to be more widespread than others, but
as stated elsewhere, mass and instant/built-in usage is not enough
justification, or why don't we all use M$ for everything?
I never thought of OSS as a path to the elitism of I can do it
myself, and you can't, {...}
Not by intention, but by consequence of commitment, which happens to
be rather the exception than the norm.
If everybody suddenly switched to use mutt and OL were the rare
crowd, I guess none of the elitists would switch just to remain
the minority.
Do you really rewrite every piece of software you find not up to
your expectations, yet you cannot convince the developer to change
it because the developer does not agree with you philosophically?
No need to rewrite, but I patch things and offer them.
(when the little skill and opportunities that I have permit ;)
This is _not_ about the attitude of the user's, but that of the
developer's.
It's about both, because there is no strict border-line.
Every dev is a user, every user can become a dev, and patchers like
me (or rather doing more than I) live on that line all the time.
Everyone can, must and does make choices, be they conscious or not,
short-sighted or long, global or local.
There are obviously drawbacks for either imposing or refraining from
it, again a matter of preference of potentially resulting consequences.
How can you call it a matter of preference, when the very choice
of this preference itself may conflict with the fundamental
value behind the ideology?
Because they operate on different levels.
It's like intolerance against intolerance. Paradox? On 1st look,
but not senseless. By your reasoning nobody should stand up against
intolerance, but is this what you want? When you're the one to
suffer from it?
In my book of good and bad, requesting a mail receipt is
nowhere remotely close to spamming/trashing. 8-)
Neither is it in mine, was just giving an example why it can be
reasonable/ necessary to think more about consequences of what you
release on the world ahead of time.
Yes, it _can_ be reasonable. It is reasonable when the
consequences are actually bad - as in your example. It _can_ also
be unreasonable and in turn self-righteously imposing when the
consequences are not even remotely close to being bad.
Heh, you're you looking only at the immediate effects.
But there is more to it. There can be cases when too much good slips
in until it begins to produce bad results by the total effect, not
by the sum of the individuals.
--
© 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.
Re: How to send a return receipt
Hi, * Patrick Schoenfeld [07-10-18 20:52:22 +0200] wrote: On Wed, Oct 17, 2007 at 10:30:07PM +0200, Rado S wrote: Depends on what you want to achieve: do we want mutt to be acceptable in the business no matter what? if we were talking about anything thats very harmful to mutt in general I would say: No. But we are talking about a mini feature, thats quiet useful in business, so in this single case: Yes. [...] Because the external solution will always hink after mutt, the maintainance needs are a lot higher, as a one-time integration into mutt source (because further changes are just streamlined into the normal development process), etc. It is simple: Offcourse it is possible, but there are a lot more cons about implementing it outside of mutt, then pros to keep it out of mutt. IHMO the problem is not that it wouldn't be useful or potentially not used by the majority of users... I see the problem that somebody has to test it and needs to track mutt development versions to make sure it still works as things internally change. Though I have something in the works, it's really difficult to automatically test mutt code since it compiles without warnings doesn't mean it actually works as advertised. For example, the exact address feature is in the code for quite some time, and it's broken for quite some time and though it's been voted against removal nobody took the time to fix it within something like a full year now (or even more). The same could happen if this feature got included. And if then some new user looking for specifically just that feature tried out mutt and find that feature being broken it actually could do harm to mutt's reputation. Rocco
Re: How to send a return receipt
Hi, On Tue, Oct 16, 2007 at 10:54:16PM +0200, Rado S wrote: color header ^dispo... color1 color2 that is what I currently do, but you cannot call this a notification. In fact it is nothing more then a mark. And so its a workaround again. One action: macro(s). Well, you are right that this enables me to write a return receipt by just one keypress (although it requires me to write a script that actually does a MUAs job), but again it is just a workaround because what you (and others, and me if it is abused by people) find annoying is what this feature lives from. It is like the question: Should all messages flagged as deleted beeing purged?. For a big number of users its neccessary to ask this or similar questions, because otherwise it won't work. Its not that clear for that purge message, but if you think about it you may come to the conclusion that its a lot more clearer for the message disposition thing. Simple to me. Well, its not that hard to achieve it, but it isn't simple either. One needs to write a script, test it, configure a macro -- the last one is by far the simplest part. Its possible, but error prone, again. Well, milage varies. Some like mutt for its current nature of simplicity and flexibility. Obviously not all do, and prefer mutt to transform into some suit-all-easily beast, which requires some more code not used by all/ many classic mutters. As usual, we never know the exact numbers and therefore who's right. Ehh. You miss that I ask about a very common and wide spread feature, not about something all to specific. I actually like mutt because of its flexibility and I don't want it to be a suit-all-easily beast. Again: I'm not asking for a feature that cooks my morning coffee, but other then that I ask for a feature which is wide spread and often used in business. You should have seen in this thread, that I am not the only one that thinks that this is a common feature. No message-hooks needed. Well, but they are the only possibility to make it nagging enough. ;) Not needed either: when you see it, you decide to press the key or not. That does not work. Not for me and not for a lot of others. It could be configurable, one could diable MDN at all or just not let it nag them with a question, but for those that need it nagging it can be like that. It's just one of many other mutt must have. I don't know whats those 'many other', but mutt does support nearly all common email features I am aware off. It even supports Delivery Status Notifications that are (as far as I can see that) less wideley supported and therefore even more useless. So i don't *understand* the reasoning to not add another *common*, *widespread* _and_ *wideused* feature. Its different from doing my homework, coffee or whatsoever. Really. -Patrick
Re: How to send a return receipt
On Wed, Oct 17, 2007 at 09:50:41AM +0200, Patrick Schoenfeld wrote: I don't know whats those 'many other', but mutt does support nearly all common email features I am aware off. It even supports Delivery Status Notifications that are (as far as I can see that) less wideley supported and therefore even more useless. So i don't *understand* the reasoning But DSNs are the way to go. The server should send the notification that it has received the mail and delivered it to the mailbox of the recipient(s). Like a postman will only get a delivery notification, not a reading notification. 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. What you want to do is bugging the MTA developpers to implement DSN (if not already available) not MUA developpers. Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: How to send a return receipt
On 2007-10-17, Stephan Seitz wrote 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. Mr. Schoenfeld has stated several times in this thread that he is trying to respond to requests for a return receipt from his *customers*. It is his concern that his customers be satisfied. -- David Ellement
Re: How to send a return receipt
On Wed, Oct 17, 2007 at 11:10:21AM +0200, Stephan Seitz wrote: On Wed, Oct 17, 2007 at 09:50:41AM +0200, Patrick Schoenfeld wrote: I don't know whats those 'many other', but mutt does support nearly all common email features I am aware off. It even supports Delivery Status Notifications that are (as far as I can see that) less wideley supported and therefore even more useless. So i don't *understand* the reasoning But DSNs are the way to go. That's only true if the people you communicate want to use them. If the people you want to communicate want to use some other commonly implemented feature, then that's the ONLY way to go. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgp5U2czjvsHI.pgp Description: PGP signature
Re: How to send a return receipt
Hi, On Wed, Oct 17, 2007 at 11:10:21AM +0200, Stephan Seitz wrote: But DSNs are the way to go. The server should send the notification that it how can you define whats the way to go, if I can show you a usecase were this is exactly isn't whats needed neither whats wanted? It has been said a lot of time in the thread (not only by me) that a reading notification is in fact whats needed. What you want is an invasion of privacy of every reader. It is not of your Arrgh. This argument is nothing more then FUD. 1) The reader actually has the right to choose weither he tolerates the privacy invasion on a case by case basis (for you as a German this means, that the Right for Informelle Selbstbestimmung is fulfilled) 2) ... and also on a every-case-basis as the reader is able to disable the feature at all. Additional: Your proposed DSN is revealing information without ever asking the user nor informing him about this. Off course you can say that it does not reveal much information concerning the privacy. concern if and when a user reads your mail. Such a feature should never be Good to know that *you* can say what should or should not be a feature of mutt. 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. Yes, thats a disadvantage of the solution, but it is a disadvantage of DSNs atwell (because not all recipient use the same MTA for receival). Also it is not that bad, as long as you know that (some people actually _want_ that) and know how to handle it. Also list of recipients could be a group of people that communicate with each other, so its not always true, that you get a notification from every recipient. What you want to do is bugging the MTA developpers to implement DSN (if not already available) not MUA developpers. Nope. In this case wins the standard thats established by common usage. Not only because of this, but because it is better in this case. -Patrick
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 10:04:34PM -0400, cga2000 wrote: On Tue, Oct 16, 2007 at 06:32:00PM EDT, Derek Martin wrote: Maintaining patches for features that lots of people want is a stupid waste of work. If the maintainers don't want to maintain the code, then they probably should stop being maintainers. Please be more specific. What are those features that lots of people want and that are absent from mutt? I have used mutt for about three years and I never once had the feeling that anything was missing. If you actually require an answer to this, then you apparently have not been reading this thread, and have simply chosen just to pick out one particular comment that you can respond to with what you think is some clever, quipy remark that in actuality is neither valuable to the discussion, nor sensible in any regard. I suggest you re-read the thread, and in particular the original poster's messages, and also the part where I wrote: On Tue, Oct 16, 2007 at 05:39:49PM -0400, Derek Martin wrote: And don't forget that just because YOU don't find any value in a feature, that doesn't mean it's not a feature that common users want... The folks who both use mutt and are likely to hang out on a mailing list are almost by definition not common mail users. But lots of people who use Mutt want the power it offers them to process a wide variety of mail in interesting ways, but don't want to hack their mailer; and they shouldn't have to, if the feature they want is commonly implemented in other mailers. 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. Mutt should implement features that are commonly implemented in other mailers so that users of Mutt can interoperate with people who don't use Mutt, which is by far the majority of mail users. Mutt's claim is that it sucks less than all other mailers, which was once true; but IMO with each new feature that other mailers implement that Mutt does not, this becomes less and less the case, and I'm not sure if that is still true anymore. It certainly does still offer some powerful mail-processing features that most other mailers don't offer; but some mailers do offer a lot of them now... To be honest I think the ONLY reason I still use mutt is because I do most of my personal mail reading remotely, and Mutt still DOES suck less than the rest of TEXT-BASED mailers... But I wonder if it isn't only a matter of time before even that isn't true anymore. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpsUZsIjuWGf.pgp Description: PGP signature
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
Re: How to send a return receipt
On Wed, Oct 17, 2007 at 07:52:03AM -0600, Charles Cazabon wrote: Actually, one of the things that makes mutt suck less than other MUAs is that it *doesn't* have additional hundreds of little-used features to cause bloat, bugs, user confusion, and UI complication for no real added benefit. As a related example, I'm still disappointed SMTP support got added. Actually I think this is a fine example of why that argument is total nonsense. Since SMTP support has been added, in what measurable way has it caused Mutt to suck more? Is the memory footprint *substantially* larger? Has it caused mutt to become noticably slower? My desktop has 2GB of RAM. Mutt's memory footprint would have to go up by a factor of about 50 before I would even notice, and more like 100 before it would be a genuine concern. My CPU is a 3GHz Pentium 4... the load on my system when Mutt is running is negligible for all but the most computing-intensive operations (and even then, it's disk load, not CPU, that's the problem). Adding the requested feature will add at most a couple of KB, and have zero noticable impact on system performance. If you're still running Mutt on a 486 with 16MB of RAM, it's probably time to upgrade your machine... but if you don't want to, and you don't care about new features, just run an old version of Mutt. 1.4 still works, and has even had (fairly) recent security updates. But your argument is completely bogus when it comes to deciding whether or not to add a feature to Mutt. Especially since, if there really was some compelling reason to keep the footprint small, features could be added as loadable modules, which is now decades-old technology. The bloat that you're talking about other mailers having is caused by needing to load huge desktop inter-process com libraries on top of huge GUI toolkit libraries on top of underlying system libraries. Mutt will never have this problem, because it doesn't try to be a GUI desktop environment application... But even if it did, on modern hardware, running these apps just isn't problematical. Balking at adding genuine features in the name of preventing bloat is simply asinine, and clinging to those ideals is an attitude that's fitting for computing's stone age, but by and large, if we're talking about genuine features that people use (even if the set of people doesn't include you personally), just doesn't make sense. When developers use this argument, what they're really saying is either they oppose the feature on philisophical grounds (which is not a good reason), or they're too busy/lazy/disinterested to work on it (which is a good reason, since no one's paying them to do it). -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpmnI4d4CL5e.pgp Description: PGP signature
Re: How to send a return receipt
Hi, Derek I can only agree with you in everything you wrote. On Wed, Oct 17, 2007 at 10:58:52AM -0400, Derek Martin wrote: Actually I think this is a fine example of why that argument is total nonsense. Since SMTP support has been added, in what measurable way has it caused Mutt to suck more? Is the memory footprint *substantially* larger? Has it caused mutt to become noticably slower? Additional I would like to second this and add: I'm working with a pretty low-end laptop with actually only having 512MB of RAM. I do use GNOME, therefore I already have a quiet big memory consumption. I do use several mutt instances in several xterms, so the memory footprint of mutt is multiplied by 2 till 5 or so. My system is fast and responsive. I can work with mutt with no harm at all. And I do use a Debian built of mutt, which contains quiet a lot features (including IMAP, SMTP, Header Cache and PGP support). So you see: You do not need to have 2G of RAM to hold up your totally valid argument. Even if those patch would be added (face it: its about 20k of added code) then the memory consumption wouldn't even be 2% more then now, so this bloat argument is not feasible. Nor would the size of the executable increase a lot. Regards, Patrick
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
Re: How to send a return receipt
Quoting Stephan Seitz [EMAIL PROTECTED]: 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. It is not of the sender's concern _only_ when the recipient says so. The recipient _could_ refuse to send a receipt. The recipient _could_ also want it otherwise, for business or legal or whatever reasons. The point here is, people and groups of people operate vastly differently, often in ways that we never think of. So why should an MUA be so morally judgmental? Besides if you are sending a mail to more than one recipient or an alias, you will get a notification from every recipient. And _maybe_ that's what they want. And again that's not something the MUA(or its developers) should be in a position to decide. What you want to do is bugging the MTA developpers to implement DSN (if not already available) not MUA developpers. Nobody is bugging anybody as far as I can see here. I won't stop using mutt just because it won't support mail receipts. In fact, I couldn't care less about mail receipts myself on a technical level. The reason I got involved in this debate is because I can't agree that a tool should decide whether a feature is socially appropriate or not for its users. That, and maybe I'm just in the mood for philosophical argument these days. Cheers. -- Jing Xue
Re: How to send a return receipt
=- Jing Xue wrote on Wed 17.Oct'07 at 12:17:08 -0400 -= The point here is, people and groups of people operate vastly differently, often in ways that we never think of. So why should an MUA be so morally judgmental? If nobody does, where should moral come from? If somebody does, why is anyone more qualified than the other? If all are the same, why not the coder(s)? Diversity is fine, but can work for bad ends, too, think of spammers and TOFU posters. You can't technically avoid it (and sometimes it's even functionally required/ wanted), but you don't have to make it easy for the crowd to satisfy few legitimate uses. In fact, I couldn't care less about mail receipts myself on a technical level. The reason I got involved in this debate is because I can't agree that a tool should decide whether a feature is socially appropriate or not for its users. Heh, same here, only I don't agree with the hardcode support for what is possible with current means. That, and maybe I'm just in the mood for philosophical argument these days. Ditto. -- © 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.
Re: How to send a return receipt
On Wed, Oct 17, 2007 at 09:10:38PM +0200, Rado S wrote: In fact, I couldn't care less about mail receipts myself on a technical level. The reason I got involved in this debate is because I can't agree that a tool should decide whether a feature is socially appropriate or not for its users. Heh, same here, only I don't agree with the hardcode support for what is possible with current means. Taking this argument to extremes, Mutt can contain *NO CODE* and that argument still applies. The user is still free to implement whatever missing features he wants, using shell scripts to glue together self-written programs and other utilities. So if less code is always better, then let's do that. I'll send you a shell script called mutt which does nothing but launch commands specified on the command line, and you can implement whatever features you want on top of that using whatever means you like. Please use that to read all your mail for 10 days, and then tell me that having features you want coded into your mailer isn't better. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpFQqzFS3CY4.pgp Description: PGP signature
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Wed 17.Oct'07 at 9:50:41 +0200 -=
color header ^dispo... color1 color2
that is what I currently do, but you cannot call this a
notification. In fact it is nothing more then a mark. And so its a
workaround again.
Hum... now we are at preference level and therefore how we name
things. Functionally it's the same: you are being informed to look
at it.
It's just the degree/ method required/ given which is perceived
differently. For me it would be enough (if I actually needed/ wanted
such support), for you it isn't. So you'd have to put a little more
effort into it, but nothing that would be needed for everyone to
this degree. And once you have a working solution, it can be
published for easy use by everyone else, the form doesn't matter
anymore, everyone can copy+paste. If it's popular enough it could
be distributed in /contrib.
One action: macro(s).
Well, you are right that this enables me to write a return receipt
by just one keypress (although it requires me to write a script
that actually does a MUAs job),
Where is the MUA's job defined?
You have a complete list with must have and must not have?
Where do you draw the line of what a MUA is/ does?
For example, is ~/.mailcap usage external by your definition?
You'd prefer a mutt-proprietary solution?
but again it is just a workaround because what you (and others,
and me if it is abused by people) find annoying is what this
feature lives from.
I don't know what you mean, but I'm only annoyed that people ask for
a special unique template answer to be hardcoded while it can be
(easily for my taste) achieved as it is.
I see justified uses for the feature generally, just no requirement
for it being hardcoded.
Such discussion has risen before and will rerise until there is a
policy/ guideline declared to give us a clue what dis-/qualifies for
mutt, i.e. what's the target audience and goal of mutt.
It is like the question: Should all messages flagged as deleted
beeing purged?. For a big number of users its neccessary to ask
this or similar questions, because otherwise it won't work.
I don't deny you the option to use it or not, since you can have it.
You just don't like what you can have, or the work that you'd have
to put on top of it to make it perfect (for your taste).
Simple to me.
Well, its not that hard to achieve it, but it isn't simple either.
One needs to write a script, test it, configure a macro -- the
last one is by far the simplest part. Its possible, but error
prone, again.
The same applies to a hardcoded variant, or do you write perfect
C-code from scratch?
As usual, we never know the exact numbers and therefore who's
right.
Ehh. You miss that I ask about a very common and wide spread
feature, not about something all to specific.
common based on what?
I don't know that many conciously working with it (and being happy
about it ;).
Again: I'm not asking for a feature that cooks my morning coffee,
but other then that I ask for a feature which is wide spread and
often used in business.
No, not yours alone, but together with all the other ones it slowly
will be able to, and put some sugar in your cup, too. Care to lift a
finger at all anymore? ;)
If that's the killer argument, then use Outlook: it's the closest to
the quasi-standard of the business world.
Why should mutt run after business standards, when business is so
stupid to measure only in numbers (of lame OL{users}) rather than
quality (of mutt{ers})?
You should have seen in this thread, that I am not the only one
that thinks that this is a common feature.
So is news-reading, eMail-filtering, spam-control, mime-support and
what not... all of that could be _much_ better when integrated into
mutt.
Oh, why not use TB or OL instead, it does all of that and
return-receipts, too?!
Hmm, why do people try to convert mutt into yet another clone of
existing MUAs rather than using them right on?
I know, it's not your single feature alone that turns mutt into TB
or OL clone, but all those inclusion requests together do.
No message-hooks needed.
Well, but they are the only possibility to make it nagging enough. ;)
D'oh, ... if you really need that.
One golden rule is to adjust the environment to the users'
convenience.
Another is that the very same rule means stagnation: you miss the
chance to improve your processing (or confirm it's the best, by
trying alternatives).
The first way to do things is not always the best (ever ;).
It's just one of many other mutt must have.
I don't know whats those 'many other', but mutt does support
nearly all common email features I am aware off.
See above, and many other more or less known/ popular/ supported
niche features/ patches/ improvements.
Which should go in and which not? Why this and not the others?
Numbers don't work as argument, since we never know the _real_
numbers to use them in favour of or against any features.
And numbers alone should never be a
Re: How to send a return receipt
=- Derek Martin wrote on Wed 17.Oct'07 at 15:22:41 -0400 -= Taking this argument to extremes, Mutt can contain *NO CODE* and that argument still applies. The user is still free to implement whatever missing features he wants, using shell scripts to glue together self-written programs and other utilities. So if less code is always better, then let's do that. I'll send you a shell script called mutt which does nothing but launch commands specified on the command line, and you can implement whatever features you want on top of that using whatever means you like. Doesn't this exist already? mh? See http://wiki.mutt.org/?MuttQuotes about MH. :) Anyway, sure, but you dropped the relevant paragraph from my response: what's mutt about, and who decides what's in/ out? Please use that to read all your mail for 10 days, and then tell me that having features you want coded into your mailer isn't better. Definitely I'm happy with mutt as it is, but as much as you and others would like to add _more_ to it, I'd like to _strip_ it off some parts not belonging there (by my taste, like smtp or spam). -- © 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.
Re: How to send a return receipt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Charles Cazabon [EMAIL PROTECTED] [10-17-07 09:51]: Actually, one of the things that makes mutt suck less than other MUAs is that it *doesn't* have additional hundreds of little-used features to cause bloat, bugs, user confusion, and UI complication for no real added benefit. As a related example, I'm still disappointed SMTP support got added. agreed, repetition of a function already provided by default installation of all linux distros that I am familiar. It's akin to including an editor, html browser, picture viewer, Last I checked: DESCRIPTION Mutt is a small but very powerful text based program for reading electronic mail under unix operating systems, including support color terminals, MIME, and a threaded sorting mode. - -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn4472 (GNU/Linux) iD8DBQFHFmSJClSjbQz1U5oRAqKMAJ9ng8lG/Dnd4yPGKUb+li51ATY7CwCfUydN RC0kO0WB3nCs3ZU9WvTCbuE= =TMe3 -END PGP SIGNATURE-
Re: How to send a return receipt
On 10/17/07 15:37, Patrick Shanahan wrote: [snip] As a related example, I'm still disappointed SMTP support got added. agreed, repetition of a function already provided by default installation of all linux distros that I am familiar. It's akin to including an editor, html browser, picture viewer, Last I checked: DESCRIPTION Mutt is a small but very powerful text based program for reading electronic mail under unix operating systems, including support color terminals, MIME, and a threaded sorting mode. Linux is about choices, not limitation or forcing everybody to use the same features. I see nothing wrong with smpt (if it works correctly), if it was added to distribution it means there was a need for it. If one doesn't like the smpt all it needs to be done is to compile mutt without smpt flag support; problem solved (on Gentoo that flag is excluded by default). -- #Joseph GPG KeyID: ED0E1FB7
Re: How to send a return receipt
Quoting Rado S [EMAIL PROTECTED]: =- Jing Xue wrote on Wed 17.Oct'07 at 12:17:08 -0400 -= The point here is, people and groups of people operate vastly differently, often in ways that we never think of. So why should an MUA be so morally judgmental? If nobody does, where should moral come from? If somebody does, why is anyone more qualified than the other? If all are the same, why not the coder(s)? Because coders are supposed to code solutions into a tool, not to code their ideology into it. (well as far as software tools are concerned) I remember reading one of Linus Torvalds's posts to the kernel list about why the kernel should not actively refuse to load non-OSS modules. His point, and obviously I paraphrase, is that that would be imposing an ideology on people, and that would be bad, and actually quite an irony considering the ideology being imposed itself is all supposed to be about more freedom. Diversity is fine, but can work for bad ends, too, think of spammers and TOFU posters. You can't technically avoid it (and sometimes it's even functionally required/ wanted), but you don't have to make it easy for the crowd to satisfy few legitimate uses. In my book of good and bad, requesting a mail receipt is nowhere remotely close to spamming/trashing. 8-) Cheers. -- Jing Xue
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.
Re: How to send a return receipt
=- Jing Xue wrote on Wed 17.Oct'07 at 16:07:28 -0400 -=
If nobody does, where should moral come from?
If somebody does, why is anyone more qualified than the other?
If all are the same, why not the coder(s)?
Because coders are supposed to code solutions into a tool, not to
code their ideology into it. (well as far as software tools are
concerned)
Why is that so?
It's not like you're forced such a ideology-loaded tool or are
entitled to use the work of somebody else against his will, or are
you? ;)
Don't like it as it is? Do it yourself.
His point, and obviously I paraphrase, is that that would be
imposing an ideology on people, and that would be bad, {...}
There are obviously drawbacks for either imposing or refraining from
it, again a matter of preference of potentially resulting consequences.
Diversity is fine, but can work for bad ends, too, think of spammers
and TOFU posters. You can't technically avoid it (and sometimes it's
even functionally required/ wanted), but you don't have to make it
easy for the crowd to satisfy few legitimate uses.
In my book of good and bad, requesting a mail receipt is nowhere
remotely close to spamming/trashing. 8-)
Neither is it in mine, was just giving an example why it can be
reasonable/ necessary to think more about consequences of what you
release on the world ahead of time.
--
© 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.
Re: How to send a return receipt
On Wed, Oct 17, 2007 at 07:33:46AM EDT, Derek Martin wrote: On Tue, Oct 16, 2007 at 10:04:34PM -0400, cga2000 wrote: On Tue, Oct 16, 2007 at 06:32:00PM EDT, Derek Martin wrote: Maintaining patches for features that lots of people want is a stupid waste of work. If the maintainers don't want to maintain the code, then they probably should stop being maintainers. Please be more specific. What are those features that lots of people want and that are absent from mutt? I have used mutt for about three years and I never once had the feeling that anything was missing. If you actually require an answer to this, then you apparently have not been reading this thread, and have simply chosen just to pick out one particular comment that you can respond to with what you think is some clever, quipy remark that in actuality is neither valuable to the discussion, nor sensible in any regard. I suggest you re-read the thread, and in particular the original poster's messages, and also the part where I wrote: On Tue, Oct 16, 2007 at 05:39:49PM -0400, Derek Martin wrote: And don't forget that just because YOU don't find any value in a feature, that doesn't mean it's not a feature that common users want... The folks who both use mutt and are likely to hang out on a mailing list are almost by definition not common mail users. But lots of people who use Mutt want the power it offers them to process a wide variety of mail in interesting ways, but don't want to hack their mailer; and they shouldn't have to, if the feature they want is commonly implemented in other mailers. 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. Mutt should implement features that are commonly implemented in other mailers so that users of Mutt can interoperate with people who don't use Mutt, which is by far the majority of mail users. Mutt's claim is that it sucks less than all other mailers, which was once true; but IMO with each new feature that other mailers implement that Mutt does not, this becomes less and less the case, and I'm not sure if that is still true anymore. It certainly does still offer some powerful mail-processing features that most other mailers don't offer; but some mailers do offer a lot of them now... To be honest I think the ONLY reason I still use mutt is because I do most of my personal mail reading remotely, and Mutt still DOES suck less than the rest of TEXT-BASED mailers... But I wonder if it isn't only a matter of time before even that isn't true anymore. As a perfectly content user of mutt I felt it my best interest to seize upon this opportunity to state that mutt does precisely what I want and does it the way I want. As I wrote earlier, I have absolutely no idea what features you are missing. Every time I need to do something, much to my delight, it is there for me .. implemented in the smartest and most natural possible way. This humble subscriber to the list is simply saying he does not want mutt to become yet another Microsoft Outlook clone. I must add that I agree with everything Charles and Rado posted to this thread as to why adding new so-called features to mutt is not a decision lightly to be taken and why I feel such enhancements will turn out not be such a wonderful idea after all. Sorry, but I have neither the time nor the desire to argue further. Thanks, cga
Re: How to send a return receipt
On Wed, Oct 17, 2007 at 10:42:06PM +0200, Rado S wrote:
=- Jing Xue wrote on Wed 17.Oct'07 at 16:07:28 -0400 -=
Because coders are supposed to code solutions into a tool, not to
code their ideology into it. (well as far as software tools are
concerned)
Why is that so?
It's not like you're forced such a ideology-loaded tool or are
entitled to use the work of somebody else against his will, or are
you? ;)
Don't like it as it is? Do it yourself.
//sigh, why is it that at the end of every one of these debates, there
is always this boiler plate answer that awaits?
I thought OSS was about the freedom of choice, and about letting (not
forcing) more and more people realize that they do have more choices.
I never thought of OSS as a path to the elitism of I can do it myself,
and you can't, even despite that the elitism is really just an
illusion, because people can't do it maybe out of many reasons other
than their skill sets.
Do you really rewrite every piece of software you find not up to your
expectations, yet you cannot convince the developer to change it because
the developer does not agree with you philosophically?
This is _not_ about the attitude of the user's, but that of the
developer's.
His point, and obviously I paraphrase, is that that would be
imposing an ideology on people, and that would be bad, {...}
There are obviously drawbacks for either imposing or refraining from
it, again a matter of preference of potentially resulting consequences.
How can you call it a matter of preference, when the very choice of this
preference itself may conflict with the fundamental value behind the
ideology?
In my book of good and bad, requesting a mail receipt is nowhere
remotely close to spamming/trashing. 8-)
Neither is it in mine, was just giving an example why it can be
reasonable/ necessary to think more about consequences of what you
release on the world ahead of time.
Yes, it _can_ be reasonable. It is reasonable when the consequences are
actually bad - as in your example. It _can_ also be unreasonable and in
turn self-righteously imposing when the consequences are not even
remotely close to being bad.
Cheers.
--
Jing Xue
Re: How to send a return receipt
Quoting Charles Cazabon [EMAIL PROTECTED]: The concept of mail receipts is poorly designed; there is no way to implement a reliable receipt notification system with SMTP mail. *Many* of the better mail packages therefore do not implement support for it -- why have a feature if you *know* it can never work properly? I think it's an overstatement to say that it can never work properly. It's actually it _might not_ work properly. It still serves its purpose when it does work - see below. It's also seen as an invasion of privacy. It certainly creates some annoyance on the recipient end. But I don't see how it is an invasion of privacy as long as the MUA has my consent before sending a receipt. Mail receipts are essentially one of those features that commercial MUA vendors include as a marketing checkbox feature, but which serve little or no useful purpose in the real world. Well, in the corporate* world where people communicate over Lotus Notes or Outlook, they tend to use mail receipts a lot. And _because_ they all communicate over the same MUA that supports the feature, it actually does work and become useful. Now _I_ don't use these mail receipts, nor do _I_ like getting them, because of the annoyance factor. But then I respect it when others request one - at least before they start abusing it. My 2 cents. -- Jing Xue *: that's real enough for me. YMMV.
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 11:18:05AM EDT, Jing Xue wrote: Quoting Charles Cazabon [EMAIL PROTECTED]: The concept of mail receipts is poorly designed; there is no way to implement a reliable receipt notification system with SMTP mail. *Many* of the better mail packages therefore do not implement support for it -- why have a feature if you *know* it can never work properly? I think it's an overstatement to say that it can never work properly. It's actually it _might not_ work properly. It still serves its purpose when it does work - see below. It's also seen as an invasion of privacy. It certainly creates some annoyance on the recipient end. But I don't see how it is an invasion of privacy as long as the MUA has my consent before sending a receipt. Mail receipts are essentially one of those features that commercial MUA vendors include as a marketing checkbox feature, but which serve little or no useful purpose in the real world. Well, in the corporate* world where people communicate over Lotus Notes or Outlook, they tend to use mail receipts a lot. And _because_ they all communicate over the same MUA that supports the feature, it actually does work and become useful. Now _I_ don't use these mail receipts, nor do _I_ like getting them, because of the annoyance factor. But then I respect it when others request one - at least before they start abusing it. My 2 cents. My #1 worry under these circumstances is that when I do accept to send a receipt I would like to be notified that the recipient actually received (and read) my receipt. Is there any way this can be done with mutt? Or Lotus Notes, Outlook? cga
Re: How to send a return receipt
Hi, On Tue, Oct 16, 2007 at 11:18:05AM -0400, Jing Xue wrote: Well, in the corporate* world where people communicate over Lotus Notes or Outlook, they tend to use mail receipts a lot. And _because_ they all communicate over the same MUA that supports the feature, it actually does work and become useful. Yep. It is as it is: Those users of MUAs that support it (actually we talk about MUAs that take at least 50-60% of the market share *¹) actually don't know that there are MUAs that doesn't support it. Its existance is natural for them *and* they often have a real world purpose for it. We *have* a real purpose for it, it *is* useful for us. And note that we are not on the sender but on the receipient side. Regards, Patrick *¹ I'm aware that at least Outlook, Outlook Express, Thunderbird, Balsa, Sylpheed, The Bat!, Eudora and Apple Mail support it. In fact mutt is the only mailer I found not supporting it (but that may just be, because i never worked with elm or alpine)
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Tue 16.Oct'07 at 21:24:22 +0200 -= In fact mutt is the only mailer I found not supporting it Return-receipts being standard replies with a preformatted content (nothing special about them), mutt _does_ support them, just not built-in as you would like it to be so that you don't have to tweak the config as freely as you must, sorry: _can_. Imagine all that could be usefully done with external resources built into mutt, it would become as chunky and bulky as the bad rest. It's not a bug but a feature that not everything that is possible is built-in but must/can be accomplished elsewhere. (not counting recent exceptions ;) -- © 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.
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: Return-receipts being standard replies with a preformatted content (nothing special about them), mutt _does_ support them, just not Well, the problem is that what you describe is not all. Additional the feature (to be comparable) it is a notification that the sender asked for a return receipt and it is a one-action-thing to confirm this. Off course it is possible to workaround the missing builtin support. But don't talk about it like it would be anything other then a workaround, cause that is what it basically is. built-in as you would like it to be so that you don't have to tweak the config as freely as you must, sorry: _can_. Imagine all that You keep talking like it was a simple configuration change, but thats not true. Tell me: Why do you keep telling something thats _untrue_? Consider the truth: It would be possible to achieve most of the requested feature by writting a script that is spawned when a message is displayed, using message-hooks. Its also possible to ask a question in this script. So we reached the goal, didn't we? Yes, we did, but: We must depend upon at least two additional components (a script and an interpreter), the question is not well-integrated into mutt and so the solution is: error-prone and not as comfortable as it could. So it is possible, but it is everything but a configurable option. It's not a bug but a feature that not everything that is possible is built-in but must/can be accomplished elsewhere. I agree. But just because it is a feature it is not a feature in *every* case. -Patrick
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Tue 16.Oct'07 at 22:26:05 +0200 -=
Additional the feature (to be comparable) it is a notification
that the sender asked for a return receipt and it is a
one-action-thing to confirm this.
{...}
You keep talking like it was a simple configuration change, but
thats not true.
Notify:
color header ^dispo... color1 color2
color index ~h '^dispo...' color3 color4
unignore dispo...
With the help of procmail and mutt's x-label feature you could do
other things, too, based on that Dispo... header.
One action: macro(s).
Simple to me.
Off course it is possible to workaround the missing builtin
support. But don't talk about it like it would be anything other
then a workaround, cause that is what it basically is.
Well, milage varies. Some like mutt for its current nature of
simplicity and flexibility. Obviously not all do, and prefer mutt to
transform into some suit-all-easily beast, which requires some more
code not used by all/ many classic mutters. As usual, we never
know the exact numbers and therefore who's right.
Tell me: Why do you keep telling something thats _untrue_?
It's true ... to me. I can only speak for myself based on what I
know and need (for your task).
Consider the truth: It would be possible to achieve most of the
requested feature by writting a script that is spawned when a
message is displayed, using message-hooks.
No message-hooks needed.
Its also possible to ask a question in this script.
Not needed either: when you see it, you decide to press the key or
not.
So we reached the goal, didn't we? Yes, we did, but: We must
depend upon at least two additional components (a script and an
interpreter), the question is not well-integrated into mutt and so
the solution is: error-prone and not as comfortable as it could.
So it is possible, but it is everything but a configurable option.
So are many other things.
It's just one of many other mutt must have.
--
© 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.
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: =- Patrick Schoenfeld wrote on Tue 16.Oct'07 at 21:24:22 +0200 -= In fact mutt is the only mailer I found not supporting it Return-receipts being standard replies with a preformatted content (nothing special about them), mutt _does_ support them, just not built-in as you would like it to be so that you don't have to tweak the config as freely as you must, sorry: _can_. Imagine all that could be usefully done with external resources built into mutt, it would become as chunky and bulky as the bad rest. It's not a bug but a feature that not everything that is possible is built-in but must/can be accomplished elsewhere. I have always, and still do find this argument to be um, less than well thought out (to put it extremely mildly). Adding features does not inherently add bloat; and in general, if adding a commonly requested feature requires the addition of a bunch of crap code, then the current design of the program (or perhaps the design of the implementation of the new feature) is broken. So if you are balking at implementing a feature for this reason, it's probably a good sign that a rewrite (of something) is needed. If a function is e-mail related, and commonly supported by other mailers, then it seems to me Mutt should have built-in support for it too. Mutt is a Mail USER Agent (not a mail DEVELOPER agent), and it should interoperate with other mailers, and should do everything that users commonly want to do with mail without a lot of fuss. The only things that should require fuss are things that are not commonly wanted by common mail users. And don't forget that just because YOU don't find any value in a feature, that doesn't mean it's not a feature that common users want... Otherwise, mutt will not suck less than the rest. Almost any feature can be passed off to some helper program, but very often doing so is annoyingly clunky and/or inflexible. Very often it's hard for a user to get a helper program which works sanely in his environment. And ultimately, who wants to have to install 100 programs to deal with mail? But this is where the current philosophy is headed... add 100 features, install 100 programs. Linux users are lucky in that most such programs are commonly pre-installed with their distro, and the design philosophy of Mutt generally reflects that fact. But Linux isn't the only game in town, and the Unix Philosophy development model is not very scalable in such a context, especially if you have to deploy 1000 Unix workstations that don't come with any of the helper programs you need to make your application work in your environment (and most especially if they need different configurations, preventing one from easily creating, say, a tarball with all the required software). -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpJ5CszzC7yZ.pgp Description: PGP signature
Re: How to send a return receipt
Derek Martin [EMAIL PROTECTED] wrote: On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: It's not a bug but a feature that not everything that is possible is built-in but must/can be accomplished elsewhere. I have always, and still do find this argument to be um, less than well thought out (to put it extremely mildly). Adding features does not inherently add bloat; Actually, it does. Every feature, and every line of code generally, incurs both a development cost, and maintenance costs. Every feature adds maintenance time for bug testing, developer documentation, end-user documentation, regression testing, developer support, end-user support, etc. It's a fairly significant burden, and it's the best damn reason for rejecting calls for features adding little or no new functionality not possible with the existing code, even when the people calling for it say but it only adds 20 lines of code, that takes like ten minutes. I'm not referring only to mutt here, either. If your pet feature is minimal code, but the developers don't want to include it because what you're asking is already possible another way -- just maintain a local patch for it. Every time you want to upgrade, apply your patch to the fresh code -- voila. You get your feature, and the developers don't get the development, testing, and support overhead associated with it. Everyone wins. Yes, I've done exactly this myself. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ ---
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 04:08:24PM -0600, Charles Cazabon wrote: Derek Martin [EMAIL PROTECTED] wrote: On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: It's not a bug but a feature that not everything that is possible is built-in but must/can be accomplished elsewhere. I have always, and still do find this argument to be um, less than well thought out (to put it extremely mildly). Adding features does not inherently add bloat; Actually, it does. Every feature, and every line of code generally, incurs both a development cost, and maintenance costs. This is not the same as bloat. From Merriam Webster: bloat - n. 1 a: one that is bloated b: unwarranted or excessive growth or enlargement bureaucratic bloat Growth is not inherently unwanted or unwarranted or excessive. So, no, it actually doesn't. Clean code added to address the needs of the users is inherently not bloat. If your pet feature is minimal code, but the developers don't want to include it because what you're asking is already possible another way -- just maintain a local patch for it. Every time you want to upgrade, apply your patch to the fresh code -- voila. You get your feature, and the developers don't get the development, testing, and support overhead associated with it. Everyone wins. Yes, I've done exactly this myself. So have I, and it sucks. Every time I had to update the patch, I couldn't help but think, the fact that I have to do this is retarded. Patches that don't get added to the code base need to be maintained... even small ones. My patches eventually did make it into mainstream mutt, and as such required far less maintenance, because the code they touch rarely changes significantly, but just enough that creating a new patch was needed fairly frequently. Maintaining patches for features that lots of people want is a stupid waste of work. If the maintainers don't want to maintain the code, then they probably should stop being maintainers. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpNn2dGz8Dtx.pgp Description: PGP signature
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 06:32:00PM EDT, Derek Martin wrote: [..] Maintaining patches for features that lots of people want is a stupid waste of work. If the maintainers don't want to maintain the code, then they probably should stop being maintainers. Please be more specific. What are those features that lots of people want and that are absent from mutt? I have used mutt for about three years and I never once had the feeling that anything was missing. Thanks, cga
Re: How to send a return receipt
On Sun, Oct 14, 2007 at 12:40:08AM +0200, Patrick Schoenfeld wrote: No. You get me wrong, repeatedly. I'm asking for a proof that a message has reached a single role. It does not matter if more then one person can actually be the role. Hm, do you mean, it is enough for you if the last server sends a Delivery Status Notification (DSN), that it delivered the mail to one or more mailboxes? Are DSNs not part of a RFC? Or do you want a notification if the recipient (and in case of a role every recipient) opens the mail? While I accept the first one, the last one should be out of question. Even in your snail mail example you will only get a notification that the letter was delivered, not that the recipient has read it. For DSN mutt offers you the variables dsn_notify and dsn_return. But if I understand the manual correctly, it all depends on the MTA to honor them. Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: How to send a return receipt
On Sun, Oct 14, 2007 at 12:40:08AM +0200, Patrick Schoenfeld wrote: On Sat, Oct 13, 2007 at 10:10:45PM +0100, Chris G wrote: But you're asking for proof that it reached us as the recipient for multiple recipients apparently, with a *single* acknowledgement. That's just not possible in any sort of system. No. You get me wrong, repeatedly. I'm asking for a proof that a message has reached a single role. It does not matter if more then one person can actually be the role. OK, so how/what/where does this single role exist? As I understand it it *has* to exist somewhere before the mail reaches the individuals each of whom actually receives the mail. Thus you need to receive this acknowledgement from somewhere that deals with the mail *before* it ever gets delivered to the individuals' MUAs, so the requirement cannot be fulfilled by mutt. -- Chris Green
Re: How to send a return receipt
On Fri, Oct 12, 2007 at 07:35:02PM -0500, Kyle Wheeler wrote: Thus, any message that does not have an X-Disposition-Sent header is a message that you haven't sent a response to, and messages that DO have such a header won't trigger the macro. That does not work (at least in my case) because the TO-address is (often) forwarded to a group of people, where one might not send such a confirmation, when another already did. So a question is probably the best way to go, because the people in the group usually know if someone already sent the confirmation. I don't see what that missing functionality might be. Maybe I'm missing something. Well, see above. The ideas others and I had so far are all lacking something, that the MDA functions gives. Regards, Patrick
Re: How to send a return receipt
On Fri, Oct 12, 2007 at 02:06:44PM -0500, Kyle Wheeler wrote: Oh, come on, the appropriate docs would be the *mutt* documentation, of course! Can we possibly ask a more vague or open-ended question? Haha! If it would be so obvious I wouldn't have asked, hu? Take for granted that I had a look at the documentation, but did not find the right part to solve my problem. Check out the -H and -i flags that can be passed to mutt. They allow you to make mutt send a specific file... or you can pipe a file into mutt's stdin, and that should work as well (kinda like /bin/mail). Look, _now_ you actually pointed me to something to nearer look at. Regards, Patrick
Re: How to send a return receipt
Hi, On Fri, Oct 12, 2007 at 01:14:07PM -0600, Joseph wrote: 8.12: How to send an auto-reply back when someone posts? thanks for that hint, but actually a auto-reply is not appropriate. I need something to actually confirm, because someone might already have sent it out. In another part of the thread I were pointed out to some mutt docs with sending files, so eventually that and a macro would be a solution. I will check this out, as long as it is not sure if the MDN patch will every make it into mutt. Regards, Patrick
Re: How to send a return receipt
On Sat, Oct 13, 2007 at 12:58:52PM +0200, Patrick Schoenfeld wrote: Hi, On Fri, Oct 12, 2007 at 01:14:07PM -0600, Joseph wrote: 8.12: How to send an auto-reply back when someone posts? thanks for that hint, but actually a auto-reply is not appropriate. I need something to actually confirm, because someone might already have sent it out. In another part of the thread I were pointed out to some mutt docs with sending files, so eventually that and a macro would be a solution. I will check this out, as long as it is not sure if the MDN patch will every make it into mutt. I don't follow this because someone might already have sent it out bit. Surely if a mail is sent to (say) ten recipients it's pretty useless to know that it got to just one of them. If all ten recipients had MUAs that understood the receipt request thing wouldn't they all acknowledge? If not then it's an even more un-useful facility than would at first appear. -- Chris Green
Re: How to send a return receipt
On Sat, Oct 13, 2007 at 01:37:13PM +0100, Chris G wrote: Surely if a mail is sent to (say) ten recipients it's pretty useless to know that it got to just one of them. If all ten recipients had Eh.. no?! If you send it to 10 different recipients, with each representing a different role, then you are right. But if you have one address for several people then it is somewhat obvious, that each person is the representative of a role that only needs to acknowledge the receival of the mail _once_. Believe me: If every (currently 3) people that read the mail would acknowledge that our customer would sureley not feel this funny. MUAs that understood the receipt request thing wouldn't they all acknowledge? If not then it's an even more un-useful facility than No, they don't, because they ask the recipient in *every* case. That is like the postman that asks you to confirm the sending of a letter. Its only different in that he does not deliver the mail if you don't confirm the sending of a letter. Regards, Patrick
Re: How to send a return receipt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday, October 13 at 12:50 PM, quoth Patrick Schoenfeld: On Fri, Oct 12, 2007 at 07:35:02PM -0500, Kyle Wheeler wrote: Thus, any message that does not have an X-Disposition-Sent header is a message that you haven't sent a response to, and messages that DO have such a header won't trigger the macro. That does not work (at least in my case) because the TO-address is (often) forwarded to a group of people, where one might not send such a confirmation, when another already did. So a question is probably the best way to go, because the people in the group usually know if someone already sent the confirmation. I don't see what that missing functionality might be. Maybe I'm missing something. Well, see above. The ideas others and I had so far are all lacking something, that the MDA functions gives. How does an MDA-enabled client communicate to other clients that a given email has already been responded to? And what's stopping the send-mdn.sh script from asking the user a question? ~Kyle - -- If the president is the head of the American body politic, Congress is its gastrointestinal tract. Its vast and convoluted inner workings may be mysterious and unpleasant, but in the end they excrete a great deal of material whose successful passage is crucial to our nation's survival. This is Congress's duty. -- Jon Stewart -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHEOZ4BkIOoMqOI14RAro9AKCobhTvRUlFl6AYLqwRxk3DBGtRCACfWWXj kLYKKU0lyq9IMRFLJWRiV70= =eFVk -END PGP SIGNATURE-
Re: How to send a return receipt
On Sat, Oct 13, 2007 at 04:13:11PM +0200, Patrick Schoenfeld wrote: On Sat, Oct 13, 2007 at 01:37:13PM +0100, Chris G wrote: Surely if a mail is sent to (say) ten recipients it's pretty useless to know that it got to just one of them. If all ten recipients had Eh.. no?! If you send it to 10 different recipients, with each representing a different role, then you are right. But if you have one address for several people then it is somewhat obvious, that each person is the representative of a role that only needs to acknowledge the receival of the mail _once_. Believe me: If every (currently 3) people that read the mail would acknowledge that our customer would sureley not feel this funny. But as I understand it in most 'normal' MUAs if you have one address for several people then it's split into separate messages at the sender end of things and from then on is simply a separate message to each recipient. I suppose if there's an alias for a lot of people at the receiving end then it's different but in that case it means that the return receipt is coming from the mail handling software (MTA ?) at the receiving end and not the MUA - in which case having mutt return an acknowledgement isn't going to do what you apparently want. MUAs that understood the receipt request thing wouldn't they all acknowledge? If not then it's an even more un-useful facility than No, they don't, because they ask the recipient in *every* case. That is like the postman that asks you to confirm the sending of a letter. Its only different in that he does not deliver the mail if you don't confirm the sending of a letter. Huh? How can the postman ask you to confirm the sending? Post doesn't work like that and neither does E-Mail in general. I post a letter by sticking it in a letter box, I don't hand it to the postman. Similarly I send an E-Mail by giving it to sendmail or possibly by handing it to a fairly local SMTP port, neither of those can usefully give any sort of 'proof' that the mail has gone anywhere at all. -- Chris Green
Re: How to send a return receipt
On Sat, Oct 13, 2007 at 04:30:44PM +0100, Chris G wrote: But as I understand it in most 'normal' MUAs if you have one address for several people then it's split into separate messages at the sender end of things and from then on is simply a separate message to each recipient. But in which way does that matter? The question were: Would it make sense to send confirmations from every person representating a specific role? It is a social questioning, not a technical. And the answer is a clear 'No'. at the receiving end and not the MUA - in which case having mutt return an acknowledgement isn't going to do what you apparently want. Right. mutt sending an acknowledgement is really not what I want, because that sounds like an automatism. But in fact it seems to me as it would be better, if I had a tool inside of mutt to ease myself the answering. Huh? How can the postman ask you to confirm the sending? Post doesn't work like that and neither does E-Mail in general. I post a letter by sticking it in a letter box, I don't hand it to the postman. Right, in case of normal letters. But there are registered mails (i don't know whats its name in english, actually right. Its Einschreiben in Germany), which are delivered by the postman to the hand of the recipient, who then has to sign the receival. The receiver then gets this sign as a proof that the sending _reached_ the recipient. Offcourse it is better then the mail disposition notification, but there is no better alternative that is widely supported *and* in our process this function just works, because it is not meant to be a lawcourt-safe proof that it reached us as the recipient. Regards, Patrick
Re: How to send a return receipt
On Sat, Oct 13, 2007 at 07:58:16PM +0200, Patrick Schoenfeld wrote: On Sat, Oct 13, 2007 at 04:30:44PM +0100, Chris G wrote: But as I understand it in most 'normal' MUAs if you have one address for several people then it's split into separate messages at the sender end of things and from then on is simply a separate message to each recipient. But in which way does that matter? The question were: Would it make sense to send confirmations from every person representating a specific role? It is a social questioning, not a technical. And the answer is a clear 'No'. Fine, but if what you're asking for is impossible it seems ver reasonable to say it's impossible. Huh? How can the postman ask you to confirm the sending? Post doesn't work like that and neither does E-Mail in general. I post a letter by sticking it in a letter box, I don't hand it to the postman. Right, in case of normal letters. But there are registered mails (i don't know whats its name in english, actually right. Its Einschreiben in Germany), which are delivered by the postman to the hand of the recipient, who then has to sign the receival. The receiver then gets this sign as a proof that the sending _reached_ the recipient. Offcourse it is better then the mail disposition notification, but there is no better alternative that is widely supported *and* in our process this function just works, because it is not meant to be a lawcourt-safe proof that it reached us as the recipient. But you're asking for proof that it reached us as the recipient for multiple recipients apparently, with a *single* acknowledgement. That's just not possible in any sort of system. -- Chris Green
Re: How to send a return receipt
On Sat, Oct 13, 2007 at 10:10:45PM +0100, Chris G wrote: But you're asking for proof that it reached us as the recipient for multiple recipients apparently, with a *single* acknowledgement. That's just not possible in any sort of system. No. You get me wrong, repeatedly. I'm asking for a proof that a message has reached a single role. It does not matter if more then one person can actually be the role. Patrick
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Thu 11.Oct'07 at 20:53:41 +0200 -= Simply send a regular reply: Seen and will do it. Thanks for the advice, but this ain't a solution. Why not? What is it different from what you're looking for? =- Patrick Schoenfeld wrote on Fri 12.Oct'07 at 12:33:00 +0200 -= All the mail clients I know (besides mutt) support it. Mutt can do that to, since you can configure much inside and around it to to achieve almost anything you need. You just have to do it yourself. And I don't mean source code hacks. E.g. is it possible somehow with macros to send out a specific template as the reply to a customer? Yes. -- © 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.
Re: How to send a return receipt
Hi, On Fri, Oct 12, 2007 at 05:04:22PM +0200, Rado S wrote: Why not? What is it different from what you're looking for? a lot of extra effort is the difference. You cannot really compare sending a return receipt with sending a mail, where a r-got it really isn't enough. Mutt can do that to, since you can configure much inside and around it to to achieve almost anything you need. You just have to do it yourself. And I don't mean source code hacks. Well, mutt can a lot but as I figured it does not support mail notificiation as usual, but yes possibly there are ways to reach the goal of mail notifications anyway -- at least somewhat like that. The problem is that I actually don't see a definitive way to do it, thats why I am asking it here. E.g. is it possible somehow with macros to send out a specific template as the reply to a customer? Yes. How? Any hint on appropriate docs would suffice. Regards, Patrick
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Fri 12.Oct'07 at 20:22:41 +0200 -=
On Fri, Oct 12, 2007 at 05:04:22PM +0200, Rado S wrote:
Why not?
What is it different from what you're looking for?
a lot of extra effort is the difference. You cannot really compare
sending a return receipt with sending a mail, where a r-got it
really isn't enough.
{...}
possibly there are ways to reach the goal of mail notifications
anyway -- at least somewhat like that.
Why isn't it enough? Technically it's the same as a simple reply, no?!
For the extra effort you have macros.
Technically possible and easy to get by or use are 2 different
things.
E.g. is it possible somehow with macros to send out a specific
template as the reply to a customer?
How? Any hint on appropriate docs would suffice.
You could first picture the process of sending a mail with mutt,
then you might find some spots to hook in.
Tweaking $editor and/or $sendmail can help, either a script or macro
in your editor to setup the auto-response.
--
© 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.
Re: How to send a return receipt
Hi, On Thu, Oct 11, 2007 at 01:23:13PM -0600, Charles Cazabon wrote: The concept of mail receipts is poorly designed; there is no way to implement I agree, if you look at whats given by the aspect of a evidence in law terms but it is practical if it is part of a given process between people. In our case it is even a big plus to have it. It saves us a lot of time, and helps defining a clear process between us and some of our customers. So sure it is not a reliable sign if someone got a mail, but it is enough to be more worth then just marketing blubb. *Many* of the better mail packages therefore do not implement support for it -- why have a feature if you *know* it can never work properly? Whatever you define as *better* mail packages -- I don't know them then. All the mail clients I know (besides mutt) support it. And its far from beeing perfect, but in some situations it helps. So this is the reason. But lets not discuss this anymore, because it is a discussion with no consense in sight. Maybe its possible to find a solution that helps me anyway. E.g. is it possible somehow with macros to send out a specific template as the reply to a customer? I can use colored headers to notify me about the return receipt question so there is no bigger problem with that, if I could send a confirmation email by just a key press. It's also seen as an invasion of privacy. Sorry, but I can't take that for serious. Best Regards, Patrick
Re: How to send a return receipt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, October 12 at 08:22 PM, quoth Patrick Schoenfeld: Well, mutt can a lot but as I figured it does not support mail notificiation as usual, but yes possibly there are ways to reach the goal of mail notifications anyway -- at least somewhat like that. The problem is that I actually don't see a definitive way to do it, thats why I am asking it here. Well, the first thing that springs to my mind is some sort of message-hook (since that's what triggers when you view a message). message-hook '~h Disposition-Notification-To:' 'do-something' The question then becomes: what should do-something be in that hook? Well, it can easily be a script of some sort, and that script could ask the user do you want to send a disposition notification? and act on the response. The only tricky part is getting that script to know who the notification should be sent to, and any other details of the message that it needs to know to generate the notification (I haven't read RFC 2298 thoroughly, so I don't know what all needs to be sent). It seems to me that you'd need a full copy of the message... so what the message-hook would need to do is something like this: message-hook '~h Disposition-Notification-To:' \ 'pipe-messagesend-mdn.shenter' Then, of course, you'd need to write send-mdn.sh to parse the message, pull out the required headers and other data, generate a response, and send it (possibly calling mutt to do so). I've never played with MDNs before, so I don't know what you'd need, but my guess is that in that script you can simply use formail (or DJB's 822field utility) to extract all the relevant headers, prompt the user as necessary, and so forth. Is that helpful? ~Kyle - -- Unthinking respect for authority is the greatest enemy of truth. -- Albert Einstein -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHD8UABkIOoMqOI14RAqx/AKCqasd3+vHxsUwoYEUP4/zmNVORhgCfXWTM fhnxBPqNilUyJFY2pf9DFX8= =K8wC -END PGP SIGNATURE-
Re: How to send a return receipt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, October 12 at 02:03 PM, quoth Kyle Wheeler: message-hook '~h Disposition-Notification-To:' \ 'pipe-messagesend-mdn.shenter' On considering, I think this would actually be better written: message-hook '~N ~h Disposition-Notification-To:' \ 'set my_pdecode=$pipe_decode; set pipe_decode=no; push pipe-messagesend-mdn.shenterenter-commandset pipe_decode=$my_pdecodeenter;' ~Kyle - -- Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it. -- Linus Torvalds -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHD8byBkIOoMqOI14RAhKuAJ9M1dYLXZl8jkeEwMRrZzNqK1ZpAgCfRTQz 02bmtcgKX5df/fnUEqfpkGs= =o25u -END PGP SIGNATURE-
Re: How to send a return receipt
On 10/12/07 20:22, Patrick Schoenfeld wrote: [snip] Well, mutt can a lot but as I figured it does not support mail notificiation as usual, but yes possibly there are ways to reach the goal of mail notifications anyway -- at least somewhat like that. The problem is that I actually don't see a definitive way to do it, thats why I am asking it here. E.g. is it possible somehow with macros to send out a specific template as the reply to a customer? Yes. How? Any hint on appropriate docs would suffice. Have a look at point 8.12 on this link: http://www.animalgenome.org/SmartList/FAQ.html#Section_8.12 8.12: How to send an auto-reply back when someone posts? -- #Joseph GPG KeyID: ED0E1FB7
Re: How to send a return receipt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, October 12 at 08:22 PM, quoth Patrick Schoenfeld: E.g. is it possible somehow with macros to send out a specific template as the reply to a customer? Yes. How? Any hint on appropriate docs would suffice. Oh, come on, the appropriate docs would be the *mutt* documentation, of course! Can we possibly ask a more vague or open-ended question? Check out the -H and -i flags that can be passed to mutt. They allow you to make mutt send a specific file... or you can pipe a file into mutt's stdin, and that should work as well (kinda like /bin/mail). ~Kyle - -- It is dangerous to be right when the government is wrong. -- Voltaire -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHD8XEBkIOoMqOI14RAiCqAKC7uJ1uDvOSTW64FA/rdbjR6kHuqgCeNWGa 5ZxxwQ1aAz0jlee+gAy8gKs= =duil -END PGP SIGNATURE-
Re: How to send a return receipt
Well, the first thing that springs to my mind is some sort of message-hook (since that's what triggers when you view a message). The difficulty with this approach is that you don't want to send an MDN response any time you read the message, so you need to track whether the message has ever been read and MDN-replied to. You can do this with formail -D, but that involves an external Message-ID cache, separate from the message store, wherever that might be. I suppose that's one reason that Werner chose to implement this as a patch instead of as a set of macros/script(s). But it might not be compelling for everyone. The patch certainly provides better functionality than hooks, macros, and scripts do, given the usual constraints. Whether the better functionality is necessary functionalty is debatable, but I'm not sure it's worthwhile to debate it unless committers are wavering about committing the patch. Otherwise it's clear what you should do: patch mutt if you're comfortable patching, or settle for scripts if they're sufficient. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: How to send a return receipt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, October 12 at 03:06 PM, quoth David Champion: Well, the first thing that springs to my mind is some sort of message-hook (since that's what triggers when you view a message). The difficulty with this approach is that you don't want to send an MDN response any time you read the message, so you need to track whether the message has ever been read and MDN-replied to. You can do this with formail -D, but that involves an external Message-ID cache, separate from the message store, wherever that might be. What? Poppycock. If the New flag is insufficient (and I would argue it *ought* to be sufficient), you can simply add a header to mark messages by manipulating the $editor variable. For example: message-hook '~h Disposition-Notification-To: !~h X-Disposition-Sent:' 'set my_pdecode=$pipe_decode; set my_editor=$editor; set editor=formail -a 'X-Disposition-Sent: yes'; push pipe-messagesend-mdn.shentereditenter-commandset pipe_decode=$my_pdecodeenterenter-commandset editor=$my_editorenter;' Thus, any message that does not have an X-Disposition-Sent header is a message that you haven't sent a response to, and messages that DO have such a header won't trigger the macro. The only thing that might muck with that hook is if using formail as the editor doesn't work (because it runs so quickly), in which case you'd have to wrap it in a one-line script. I suppose that's one reason that Werner chose to implement this as a patch instead of as a set of macros/script(s). But it might not be compelling for everyone. I think the reason he did it was because of convenience. The patch certainly provides better functionality than hooks, macros, and scripts do, given the usual constraints. I don't see what that missing functionality might be. Maybe I'm missing something. ~Kyle - -- Nonsense. Space is blue and birds fly through it. -- Heisenberg -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHEBK2BkIOoMqOI14RAlAaAJ9mOsCYoQSKb4jtzMGtMPfDMnKLngCg5i4U ooTY65Ks0t46vCic/us4au8= =O7++ -END PGP SIGNATURE-
Re: How to send a return receipt
The difficulty with this approach is that you don't want to send an MDN response any time you read the message, so you need to track whether the message has ever been read and MDN-replied to. You can do this with What? Poppycock. If the New flag is insufficient (and I would argue it *ought* to be sufficient), you can simply add a header to mark messages by manipulating the $editor variable. For example: So in other words, you're tracking whether the message has ever been read. I just named one way to do it; each has its merits. The patch certainly provides better functionality than hooks, macros, and scripts do, given the usual constraints. I don't see what that missing functionality might be. Maybe I'm missing something. I didn't say missing, I said better. I haven't said there's anything fundamentally wrong with your approach; it's just not as -- as you said -- convenient. But why is this an argument? -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: How to send a return receipt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, October 12 at 08:00 PM, quoth David Champion: The patch certainly provides better functionality than hooks, macros, and scripts do, given the usual constraints. I don't see what that missing functionality might be. Maybe I'm missing something. I didn't say missing, I said better. I haven't said there's anything fundamentally wrong with your approach; it's just not as -- as you said -- convenient. But why is this an argument? I guess I don't view convenience as better functionality, but rather equal functionality. If I can bend mutt to do exactly the same thing two different ways, it's equal functionality, even if one requires more keystrokes. Better functionality implies that one performs faster/more-thoroughly/more-accurately/etc. than the other. But you're right, at this point, it doesn't matter: the OP has a multitude of ways of doing it. All that remains is to quibble about whether mutt's source should include code for functions that can be performed via hooks. ~Kyle - -- To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt, 1912 -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHEEsrBkIOoMqOI14RApu7AJ9mhtGAXbGRGloWxOHFhjM9+VzjLwCeKzOw HHNl7/+TONTk7HtdmHwOVts= =wgVc -END PGP SIGNATURE-
How to send a return receipt
Hi, we have customers that send as jobs per email. Some of them set the I want to receive a return receipt-option which means that I (as the receipient) am asked if I want to send a return receipt. Technically the header set is Return-Receipt-To: with the email adress of the sender. It has become the best practice between those customers and us, that we confirm the sending of a return receipt to confirm that we have seen and will process the job (because we do not need to interact with the customer afterwards). In mutt we are not asked if we want to send such a return receipt. Is this configurable? I also read somewhere that mutt doesn't support that but I can't believe that. Is that true? Thanks in advance, best Regards Patrick signature.asc Description: Digital signature
Re: How to send a return receipt
=- schoenfeld / in-medias-res wrote on Thu 11.Oct'07 at 17:43:27 +0200 -= Some of them set the I want to receive a return receipt-option which means that I (as the receipient) am asked if I want to send a return receipt. Simply send a regular reply: Seen and will do it. -- © 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.
Re: How to send a return receipt
asked if we want to send such a return receipt. Is this configurable? I also read somewhere that mutt doesn't support that but I can't believe that. Is that true? This is correct. Mutt doesn't internally support MDNs. A patch has been posted by Werner Koch, but it might not be current. Check the mutt-dev archives. You can set up procmail or a similar mail filter to return a DSN if your mail server doesn't support it, but this lets the sender know only that the message was received, not that it was read. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: How to send a return receipt
On Thu, Oct 11, 2007 at 11:28:46AM -0500, David Champion wrote: This is correct. Mutt doesn't internally support MDNs. A patch has Uhh, thats funny... in a not funny at all way. :-( been posted by Werner Koch, but it might not be current. Check the mutt-dev archives. Hm. I will look for that patch. Any ideas why this has not been integrated into the main development tree of mutt? You can set up procmail or a similar mail filter to return a DSN if your mail server doesn't support it, but this lets the sender know only that the message was received, not that it was read. Well, actually it is more important for me to indicate that the message has been read, so this does not help me much. Thanks anyway. Regards, Patrick
Re: How to send a return receipt
On Thu, Oct 11, 2007 at 05:59:45PM +0200, Rado S wrote: Simply send a regular reply: Seen and will do it. Thanks for the advice, but this ain't a solution. Regards, Patrick
Re: How to send a return receipt
Patrick Schoenfeld [EMAIL PROTECTED] wrote: On Thu, Oct 11, 2007 at 11:28:46AM -0500, David Champion wrote: This is correct. Mutt doesn't internally support MDNs. A patch has Uhh, thats funny... in a not funny at all way. :-( been posted by Werner Koch, but it might not be current. Check the mutt-dev archives. Hm. I will look for that patch. Any ideas why this has not been integrated into the main development tree of mutt? The concept of mail receipts is poorly designed; there is no way to implement a reliable receipt notification system with SMTP mail. *Many* of the better mail packages therefore do not implement support for it -- why have a feature if you *know* it can never work properly? It's also seen as an invasion of privacy. Mail receipts are essentially one of those features that commercial MUA vendors include as a marketing checkbox feature, but which serve little or no useful purpose in the real world. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ ---
