Re: Howto run a command in message hooks (was: Re: How to send a
Hey Karl, it may have sounded arrogant, but indeed it wasn't intended to sound that. But... On Thu, Oct 25, 2007 at 10:35:31AM +1300, Karl. wrote: > Given that you asked for advice, perhaps you should work on accepting > all advice _graciously_, rather than being arrogant? You'll find it a You are right. Given that I'm the one searching for advise, I should not bite into the hand of people that could probably give it to me. But I didn't think that I do, because in my opinion I just told him, that the requested information is already there (and I confirmed it with my first reply to him). Given that I needed to confirm it a second time to him, my reply was a bit rude, yes, and I'm sorry for that. > The list archives are littered with examples of people declaring that "I > have done exactly what you told me to do" and then finding out that they > had not. His request was entirely reasonable. Your response just puts IMHO that case is different from the current case. 1) I wasn't following an advice to set it executable, but checked it myself before I've written the help request. 2) I already indicated twice that I checked it (and after telling it a second time, one should be sure that I really did it and not just tell it). So IMHO his first request was just a sign that he does not trust me that I am telling the truth (but maybe reasonable), but his second request wasn't reasonable anymore. > you higher on the list of people who are not worth responding to (unless > it's amusing to :-) I know that *I* were searching for advice and therefore should provide verbose informations to avoid unneccesary effort on the side of someone who could help me. But the other way round is true. Just because I'm asking for help I'm not forced to accept _all_ conditions and _wasting_ _my_ time w/o sense do I not have to accept. Off course you are write that it could mean that I won't get help. Thats bitter, but unavoidable. Best Regards, Patrick
Re: Howto run a command in message hooks (was: Re: How to send a
On Wed, Oct 24, 2007 at 01:39:17PM -0400, Patrick Shanahan wrote: > ls -la ~/.mutt/return_receipt You should work on you ability to _read_ mails others write _properly_. I told you, that the file _is_ executable. And as you eventually noticed someone else already pointed the right solution out to me, which were not a missing executable flag. -Patrick
Re: Howto run a command in message hooks
On Wed, Oct 24, 2007 at 05:30:45PM +0200, Christian Brabandt wrote: > If you have used I think your stdin has changed to the > messages you piped. And read expects your answer from that filehandle. > So you might try explicitly setting your tty with read yn
Re: Howto run a command in message hooks
Hi Christian,
On Wed, Oct 24, 2007 at 04:56:13PM +0200, Christian Brabandt wrote:
> Do you mind formating your message with a width < 80 chars?
no, thats no problem.
> Depending on what your want try either or
Hm. That and what Dave Evans wrote works, at least partially. Now the
script is launched, but it does not work as expected. It starts the
script which outputs:
User has asked for a return receipt. Send one? ([yes]/no):
and waits for an input ("read yn"), but mutt adds its "Press any key to
continue...". So it seems that mutt already answers the question (what
it shouldn't do). Also if I do press return to that question, it
restarts the script and the game starts from the beginning. Endless,
until i somehow force it to quit (not that easy).
The (for now very basic script):
#!/bin/sh
TEMP="`mktemp`"
trap "rm -f $TEMP" INT ABRT EXIT
tee > $TEMP
QUESTION="User has asked for a return receipt. Send one? ([yes]/no): "
echo -n $QUESTION
read yn
(I know that this is far from beeing complete, but to test how things
would work it is enough)
Any hints?
Regards,
Patrick
Re: Howto run a command in message hooks (was: Re: How to send a
On Wed, Oct 24, 2007 at 04:53:23PM +0200, Patrick Schoenfeld wrote: > What information do you expect me to presentate? Eventually my whole mutt > configuration just to ask why one specific message-hook (which I presentated) > is not working? There is only one information that I see that I really missed to presentate: [EMAIL PROTECTED] ~ % mutt -v Mutt 1.5.16 (2007-06-11) -Patrick
Re: Howto run a command in message hooks (was: Re: How to send a
On Wed, Oct 24, 2007 at 10:47:58AM -0400, Patrick Shanahan wrote: > * Patrick Schoenfeld <[EMAIL PROTECTED]> [10-24-07 10:42]: > > And even though the specified file is a valid executable script mutt says > > (when > > I open this mail in the pager): > > first *guess* w/b that ~/.mutt/return_receipt script was not Whats so hard to understand about ".. is a valid executable script .. "? > executable, but you have really presented little information. What information do you expect me to presentate? Eventually my whole mutt configuration just to ask why one specific message-hook (which I presentated) is not working? -Patrick
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: account-hook, imap_pass not used ?
Hi, On Wed, Oct 24, 2007 at 12:25:03PM +0200, Nicolas KOWALSKI wrote: > I am trying to use multiple IMAP accounts. Following the Wiki, I use > these settings: I have not yet used this multiple IMAP accounts, so I don't know this for certain, but.. > account-hook . 'unset imap_pass' ... my instinct tells me that this is the reason, because it is a default hook, causing set imap_pass to be unset. Is your default account listed with an own account-hook? Sorry, if I may be wrong. Regards, Patrick
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
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
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 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?
Re: How to send a return receipt
On Mon, Oct 22, 2007 at 09:52:58AM +0200, Stephan Seitz wrote: > Then you don’t want a delivery notfication, you want read-it Nobody were saying that. We talk about "return receipts". > notification. That is in my eyes a very big difference. A delivery Not of concern. See above. > 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. Surveillance or Monitoring? OMG! This FUD-argument about privacy invasion and a such were discussed about 20 times in this thread. And after all it should be clear, that there is _no_ privacy invasion and that it is _impossible_ to use return receipts for surveillance or monitoring. Actually monitoring an employee by asking him to tell if he does bad things is worth nothing for people who want to monitor 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. Blah. Its shouldn't be part of this discussion weither calendars and cook books and coffee machines should be part of mutt. We are talking about return receipts. Thats not groupware, that is pure and simple email functionality. And that is what mutt is -- a mail user agent. Nobody (at least not in this thread) is asking to support everything a secretary in an office does as part of mutts builtin features. But without return receipts its like mutt is not even providing a _basic_ _needed_ functionality subset _completely_. -Patrick
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
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
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 04:10:22AM -0700, David Ellement wrote: > 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. Yes. Thanks for pointing that out. It seems I express myself unclear, because I am in need to repeat everything over and over again. But when I read replies like yours I feel lucky that I obviously don't. :-)) Patrick
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
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 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
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
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
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 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
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 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
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
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
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
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 limit displayed messages via folder-hooks
On Sat, Oct 06, 2007 at 12:19:00PM -0700, Gary Johnson wrote: > 'limit' is a function, not a command. folder-hooks execute commands Ahh. I understand. Thanks for pointing this out. > not functions. However, the 'push' and 'exec' commands will execute > functions. So one solution would be this: >folder-hook =Mailinglisten.mutt-users 'push ~N' Yep, that does the trick. Thanks for it. > You don't need a default hook to "limit all" because the limit list > is cleared when you change folders. Okay, thats good to know. Thanks to all, helping me with this. Regards, Patrick signature.asc Description: Digital signature
How to limit displayed messages via folder-hooks
Hi, i am reading several mailing lists (including mutt-users) and prefer to view those folders with 'limit ~N'. But it seems not to be possible to enable this limit for folders by default, by using folder-hooks. Example: folder-hook . 'limit all' folder-hook =Mailinglisten.mutt-users 'limit ~N' It says that limit is an unknown command. But why? According to the help texts with '?' this is exactly the command hiding behind the keybinding 'l'. What would I need to do in order to achieve what I want? Thanks in advance, Best Regards Patrick signature.asc Description: Digital signature
Mutt and and IMAP Folders (Namespaces / Prefixes)
Hi, I intend to use mutt in the feature for reading/writing emails. However, besides some defaults that seem strange to me, it is good. But I am experiencing problems with IMAP. Scenario: Our companies imap server is a dovecot imap server, migrated from an earlier courier imap. So this one has an INBOX. prefix before each folder. Thats annoying, but it is. So now the question is: How to setup mutt, so that working with this is posssible efficient? Configuration in .muttrc: set imap_user = X set imap_pass = X set folder = imap://[EMAIL PROTECTED]/INBOX. set spoolfile = imap://[EMAIL PROTECTED]/INBOX set record = imap://[EMAIL PROTECTED]/INBOX.Sent set postponed = imap://[EMAIL PROTECTED]/INBOX.Drafts This configuration works so far, that I can change to folders via 'c'. If i remove the point at the end of set folder I cannot see any folder except INBOX. Not working are the shorthand to call e.g. INBOX.Mailinglisten.mutt-users by =Mailinglisten.mutt-users. I could really need this to work with my folder structure. So can somebody give me a hint on how to fix this? Is this fixable at all? If possible I would like to avoid the use of an imap syncer. Regards, Patrick signature.asc Description: Digital signature
