The story of how I find cool stuff, inevitably break said cool stuff, and (hopefully) end up fixing whatever I did

Email clients suck, Mutt just sucks less (yes I did rip off their slogan).  There are tons of email clients out there, most of which really do suck badly.  I used the Gmail client for some time and it was OK, for a web client.  I could have used sane thread handling, actually showing email that got sent to myself, S/MIME or PGP support (preferably PGP), not having to fire up resource heavy firefox, etc etc.  Now let me preface this by saying that Mutt is not for everyone.  It is a terminal based client, making it great for ssh, and it has a very steep learning curve.  One mistake people commonly make is that they assume that, like most other email clients, Mutt handles receiving, sending and viewing email.  This is an incorrect assumption as mutt is solely a MUA (Mail User Agent).  The idea is that you piece together exactly how you want your email system to work.  This means that it requires a lot of work on the users end to configure the system, although it does afford the advantage of having an email setup that does exactly what you want it to do, exactly how you want it done.

With that being said, I will first explain in words what my setup is, how it works, and why it makes sense to do it this way…then I will include all relevant configuration files along the way.

So I have Mutt, and my massively customized .muttrc. It includes where my folders are located, how I want key bindings to behave, colors, PGP settings, key bindings hooks for sending from the appropriate addresses, how i want to edit and view my headers, that I want to use vim to edit email, how email threads should look, blah blah blah. Below is my muttrc in all of its glory. I have painstakingly commented all the relevant pieces so everything makes sense to the normal person (and to me when I forget what stuff does. I have excluded certain pieces to avoid getting spammed :p )

I use vim as my email composer and there are a few tricks to get vim to play well with mutt.  Here is a snippet from my vimrc that enables spellchecking for mutt files and a few key bindings to may my mail look pretty when I’m done slapping on my keyboard.

Pretty self explanatory if you’re familiar with vim.  Enables spellchecking for mutt composition and gives me F3 – F5 for nice paragraph formatting.

As far as the F key mappings and reply hooks go, this is how I send from multiple addresses in Mutt easily. Whenever I want to send as a certain address I just hit the corresponding F key from within mutt and then go on composing merrily. The reply hooks ensure that I always reply as the address the email was addressed to. Reply hooks essentially work the same as send-hooks except backwards. They are not very well documented in the Mutt manual, which is a shame because they are extremely useful in cases like this.  The F keys source profiles that I have in my .mutt folder, they all must identical (except for different values in the variables of course) since they are sourcing out the same information.  Here is a skeleton profile that I use:

As you can see, each profile contains a path to the correct signature for that profile, setting the “send from” variable, passing the correct arguments to msmtp (which will be covered later), and setting the status bar to show which profile I am actually using…in this case al3k is the profile.  The default profile sourced is set in my muttrc (see above) and I can switch them out at will by hitting F7 through F12 in Mutt.

Now this is how I view and compose mail, sending and receiving is a different story; I will begin with how I receive my email. Bottom line, offlineimap is awesome. I realize Mutt has built in imap support, but it is mega slow and I would rather have a local copy anyways. From the offlineimap project github site, “You get a current copy of your messages on each computer, and changes you make one place will be visible on all other systems. For instance, you can delete a message on your home computer, and it will appear deleted on your work computer as well. OfflineIMAP is also useful if you want to use a mail reader that does not have IMAP support, has poor IMAP support, or does not provide disconnected operation.” The one downside to this is that it’s tough to find a solution to store your passwords in a secure way. For now I just store them directly in the file as I have an encrypted disk. In the future I would like to whip up a simple python keyring to store these safely, gnome-keyring and kwallet are waaaay too bloated for me to feel worth using them. Here is my .offlineimaprc

Just insert your username and password where needed and chmod 0600 the file. The nametrans function just uses a regex to translate the goofy gmail virtual folders into names that actually make sense. Feel free to change the names of localrepository and whatever else, just my setup…doesn’t have to be yours.

The, I use this short script stolen from the Arch Linux wiki to quickly daemonize a program that i place in ~/build/start_daemon (offlineimap occasionally crashes and becomes a resource hog, this takes care of that problem):

And then set up a cron job to run this every five minutes:

Ta da! offlineimap is syncing your local copy of your inbox with gmail every 5 minutes, all changes made at any point will be reflected everywhere, plus you have an offline copy of your inbox to work with!

For sending mail, I use the lightweigh msmtp and it works awesomely for me.  You saw above that each profile sets the sendmail command, which is smtp followed by the argument -a and the name of the profile.  This makes it extremely easy to send from different smtp servers and email addresses at will.  Here is a skeleton .msmtprc that is similar to the one I use:

With that setup you can send from the different accounts via msmtp -a <accountname>, works pretty well for me.
As far as PGP signing/encrypting goes, it’s rather simple as well.  I borrowed a piece of configuration from another guy who was nice enough to write about his mutt setup and combined it with some gnupg configuration to get a very nice PGP + mutt combination.  As you can see above in my .muttrc I source a file called ~/.mutt/gpg which contains all of my gpg settings and looks like so…

I know that just looks to be a bunch of jibberish but I do promise that it does work.  The setup is generic and should work for anyone, I won’t bother explaining it since I feel it is well commented but the short version is that Mutt just needs to be spoonfed the commands it needs to perform PGP actions on email.  This, in conjunction with a few settings on your .gnupg/gpg.conf, will make Mutt a secure email machine.  Here’s the relevant pieces you will want:

