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
encrypt to self with gpgme?
Hi everyone, I have a self configured mutt 1.5.16 with encryption via gpgme: -CRYPT_BACKEND_CLASSIC_PGP -CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME That works fine despite of this bug: http://dev.mutt.org/trac/ticket/2913 I noticed today that there is no encrypt to self functionality with this setup: set crypt_autoencrypt = no set crypt_autopgp = yes set crypt_autosign = yes # default: no set crypt_autosmime = no # default: yes set crypt_replyencrypt = yes set crypt_replysign = yes # default: no set crypt_replysignencrypted = yes # default: no set crypt_timestamp = yes set crypt_use_gpgme = yes # default: no set crypt_verify_sig = yes set pgp_auto_decode I thought this where all options regarding GnuPG. I want to use encrypt to self with mutt but I don't find any config option. Did I miss some? Assuming there is no such option, can I achieve this behaviour by some kind of hook? Greets Alex -- * http://www.lespocky.de *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 pgppNPaSWCNpI.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
Mutt Quick Reference v.1.00
Since I couldn't find one I created Mutt Quick Reference v1.0 (PDF file) especially useful for new users. It is just two pages reference and looks best when you print it on a Color Printer. I wanted to add a link to MuttWiki but I think it is locked. Anyhow, you can view it and download it from: http://www.sys-concept.com/Mutt-Quick-Reference-Letter.pdf (Letter format) http://www.sys-concept.com/Mutt-Quick-Reference-A4.pdf (A4 format Most information I collectd from Mutt manual. If you would like me to add/expand some entires with additional information just let me know. eg. under Patterns there is: ~d [MIN]-[MAX] messages with ``date-sent'' in a Date range I've added: Dates must be in DD/MM/YY format (month and year are optional, defaulting to the current month and year).eg.~d 20/1/95-31/10; -DD/MM/YY all messages before the given date will be selected; DD/MM/YY- all messages after the given date will be selected. You can add error margins to absolute dates. An error margin is a sign (+ or ? or * = + - or =), followed by a digit, followed by one of the following units: y years; m months; w weeks; d days -- #Joseph GPG KeyID: ED0E1FB7
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: Mutt Quick Reference v.1.00
On Wed, Oct 17, 2007 at 09:13:11AM -0600, Joseph wrote: Since I couldn't find one I created Mutt Quick Reference v1.0 (PDF file) especially useful for new users. #Joseph GPG KeyID: ED0E1FB7 Thanks, I'm not new user, but I'll use the guide. Tom
Re: Mutt Quick Reference v.1.00
On 17.10.2007 (09:13), Joseph wrote: Since I couldn't find one I created Mutt Quick Reference v1.0 (PDF file) especially useful for new users. Excellent work! If you would like me to add/expand some entires with additional information just let me know. As for mutt-internal stuff, I don't have any requests. (that would have to be the various flags for the index/status line -- how to read them and how to write them in the muttrc. I was wondering, though: I guess not everybody uses mairix and abook, but what about some of the commands for interaction with them in an appendix or something...? It particularly bugs me that the flag syntax for mairix is different from that of mutt -- it took me a while to remember it. Also: would you mind making the source files available (whatever format they're in)? eyolf -- There's certainly precedent for that already too. (Not claiming it's *good* precedent, mind you. :-) -- Larry Wall in [EMAIL PROTECTED]
Re: Mutt Quick Reference v.1.00
On 10/18/07 00:47, Eyolf ?strem wrote: On 17.10.2007 (09:13), Joseph wrote: Since I couldn't find one I created Mutt Quick Reference v1.0 (PDF file) especially useful for new users. Excellent work! Thanks. If you would like me to add/expand some entires with additional information just let me know. As for mutt-internal stuff, I don't have any requests. (that would have to be the various flags for the index/status line -- how to read them and how to write them in the muttrc. I was wondering, though: I guess not everybody uses mairix and abook, but what about some of the commands for interaction with them in an appendix or something...? It particularly bugs me that the flag syntax for mairix is different from that of mutt -- it took me a while to remember it. If you give me a source in OpenOffice spreadsheet, put into columns and rows all the keys, I'll do quick format and add it in. I would be interested in mairix as well as I'm using maildir format. Also: would you mind making the source files available (whatever format they're in)? I've posted everything including OpenOffice source file on one of our servers: http://www.sys-concept.com/Mutt_connections.html Enjoy. Though it would be a good idea if somebody could post a link on MuttWiki under MuttTools. -- #Joseph GPG KeyID: ED0E1FB7
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: Mutt Quick Reference v.1.00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Joseph [EMAIL PROTECTED] [10-17-07 19:47]: I would be interested in mairix as well as I'm using maildir format. jfyi, mairix now also works with mbox files :^) - -- 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) iD8DBQFHFqsiClSjbQz1U5oRAqtUAJ9x4OkdvBmz8QrrJ1INb1mL2CuzHgCfcZB4 aUmY369Kl/As3zuaKJ3hOz8= =2gNs -END PGP SIGNATURE-
Flagged messages with mairix
Hi, I just finished setting up mairix, and it seems pretty good. In particular, I like the feature that I can view flagged messages from all the mailboxes in one list. One feature that I think would be nice to have, is the ability to make the changes to the flag stick to the original mailbox. For example, if I unflag/ flag a message in the search result (which is a temp mailbox), the corresponding changes should be visible in the original mailbox. Does anyone know if there is some existing script that does this? I am using maildirs everywhere, so just changing the filename of the corresponding file should do it for me. In the case of mboxes though, you would need to manipulate the X-Status header. So I guess writing a script that does this should be fairly easy, but I dont want to reinvent the wheel. -- Regards, Ajeet
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
Using Mairix
I just installed Mairix, and the program works fine, except that I don't seem to be able to access the mfolder from within Mutt. When I do a search Mairix creates the requiste mfolder containing cur, new, and tmp, and the result of the search is placed in the new subdirectory. But I am unable to access the results of the search in the Mutt index. The mfolder shows up in the index, but it is empty. Anyone tell me what I am doing wrong? Rem
