Re: format string: time for today, date for others.
* On 05 Jan 2011, Toby Cubitt wrote: is dated less than 24h before the current time. That's *not* what I'm after. When the current time is 00:01 on the 6 Jan, I want an email that arrived at 23:59 on the 5 Jan to display Sun 05, even though the email is only two minutes old. I understand now. In your first post I read emphasis in the multiple conditionality, not in the idea that yesterday is not the same as less than one day ago. Does your patch still support the original behavior of date_conditional? I personally don't want everything to change at midnight. (I'm more sensitive to how long ago something happened than to what day it was at the time.) But if your version does both it's a more complete feature, and I'm interested it using it instead. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: format string: time for today, date for others.
* On 05 Jan 2011, Yue Wu wrote: Hi list, Is there a date/time string that show the time only for today's emails but date for else? So, in the index, the emails that got today will show the time only, but the ones that got on other days will show the date and time. Not in out-of-box mutt. For that you need the date_conditional patch by Aaron Schrab. I don't see a version on the web that is rebased against current mutt but I can send you one if you're comfortable patching and compiling your own mutt. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: format string: time for today, date for others.
* On 05 Jan 2011, Toby Cubitt wrote: If I remember correctly, the date_conditional patch doesn't *quite* let you have a different date/time string for today, rather it gives you a different date/time string for the last 24h. The best documentation I've seen is the changelog entry that I wrote for my mercurial patch queue: Allows you to construct format expressions based on relative dates. This adds conditionality features to mutt's date-formatting operators, so that you can build conditions based on whether the date in question is less than or grater than some amount in the past. Example: %?[1y?less than one yeargreater than one year? Example: %?[3d?less than three daysgreater than three days? This is particularly useful in concert with nested_if. For example, this expression: %[1y?%[1w?%[1d?%[ %H:%M]%[%a %d]%[%b %d]%[%y%m%d] means to show the YYMMDD date for messages older than one year, the mon dd date for messages from one week to one year, the day dd date for messages from 1 to 7 days old, and the HH:MM time for messages under one day old. So it can handle a single split point as it stands (less than 24h, greater than 24h). A while back, I wrote a modified version of the date_conditional patch so that it could be used to produce different formats for mails from today, from the current month, from the current year, etc. I haven't gotten around to making it available online, but if you want a copy I'd be happy to mail it to you. That's what I want as well, but I do it by using date_conditional in conjunction with the more general nested_if patch. Nested_if, as its name suggests, lets you nest mutt's ternary conditionals arbitrarily deep. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: format string: time for today, date for others.
* On 05 Jan 2011, Toby Cubitt wrote: Yes, but how would you use this to e.g. print only the time for all emails received today, but print the date for all emails received yesterday or earlier? A split point of 24h is no use. If it's currently That's what nested_if is for. Here is the date string from my $index_format: %[1y?%[1w?%[1d?%[ %H:%M]%[%a %d]%[%b %d]%[%y%m%d] that is, if 1y: if 1w: if 1d: %H:%M else: # = 1d %a %d else: # = 1w %b %d else: # = 1y %y%m%d It does work, or I've been misreading my index for the last 5 years. ;) -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: Can one fix the directory for saving attachments?
* On 20 Nov 2010, Chris G wrote: By default mutt saves attachments in the current directory (i.e. in the directory in which it was started). In my case this is often somewhere completely random and most definitely isn't where I want to save attachments. Apart from being careful about the dreictory from which I start mutt is there any way to force it to always save attachments to the same place (for example ~/tmp)? I have recently begun wanting to do this, and created this macro: macro attach S save-entrybol~/maildrop/enter Save to maildrop folder (~/maildrop is a zfs filesystem on my opensolaris server that is nfs-exported to an IP address controlled by OpenVPN. I use OpenVPN client on my Macbook and mount maildrop wherever I go.) -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: attachment count issue with multipart messages
* On 10 Nov 2010, Will Fiveash wrote: I've received a message from an iPhone that has a MIME structure as follows: 1 no description [multipa/alternativ, 7bit, 48K] Mutt's attachment counter does not recurse through multipart/alternative MIME parts. See parse.c:1556. I checked the latest version of this patch that I made before it was mainlined 5 years ago. While several things were simplified to get that patch upstream, it has the same logic for multipart/alternative. I'm afraid I don't remember for sure why I made this choice, but it's probably because there's no objective basis for deciding which alternative in a multipart/alternative should be analyzed. Counting attachments among all available alternatives is almost certainly not what a user wants. In principle the attachment counter could follow display rules and choose the preferred alternative based upon alternative_order, etc. This crosses an imaginary boundary between describing the absolute structure of the message and making subjective decisions about interpretation, but there's nothing logically incorrect about it. However there could be unwated computational expense in that approach. In 2005 at least there was pretty serious concern about the computational cost of counting attachments at all, so in order to get the code upsteam I took all possible steps to minimize that. 2 ??no description [text/plain, 7bit, 0.1K] 3 ??no description [multipa/related, 7bit, 47K] 4 ??no description [text/html, 7bit, 0.5K] 5 ??Photo [image/jpeg, base64, 46K] Note that when iPhone sends a multipart/related message with text and image parts -- when it sends just the mp/related subtree of the message you have -- mutt does notice and count the jpeg. (I tested this by sending email from the SMS/MMS app on an iPhone.) So it's certain that your problem is caused by having a mp/alternative that envelops the mp/related. Michelle Konzack wrote that iPhone's appraoch is wrong. I guess it's somewhat a matter of interpretation: is the text message a textual representation of an HTML message that includes one JPEG, or does the JPEG accompany a message which can be represented as HTML or as text? It probably depends on how you see the relationship between the image and the message. FWIW I tend to agree with Michelle but I can see where iPhone developers might think otherwise. Even so though, your problem is a mutt limitation and not inherent to the MIME structure, which is completely legitimate even if it is conceptually flawed. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: attachments in index without patching
* On 09 Nov 2010, Francesco de Virgilio wrote:
Hi all,
show at least if the mail has any attachment in the index? I don't
want the exact number of attachments, but only I want to know if there
is any.
Yes, I know there's a patch for this, here [1] but really don't want
[1] http://home.uchicago.edu/~dgc/mutt/#attach
This patch was incorporated upstream here:
changeset: 4412:5a347f860ec3
branch: HEAD
user:David Champion d...@uchicago.edu
date:Tue Oct 04 06:05:39 2005 +
summary: Attachment counting for index display (patch-1.5.11.dgc.attach.6).
Which according to mercurial was released in 1.5.12:
$ hg parents --template='{latesttag}+{latesttagdistance}\n' -r 5a347f860ec3
mutt-1-5-11-rel+99
So your 1.5.20 should include it. You may be reading old
documentation, epecially if you're looking on http://www.mutt.org.
See http://dev.mutt.org/doc/manual.html#index-format and
http://dev.mutt.org/doc/manual.html#attachments for the most current
version.
--
David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: change order of attachments in compose mode
* On 25 Oct 2010, Eric Smith wrote: Is this possible? Not out of the box, but I wrote a patch that allows it. Original: Message-ID: 20030311223336.gf6...@dust.uchicago.edu http://marc.info/?l=mutt-devm=104742220831941w=2 Current version of this patch: http://paste.org/pastebin/view/23999 -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: batch deleting
* On 08 Oct 2010, Robert Holtzman wrote: On Fri, Oct 08, 2010 at 09:08:50AM -0300, Monte Stevens wrote: On Fri, Oct 08, 2010 at 12:29:31AM -0700, Robert Holtzman wrote: I can't find a way to delete a specifie range of messages, ie message #1-1000. If it's in the docs I missed it and a search turned up nothing of value. Is ~m what you want? You lost me. I don't see it in the help menu or the docs. What did I miss. When I tried it I got the new mail template (as expected). ~m1-1000 is a search expression. You can enter that to tag messages and then deleted tagged messages, or you can delete by pattern. Most search patterns begin with ~ and most times someone speaks of something that begins with ~ they're talking about a search pattern. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: is it possible to set pager search pattern based on message-hook?
* On 28 Sep 2010, Will Fiveash wrote: I'd like to set search to a particular pattern when I view a message with a particular subject. The reason I want this is that some messages I receive have sections with section delimiters and I want search initialized to that delimiter pattern. Is this possible and if so can someone give me a hint as to how? message-hook '~s pattern' 'macro pager n searchkill-line^===enter; macro pager / bind pager n search-next; bind pager / search; push /' message-hook . 'bind pager n search-next' Untested (naturally) and probably doesn't work due to quoting, but maybe a start. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: How to match all theaded emails excluding the first one?
* On 20 Sep 2010, Marco Giusti wrote: I got another idea that uses mutt's thread capability. I test it but i didn't create a macro (because I'm lazy) and I leave it to you as exercise. I have used this technique before. It works well. Uncollapse all threads (Esc+V), tag all messages (T and '.' as pattern), collapse all threads (Esc+V again) tag all messages (T and '.' again). ITYM untag for the second pass :) The tricky part of macrofying it is that collapse-all is a toggle, so you have to assume the initial state of your folder. Assuming you start out uncollapsed: macro index =tS tag-pattern.entercollapse-alluntag-pattern.entercollapse-all tag all non-initial messages in threads You can of course extend this technique to work on the current thread. macro index =ts enter-commandset my_resolve=$resolve; set resolve=noentertag-threadcollapse-threadtag-messagecollapse-threadenter-commandset move=$my_resolveenter tag non-initial messages in current thread -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: Taking notes using Mutt threads
* On 30 Aug 2010, mjsseppl-m...@yahoo.de wrote: On a more general level, regarding Jose's idea: What are the ways to send local messages so that they end up in the mail spool file? It seems to me a simple question and I seem to remember being able to do it, but now when I try to remember how I did it, I can't find the way. set my_real_sendmail=$sendmail set sendmail=procmail [send note] set sendmail=$my_real_sendmail -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: 1.5.20 and sidebar
* On 31 Aug 2010, fe...@crowfix.com wrote: So here is my 'mudd' command which is used as mailboxes `~/bin/mudd` Tangent: I don't have this exact need, but I have similar requirements for building dynamic configuration. A trick I use is to create a script whose output is a (partial) mutt configuration file. In your case, the script could be a slight modification of 'mudd' which outputs: mailboxes =folder1 mailboxes =folder2 mailboxes =folderN ... then I source it from .muttrc as: source ~/bin/myscript | The | at the end makes mutt execute the script and interpret its output as if it appeared right there in .muttrc. It's very much like using backquotes, but you can make the script much simpler because any config command can be emitted at any time, with less need for tracking state information or compiling arrays. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: Taking notes using Mutt threads
* On 29 Aug 2010, Chip Camden wrote: I often find that I want to copy text from an email into another file. Rather than reaching for the mouse to highlight the text and then start my editor and paste it, I just forward the message to myself without actually sending it. Since my email editor is vim, I can then yank the text from the almost-forwarded message and then open the other file and paste it. Then quit the original file and press 'n' to avoid sending it. Anyone have an even easier hack? Do you have a command-line tool that copies stdin to your pasteboard or clipboard? (MacOS X has pbcopy. When I used X11, I used an Xaw program called 'xcb' for similar purposes. I see references to something called 'xclip', but I don't know what's current in the window managers people use these days.) Use that as your print command, or embed it in a macro to accomplish the same via pipe-message or decode-copy. In the latter approach you can add dressing to select only the decoded message body, etc. You likely can paste with a similar solution -- pbpaste on MacOS, or xcb/xclip/whatever on X11. '!!pbpaste' is pretty easy vs. ':r /tmp/some-draft-file'. -- David Champion * d...@uchicago.edu * IT Services * University of Chicago
Re: sending an email with a mutt one-line without being prompted
* On 09 Aug 2010, Derek Martin wrote:
$ mutt [...] -a `echo *|tr ' ' \$DELIMITER\` $RECIPIENT
or something of the sort. Of course, then you have either the
spaces-in-filenames problem, or the delimiter-in-filenames problem.
Or both.
If we're actually going to revisit this in -dev, I'll reiterate my
suggestion from back then:
mutt -a { *.jpg } $RECIPIENT
I don't think that needing to attach files named '{' or '}' from the
command line is a very common problem. But I also don't think that
what we have is such a problem that it must be changed, so long as it's
properly documented in usage and the manual.
--
-D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
* On 03 Aug 2010, Nicolas Williams wrote:
On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
On 2010-08-02, Nicolas Williams nicolas.willi...@oracle.com wrote:
Right. There's no good convention for end of list of arguments to an
option. There's only a good convention for end of variable argument
list ('--'), and since this is the closest thing...
And since there _is_ a convention that '--' ends the option list, it's
A Bad Thing(TM) to use it for something else. I think violating the
almost universal convention about what '--' means is a terrible idea,
but apparently we're now stuck with it.
The convention is that '--' ends the entire option list, not a list of
arguments to a single option. Therefore mutt clearly uses something
other than the existing convention.
Strictly speaking, no: since mutt requires the -a option to be last,
a '--' terminating the list of arguments to -a implicitly terminates
the option list as well. I think this may have been part of the design
consideration.
--
-D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
* On 03 Aug 2010, Grant Edwards wrote: Strictly speaking, no: since mutt requires the -a option to be last, a '--' terminating the list of arguments to -a implicitly terminates the option list as well. I think this may have been part of the design consideration. IMO, requiring that unrelated options be present in a certain order is also a bad idea. What we have wouldn't have been my solution, but this solution got there first with a patch. Unless there's a patch implementing something else and a problem statement or use case to justify changing the interface (again), I think this is a solved problem from the maintenance point of view. :) We three agree that we don't *like* this syntax, but is anything operationally broken about it -- can any commonplace operation not be accomplished, or does it require a bizarre workaround? Nothing like that has been demonstrated. -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
* On 02 Aug 2010, Nicolas Williams wrote: On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: Syntax has been changed: -a indicates a *list* of attachment files ending with --. I don't recall which version was first to boast this new syntax, but it's the problem you're seeing right now even if it's not related to the problem you saw earlier. Try: mutt -s test -a Bild.jpg -- m...@some.org body.txt I recommend against this use of '--'. It makes it harder to write wrapper scripts that parse the same arguments using getopt/ getopts, for example. Sadly, I don't have a counter-proposal, nor am I suggesting this get ripped out now. I'm not fond of it either, but there was fairly extensive discussion when it was committed in April 2007. See mutt-users 20070320122350.ga25...@giotto.argoss.nl and mutt-dev 20070321193650.gb2...@df7cb.de for thread heads. I think your specific concern may be exempted by the implementation used. -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
* On 01 Aug 2010, Christoph Kukulies wrote: k...@post:~$ mutt -s test k...@validaddress.debody.txt Error sending message, child exited 1 (). Segmentation fault This should work. Maybe you could try to upgrade mutt to the most recent version 1.5.20? I tried it on another machine (ubuntu) and there it says k...@accms33:~$ mutt -s test -a Bild.jpg m...@some.org body.txt Keine Empf?nger angegeben. Syntax has been changed: -a indicates a *list* of attachment files ending with --. I don't recall which version was first to boast this new syntax, but it's the problem you're seeing right now even if it's not related to the problem you saw earlier. Try: mutt -s test -a Bild.jpg -- m...@some.org body.txt -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: Suggestion when saving mails
* On 21 Jul 2010, Roger wrote: Since I'm always saving/moving email to $HOME/.maildir/.Spam... you would think Mutt would catch-on after the 10th email. ;-) I attach the following macros to the z key in my .muttrc macro index z s=mutt/spam\n move message to spam macro pager z s=mutt/spam\n move message to spam And then i can just z(ap) any nasty spam. Ah. Thanks Steve. Wasn't going to get around to configuring save-hook for awhile, but since you mention this, I'll likely deploy it here. ;-) I assume your goal in saving stuff you know is spam is to finely train your spam analysis engine. Consider using the spam directive with this. For example: # SpamAssassin markup catcher. spam X-Spam-Status: Yes, score=([^ ]+) SA:%1 # Add more patterns as needed for other spam engines you use. # Save known spam to spam folder for bayesian analysis. fcc-save-hook ~H . =spam # Augment this with macros to save uncaught spam and false positives. # (I use ^S as a prefix for a variety of spam-related functions.) macro index \Css save-message=spamenter message is spam macro pager \Css save-message=spamenterexit message is spam macro index \Csn save-message=notspamenter message is not spam macro pager \Csn save-message=notspamenterexit message is not spam If that's not your goal, I'm not sure why you're saving spam. :) -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: text/html change from 1.5.18 to 1.5.20
* On 16 Jul 2010, Michelle Konzack wrote: Shouldn't %s be the preferred form as mutt creates a unique file in /tmp, so creating it manually shouldn't be necessary. No it does not. The file is always called /tmp/mutt.html and if you run a Multi-User Environment and several peoples login using SSH and run mutt you get the hell on the ass. http://www.mutt.org/doc/manual/manual.html#toc5.3 5.3 MIME Viewer configuration with mailcap nametemplate=template This field specifies the format for the file denoted by %s in the command fields. Certain programs will require a certain file extension, for instance, to correctly view a file. For instance, lynx will only interpret a file as text/html if the file ends in .html. So, you would specify lynx as a text/html viewer with a line in the mailcap file like: text/html; lynx %s; nametemplate=%s.html -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: return reciepts
* On 28 Jun 2010, lee wrote: Hi, how do you handle return reciepts with mutt? I know I can add header lines to request a reciept (with my_hdr), but how do I make it so that reciepts are requested based on, for example, recipients? You could try Werner Koch's rfc2298 MDN patch, but afaik it has not been updated in years and probably needs some love. http://intevation.de/roundup/aegypten/file34/mutt-patch-1.5.6cvs.g10.mdn.1.asc -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago http://www.chicagomaroon.com/2010/5/28/spring-sprout
Re: Soft killfile, folder-hook limit
* On 03 Feb 2010, Andre Majorel wrote: I'm trying to set up a sort of soft killfile whereby messages from a certain address are not shown. That would be folder-hook . limit ~A folder-hook infestedlimit ! ~f annoy...@gmail.com right ? Except that there's no limit command. Is there a way around that ? Limit is a function that you bind to a key. To tell mutt to execute a function, you use the push command. This emulates keystrokes by pushing them into the keyboard input queue. folder-hook .'push limit~Aenter' folder-hook infested 'push limit! ~f annoy...@gmail.comenter' -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: List management headers
* On 26 Jan 2010, Tim Gray wrote: Yeah. It would be nice if you didn't have to weed through 3 screens of headers to find the right link. Like a 'list details' command that extracted the appropriate links/emails from the headers and let you open the right links or send a mail to the right address. I would love to see RFC2369 handling built in to mutt, but have not had time to explore this in code. I'm certain there are others here who would cite the Unix Philosophy or whatever, and assert that an external program could do this as effectively and with cleaner layering. In any case that solution is perhaps more approachable for someone with time to look into the problem. Such a program might work like urlview: parse out List-* headers from a piped-in message and display a menu of options that these headers present (and then generate and submit mail messages as appropriate). -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: Terminal for mutt (Poll)
* On 08 Oct 2009, Charlie Kester wrote: On Thu 08 Oct 2009 at 02:14:32 PDT Michael wrote: Black on white for me. Getting old and white on black is hard for my eyes. Good to know I'm not the only one! I read somewhere that when your eyes get older, they have more difficulty picking out the subtle differences between light shapes on a dark background. I know that's true for me. When I was younger, I did all my programming with the lights out and a black background to my screens. If I try that now, I find I have a hard time focusing and keeping track of which line I'm on. No such problems when I use a light background. I certainly like my books printed dark on light, but screens are a different matter: light emission, not light reflection. I find that I can get more legible contrast from light text on dark background than from dark on light, after taking into account the range of ANSI colors that I want to read (which generally aren't part of book-reading, either.) I use #b8b8d8 on #282840 for mutt. High contrast is very hard on my eyes whether it's b-w or w-b. -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: Regexps suddenly case-sensitive?
* On 02 Oct 2009, Joost Kremers wrote: For some reason, since I did the OS upgrade, mutt's regular expressions are case-sensitive. I noticed this with several hooks that use regexps and also with the variable reply_regexp, which all of a sudden doesn't match capitalized Re: anymore, with the result that when I reply to a message, an additional Re: is added to the subject line, even if it begins with Re: already. I hadn't changed it from the default value, which always worked fine. A regex that is all lowercase matches insensitively. A regex that contains uppercase is case-sensitive. I changed reply_regexp to ^(Re([\\[0-9\\]+])*|Aw):[ \t]*, and then noticed Use ^(re([\\[0-9\\]+])*|aw):[ \t]* and see whether the behavior changes. -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: multipart/alternative question
* On 16 Jul 2009, Tim Gray wrote: I 1 no description[multipa/alterna, 7bit, 653K] I 2 |-no description [text/plain, utf-8, 2.0K] I 3 `-no description [multipa/mixed, 7bit, 651K] I 4 |-no description [text/html, quoted, windows-1252, 3.0K] I 5 |-Typeface Ideas.pdf [applica/pdf ...] I 6 `-no description [text/html, 7bit, us-ascii, 0.2K] This is exactly what I'm dealing with. Though sometimes it's not multipart/mixed but multipart/relative. Regardless, I was not able to set up attachment detection properly to pick up the application/pdf. It's actually not possible in this case. Message and multipart are the two major MIME categories which are containers. All other types are atomic, but these two always exist to contain other components (which may themselves be atomic or containers). The attachment-counting algorithm has a flag that decides whether to traverse (recurse) the container types while looking for attachments that qualify by your attachments rules. Multipart/alternative containers are specifically excluded from ever being traversed. Why? Because mutt at this stage has no way of knowing which alternative in a multipart/alternative you want looked at. It either needs to count all attachments within the multipart/alternative, which is most assuredly exactly the thing you least want, or it needs to guess which alternative represents the view that you want counted. So it ignores multipart/alternatives. However, I think that when mailers are behaving well, that's a fine decision. How often should an attachment that you're truly interested in actually be part of the multipart/alternative enclosure? I would argue that Apple's arrangement here, while valid MIME, is not a faithful representation of what the sender intended to send. She has a letter with an inlined PDF in the middle of it. If Apple Mail is honoring her intent, the children of the mp/alternative part should be two multipart/mixed parts, each containing two text parts with a PDF sandwiched in the middle. It eats space (unless you cite content by reference, as with cid: naming), but what Apple Mail has done excludes the PDF content from visibility in the text/plain view. So does that exist as an attachment or not? It depends on whether you're reading text or HTML. The best combination of efficiency and accuracy for this message would have been: multipart/mixed |- multipart/alternative | |- multipart/mixed | | |- text/plain | | |- application/pdf (reference, no content) | | `- text/plain | `- multipart/mixed | |- text/html | |- application/pdf (reference, no content) | `- text/html `- application/pdf (referent) ... but mutt doesn't support cid: references, so this wouldn't help us. :/ If you have ideas for how mutt could deal with this conundrum in a way that's compliant, consistent, and user-centered, I'm interested to hear. I'm not sure whether I'll have time to update the code, but it would be good to get the ideas onto the table. -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: multipart/alternative question
* On 16 Jul 2009, Kyle Wheeler wrote: Multipart/alternative containers are specifically excluded from ever being traversed. Why? Because mutt at this stage has no way of knowing which alternative in a multipart/alternative you want looked at. Well, it's not an issue of which alternative I want to look at, because even if the attachment counter obeyed my alternative_order rules, I prefer to look at the text alternative. I mean which alternative you want the attachment counter to look at. Thus, for attachment counting purposes, we can reasonably decide to ALWAYS count *only* the attachments within the last alternative in a multipart/alternative MIME section. That's the one that should best reflect the original content, and thus that's the one that best reflects the intention of the user. It's technically possible to have I think the RFC is leaves a lot of room for ambiguity, and this isn't necessarily what anyone wants to happen, but I'll agree that it seems like the most defensible last effort possible. If you want to add a config option to allow it to count ALL alternatives, that's fine by me, but I think counting only the last alternative is perfectly reasonable and compliant. When this code was a patch, long back in the 1.3 days, there was a means of instructing mutt how to descend containers while counting attachments. IIRC we decided to drop that in favor of simplicity. It was more important to me to get the code pushed upstream than to maintain options. The thing I like about this idea is that if someone sends a multipart/alternative that has the attachment in an earlier component but not a later component, we can point to the RFC and say you're doing it wrong; the LAST component is the one that's supposed to have all the fancy stuff. (I.e. the choice to count only the last alternative is a defensible one.) Not necessarily. The RFC says that if the alternatives are unequal (whatever that might mean), then the last is the richest. What if the first is HTML with an inline addition, and the second is a PDF with all content inlined within the PDF? This isn't incorrect because the HTML is not richer, fancier, or more faithful than the PDF. It just requires more parts (in this hypothetical case; certainly this is not necessary for any hypothetical case.). I think it all depends on what you mean by intent. Another way of looking at it is that Apple sent me her original content, formatted exactly the way she wanted, and additionally sent me a text-like representation of what she sent, just in case I can't render HTML. OK, instead of intent let me amend my previous statement to say best representation in an unintended encoding of what she meant for you to see. I don't think it changes anything dramatically. The best combination of efficiency and accuracy for this message would have been: multipart/mixed |- multipart/alternative | |- multipart/mixed | | |- text/plain | | |- application/pdf (reference, no content) | | `- text/plain | `- multipart/mixed | |- text/html | |- application/pdf (reference, no content) | `- text/html `- application/pdf (referent) Yeah, but... that's so ugly and inefficient, I don't blame Apple for sending a smaller, simpler message (that complies with the letter and original spirit of the RFC). It's not really. Maybe it's ugly if you don't like looking at structure documents and suddenly you have to, but this is very straightforward and reasonable and not at all inefficient for a computer to process. A MIME boundary is very cheap. Maybe it looks cleaner to consider it as: message alternative-set alternative text/ pdf reference=blah/ text/ /alternative alternative html/ pdf reference=blah/ html/ /alternative /alternative-set pdf id=blah /message That's not very ugly or inefficient, as XML documents go. By the way... would mutt's attachment counting view that as three attachments or only one? (Yes, I know multipart/alternatives are ignored, but let's say the structure was flattened a bit.) In other words, does mutt's attachment counting understand references? Nothing in mutt understands references. When being counted, a MIME component is evaluated strictly by its Content-type and Content-disposition. -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: Bookmarks?
* On 08 Jun 2009, Cameron Simpson wrote: Personally I wish I could go to a message by Message-ID. Then stuff could be build on top of that as open mailbox, go to message-id. Different from this? ;) search~i 20090609040352.ga18...@cskk.homeip.netenter I use this pattern in a patch that lets me bind a macro to the current message, so that I can return to it later or alternate between two points in my mailbox. (In case that's interesting, it's here: http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.1.dgc.markmsg.2 .) This or even more complex things (such as you suggest) might be possible with a macro that copies the message to a file, runs a script on it, and evaluates the output. -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: a puzzlement
* On 18 Apr 2009, Paul E Condon wrote: When Mutt closes, it invariable issues the message: Mailbox is unchanged. Do you sync-mailbox before you quit or exit? Mailbox is unchanged means that no messages were changed since the last sync. (It doesn't count changes since startup, just changes to the current context; and the context is reset whenever you sync.) -- -D.d...@uchicago.eduNSITUniversity of Chicago
Re: what is the benefit of imap? Another meta-question.
RfC1939 explicitely states that the maildrop (mailbox) needs to be locked once a client is authenticated, see section 4. It doesn't say what exactly the lock means, though. At least I read it like that. This is drifting pretty far away from mutt, and I doubt any of us are writing new POP client code, so I'll keep this shortish. :) I imagine that I understand why the draft suggests a mailbox lock, but I think it's wrong to interpret that as a real requirement of POP. RFC 1939 predates BCP-14 (RFC 2119) and no MUST/SHOULD is present. Absent such terminology (and reasons for using it) I think that a protocol RFC doesn't get to prescribe the exact behavior of the server as long as the interface goals are met, and this can be done without an exclusive lock on the whole mailbox. What 1939 describes may be necessary for some server implementations, but not for all. -- -D.d...@uchicago.eduNSITUniversity of Chicago Just to clear the deck, I own no monkeys.
Re: what is the benefit of imap? Another meta-question.
I think the best summary is that IMAP is a remote mailbox access protocol, supporting all common mailbox operations at the protocol level. POP is not: it supports full message retrieval, new-message scan (kind of, via UIDL), and deletion. This makes it, at best, a queued message pull protocol. But as someone else said, IMAP is just more flexible. You may not need all the features of IMAP, but since it fully encompasses everything that POP supports, why not use it? so the leave mail on server option that most pop-clients have is certainly not a convenient way to access your mail remotely from different locations. If you have minimal needs, it works alright. It's implementation- dependent since it's not done at the protocol level, but POP servers can track basic message and mailbox status. Plus: POP needs locking, i.e. only one client at a time can access the mailbox which implies that tools should not perform time-consuming tasks while they have a POP session open. That's implementation-dependent though. A server might require locking, but it's not inherent to the protocol and it's possible to implement one that has few of the contstraints that people have mentioned in this thread. But historically, there are few really good POP servers, so in practical terms you're not wrong. Most of the things that people cite as flaws of POP are really flaws in particular implementations, not in the protocol. The POP protocol is limited in scope, but I don't think this is a flaw; POP just has a different design goal. (That said, it's really too bad that the POP and NNTP groups didn't join forces from the start. With an NNTP server that supported authentication and operationally understood the goals of user-oriented mailbox access, it would have been a completely reasonable alternative to both POP and IMAP, and much closer to IMAP in spirit.) -- -D.d...@uchicago.eduNSITUniversity of Chicago Just to clear the deck, I own no monkeys.
Re: Remove old signature
Any pointers on how to do that with vim ? I don't let my editor (vi, not vim) strip signatures automatically. Sometimes I want to comment on the signature in my reply. I have a vi macro for signature-stripping: From main.d/070.delsig: Remove quoted signature, up to blank line map ; :/^[ ]* -- *$/;?^[ ][ ]*$?;.,/^[ ]*$/-1d All the sequences of whitespace above are spacetab, and the ^M is a control-M, not a caret and an M. Be sure to fix that if you copy and paste. Vim should be able to use this too -- if not, its vi compatibility is worse than I thought. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: save-message to ? and then sync the folder
* On 2008.11.27, in [EMAIL PROTECTED],
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello
how can I sync the mailbox after save a message to any folder like this:
macro s save-message?
the above works great, but after this save mutt should sync
automatically. Like this:
macro s save-message?sync-mailbox
This works for me.
macro index S 'enter-commandset my_folder=`mutt-prompt Save to folder \\`;
push refreshsave-message$my_folder\enter\sync-mailboxenter'
Be sure to enter it in only one line. The backslashes are wacky, but so
are mutt's quoting rules. This is no typo; it really does work on my
system.
A mutt-prompt script is required; see attachment.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
#!/bin/sh
##
## usage: mutt-prompt prompt text
##
## In muttrc:
## set my_var=`mutt-prompt Folder`
##
# save current tty state
s=`stty -g`
# redirect default i/o, saving current stdout in fd 5
exec 51
exec /dev/tty /dev/tty
# reset tty state
stty icanon sane onlcr
# position cursor at bottom of screen
rows=`tput lines`
rows=`expr $rows - 1`
tput cup $rows 0
# print prompt and read response
printf ${1}:
read answer
# return response to mutt
echo $answer 5
# reset tty state
stty $s
Re: new mail to sender
Sorry for the maybe primitive question, but I couldn't find an answer anywhere: Sometimes I want to create a new mail (not reply) to a sender who is not in my aliases file. Is there a way to do it quicker then typing his email address? If you have edit_headers=yes, you can just use reply and delete the In-Reply-To: header and change the subject. But I understand that some people don't like edit_headers. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: unignore and regular expression help needed
I want to only show a a spam status header when the score is positive. In other words, X-Spam-Status:\ No,\ score=2.4... should be displayed, but X-Spam-Status:\ No,\ score=-2.4... shouldn't. Consider upgrading to mutt 1.5. Then you can do this: spam X-Spam-Status: Yes, score=([^-][^ ]+) %1 Now %H in your $index_format will expand to a message's spam score, but only if it's positive. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: patch: signin signoff feature (1.5.18)
This entire discussion should be on mutt-dev. Followups set. Why can you set sig_dashes, if you could set it via signature? signature can be a file or a program. The signature turns out to be whatever is read from the file or whatever is printed to stdout by the program. This file or program may or may not include the dashes, so there's an option to let you tell mutt whether to assist by including them. The only simplification that doesn't remove functionality is to always assume that the signature provides its own dashes, and eliminate the sig_dashes variable. I would say that the reason for not doing that is that it's an extra hurdle for new users, who most likely assume that only the signature proper should be in the signature file. (If you're using a signature program, it's reasonable to assume you're an advanced user.) Maybe conditionally redundant describes sig_dashes, but it's not absolutely redundant. It may be redundant, but it depends on what the signature actually produces. I guess the proposed signoff variable is similarly conditionally redundant, but logically we can: * express signoff in terms of sig_dashes + signature, or * express signature in terms of sig_dashes + signoff, or * express sig_dashes in terms of signoff + signature. Having all three is strictly redundant, so adding signoff adds complexity. Adding a variable should introduce simplicity, convenience, functionality, or some other value. It doesn't add simplicity or functionality. Does it really add convenience? How often do you need to change this in a way that you can't as easily change sig_dashes and signature? -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: command mode?
On Sun, 28 Sep 2008, Michael Kjorling wrote: :push query Thank you for quick response. I see the syntax is to type :push first. memo Right. These symbols from the help screen are names of key bindings. Commands are different; they're what you putt in muttrc or after pressing the : key (the enter-command keybinding). The push command is the inverse of enter-command. Enter-command lets you initiate a command by pressing a key (:). push lets you enter keystrokes (or bindings) by entering a command. When you push keystrokes, you can use either literal letters, numbers, etc., or you can use binding names. Binding names are always inside angle-brackets, with no spaces. Keys substitude for the bindings they're bound to, but binding names can be used whether or not they're bound to a key. In other words, push arguments work the same way as macros definitions do. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
On RTFM
Of course one should always check the manual and try a web search before asking for help. This is a given, and I don't think there's any argument. It's not always easy to find what you're looking for in the manual, and it's not always straightforward to construct a search query that yields what you're looking for. Your success varies with multiple factors: your facility with reading *and* with writing English, as noted; the way you're framing the problem in your mind; the character of the problem; the terminology involved; the organizational structure of the manual vs. the kind of problem you're trying to solve; your existing familiarity with the subject and with the reference material available. These can interplay to make one person's search fruitless, or to suggest that further search will be fruitless, while another person might come up with the answer right away. So a person posts to a list that is nominally for providing support, answers, and discussion. How can I fairly judge whether he's read the manual, or how deeply? Just based on my knowing where the answer is, and thinking he should have found it too? I don't think that's a fair measure. Yet I don't think it's the point, either. Even if someone has not done his own legwork, how is anyone's time well spent for me to tell them publically to do so? I don't see that, as someone suggested, this is helpful. It's condescending. It's saying: it's there, you missed it. Look again. But I won't say where to look because I think the exercise of finding it yourself is good for you, grasshopper. Even in this thread, Bill's question just by being asked has sparked original discussion of other approaches than what you'll find in the manual. Is there no value in that? Does anyone suggest some other way to obtain that benefit, besides having and expressing a need? It's absurd to say that you should not post a how-to question to a mailing list until you're sure the answer is not already out there, or prepared with your flame-retardant jammies. If I don't have time to help with a basic question, or I don't want to, or I resent the simplicity of the question or the way it was asked, I don't reply. It's simple, it causes no grief. The question, unanswered, has done me no harm. I am facile with my 'd' key. What's the trouble? Let people ask questions honestly and politely, but if all you have to give is rtfm, with no reference or citation or vague hint at a substantive answer, then don't bother replying -- or at least keep it out of the mailing list archive and my mailbox, please. Save RTFM for abusive and demanding inquiries only, and you'll see less abuse and fewer demands. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Index Column Width
I'm looking for a way to more strictly regulate the width of the columns in the index. For example, in my current configuration if an email address shows up in my index that is too long to be displayed in the parameters I have set for the From field (25 characters), it overflows into the subject column pushing my column formatting off. Is there a way to cut off names and addresses that run over? %-25.25F This is a printf-like string sizing specification. See the mutt manual or man printf for details. It's the .25 that makes the difference. The first 25 makes it a minimum of 25 characters; the .25 makes it a maximum. The - left-aligns. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Automated message processing
On Wednesday, September 3 at 10:54 PM, quoth Peter Davis: Usually, the person responds to the who are you? message leaving the message body intact. So I want to have something embedded in the who are you? message that can point my script back to the original so-and-so wants to join message from Yahoo!, so I can reply to that. How about just a long random number? This works, but you'd need to store the valid random number someplace. For a zero-knowledge approach you could do something like generate an MD5 hash of the prospective member's e-mail address with some secret that's shared between the script that sends the 'who are you' and the script that processes the reply. This would depend on some reasonable parsing of the sender address, though (to reduce it to [EMAIL PROTECTED], discarding angle bracket enclosures and any real name present). -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Dealing with Exchange meeting invitations
Can one accept/decline a meeting invitation by sending a reply in some defined format? If yes, where can I find some documentation on what the reply is supposed to look like? I don't have a good answer, but a cheap partial solution is to save invitations to imaps://exchange.your.org/Calendar to accept them. Not sure how to decline though, and this still depends on actually receiving the invitation. I've run across cases where the invite doesn't reach me as an IMAP user, I but haven't figured out why yet. (Time and concern haven't intersected.) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: trash folder in 1.5.18
http://cedricduval.free.fr/mutt/patches/#trash is only upto the mutt version 1.5.5.1; there are no patches after that. I am guessing that it has been included in the original code. It has not been. Cedric hasn't updated it AFAIK, but a google on cedric duval trash patch turns up http://scie.nti.st/2007/6/21/mutt-trash-folder-patch-for-1-5-16 . Maybe that version will apply more cleanly to 1.5.18. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: mutt and plaintext passwords : muttrc encryption ?
:source echo set my_var | All I get is the error message: source: errors in echo set my_var | :set my_var yields my_var: unknown variable too. Try, for example, :source echo set ?index_format | I was going to suggest this approach as well, although I'd have proposed openssl enc instead of gpg, I guess. Not much call for an asymmetric cipher here, especially as the point is to store secret data on a filesystem that contains the key for decoding the secret data. (I'm sure your gpg key is secure and all, it's just that no stored key encrypted key.) I'm kind of surprised you've missed my dozens of messages recommending source with pipes, Kyle. :) It's super useful. My entire muttrc is generated this way. Thanks to the OP for asking the question, though. I hadn't thought of using programmic sources to encrypt sensitive muttrc files. Embedding programmatic source statements within programmatically-generated muttrc streams... tasty. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: use script output as regex pattern in folder-fook
folder-hook folder1|folder2|folder3 ... I replaced this with folder-hook script.sh| ... This approach won't work. Here's why, and a possible alternative. The script.sh| notation for incorporating a script's output into your muttrc only works where mutt knows that it's looking for a filename or a format string. Otherwise, script.sh| is just a literal string. In your case, it's a regular expression listing a set of either-or patterns, and one of these patterns is an empty string, which matches everything since all strings contain an empty string as a subset. As Michael said, you can use `script.sh` instead. This should work equally well for most purposes. The only difference is that script.sh|, when it works, executes the script each time that the value is evaluated. `script.sh` executes the script only once, at the time that the muttrc is processed. This makes script.sh| really useful only when used for set variables that are evaluated multiple times. Hooks are evaluated only once anyway, so it wouldn't really be meaningful. If you really need the same kind of dynamic meaning that script.sh| provides over `script.sh`, you might be able to use a compound folder-hook -- something like this: folder-hook . 'folder-hook \`script.sh\` command...' or perhaps: # all other folder-hooks in folder-hooks.mutt folder-hook . 'source folder-hooks.mutt' These are untested, but its intention is that for each folder change, mutt will interpret folder-hook `script.sh` command... again. I'm not sure that the second folder-hook would actually be applied to the new (now current) folder, though. It might be necessary to reopen the folder to make the new folder-hook stick, and that's so unusable as to make the whole approach worthless. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: robots [ was Re: Alternative Identities ]:wq
Question for people who post here more frequently than I do - is it normal to get a challenge/response mail from [EMAIL PROTECTED] when posting here ? It's typical (I get one every time I post), but it's not normal (in the sense that it shouldn't happen). Challenge/response should never be used for mail that you receive as a list member; it's really, really irritating to other list members. It's understandable (if somewhat annoying) as a posting filter on a list -- just not as a receiving filter on your personal subscription. I'd like to see the subscriber in question removed from the list -- evidently he's not getting list mail anyway. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: use script output as regex pattern in folder-fook
You can work around this by putting MUTTDIR in your shell environment before running mutt. Hmm, how do you read my mind? :) :) Well, I actually do this for a few variables -- predating the $my_xyz feature. I should switch where I can though, so I can drop the setenv patch. (Lets me stuff things into the environment from inside mutt.) A more elegant solution could be a config var $configdir or $scriptdir for people who - have more then one script laying around in ~/.mutt (or wherever) - don't want to put Mutt-specific scripts in a location on $PATH You also can do this in ~/.muttrc: source ~/.mutt/muttrc.py| and generate your real muttrc programmatically: another way to do things like macros/variables and search paths, and you also get to automatically define hooks, lists, etc. based on the contents of your filesystem. But once again this only executes at startup -- it doesn't update itself continuously. If you're ambitious enough you could set mutt up to reload much of its configuration every time you change folders, or something. But I'm not sure how useful this really is for most people. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: gbnet address still used for mutt-users list?
A few years ago messages to the mutt-users list (from Germany?) were occasionally ending up in my inbox because they had been sent to what was apparently some sort of alternative address for the list: [EMAIL PROTECTED] Is anyone aware if this address is still in any way active for the list? That was the original address for the list, before mutt.org began fronting for it. It's still the domain that handles the list though: % host -t mx mutt.org mutt.org mail is handled (pri=10) by dm.gbnet.net mutt.org mail is handled (pri=20) by spamgizmo.flirble.org So it almost certainly still works, and it's probable that some day someone will use it. If it is not, I'd like to remove the following from my .procmailrc: :0 * ^Delivered-To:[EMAIL PROTECTED] $HOME/Mail/m/ Just use a List-* header instead: List-Post: mailto:mutt-users@mutt.org It's too bad Majordomo doesn't offer List-ID, but List-Post will do. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: gbnet address still used for mutt-users list?
Not sure what you mean by use a List-* header -- I'm trying to clean out
Several RFCs (e.g., 2369, 2919) specify mail headers beginning with
List-. These culminate (I guess) with inclusion in RFC 4021.
Most modern mailing list managers support one or both of List-ID or
List-Post. You can write a single rule or two that will categorize
almost all lists appearing from a mailing list, and dispose of almost
all rules dealing with specific lists.
# Discover mailing lists with List-Post: set
:0
* List-Post: mailto:\/.*
{
# To set LISTNAME to whole posting address:
#LISTNAME=`echo $MATCH | cut -d'' -f1`
# TO set LISTNAME to LHS of posting address:
LISTNAME=`echo $MATCH | cut -d@ -f1`
}
## [insert other rules which update LISTNAME for edge cases]
# File discovered list mail into per-list archives
:0 c
* LISTNAME ?? .
$HOME/Mail/lists/$LISTNAME
# Add X-Label for list name
:0 f
* LISTNAME ?? .
| formail -I X-Label: $LISTNAME
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: index_format setting to show yr
Is there any way to setup mutt (the date_format variable?) such that in the index view, the year is shown only if the year of the message is different from the current year? The default %d shows only the Month date. You need the date_conditional patch to make date formats conditional upon relative date offsets, but even so you can only say in the last 6 months or the like -- not in the current year. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Hi all, is there anyone knows how to send bigger attachments
Thanks. But I am using a Linux system, and the file is just about 6M. I am just curious that where can I find the so-called system restriction ? It could be on your system, or it could be on the one that your system relays to when it sends the message on to the recipient. Where you find the configuration depends on what MTA you're using. If you're using sendmail, it's probably in /etc/mail/sendmail.cf and/or /etc/mail/sendmail.mc. If you're using postfix, it's probably in one of the files in /etc/postfix -- perhaps main.cf. Check your MTA's docuementation for whatever distribution of Linux you're using. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Sorting messages by score AND keeping threading - is it
Question: Is it possible to maintain the following threading whilst viewing messages in sorted by score mode ? folder-hook . \ set sort=reverse-threads ;\ set sort_aux=last-date-received ;\ set duplicate_threads=yes ;\ Not really. Mutt's threading is implemented as a sorting mechanism rather than some other layer, and unfortunately mutt is coded in multiple places to honor only two sort functions. Daniel Eisenbud did the last major overhaul of mutt's threading code. Shortly after he finished it he proposed taking a further step of either separating threading out from sorting, or permitting more than two sort functions. I gather there wasn't very much interest from people with substantial use cases. I think perhaps the only vaguely common use case for having two sort keys in addition to threading involves scoring, and I'm not too sure that very many people actually use scoring. You might approximate this if you can find a way to mix (last-)date-received into score, but whether that's feasible depends on your mailboxes and your habits. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Mutt hangs, Network Issue?
This Mutt hangs/freezes probably 10-15 times a day. It is completely unresponsive. If I open a second ssh session, and kill the mutt process, it generally takes maybe 30 seconds for mutt to let go, and to get a shell prompt back. If I don't manually kill mutt, and just So you regain control of mutt's session when mutt dies to a kill signal? Can you also suspend mutt (control-Z) from within the same session, or only from outside? Does mutt freeze while you're actively using it, or only while you're idling? Or both? Is it at all possible that the freezes are related to software flow control signals (normally control-S = stop; control-Q = start; but see `stty`)? This seems unlikely since you said the problem started with the installation of a NATting router, but it's sometimes worth asking. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Mutt hangs, Network Issue?
What should a functional control-z tell me? If control-Z works, your transport (ssh) and terminal are still fundamentally intact, and responsive to low-level traffic and out-of-band signals. (It means that mutt is responsive to signals too, for that matter -- once it receives them.) Does mutt work again once you bring it back to foreground, or does it remain hung? If it hangs, and you type a bunch of stuff followed by control-Z, and then foreground mutt, does all the stuff you typed suddenly appear to execute at once? Does it appear to have already executed long ago? Or is it ignored? This all serves to indicate what stage things are at when mutt appears to be unresponsive. You might also check the debug log during a suspend instead of after a kill; this could help pinpoint more exactly what mutt thought it was up to. If you have gdb installed and you're familiar with it, you might try attaching gdb to the hung mutt process from within another terminal. That is: window 1window 2 -- -- + ssh in- ssh in + run mutt - get mutt's process id from ps for example: 14001 + do stuff, wait for a hang - attach gdb to the mutt process for example: gdb /usr/bin/mutt 14001 - get a backtrace, minimally type: backtrace This will tell you more finely than debug logs will what mutt is doing at an exact moment that it appears hung, but it's quite possible that it's just waiting for input that's simply not arriving. The logs will tell what it *has* been doing up until that, but it might not be anything special. Honestly this has the feel of an ordinary session timeout at the network level, which wouldn't be surprising. But you said that it happens only with mutt, and not even with an idle shell. That's what seems strange to me. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Change mail folder without pressing = first?
The subject line hopefully says it all: the one thing that bothers me most in mutt is that I have to press = before changing mail folders. Is there a way to change this behaviour, so that I can type c and then directly the name of the mailbox? On my keyboard (norwegian), the = key is a macro index c change-folder= -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: pass single-quoted arguments to external script
So how do I properly escape the single quotes in the vim args Personally, as soon as I start having trouble figuring out how to quote things withing multiple layers of parser, I ditch the headache and put the command into an external script that accepts only the minimum arguments from mutt (i.e., the values that only mutt knows). In you case, I guess that would be approximately: send-hook ... 'set editor=mutt-xvim' $ cat mutt-xvim #!/bin/sh exec xterm -e vim '+/^--[ ]*$' -c 'read some_file' $@ I know that's a level of abstraction away from what you were aiming for, but time is just too precious to spend it on all the various (and they indeed vary) quoting idiosyncrasies, unless that sort of thing is fun or educational for you. And by putting mutt-specific scripts into a mutt namespace, as it were, you're not really causing any layering conflicts. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: changing subject of all messages in a thread
part of a subthread? I know how to set $editor to get it to do this automatically, but how do I convince mutt to spawn the editor on all tagged messages or messages of a subthread without manually iterating? set editor=perl -pi -e 's/^Subject: .*/Subject: mwahaha/;' %s [tag some messages] tag-prefixedit-message -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: changing subject of all messages in a thread
/me wants mutt to have a prompt function. prompt would be handy. Meanwhile, you might try something like: $ cat mutt-subject-edit #!/bin/sh printf New subject: /dev/tty read subj /dev/tty cat X set editor=perl -pi -e 's/^Subject: .*/Subject: $subj/;' %s X :source mutt-subject-edit | [tag some messages] tag-prefixedit-message Untested. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: copy on a per email basis
Do you want to press a key to make mutt save messages to a specific folder, but to not do so if you do not press this key? Yes, exactly, without even having to answer the Yes/No question (if I set ask-yes, or ask-no option) every time. This might do it. ## Set copy to no when initiating new messages send-hook . 'set copy=no' ## Set copy to yes when you press control-K at the compose menu macro compose \CK 'set copy=yes' -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: A few mutt questions
1. I'd like to have new or unread mail (what's the difference, anyway?) To mutt, 'new' means that the mail is unread and has arrived during this mutt session. 'old' means that it's unread but remains from a previous mutt session. But like another poster, I use them differently. For me, 'new' means 'unread', and 'old' means 'must reread'. Unmarked mail (neither new nor old) is read and can be removed. flagged somehow. Occasionally I see an N next to some messages, but in general mutt seems to completely oblivious to what's new or unreaed. It certainly supports this, but it depends on the mail source itself to say what's read. Mutt can alter these flags, but so can other tools. If you have other programs (other mail clients, or biff programs, etc.) reading your mailboxes, they could be interfering with your expectations of mutt. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Deleting attachment from signed email
How can I do this? Is it a principal problem, or a bug in mutt? It's unsupported because attachments are part of the signed data. If you delete the attachment, the signature becomes invalid. I would guess that this was a design decision, not an oversight (bug). But that's largely a semantic technicality. If you want to remove an attachment, first remove the signature. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago War is God's way of teaching Americans geography. - Ambrose Bierce
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
Well, the first thing that springs to my mind is some sort of message-hook (since that's what triggers when you view a message). The difficulty with this approach is that you don't want to send an MDN response any time you read the message, so you need to track whether the message has ever been read and MDN-replied to. You can do this with formail -D, but that involves an external Message-ID cache, separate from the message store, wherever that might be. I suppose that's one reason that Werner chose to implement this as a patch instead of as a set of macros/script(s). But it might not be compelling for everyone. The patch certainly provides better functionality than hooks, macros, and scripts do, given the usual constraints. Whether the better functionality is necessary functionalty is debatable, but I'm not sure it's worthwhile to debate it unless committers are wavering about committing the patch. Otherwise it's clear what you should do: patch mutt if you're comfortable patching, or settle for scripts if they're sufficient. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: How to send a return receipt
The difficulty with this approach is that you don't want to send an MDN response any time you read the message, so you need to track whether the message has ever been read and MDN-replied to. You can do this with What? Poppycock. If the New flag is insufficient (and I would argue it *ought* to be sufficient), you can simply add a header to mark messages by manipulating the $editor variable. For example: So in other words, you're tracking whether the message has ever been read. I just named one way to do it; each has its merits. The patch certainly provides better functionality than hooks, macros, and scripts do, given the usual constraints. I don't see what that missing functionality might be. Maybe I'm missing something. I didn't say missing, I said better. I haven't said there's anything fundamentally wrong with your approach; it's just not as -- as you said -- convenient. But why is this an argument? -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: How to send a return receipt
asked if we want to send such a return receipt. Is this configurable? I also read somewhere that mutt doesn't support that but I can't believe that. Is that true? This is correct. Mutt doesn't internally support MDNs. A patch has been posted by Werner Koch, but it might not be current. Check the mutt-dev archives. You can set up procmail or a similar mail filter to return a DSN if your mail server doesn't support it, but this lets the sender know only that the message was received, not that it was read. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: index_format - indicate which email has attachment
Did you properly configure all 'attachment' commands (see the system Muttrc file for examples) or did you just add '%X' to $index_format? You have to tell mutt what an you consider an attachment before %X does display the counts in $index_format. Right. You can type :attachments ? (no quotes) into mutt to see what settings it has now. The defaults come from the system muttrc: Current attachments settings: attachments +A */.* attachments -A text/x-vcard attachments -A application/pgp.* attachments -A application/x-pkcs7-.* attachments -A message/external-body attachments +I text/plain attachments -I message/external-body These basically mean that attachments with a content-disposition of inline will not be counted as attachments, unless they are content-type text/plain; and all messages with a content-disposition of attachment will be counted, except for the four types listed (pgp signatures, vcards, and external-body messages). Perhaps your message with an attachment doesn't qualify under these rules. But that's why you can change the rules. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: index_format - indicate which email has attachment
Thanks Dave for the example, no my muttrc did not come with these
defaults, and yes it works now.
These defaults are installed when you build from source. Are you
using a distributed package? If so, sounds like someone oopsed.
It displays attachments but is there a way to suppress the 0 if there is
no attachment.
What Gary said. :)
Personally I use something akin to this:
%?X?{%2X}%4c?
Which shows me attachment count if there are attchments, or
total message size othewise.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: Generate Reply / New Mail in new shell session
It would be nice if it was possible to start a New Email or Replies in a new shell session and close it automatically when a mail is sent, without, going through postpone. Is it possible? Check the archives -- possibly a few years back. People have posted examples of how to do this using an external script and a macro. Basically you generate a draft file as normally, but set your editor to an external script that launches a new mutt instance in a new window using that draft file as a template. Then restore $editor and move on. Should be even easier now, with my_ variables. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: Send Later
As I understand, ssmtp does not support message queuing, which is possible in other mta's, but if there is any workaround to this (before I explore any other mta), would like to know it. Check the archives, possible several years back. People have posted scripts for this too. :) Basically you set $sendmail to a script that appends your outbound message to a folder (mbox or maildir, your call) and returns. You can have a cron job, an external script, or a macro that splits this folder (using formail, if mbox, or basic looping structures if maildir) and sends each message into ssmtp one by one. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: Generate Reply / New Mail in new shell session
All I was able to find is a solution with Ctrl-z putting it in a background and starting new session. That is not really a solution. Agreed. That's not it. I'm sure somebody has similar macro worked out, it is just a mutter of finding it :-/ Something along these lines might work. Untested. It's been years since I used xterm, so I'm not sure if the syntax below is correct for expressing what xterm should run. Might need to add sh -c and quoting, or somesuch. Maybe you need some more dressing, but perhaps this will get you started. If you want this only sometimes, you'll need to macro-fy the muttrc bits. $ cat external-reply #!/bin/sh DRAFT=$1 # hard-link our own copy of the draft so that mutt can remove original ln $DRAFT $DRAFT.tmp ( ## execute this in a bkgrounded subshell, ## allowing the original shell to exit xterm -e exec mutt -H '$DRAFT' rm -f $DRAFT ) exit 0 .muttrc: set editor=external-reply -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: how to cut attachments from mails...
how can I remove all attachments from a mail? The idea is, if someone Delete them from the attachments menu. Normally this means pressing 'v' while viewing the message in index or pager, scrolling to the attachment you don't want, and pressing 'd'. When the folder is synced, the attachments will be gone. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: sorting outgoing mail
Procmail is a delivery agent; it only handles incoming mail. Automatically sorting outgoing mail (i.e. putting mail into different folders as it is sent) requires send-hooks. While it's true that procmail can act as a delivery agent, it can also filter any mail that you feed into it. If you sent $sendmail to a program that first filters the message, then injects the message to SMTP, you can external outbound message filtering. #!/bin/sh ## ## Use this as $sendmail in mutt ## procmail -p -f [EMAIL PROTECTED] -m $HOME/.procmailrc.outgoing Make sure that .procmailrc.outgoing **always** acts on a message copy using rules beginning with :0 c. Then make sure that the last rule in .procmailrc.outgoing, the one that catches all messages coming into the filter, is like this: :0 | /usr/lib/sendmail -oi -oem -t I haven't tested this approach at all, but it seems like it should work. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: Is SMTP with no authentication possible?
I use this: smtp_url=smtp://localhost/ (I run sendmail locally. I could use local submission via $sendmail, but I use the built-in SMTP code to exercise the code.) I also have certain send2-hooks which replace that with another SMTP server. You can replace localhost with your smtp server name, and submit without authn. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: Is SMTP with no authentication possible?
It still seems a bit odd that you have to compile it with SASL in order to get mutt to work with an SMTP server that doesn't require authentication. I don't think you do. $ mutt -v | grep -i sasl +USE_POP +USE_IMAP +USE_SMTP -USE_GSS -USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +HAVE_GETADDRINFO As Kyle said, try it with no username in $smtp_url, and $smtp_user and $smtp_pass unset. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
top-posting and Re: signature at the beginning, not the end
Ok, I can see how its preferable to edit and reply at the bottom for mailing lists. I'm going to keep that in mind from now on. :) Jeopardy-style, answer-first is not always bad for other types of correspondences. This is fair. You said before that it seems like a matter of preference. I can agree somewhat, but it's really more a matter of general convenience to the _reader_, rather than to the _author_. Whether I'm posting to a conventional list or to an individual or small group, I try to anticipate the situation and post accordingly. (Sometimes top-posting makes most sense.) But obviously, the more people might be reading your message, the more you lose the ability to anticipate what works best for the reader. :) I'd like to think that's why it's called 'netiquette', btw: not because it's a strict behavioral convention, but because its goal is to honor the recipient's interests above one's own. I usually find that top-posting is only suitable for very concise answers to questions, or me too type stuff. If the reader is likely not to know what I'm talking about at a glance, it's better to trim context and tail-post. But I suppose there are probably exceptions, and I'm allowed some error in judgment. :) And sometimes I find it best to put text both before and after the quoted material. * As for your original question, because I sometimes top-post and usually do not, I don't normally use mutt for attaching my signature at all. Instead I have an editor macro to insert it at the current cursor line. Mutt inserts my signature automatically at bottom, but I usually end up deleting it and re-adding it during the course of trimming context. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: A question about macros, how to handle user input (if
E.g. I want a macro which does something, then does a s[ave] command (to which the user responds) and then does some more things after the save. This is not a complete or flawless answer, just a quick example of one way to do this. And it's untested. macro index = do-somethingenter-commandsource 'mutt-prompt \save as\ \push \save%s\enter\ |'enterdo-something-else If I didn't screw up quoting, this (1) does something, (2) enters the command source 'mutt-prompt save as push save%senter |' then (3) does something else. In stage 2, mutt-prompt (a) issues the prompt save as: (b) accepts input, then (c) echoes out save[your input here]enter. Because of the | at the end of the source command, mutt executes the commands echoed in (c), then proceeds to (3). Horrific, no? Mutt-prompt is attached. It's very straightforward. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago #!/bin/sh ## ## usage: mutt-prompt prompt text mutt commands ## mutt commands should contain a %s, which will be replaced by ## the user's response to the prompt. ## printf $1: read answer /dev/tty printf $2 $answer
Re: Fwd: Re: alias list and bcc
Okay, as a workaround this should work for me, too. Thanks. But I don't want my mails regarded as possible spam for the to-field isn't correct. Please explain to-field isn't correct and site rfc's supporting your supposition. undisclosed-decipients:; is a valid content for the To: header, but that doesn't mean that spam filters will never object to it. By necessity, spam filters are as bad in their non-accomodation of irregular but legal constructions as spammers are in their use of irregular/illegal but accepted constructions. The concern is legitimate. Maybe someone shows up with a clean solution. I tend to use undisclosed-recipients:; myself, but a more normal-looking approach that I often see is to put your own address in the To: field. You can also just make one up, if you don't mind the bounce. example.com and example.net are even reserved by IANA, and will never (again) be valid domains for actual users. ps: full quoting, especially sigs, is ungregarious. So is being an ass. If you want to tell someone you're not going to help, do it in private, not on a list with thousands of subscribers. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: alias list and bcc
is there a way to create a simple list with the alias command like alias my_list contac1 contact2 contactN but not having send your messages cc: but bcc: ? What isn't working about this? The alias you gave should work, and if you put it into the Bcc: field it should Bcc those addresses. You can do this either in your editor (with edit_headers set), or in the compose menu. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Solved: Re: multiple smart hosts
I've recently started using mutt's builtin smtp. I run a sendmail daemon locally, but I don't always want to submit to local SMTP. I use this config: send2-hook . 'set smtp_url=smtp://localhost/' send2-hook '~f [EMAIL PROTECTED]' 'set smtp_url=smtp://example1.org/' send2-hook '~f [EMAIL PROTECTED]' 'set smtp_url=smtp://example2.org/' ... which might be a useful alternative to exim or msmtp. (Replace 'localhost' with any smtp server you have posting access to.) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Change into an mbox - like chdir
* On 2007.07.13, in [EMAIL PROTECTED], * David Woodfall [EMAIL PROTECTED] wrote: No I've had this problem before. Mutt sees the c of change-folder and assumes its c and everything after the 'c' is the folder name. Specifically, since change-folder is not defined in the generic binding map, mutt interprets this as literal , c, h, etc. You'll need to write this macro once for index and once for pager, since those are the only binding maps that change-folder is defined in. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Problem with new 'pager_format'
* On 2007.06.27, in [EMAIL PROTECTED], * Gary Johnson [EMAIL PROTECTED] wrote: With mutt-1.5.16, that behavior has changed. The fixed indicator has been replaced by the % -- (%P) format sequence in 'pager_format'. The problem with this is that the percentage indicator can now be shoved off the right side of the screen by long subjects. It's not exactly the answer you're looking for, but this is precisely the kind of scenario my softfill patch is made to address. This patch implements the %* notation, which is analogous to % but gives precedence to the right side instead of to the left when the fill length is zero. With a long subject, the subject would be truncated enough for anything to the right of %* to render in full. http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.16.dgc.softfill.1 -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Problem with new 'pager_format'
* On 2007.06.29, in [EMAIL PROTECTED], * Gary Johnson [EMAIL PROTECTED] wrote: I'm sorry I've taken so long to get back to this. It was an especially busy day of real work. Understood. :) You don't have permission to access /~dgc/sw/mutt/patch-1.5.16.dgc.softfill.1 on this server. You know, I actually checked permission before posting, and in retrospect I clearly recall seeing 600 and thinking well, that's all right. Too many things on my mind, I guess. This is fixed; sorry for the trouble. Silly umask. Just as a side note, I've used this for 3-4 years in $index_format, to fit my X-Labels to the right edge of the screen regardless of the subject's content/length. It's pretty useful. The patch includes some extended doc on format strings, too. Mostly this covers printf formatter semantics, which are neglected in the manual currently. pitchIn light of the situation with 1.5.16's $pager_format, is it time to review adding this code to hg tip?/pitch -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Programs to Receive and filter mail
* On 2007.05.11, in [EMAIL PROTECTED], * Charles Cazabon [EMAIL PROTECTED] wrote: In my experience, most people find configuring and using getmail easier. I I actually found fetchmail much easier to configure than getmail, but that's partly because I began using fetchmail many years ago, when it was easier to configure than it is now. And in fact, it's not as much that getmail was hard to configure as that it was hard to figure out how to configure it. Once I knew the rules, it was pretty easy to do correctly. think fetchmail's abominable security record will likely improve under its new maintainers (they actually have some technical credentials), but they're still saddled with the design decisions and some code from its ... ahem ... wild years. I know this makes me a bad person, but I haven't been much bothered by fetchmail's security. However, I've found it mind-bogglingly buggy over the years in more mundane ways. Every now then it just stops downloading my mail -- dumps core and leaves messages piled up on the server, such that I can only dig myself out with another tool. And I only know it's happening when I stop getting mail from certain sources/to certain destinations. I've upgraded to fix this many times, but it's always happened again after a few more months. It's been very frustrating. A POP downloader is one of the rare terminal-mode programs that I really don't care to know anything about or to look at the code for. I'll never care about new features, and I'm happiest if I never have to update it. I just want it to do its job quietly, quickly, and without engaging me. On these points, getmail has been a success in the several months I've been using it. Also, if I do need to dig in, python is tasty. Although there are C programs whose code I like very much, fetchmail's is not among them. -- -D.[EMAIL PROTECTED], an Element of NSITUniversity of Chicago
Re: Programs to Receive and filter mail
* On 2007.05.12, in [EMAIL PROTECTED], * Cleverson [EMAIL PROTECTED] wrote: In Gentoo's Portage system, the latest Mutt version is 1.5.15-r2. Does it have built-in SMTP, or should I install a piece of software to send e-mails? ESMTP client support was added between 1.5.14 and 1.5.15, so Gentoo's package should have it. -- -D.[EMAIL PROTECTED], an Element of NSITUniversity of Chicago
Re: How to specify multiple alternates
* On 2007.04.29, in [EMAIL PROTECTED], * Chris G [EMAIL PROTECTED] wrote: The manual just says:- set alternates=regular expression How does one specify a collection of different addresses? Is it just address1|address2|address3 ? For 1.4.1, yes: set altnernates=address1|address2|address3 or, if you're picky: set altnernates=^(address1|address2|address3)$ * On 2007.04.29, in [EMAIL PROTECTED], * Kevin Coyner [EMAIL PROTECTED] wrote: alternates [EMAIL PROTECTED]|[EMAIL PROTECTED]|[EMAIL PROTECTED] This notation was introduced as a replacement for set alternates during the 1.5 series. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: An alias for the mailboxes
* On 2007.03.13, in [EMAIL PROTECTED], * Salvatore Iovene [EMAIL PROTECTED] wrote: Hello, in my .muttrc I have several mailboxes defined, and all of them correspond to imap mailboxes. They show like this: imaps://server_1/INBOX imaps://server_2/INBOX etc I would like to have this a bit more organized, and it would suffice to be able to make aliases for them, so they would show up as: work private etc There's no way to alias mailboxes, but you can do something very close with macros: macro editor *work kill-lineimaps://server_1/INBOX macro editor *private kill-lineimaps://server_2/INBOX etc -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: MTA for Solaris - ideas anyone?
* On 2007.02.16, in [EMAIL PROTECTED], * Eur Ing Chris Green [EMAIL PROTECTED] wrote: I am looking for an MTA to use with mutt on a Solaris 2.6 system, so far none of the ones on http://wiki.mutt.org/?LightSMTPagents builds successfully though I'm pursuing msmtp still. Most non-queueing SMTP clients are, shall we say, optimized for Linux. Getting the native-code ones to compile on Solaris is not an enjoyable exercise. If you're using Solaris 2.6, you're probably not on dialup (or wireless). What's wrong with a full MTA like sendmail that's simply not running a listener? Very likely the sendmail that ships on Solaris 2.6 will work fine, as old as it is. I wouldn't run it as a server, but as a client it should be okay. Plus you get an outbound queue in case of problems. Sendmail is very common on Solaris, so even if you do need to compile it shouldn't be much of an issue, and if you're not running a listener you don't really need to be very conscious of security issues (in case you're one of those who feels that sendmail is fatally flawed, security-wise). -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: MTA for Solaris - ideas anyone?
* On 2007.02.16, in [EMAIL PROTECTED], * Eur Ing Chris Green [EMAIL PROTECTED] wrote: On Fri, Feb 16, 2007 at 08:52:16PM +0100, Rado S wrote: =- Eur Ing Chris Green wrote on Fri 16.Feb'07 at 19:33:44 + -= Problem is I don't have root access so configuring sendmail is not really possible. You don't need root: get the config m4-source dir (admin could give you read-access to them, otherwise get them from source-package), build your own config (for example 'nullcient'), and then use it with 'sendmail -C .../your-file' as your $sendmail value. Can sendmail do authenticated SMTP? If so then this is a distinct possibility. You would need a new sendmail, not the Solaris 2.6 one, but it can. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Add alias during session
* On 2007.02.05, in [EMAIL PROTECTED],
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is there really no way to do a generic create-alias, where you don't
have to change the information of the current sender? I've often
wanted to do this - just hit 'a', but not have to erase all the
information I don't want first (I just want it blank so I can enter
what I want).
macro index A enter-commandsource '~/bin/mutt-add-alias |'enter
mutt-add-alias is attached.
--
-D.[EMAIL PROTECTED]NSITUniversity of Chicago
#!/bin/sh
ALIAS_FILE=${MUTT_ALIASES:-$HOME/.mutt/aliases}
q=''
exec 91
exec /dev/tty /dev/tty 21
get_vals () {
printf New alias name${alias:+ [$alias]}:
read line
alias=${line:-$alias}
printf Enter e-mail address${addr:+ [$addr]}:
read line
addr=${line:-$addr}
printf Enter comment/name${name:+ [$name]}:
read line
name=${line:-$name}
new=`echo $name | tr -d ''`
if [ ! $new = $name ]; then
printf (Removing double-quotes from $q$name$q.)\n
name=$new
fi
}
notfinished=true
while $notfinished; do
printf \n
get_vals
printf \n
notfinished=
while [ $notfinished = ]; do
printf Is this correct: $alias = $name $addr [yes]?
read line
case $line in
|y*|j*|s*|o*) notfinished=false ;;
n*) notfinished=true ;;
*) echo Yes or no is good. ;;
esac
done
done
printf alias %-16s %s %s\n $alias $q$name$q $addr $ALIAS_FILE
printf \nAdded alias $q$alias$q for $q$name$q $addr\n\n
cat $ALIAS_FILE 9
Re: jump to last read
* On 2007.02.05, in [EMAIL PROTECTED], * Christian Ebert [EMAIL PROTECTED] wrote: One of the very few features I am missing in Mutt is the ability to jump to the last read message. This is often available in newsreaders. For instance if I sort threads and tab jump to the next unread message, sometimes I'd like to go back to the last read, and have to search for it first. Anybody else interested in such a feature? Or could it be done with a macro? Or did I even overlook something? http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.11.dgc.markmsg.2 provides an operation mark-msg which constructs a macro to search by Message-ID, using the current message's Message-ID. It's modelled on vi's feature to mark lines with m and return to them with '. For example, if I'm in the pager on Message-ID: [EMAIL PROTECTED], then entering mark-msgaenter results in a macro 'a that issues search~i [EMAIL PROTECTED]enter. With this patch you could build your feature as a macro (e.g., macro index space mark-msgpreviousenterdisplay-message; 'previous to jump back), or you could implement it in code using the same technique as this patch uses. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: reading color quoted replies
* On 2007.02.01, in [EMAIL PROTECTED], * Rado S [EMAIL PROTECTED] wrote: Are you serious about option 1? Why not? Generally it's good to have visual aids. However, the implementation varies, and I prefer a simple data format that works even without a dedicated visual aids interpreter (human readable): i.e. the way of aiding is not stored in the data itself but left up to the reader (the original www idea). A tool can perform its beefing-up well enough on this simple/ raw data, too, as mutt and other MUAs show. I agree with you, and I prefer that too, and from his post I think Marc is in our camp. But most people don't care that much, as long as they can tell the difference in their way, and most people don't want to deviate too far from whatever happens by default. Trying to persuade them otherwise often just makes one seem... well, too interested in telling others how to work, to put it gently. Although I'd love for everyone to work my way, telling them that they should usually doesn't work out very well. This argument must be taken up with developers, not users. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: reading color quoted replies
There are many factors in how people behave. Interoperability of personal preference ranks low for most people. Has no one ever asked you how you can stand not reading e-mail in full blazing GUI glory? I said this is a matter for developers, not for users, because developers (and administrators) are responsible for setting up users' capabilities and defaults and ensuring interoperability. I suspect most users would be fine with quoting, if that were the default. Since it's not, they don't use it. But even if it's a chosen setting, it most often aligns with what they like the look of, not what they understand. It's a lot to ask of many people that they frame their workflow around issues they don't understand or want to understand, just because I pitched them a set of reasons that I said were logically sound. Non-enthusiasts just want it to work with a minimum of fuss and configuration, and if it looks like it works to them, then it works. Have you worked in direct user support? For each professional or enthusiast, there are hundreds who just use computers as a tool, the way you would use a hammer or a gas oven. Few people want to modify their ovens, even if oven engineers have suggestions for how to do it. I don't disagree with your rationale, I just don't think that training everyone else to think right isn't very practical as a solution to interop problems. Let me know when you convince them all, though, and I'll pay for drinks. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: Help please with mutt
* On 2007.01.22, in [EMAIL PROTECTED], * David Hoover [EMAIL PROTECTED] wrote: I have a system running Red Hat Linux. We did a reboot on December 20, 2006. Prior to the reboot, mutt was working great. After the reboot, I have no e-mails going out using mutt. I have tried to manually send an e-mail using mutt beside the automated script that had been working prior to the reboot. My hope is that you might be able to spot what is missing to have cased mutt to have stopped. If a reboot stopped your ability to send mail, but not to read it, then it's very possible that the problem is your SMTP server, not mutt. Check that sendmail (or postfix, or qmail, or whatever you use) is running. You can verify this with ps (is it running now) and chkconfig (does your system run it on boot). -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: iconv stuff on solaris still unresolved
* On 2002.10.13, in [EMAIL PROTECTED], * Sven Dogbert Guckes [EMAIL PROTECTED] wrote: so - what *is* required then? I don't know: I install Solaris (with all the language options), I compile mutt. Mutt works. well - +HAVE_ICONV, for sure. but is +ICONV_NONTRANS? what? I don't know. Do you want me to find out what ICONV_NONTRANS is and report back? I only pasted it because you did, and I figured you'd be irritated if I didn't include mine. You don't really have room to be snotty today. Today it's *your* problem that someone else is trying to contribute information to. besides, you did not specify the kind of solaris you use. No, I didn't. I probably should have, but neglected to because I've had success on all recent revs -- some minor issues on 7, but it works perfectly on 8, which is what you use. No trouble along these lines on 9 beta, either. I haven't upgraded to 9 FCS yet. I'll add that I don't have any particularly strange libraries linked. The usual Sun base and networking libraries, libgen for regexes. I suppose you might not have libintl (mine does, of course), but that would be very strange on your side. Sven, if you have a question, please ask. But don't get irritable because I didn't dissect my installation to find out why yours doesn't work. Perhaps you should post your configure output, or mail it to me directly. I'd be glad to look over it, if you like. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: mutt 1.4 -- where does mutt write error messages to?
* On 2002.10.14, in [EMAIL PROTECTED], * Sven Dogbert Guckes [EMAIL PROTECTED] wrote: * Lukas Ruf [EMAIL PROTECTED] [2002-10-14 10:40]: I would like to know where mutt writes error messages to. Reading the man pages did not help me understand how to set on debug messages. mutt does not have a debug mode - yet. Yes, it does. You have to compile with --enable-debug, then run with -dN, where N is a number from 1-4 indicating how fine-grained you want to get. (I think it only cares about 1-4 -- I think all numbers higher than 4 give the same result as 4 -- but I could be wrong.) The output goes into ~/.muttdebug0. .muttdebug0 is renamed to .muttdebug1, etc. Almost like pine. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: iconv stuff on solaris still unresolved
* On 2002.10.12, in [EMAIL PROTECTED], * Sven Dogbert Guckes [EMAIL PROTECTED] wrote: so - is anyone using mutt 1.4 with iconv on solaris successfully? mind you - i am not root, so all my stuff resides in my $HOME. I'm using 1.5.1 on Solaris, and before that I used 1.3.x on Solaris, all successfully. I use the native iconv, though, not libiconv. I didn't do anything special; it just worked. +HAVE_ICONV +ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO I've built 1.4 on Solaris with no trouble, but I don't regularly use it. i once tried to resolve this but i think the bottom line was that it all is of no use because the solaris admin chose to install only the language stuff for C - and no others... Well, that would be a problem. But it's not fair or correct to say that this iconv stuff just doesn't work on Solaris. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: send hooks again .. not working
* On 2002.10.11, in [EMAIL PROTECTED], * Toby Coleridge [EMAIL PROTECTED] wrote: i have the following: send-hook . my_hdr From: [EMAIL PROTECTED] send-hook @student\.lboro\.ac\.uk my_hdr From: me@myuniemailadrress however when I send mail to [EMAIL PROTECTED] I get it from [EMAIL PROTECTED] not the send-hook as I believe I should .. any ideas? I thought that you need to use set from= in send-hooks instead of using my_hdr, but I might misremember. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: Any way to add a header with send-hook?
* On 2002.10.10, in [EMAIL PROTECTED],
* Chris Green [EMAIL PROTECTED] wrote:
Well it says in the manual:-
Also note that my_hdr commands which modify recipient headers, or
the message's subject, don't have any effect on the current message
when executed from a send-hook.
So does the above mean what it says, or have I misunderstood it?
It means what it says, but it might not say what it means. It's saying,
I think, that my_hdr cannot modify To:, Cc:, Bcc:, or Subject: inside a
send-hook. Other my_hdr headers are fine.
What I'm trying to create is a macro which will do the following:-
1 - It will work exactly like the current 's' command allowing
mail to be saved in a specific mailbox. Thus the macro will
first call the 's' command.
2 - It will bounce ('b' command) a copy of the mail to a specific
(fixed) address with an added header which will contain
the name and directory of the mailbox where the message has
been saved locally.
Is the above remotely possible? It's easy enoough to create a macro
Seems like it, although I don't know how you get the name of the folder
into the my_hdr, unless it's just a hard-coded part of the macro.
--
-D.We establised a fine coffee. What everybody can say
Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's
University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW!
[EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: short time in index view?
* On 2002.10.09, in [EMAIL PROTECTED],
* Eric [EMAIL PROTECTED] wrote:
Another option are the %{}, %(), %, and %[] formats:
I tried these but I think my syntax was incorrect. Does anyone have
an example syntax.
man strftime.
%m/%d %H:%M gives 10/09 12:49 right here, now.
You can test strftime sequences with (for example):
date +%m/%d %H:%M
--
-D.We establised a fine coffee. What everybody can say
Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's
University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW!
[EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
Re: ISO cancel option in quit prompt from send-message
* On 2002.10.08, in [EMAIL PROTECTED], * Ken Irving [EMAIL PROTECTED] wrote: Apologies for subscribing just to ask a question, and maybe for the unclear subject. Too often I accidentally hit 'q' after editing a message, and am presented with the choice to discard the message or not. Usually I want to select a third option, cancel the quit operation altogether, but instead have to carefully _not_ discard the message, then hit 'm' to see a prompt to revisit pending messages. Control-G cancels most prompted operations. -- -D.We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. LET'S HAVE SUCH A COFFEE! NOW! [EMAIL PROTECTED] Please love CAFE MIAMI. Many thanks.