Pretty simple, all this does it set what public keyserver you want to use, MIT is extremely popular and I’m pretty sure they all propagate to each other anyway, and will automatically retrieve public keys when you receive mail from someone who stores their key on the server(s) as well.  The last line will automatically sign all encrypted messages to yourself as well as the recipient so you don’t get encrypted out of your own sent email :p
Lastly is my coloring, but that is really just a matter of taste.  I use 256 color profiles as well so it may not be compatible with everyone’s setup.  I’ll go ahead and post my colorscheme here and a screenshot, but that pretty much makes covers everything I do in Mutt.  I have yet to work on getting a real good mailcap going so I don’t have anything worthwhile to post here, but I will check back in when I have something worth sharing.
Here’s my color setup:

And here’s a few screenshots of my Mutt in action. Excuse the crappy pictures, I was on my Mac (not by choice) at the time and I personally think the console looks cartoony as hell. I’ll get some better ones up later.

Here is how my full setup looks, in fancy gallery fashion.

Hope this helps out people looking to get a jump start on mutt, or those looking for some more advanced tweaks to make mutt more awesome than it already is.  Leave a comment if you have any questions, or really just anything to say.

I have a Macbook Pro which has a large touchpad that is really sensitive so its always clicking on stuff while I am typing, which is extremely annoying. I have tried going the syndaemon route to disable the touchpad while typing, but it is very unreliable in my experience and I’d rather go about doing this without another process running in the background. This is a Linux specific tutorial, so if you want to know how to do this on Windows or OS X I apologize as this will not work for you. I do most everything in a terminal except web browsing (and even then I use elinks unless I need flash or fancy javascript), DWM is my window manager and I use vimperator with Firefox so I hardly use my mouse as it is.  Who needs a mouse when I already have 100 buttons at my disposal?  Anyway, I was looking for a way to quickly toggle my touchpad driver on and off so I can use it when I need to and then quickly get rid of it again.  While this guide is specifically for DWM and my Macbook touchpad, if you alter the scripts for your particular drivers and set up the keyboard shortcuts with whatever window manager you use, this guide should be fairly universal.

Here is a simple bash script that will determine whether a module is loaded and insert/remove accordingly:

I have this script located in /usr/local/bin/toggletp.  bcm5974 is the name of the macbook’s touchpad driver and swarp is a program that will move your cursor to specific coordinates on the screen.  Unfortunately there is no way to disable the mouse cursor in X so my solution was to move the cursor to the very bottom right corner of the screen where it can’t be seen when the module is disabled.
Now we are going to need a simple sudo wrapper since modprobe/rmmod require root access:

Now in order for you to be able to execute this script requiring root access without a password, you will need to edit the sudoers file to allow this. I tried using setuid originally until I realized that setuid doesn’t work on shell scripts

Here is the line I use in my sudoers file:

Wheel is just a group that my user belongs to. This is just the bsd style way of managing root access. This line allows you to execute the toggletp script as root without a password. Make sure that you set the executable bit on these scripts and lock down access since they can execute commands as root without passwords.

Now, these are the relevant lines from my DWM config.h so set the keyboard shortcuts for my scripts:

The third line and the last line are the chunks relevant to this guide. Copying these lines into your config.h will make it so that every time you press MODKEY+Z, it will execute the sudo wrapper for toggling your driver (mine is located in the build directory in my home folder). Now recompile dwm, reload, and , if everything worked out correctly, you should be able to toggle your laptop touch pad on and off at will with a simple keyboard shortcut!

Leave comments if you have any questions, I’m happy to help. Also, I cannot take credit for the touchpad driver bash script, a friend of mine came up with it and I modifed it for my use.

As an Arch Linux lover, I love all things minimalist. I have recently fallen in love with MPD (Music Player Daemon) due to the fact that I am prone to dropping out of X, working on something (usually something that I broke :p), and then jump starting X once more. MPD allows me to do this and keep on jammin’ to my tunes. Unfortunately, I have encountered a problem where, when updating the database (and sometimes at other times), MPD procedes to eat both of my cores and then all of my memory and swap, resulting in a segfault. This is highly upsetting. Turns out, the culprit is an ancient version of libid3tag in the Arch repos that is causing all of the issues. libid3tag gets hung up on certain id3 tags and then just gets confused and goes on a cpu and memory stealing rampage. I found an bug post just earlier this month on the Arch site documenting this issue and I was glad to find out that I was not the only one with this issue. The gentlemen was kind enough to post a PKGBUILD that included some patches that, ironically, came from Debian repos. I thought Arch was supposed to be the bleeding edge one??!! :p I have posted a link to the bug report which has the PKGBUILD attached near the bottom of the page and I am proud to report it has solved my issue. Kudos to honki for fixing this for us!

http://bugs.archlinux.org/task/18595

It annoyed the piss out of me that irssi doesn’t have a list of nicks in a given irc room.  Granted you can just /who but this just seemed like too much work given that programs such as weechat (which I have since swtiched to) have a nicklist right out of the box.  If, for whatever reason, you decide that weechat just isnt for you and you wish to have a nicklist in your irssi, then follow these simple steps.

grab the nicklist script from irssi.org

then move said script into your irssi scripts folder

then fire up irssi and issue these two commands:

Presto!  now you have a nicklist inside of irssi.  Beware of this script however, it does not play well with certain terminal,mrxvt for instance.  There are ways to autoload scripts in irssi but I honestly didn’t use it long enough to be moved to figure it out.  I suggest you check out weechat.

So I read an article on slashdot about how two hackers at the Hack in the Box convention in Dubai demonstrated how it is possible to compromise the OS due to a security flaw in the design….the flaw is that the OS trust that the boot process is safe. Now this may sound potentially groundbreaking, but I assure you it is not. The catch is that you have to have physical access to the machine. What the hell is the point in that?! If you had physical access to the machine, then the machine is compromised already anyways. Also, if you had access to the machine, no matter the OS, you could install whatever code you wanted on it…why the need for the boot code? What a waste of freakin’ time.