Slashdot Mirror
Mutt Fork Adds Features From Notmuch
Karel Zak started a fork of Mutt back in January to integrate features the upstream authors deemed too radical, and today released the first status update. So far implemented is native notmuch support (inspired by Sup) which adds fast search, tagging, and virtual folders from notmuch queries. Unlike the current hackish solutions, all of these are available as native mutt commands and can be used in your muttrc. Additionally, patches from Debian and other distributions will be integrated. Source is over at Github, and a few screenshots are on their wiki.
I moved from pine --> mutt --> any modern mail client.
No, seriously. Who here is using it? What's it do for you that made you choose it, or this fork?
[Disclaimer: Claws-mail. It's fast, and I'm lazy.]
"Whats in your new release?"
"Notmuch"
"That's what I'm asking, what did you add that's not in the original software?"
"Notmuch"
"Oh... well, did you improve on the performance?"
"No, that's still the same as Mutt"
"Still as slow as a dog?"
"No, it's at least as fast as Mutt"
Every other email client supports identities in the same clumsy fashion. Each and every identity must be individually configured in. That's fine when you four and they never change. It is nearly useless when you have 400 and add several new ones each week.
Mutt lets me define identities with regular expressions. I can set alternates=(.*@foo,example.com,.*@bar.example.com)
Now every user @foo.example.com and @bar.example.com will match as me, even ones I haven't thought up yet.
When sending a new message, I can type in whatever I want in the From: field. When the reply comes in, it is automatically recognized if it matches an established pattern. I haven't had to change my alternates in years even though I have added hundreds of identities.
I'm glad that mutt isn't stagnating, and that there are people dedicated to keeping it awesome, relevant and supported. Rock on, you crazy forkers.
Look, I know this is ads - sorry, news for nerds, but it just seems like common courtesy to make a summary at least partially non-opaque to a casual reader. I know what Mutt is, but if I hadn't been able to drag up that half-remembered fact I'd have found this to be yet annoying frustrating FS.
systemd is Roko's Basilisk.
yes.
if you're used to pine, it will take a day or two to get used to mutt's keybindings. it'll probably piss you off while you're learning them, because there are some subtly annoying differences.
after that, you'll be glad you did and you'll never look back.
mutt's searching and tagging features alone are worth the switch.
Yes, another former (al)pine user here. Header caching alone makes it worth it.
Neckbeards: Activate!
I'm a bit divided on whether I like (al)pine or mutt more.
alpine does local deliveries well, but defaults to creating external lock files and requiring world write access (instead of more sensible 3775 permissions), which opens up for denial of service attacks. And what it does when new mail arrives is attrocious - you pretty much have to exit and re-enter.
Mutt on the other hand, defaults to color, which is rather annoying, and can't do local delivery but depends on the availability of a sendmail compatible MTA/MDA.
This more than eats up the size advantage it has over (al)pine.
I wish old ZMail was maintained. I know Netmanage released the source, and one of the original authors released a one-time fork, but that was years ago, and it doesn't easily compile on new systems. But it truly was a great client, especially since you could use it both under X and from the command line, and it had a really good scripting language.
Mutt speaks SMTP now: http://www.mutt.org/doc/devel/manual.html#smtp
Mutt speaks SMTP now
Yeah, and that's a good thing, but it doesn't do local delivery.
On multi-user systems, it's nice to be able to leave a message to other users, without depending on another mail delivery agent. Even on machines that don't have mail servers installed. When setting up linux boxes or VMs for people, I like to leave a message in their inbox. Sure, I know the mbox format well enough to do that with vi, or I can temporarily enable a mail server on the box. But local delivery is still a missed feature in mutt.
You can set it up to use w3m to convert HTML mail to text. That way you can read all the HTML mail inside mutt, but without the formatting and images. A couple more keypresses and you can go into w3m to navigate around and follow the links, and if really necessary in w3m you can use 'm' to bring up the page in a graphical browser. All really convenient.
'mutt' is the best way to read mail in my opinion. I use it both at home (local folders) and work (IMAP).
Proportionally-spaced fonts are modestly more readable than monospace, for prose text.
Monospaced fonts allow for column-based formatting of tables, ASCII-art diagrams (networking, etc.), programmatic output, etc., which makes for a greatest common denominator balance between both readability and flexibility. For technical uses (programming, systems/network admin), monospace wins hands-down. It's also very easy to write simple programs / shell scripts to output data in fixed-length columns, which again, present well in monospaced fonts but are fugly in proportional ones (most of my text formatting in GMail, FWIW, is based on indenting and formatting in courier program output).
The alleged legibility gains of proportional fonts are minimal, and in the context of other benefits of mutt (threading, quote precedence, syntax highlighting of quote levels, URLs, email addresses, etc.), a full GUI mailer (Exchange, Thunderbird, GMail, KMail, etc.) is a net loss.
There's an issue for those reading mail on mobile devices with displays of Browser overhead means that GMail takes up most of a display, while I can stack up multiple mutt, shell, and other console apps either vertically or horizontally. Much more effective use of screen real estate.
What part of "gestalt" don't you understand?
When you've got many or large folders, the switching time can be substantial.
Systems admin, with various alerts and notifications getting filtered to various places. Opening a folder with ~10k messages takes a few seconds, ~100k really starts to bog down. Once I'm in the folder, filtering, tagging, and other actions are really quick. Getting there is slow.
My compromise: screen with several mutt buffers open, primary ones are my inbox and other hot folders, others I'll switch between less-frequently read folders.
What part of "gestalt" don't you understand?
it's easy enough to write a monochrome .muttrc
you can probably find one on the net if you search.
mutt shouldn't do local delivery - or do you routinely misconfigure systems so that mailboxes are world-writable? or do you want mutt to be setuid root or setgid mail?
mutt's job is to be an MUA, not an MTA or MDA.
there are numerous light-weight MTAs & MDAs that can be installed to handle local delivery...most of them just an apt-get install or yum install away.
e.g.
dma - lightweight mail transport agent
masqmail - mail transport agent for intermittently connected hosts
even postfix or exim aren't too heavy to just install as a matter of course on most, if not all, machines. it's hard to imagine any machine that shouldn't have a local MTA, or wouldn't benefit from one. even a little openwrt router or similar embedded device should have one just so that it can send alert messages.
lots of things already depend on (or assume) the presence of an MTA anyway. cron, for example. so you need something to fill that job, whether it can handle local delivery (most MTAs) or not (nullmailer, and similar relay-only MTAs)
echo "message" | mail -s "hi" username
an MTA is an (almost) essential service that can be used by many other tools to send mail (both local and remote), without each of them having to reinvent the wheel.
mutt shouldn't do local delivery - or do you routinely misconfigure systems so that mailboxes are world-writable?
Hell no. Removing o+w for /var/spool mail (or /var/mail) is about the first thing I do on systems, cause MOST distros seem to get this wrong.
or do you want mutt to be setuid root or setgid mail?
If mutt had been capable of local delivery, it should be setgid mail, definitely. Any MDA you use with mutt most certainly is either sgid mail or suid root.
The thing is to give /var/spool/mail sensible permissions., like 3775 root:mail. I'd even make that 3770 if all the mail apps on the system are under control. Or use acls or SELinux to limit as appropriate, if you can be certain that the system won't be admined by someone who turns off acls and SElinux because they don't understand it.
The 1777 most commonly found is sheer folly. It opens up for DoS attacks like: /var/spool/mail | sed 's/$/.lock' | xargs touch ... or a user pre-creating mailboxes for new users before the sysadmin gets to create the accounts, and make sure they are o+rw. The new users can still read and get mail, but so can others.
ls -1
Even worse if on a Unix system where you're allowed to give away files. Then the sysadmin can't even see who created the file if it gets discovered before the bad user got a chance to delete it.
In short, the paranoia against sgid does more harm than good, and in many cases lessens security by requiring more liberal permissions. Be paranoid about people and their intentions. And use permissions including sgid appropriately to make things more restrictive, not less.
On the upside, since I have a static IP at home, I just set up an MTA on my desktop, and send mail much much faster that using some external (innecesary) relay!