Re: How is mutt with multi-mega-byte mboxes?
On Thu, Sep 18, 2014 at 04:19:12PM -0400, Mark Filipak wrote: How is mutt with multi-mega-byte mboxes? Have you found that having tens of thousands of messages in a single box is dangerous? Thank You. I've had up to 40k messages in a mbox file, collecting debian-devel. The only effect I noticed regarding mutt is that loading the box upon access took its due time (my disk is quite slow). But the file itself didn't get corrupted by the fault of mutt in any way. That being said, since you're talking about 'multi-megabyte mboxes': my local 'sent' mbox is well over 1 gigabyte due to attachments -- this too doesn't seem to be a problem at all. Best regards, Jens.
Re: muttprint
On Sun, Apr 08, 2018 at 01:51:36PM +0530, Kumar Appaiah wrote: Currently, on Debian, my muttprint seems to work with Perl 5.26.1. Can you tell me what the problem you are facing might be? Debian's version is heavily patched. OP may want to try the most recent Debian version after applying all patches (there are a dozen or so in debian/patches).
Re: choices on reading HTML emails
On Tue, 10 Apr 2018, at 21:34, Grant Edwards wrote: > I have my mailcap entry set up so that "viewing" an html message uses > w3m but "printing" an html message opens it in chromium Many thanks for pointing me to the `print=` configuration option in mailcap! I used to save the HTML message part manually and then open it in the browser for when the w3m rendering was not good enough, and was looking for a workaround to rebind the open action from the message part browser to call a GUI browser. Repurposing the print functionality is a neat trick. Regards Jens.
Re: Mail checking a bit slow
On Tue, 20 Mar 2018, at 05:17, David Woodfall wrote: > Is there a way of speeding this up? I'm not using IMAP or anything, > just plain maildir. You should try `header_cache`. It worked wonders when I was still using a HDD and Maildir, reducing mailbox load times from ~4s to .5s for large maildirs. Not sure how much of a difference this would make on a system that already has SSD, but even then it's worth a try. header_cache Type: path Default: “” This variable points to the header cache database. If pointing to a directory Mutt will contain a header cache database file per folder, if pointing to a file that file will be a single global header cache. By default it is unset so no header caching will be used. Header caching can greatly improve speed when opening POP, IMAP MH or Maildir folders, see “caching” for details.
Re: Saving sent e-mails in INBOX for better threading?
On Thu, 28 Mar 2019, at 13:32, Max Görner wrote: > Could some readers of this list please share their opinion/experiences with > me? As someone who is only using mutt's threaded view, it's terrific and achieves exactly the behaviour I want from a mail client. mutt's way of displaying threads -- at least with Unicode characters -- also looks very tidy. Collapsing, splitting, merging threads is also a very convenient feature to have, especially in cases where the conversation partner or software breaks threading by applying worst practices on every occasion. An issue is that when using multiple email clients, online IMAP must be used for all mailboxes (which I don't like -- I like to only pull IMAP to my local machine, which is the authoritative copy, and not push; also, I don't sync IMAP deletions from the server) OR you could just do it like I do, I BCC all outgoing emails to myself so I can have the same consistent inbox view from everywhere. Multiple clients in my case means: mutt at home with isync (pull only), webmail from everywhere else.
Re: Compiling a newer version than the latest .deb package
On Sun, 2 Jun 2019, at 05:36, Frank Watt wrote: > Am I to assume that I would have had sendmail in my environment at the > time the deb was installed? So I'd need to remove it so that I can > compile mutt with built-in SMTP. What else would I need to bear in > mind? > > I'm a bit apprehensive about compiling code outside the control of a > package manager, but I can't see a way around it -- unless someone has > made a more recent .deb. (Why not just upgrade your Debian or Ubuntu release?) Anyway, whether sendmail (or compatible provider of it, such as postfix) is installed at compile time has, if I see it correctly, no bearing on whether the built-in SMTP client will be compiled or not. Just remember to select the configure flags you need – you likely want TLS support – and perhaps install into /usr/local or /opt/mutt if you compile from source. A reasonable set of configure flags yielding a versatile mutt can e.g. be found at [1]. --- [1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mutt#n21
Re: Going GUI...er
On Sat, 4 Apr 2020, at 09:41, Vegard Svanberg wrote: > Suggestions? What does everyone else do? If you're already SSHing to your mutt instance, that is, using email online-only, it doesn't like like webmail would be the worst bet you could make. I can recommend Fastmail.com; their webmail application can be driven 100% by keyboard shortcuts [1] in all modes (index, reading, composition), the UI is very fast and response, layout-customizable in some degree, and their email capabilities are pretty much complete (MFA with app passwords, standards-compliant IMAP, Sieve/filters, SPF/DKIM, identity management, they have labels/tags a la G-Suite as well in their beta by way of their JMAP implementation). When compared to G-Suite, Office365, Rainmail, Roundcube, Zoho, Open-Xchange, and a few others I've tried, Fastmail is the fastest and most power-user friendly solution there is at the moment. You buy these advantages with a lack of customizability: there's more of a take-it-or-leave-it component to it than to mutt, but I think that the same goes for Thunderbird, Sylpheed, and other GUI clients. My personal setup is actually dual: I use Fastmail in the web client most of the time, and for server side search, but as part of my offline strategy, I always have a local setup with mutt, notmuch, 100% synced IMAP content using isync/mbsync. Effectively, I use both mutt on the desktop and webmail on the web. Works great together. So from personal experience, I'd recommend a dual mutt-desktop+imap plus webmail+imap setup that gives you all the advantages and none of the drawbacks. You'll have to evaluate the webmail offerings first, of course. [1] https://www.fastmail.com/help/receive/kbshortcuts.html
Re: conditional automatic cc header?
On Wed, 1 Apr 2020, at 06:22, raf wrote: > e.g. Add a CC header to f...@work.com whenever > sending/replying/forwarding from m...@work.com unless the > email is already going to f...@work.com. I think a combination of hooks or only a send2-hook could be used. How about something along these lines (not tested): send2-hook "~f m...@work.com !(~C f...@work.com)" "my_hdr cc: f...@work.com" I do not know if my_hdr would respect headers that are already there. For example, if you set a header using the editor CCing a few people, Fred should only be added.
Re: conditional automatic cc header?
Apologies for answering a solved thread; I received raf's followup only after reconnecting to the server when sending my reply. Cheers.
Re: Inline PGP Within HTML
On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote: > IT guy refuses to install any Outlook plugin for them to properly > handle encypted emails. Outlook has pretty comprehensive, native support for encrypting and signing with S/MIME. Perhaps your IT guy would be more open to just using a well-documented Outlook feature? As mutt has support for S/MIME too, this might be much more workable than insisting on PGP.
Re: Inconvenient Signature Requirements
On Mon, 4 May 2020, at 22:54, Kevin Monceaux wrote: > My employer is trying to force me to downgrade to Outlook. One of the > powers that be came up with the brilliant idea of having a standard company > signature, with logo, specific font requirements, etc. Is there any way to > include such a signature in e-mails sent from mutt? Sadly, I suspect I > already know the answer. Note that in order to include such a signature, you'll also need to send the email as text/html. When composing a text/plain email and sending it, you then seem to need to generate a text/html MIME object and insert it into a multipart/alternative container. The recipient then will have the choice and see either the corporate design HTML or plain text (MUA will likely prefer the HTML version). Current mutt has a convenient option for this, $send_multipart_alternative: > If set, Mutt will generate a multipart/alternative container and an > alternative part using the filter script specified in > $send_multipart_alternative_filter. See the section “MIME > Multipart/Alternative” (alternative-order). You should be able to get done what you want by implementing a $send_multipart_alternative_filter (for the protocol see man muttrc) that converts the message to proper HTML markup (including ) and includes the signature snippet. If the signature contains image data, it is possible to inline the image data into the HTML by using the src=data:image/jpeg;base64 attribute of the tag. This saves you from having to inject extra attachments with certain content dispositions into the message, and allows you to keep the filter clean from side effects. This could be done real quick using Python; though I can also think of getting this done elegantly using pandoc: You'd specify the input format to be markdown, rst or similar, and pandoc will then emit HTML markup with paragraph markers etc, and your signature can be appended to the output file using a footer. Using pandoc with a HTML5 template file would be even simpler than piling up the command line switches; the template could look as simple as (first two lines are $send_multipart_alternative_filter protocol) > text/html > > $body$ > $for(include-after)$ > $include-after$ > $endfor$ and as part of the include-after, pandoc will append any HTML snippet(s) you specify using --include-after-body= to the output as-is. Since pandoc works fine with reading from stdin and writing to stdout, this could make for a clean solution. pandoc has documentation as good as mutt so it should be easy to find your way around it. You'd have two changes: implementing the filter, and possibly a change in style how you format your messages (because Pandoc needs a recognizable markup input format) to match markdown, rich structured text, asciidoc etc.
Re: support autocrypt support in Debian and Ubuntu
On Wed, 30 Dec 2020, at 13:11, Arsen STASIC wrote: > Hi, > > Is there no one interested in autocrypt support in Debian or Ubuntu? > > cheers, > -arsen I marked myself as affected on the Launchpad bug. Not seeing anything moving too fast here though by nature of the upstream distros concerned.
Re: textwidth/linewrap
On Thu, 7 Jan 2021, at 18:25, tech-lists wrote: > > I guess lots of people would use mutt with vim-console. > > Can anyone tell me please what setting they use for line > wrapping? I thought in .vimrc it'd be > > set textwidth=72 > > but that doesn't seem to work. Is it a setting in .muttrc > or in .vimrc? Or an additional setting? A syntax plugin may override your settings. I suggest trying the following line in your vimrc: autocmd BufNewFile,BufRead mutt-* set tw=72 syntax=mail Personally, I use autocmd BufNewFile,BufRead mutt-* set tw=72 autoindent noruler syntax=mail
Re: Validate DKIM in Mutt?
On Wed, 5 May 2021, at 15:38, Gregory Anders wrote: > Has anyone attempted this, and if so would you be willing to share? I had the following two setups related to that over time: (a) When I had my own Postfix mail server, I had rspamd add a _short_ extra header to emails which pass DKIM validation. (b) Similary, at my current paid email hosting, they automatically add a rather complex Authentication-Results header to incoming email that contains the required info. I had a Sieve script configured that adds, if dkim=pass, a short extra header just like in (a) In both cases, I then just instructed mutt to show the short custom header when viewing email, in color, so it was easy to see which emails were authenticated and which were not. DKIM validation is necessarily an online thing to do unless you know the current DKIM keys of the involved parties in advance, and/or do caching. Should you attempt DKIM authentication, I would not make it an ad-hoc validation at view time, but always at email reception time, since the DKIM keys for any party involved in the authenticated chain may also change over time without the DKIM selectors changing, or the parties take their old DKIM selectors offline after rotating (! you'd be surprised how many postmasters get so much wrong), so after some time, it is almost guaranteed for DKIM validation on already received messages to fail. In fact, I believe that if you do DKIM validation an hour after the email has been delivered over SMTP, it is already too late. This is significantly different from offline and ad-hoc PGP signature validation, esp. more complex due to the many parties involved. You can still check if a signature of an expired key on an old message is good, but what do you do with a message that suddently starts failing DKIM authentication? In the latter case, the authentication result at view time is useless. These days, I rely on the spam filter as a proxy for passing DKIM authentication.
Re: Search and limit from command line
On Sat, 20 Mar 2021, at 10:42, Julius Hamilton wrote:
> Hello Mutt users,
>
> I would like to know if there is a way to retrieve a list of emails from
> a particular user at stdout in bash, rather than launching the mutt
> application. Or, if one can launch mutt with the search already
> executed. I currently know how to launch mutt, and then search for a
> particular sender.
>
> Or, if someone knows commands from a similar tool to achieve this.
Use notmuch.
$ notmuch search 'from:Julius Hamilton'
thread:00015cd4 25 mins. ago [1/1] Julius Hamilton; Search and limit
from command line (inbox unread)
$ notmuch search --format=json 'from:Julius Hamilton'
[{"thread": "00015cd4", "timestamp": 161622, "date_relative": "26
mins. ago", "matched": 1, "total": 1, "authors": "Julius Hamilton", "subject":
"Search and limit from command line", "query":
["id:YFXDdAEhEL3NU0sj@localhost", null], "tags": ["inbox", "unread"]}]
I have integrated it with my mutt like so (I fetch email using isync/mbsync
instead of using mutt's IMAP support):
macro generic,index,pager "mbsync
-anotmuch new" "fetch mail"
macro index \
"set my_old_pipe_decode=\$pipe_decode
my_old_wait_key=\$wait_key nopipe_decode nowait_key\
notmuch-mutt -r --prompt search\
`echo
${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`\
set pipe_decode=\$my_old_pipe_decode
wait_key=\$my_old_wait_key" \
"notmuch: search mail"
macro index \
"set my_old_pipe_decode=\$pipe_decode my_old_wait_key=\$wait_key
nopipe_decode nowait_key\
notmuch-mutt -r thread\
`echo
${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`\
set pipe_decode=\$my_old_pipe_decode
wait_key=\$my_old_wait_key" \
"notmuch: reconstruct thread"
Macros given as a reference, not as an example of especially good scripting. I
haven't touched or improved these definitions in years.
Re: Search and limit from command line
On Sat, 20 Mar 2021, at 20:24, Julius Hamilton wrote: > Thanks very much. > I'm a beginner to this, so I'd appreciate being able to ask a few > questions about setting this up. > It asked for the path to my email archive. I had a folder on my desktop > called Mail, but it's empty, and not connected to Mutt. I always just > launch Mutt "live", and it connects to my gmail server, when I want to > check my email. > Do I need to somehow integrate Mutt with that archive folder for notmuch > to work? How do I do that? Or should I give it somehow a different > path, into my Gmail? These are the exact right questions to ask. >From notmuch's website: > Notmuch is not much of an email program. It doesn't receive messages (no POP > or IMAP support). It doesn't send messages (no mail composer, no network code > at all). And for what it does do (email search) that work is provided by an > external library, Xapian. So if Notmuch provides no user interface and Xapian > does all the heavy lifting, then what's left here? Not much. So, notmuch can only read local email, and it needs to read the email completely in order to index everything; just mutt's IMAP header cache is not enough. You need to donwload all email for notmuch to read. This might even be good as an extra backup. There are two ways I can think of: (a) The way I am using. I do not use mutt's IMAP support; I use mbsync [1] to download all email from all my accounts, to ~/mail. I just use mutt to read the many mailboxes that are in ~/mail. After downloading the email, I can run `notmuch new` on ~/mail and index all new mail for search. mbsync supports two-way sync: it pulls the remote IMAP account to a local mailbox, but also supports pushing your local changes back to the remote, including moves, copies, flags and deletions - this means that while you might not be using IMAP in real time, there would still be a way to retain the flexibility of IMAP. (b) Just keep using mutt as-is, but always download an extra copy of all remote email using mbsync. For example, I run a systemd timer every 15minutes in the background which downloads all email and updates notmuch. This way, you do not need to ever worry about the sync. But then you're free to just use notmuch on the command line, or make some macros to use notmuch from within mutt like I posted earlier. -- [1] https://isync.sourceforge.io/mbsync.html
Re: Using Gmail IMAP with Mutt
On Thu, 2 Sep 2021, at 19:12, David J. J. Ring, Jr. wrote: > What does gmail really want? Gmail or GMail or something different? > > Thanks in advance for your replies and help. I'm sorry I'm confused > but it is confusing. Accidentally, I think they changed something because by mbsync config broke some time in August or July. I am now using "[Gmail]/All mail" & "[Gmail]/Sent Mail" (sic: yes, mail lowercased and Mail uppercased for the other folder. Previously, I had been using "[Gmail]/All Mail" (sic) (did no longer work). If in doubt, I would recommend using Thunderbird or another IMAP tool to check which folders a vanilla gmail account presents. Gmail is only a legacy account for me so I'm not exactly keeping up to date with the service.
Re: Using Gmail IMAP with Mutt
On Fri, Sep 03, 2021 at 06:59:23PM +0100, Steve Karmeinsky wrote: > On Thu, Sep 02, 2021 at 07:21:30PM +0200 or thereabouts, Jens John wrote: > > On Thu, 2 Sep 2021, at 19:12, David J. J. Ring, Jr. wrote: > > > What does gmail really want? Gmail or GMail or something different? > > > Thanks in advance for your replies and help. I'm sorry I'm confused but > > > it is confusing. > > Accidentally, I think they changed something because by mbsync config broke > > some time in August or July. I am now using "[Gmail]/All mail" & "[Gmail] > > /Sent Mail" (sic: yes, mail lowercased and Mail uppercased for the other > > folder. Previously, I had been using "[Gmail]/All Mail" (sic) (did no longer > > work). If in doubt, I would recommend using Thunderbird or another IMAP tool > > to check which folders a vanilla gmail account presents. Gmail is only a > > legacy account for me so I'm not exactly keeping up to date with the > > service. Now this is very funny. Today's IMAP pull with mbsync indicates that Gmail has changed its reported folder names'/labels' capitalization. Again. After everything was fine for one or two weeks. Error: channel gmail: slave [Gmail]/All Mail cannot be opened. Error: channel gmail: master [Gmail]/All mail cannot be opened. As I don't really need my Gmail anymore I'll just remove Gmail from my sync altogether. Personally, I find this inconsistency on Gmail's side highly annoying. Their IMAP implementation is garbage. What a waste of time.
Re: Search and download
On Thu, 29 Jul 2021, at 16:37, Bastian wrote: > On 29Jul21 09:38-0400, hy...@nasalinux.net wrote: > > Is "fetchmail" still a thing? > Yup. at least for me. Should I change to a modern tool? fetchmail is still getting regularly updated :) Though fetchmail does one-way sync = pull. According to the OP's requirement for switching from "online IMAP" to "offline IMAP" he actually requires two-way as supported by offlineimap or (my preferred tool) isync/mbsync unless he is OK with local changes not being reflected on the IMAP server. @OP If speed is your only concern: have you already configured all available caching mechanisms (headers, messages) as explained in the mutt manual? Perhaps with the right cache use, the delay between mutt launching and going online wouldn't be as long anymore.
Re: Binding the pad-Enter key?
On Mon, Sep 27, 2021 at 12:48:11PM -0400, Mark H. Wood wrote: > I wanted to bind the Enter key on the numeric pad so that it works the > same way as the Enter on the main key grid. I entered ":exec > what-key", hit pad-Enter, and was told that it is "Char = , Octal > = 527, Decimal = 343". So I entered ":bind generic > select-entry", got no error back, but pressing pad-Enter still results > in "Key is not bound. Press '?' for help." > > What am I missing? Both the pad enter key and the main enter key yield for me an identical: Char = , Octal = 15, Decimal = 13 on German standard keyboard layout. Why do these yield different chars for you? What keyboard layout are you using that it sends different keycodes for both enter keys, and what terminal emulator with which terminfo are you using? To my knowledge, all that can affect what a TUI application is seeing when you press a key. If your keyboard layout does not have both enter and pad enter bound to to begin with, perhaps that would be the most straightforward way to go?
Re: NeoMutt Opinions
On Wed, 22 Dec 2021, at 22:50, Oleg A. Mamontov wrote:
> The feature of neomutt that completely determines my choice is an
> elegant built-in integration with notmuch. Really worth to try.
Like Oleg I see the notmuch integration including the notmuch:// protocol for
folders as the biggest selling point of notmuch these days plus the Lua
scripting interface.
That being said, while I could see myself not being able to do without that
much notmuch in a business setting where mutt would be front and center of my
emailing and day-to-day work; for my private use, mutt is enough --- I use
notmuch mainly for search across mailboxes and detailed search, and for that,
these trusty macros have been in my muttrc for years unchanged and do the job:
macro generic,index,pager \
"mbsync -aqnotmuch new" "fetch mail"
macro index \
"set my_old_pipe_decode=\$pipe_decode
my_old_wait_key=\$wait_key nopipe_decode nowait_key\
notmuch-mutt -r --prompt search\
`echo
${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`\
set pipe_decode=\$my_old_pipe_decode
wait_key=\$my_old_wait_key" \
"notmuch: search mail"
macro index \
"set my_old_pipe_decode=\$pipe_decode
my_old_wait_key=\$wait_key nopipe_decode nowait_key\
notmuch-mutt -r thread\
`echo
${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`\
set pipe_decode=\$my_old_pipe_decode
wait_key=\$my_old_wait_key" \
"notmuch: reconstruct thread"
Most of my email processing these days is also happening server-side (starting
from SPF, DKIM, DMARC, ARC and ending at Sieve) so that I simply do not need
turing-complete script bindings via Lua in my MUA. This used to be different
(msmtp > procmail > (filter chain) > mailbox, but not anymore.
Re: OT: "domain-level" email hosting services?
On Sat, 23 Oct 2021, at 16:21, Bastian wrote: > The stack I use is exim, spamassassin, dovecot on debian > stable since ~2006. If somebody would set something up new today, I would recommend the following 3-piece software stack: 1. postfix as the SMTP server and Let's Encrypt for a proper validated host SSL certificate 2. dovecot as the IMAP mailbox server 3. rspamd as the "policy engine". It can validate incoming SPF, DKIM, DMARC and ARCs which are all current best practice among the commercial email hosts, and it also can apply DKIM signatures and ARC seals to outgoing mail in a standards compliant way. The usual spam learning techniques are all implemented in rspamd, and it can interface with spamassassin, clamav etc as well. rspamd is very useful to prevent the piling up of different milters in postfix which work all differently.
Re: Thank you for threading!
On Thu, 22 Jul 2021, at 17:38, David Lowry-Duda wrote: > Threading is amazing, it's true. It's something that mutt does correctly > and the big webmails don't do correctly. Correction, it's something any other mail client simply does not in any bearable way. It's just so nice and tidy in mutt. Plus thread-level message management. And the guy who breaks Reply-To chains with his every time while also changing the subject beyond recognition? mutt has link-threads! I mostly use webmail these days for unrelated reasons but the magic of IMAP two-way sync allows me to fall back to mutt for wrangling my inboxes when I need to.
Re: Set variable depending on environment (or similar)
On Thu, 20 Jan 2022, at 13:29, Chris Green wrote: > I was thinking I might need to use muttLisp Now _that's_ something I've missed so far. Looks neat. Though the only use I personally see at the moment is replacing repeat statements in muttrc with varying arguments (mailboxes ..., alias ...) with a list expansion.
Re: Set variable depending on environment (or similar)
On Thu, 20 Jan 2022, at 10:52, Chris Green wrote: > The first one is easy (I think?!) but how can I do the second one > where my_hdr bears no relation to the hostname? According to the mutt man page: > It is also possible to substitute the output of a Unix command in an > initialization file. This is accomplished by enclosing the command in > backticks (`command`). In a very simple case, setting From: based on shell logic: my_hdr From: `case "$(hostname --fqdn)" in zbmc.eu) echo 'Chris Green ' ;; *) echo 'Chris Green ' ;;` If you're always running from a shell that guarantees $HOSTNAME to be set, you could remove the subshell $(). You can also freely adjust the shell expression. Another solution would be to reference an environment variable that always contains your email address. For example, my_hdr From: "Chris Green <$EMAILADDRESS>" with EMAILADDRESS= being set in the environment of any host you're using that muttrc on.
