On my Linux desktop, I use mutt for email. I have a friend who also uses mutt. He used to run mutt on a Linux desktop, but he has since migrated to using mutt on a Mac. You can do that using MacPorts or Homebrew or similar add-ons that give a better Unix experience on a Mac.

Back in 2003, we set up encrypted email between ourselves. This was a bit of an adventure, but we did it. We continue to use encrypted email. We don't have to, we don't have any massive secrets, we did it because we could, and we keep doing it to keep our knowledge fresh. We use gpg for the encryption.

My friend wants to expand the encryption. We are using older keys. Mine is 2003 vintage, my friend's key is 2006 vintage. Mine is only 1024 bits long. It's old, it's near worthless. Also, my friend wants to access his mail in two ways now. He wants to keep reading it in mutt when he's home, but he wants to read the mail when he's on the road, using his iPad. He can use Canary Mail on the iPad, but it doesn't support our old keys. Canary Mail supports OpenPGP. So does gpg, and therefore mutt can too, but we have to change our keys. We did that today, and I updated my notes, and wanted to add my notes here so we have access to them next time we have to fiddle with the keys.

(These notes assume that you already have mutt configured to use gpg. This can be a bit of a struggle, but mutt provides good instructions and a sample config file. I'm not going to go into detail about this here.)

Look at that. My key was created back in 2003. My friend updated his key in 2006. Here we are in 2019 and we're using such ancient keys, and such small ones. Tsk.

What we did was add two new keys, one mine, one his.

I created my new key using these steps:

Creating a new key for myself

gpg --openpgp --gen-key

Using --openpgp will create an OpenPGP key that will be more compatible with a lot more software.

Choose 1 for the default, RSA and RSA

keysize 4096

0 for key not expire

my name

my email address

a small comment. This will appear in brackets after the name, so make it useful. As this change is to add an OpenPGP key, I made my comment "OpenPGP compatible" so I can immediately distinguish this key from others.

passphrase - make this smallish. You'll have to type it in the first time each mutt session you want to use this key, so don't make it 300 bytes long because you'll get sick of typing it in. This is the password to using this key.

Your new key will be generated. I got complaints from the operating system that I wasn't generating enough entropy and needed to move the keyboard and jiggle things around, and in the end I played music on my desktop with cmus, and that generated enough entropy and the key finished creating.

So there's my new key. I have the comment in brackets beside my name which will help distinguish between the old key and the new key. I note the key ID so I can specifically refer to that key. The key id is the second number on the first line, the one after the slash. In this case, 57BC136C.

Make the new key the default

Edit the file ~/.gnupg/gpg.conf and change the default to the email address,
and you may as well change the encrypt-to to the same address.

default-key xxx@brownsack.com
encrypt-to xxx@brownsack.com

Send the public key to my friend

I now have both my public and private keys, but that's not much use. I have to pass my public key to my friend, and I have to get his public key. There are a number of ways to do this. The easy way is to use mutt and send an email. An encrypted email. You want to send the new key inside an email encrypted with the old key. Right now, we are still emailing with the old keys, so we can do this.

Start mutt

Create a new message for the other person

At the Compose screen, press Esc-k to generate the public key to send

Enter the ID of my new public key because that's what I want to send to him. Yes, the key id I mentioned up above, so run "gpg --list-keys" and get the key id of my new public key and type it here.

Send the message, making sure the message is encrypted using the old key.

Accept my friend's new public key

While I've been creating my new key, my friend has been creating his new key using the same instructions. He emails me his public key in an email encrypted with our old keys.

Start mutt

Look at the new email, and press v to view the components

Mutt will put the word 'key' at the start of the email component that is his new public key

Switch to the new keys

Right now, we are both still using our old keys. Now we co-ordinate. I have imported his public key and signed it and trusted it. He has imported my public key and signed it and trusted it. So we send one final email to each other using our old keys, telling us to switch to the new.

All my gpg stuff for mutt is stored in a config file called ~/.mutt.gpg. Your mutt configuration might well be different. At the end of .muttrc, I have these lines:

# Add in GPG configuration
source ~/.mutt.gpg

and at the end of .mutt.gpg, I have this line:

set pgp_sign_as=0x91D9A11F

This tells mutt to sign and encrypt messages with the key identified by the key id of 91D9A11F. If you look at my list of keys, you can see that this is my old original public key.

So I change this to the key id of my new public key.

set pgp_sign_as=0x15BC809F

So now, mutt will start using my new key.

Just FYI, I have two lines in .mutt.gpg that determine who gets encrypted email and who doesn't.

The first line sets the default and no encrypting and signing happens for everyone. The second line makes an exception for my friend, and emails to his email address are encrypted and signed.

Exchange emails encrypted with the new key

Now that I have switched to my new public key, I can send him an email or wait for him to email me. We both did this.

I used mutt and created an email for him. It recognised that his email address needs signing and encrypting, per the config up above. It gets my new public key, because it knows which one is the default now. It has to combine my public key with his public key, but oh look, his email address is associated with two public keys. Mutt shows a list of both keys and lets me choose which one to use. This is where the comment becomes useful, as one has a comment of OpenPGP and the other has no comment. See the list of keys up above. I select the new key, press Enter, and then mutt wants to know if I am really authorised to use these keys by asking for my passphrase. I type the passphrase, and press Enter, and then the email is encrypted using my new public key and his new public key, and mutt emails that encrypted email to him.

In the meantime, an email from my friend has arrived and it is encrypted with the his new public key and my new public key. I start mutt again, select his email and press Enter. Mutt knows it is encrypted, and it knows how to decrypt it, but first it wants to know if I am authorised to do this, so it asks for my passphrase. I type that and press Enter, mutt decrypts the message and displays it.

And we are done.

Cleaning up

So now we have two keys each, and we are using only the latest one. If I have any old encrypted messages, I need to keep the old key around to be able to decrypt those old emails. But if I have saved all the messages in unencrypted form and never expect to get another one with the old key, I could delete my old key, and probably my friend's old key. I would do this:

After yesterday's success with getting mutt to show calendar invites, I looked at how I view HTMl emails. Apart from them being an abomination, and a huge security risk, sometimes I have to see them.

I used to have a .mailcap entry of:

text/html; links %s; nametemplate=%s.html

And that works okay, but I have to v to view the contents of the email, then manually select the text/html part, then m to view it with the mailcap entry. I did some reading to see if there was a way to improve this.

There was.

First I installed w3m, a small HTML to text converter. I installed it using sbopkg under Slackware.

Then I changed the .mailcap line for text/html to this:

text/html; w3m -I %{charset} -T text/html; copiousoutput

and finally, I added this line to .muttrc:

auto_view text/html

Now, when I view an email that contains a text/html section, mutt will show the HTML portion as parsed through w3m. There's rudimentary formatting, and most of the HTML will be displayed in a good-enough fashion. It works automatically, and it's better than before, so that's good.

I use mutt for mail, and it's a text based mailer, very fast, very neat, and I've been using it very happily for 20+ years. I ran into a small irritation last week.

We have new managers, so now I am getting vcalendar invitations to meetings. These are included in the email as mimetype text/calendar, and sometimes application/ics. Mostly the first one.

If I am just looking at the raw format of these invitations, I have a hard time understanding when these things start, especially factoring in timezones. So I went looking for a way to display the vcalendar info in mutt when viewing a message. There are some wonderful solutions out there, and I settled on this one.

The first step is to get a vcalendar filter, and there is a nice one available on github. Follow that link.

It requires a number of Perl modules:

Text::ICal

Text::Autoformat

Date::Manip::DM6

Install those Perl modules, then put the script in your private bin directory and call it vcalendar-filter. Make sure it's executable. Test it by extracting a vcalendar entry from an email, saving it to a text file, and then running vcalendar-filter on it. If it works and displays a neat easily-understandable version of the meeting, you are ready to move on.

I tried it out. Different interface to Moves. You get the timeline of events up front, overlayed on the map. It took me a little while to find how it worked. I should have read more. Beside the locations it found, and besides the transportation methods, I had a lot of little red dots. These mean it wasn't sure of these things. The more you use it, and the more you eliminate the little red dots, the more confident it gets in placing you and working out your movements.

When you start the app, you get the map at the top with your movements marked. Tap on the map and the other views disappear and you can move the map around, expand it and shrink it with the usual pinch and pull gestures. Tap the X at the bottom to go back to the main view.

You get a horizontal bar in the middle which summarises your movements. Tap on that and you get an expanded view of your activity.

Then you get your timeline in a big view at the bottom. Slide up and down to see it all. You can tap on segments to edit them, and correct the location and activity. There's quite a lot you can do there.

Right at the top is the date, and you get a calendar to move around. To the right of that is a double arrow to go to Today. If you just want to move around a day at a time, swipe left or right on your timeline.

At the bottom left is the Arc symbol again, tap that and you get the menu.

Top left is a search button, and I haven't done a lot with it. I searched for Acredale (the cat's vet), it showed me a lits of my visits there, let me choose one, and then showed me the timeline and map for that day. That's really nice.

Overall, it's an easy interface, and the more you use it, the easier it gets. I'm liking this app.

Once I started confirming and correcting things, I was in a better position. What I particularly like is that the data is stored in iCloud. It does not appear to be sent off the phone to the developer. I have the data, I control the data. I like that. It also seems to be lighter on the battery than Moves was. I also like that.

There have been several updates to the app recently. It's under constant development. The author announced that it might be possible to import Moves data. This morning, that update with the import came through.

The import method involves getting your data from the Moves website. It's in a file called moves_export.zip. You put that whole file in your iCloud drive, in the Arc App directory. Once you do that, you go into Arc and it should import your data. It didn't do that for me. I moved it into place on my Mac. When I looked at it on my phone using Files, it had the little iCloud symbol on the icon for the file. Ah, it was in iCloud, but had not been downloaded to the iPhone. That's why Arc hadn't started importing it. I tapped the icon, it downloaded to my iPhone, I went into Arc, tapped the little Arc symbol at bottom left, and it showed that it was importing my data. Nice.

It didn't take long. I have a lot of data since 2014. The iPhone ran pretty warm during the import. I did some spot checks on the 2016 Hawaii trip and the Pennsylvania trip, and the data was there. The locations, places, times, it was all there. My history has been preserved. It's viewable, and usable. This is awesome. Most of the imported data has the little red dots beside it in the timeline. I think I need to go through and confirm every entry. That's going to take some time. I also seem to have two different items now for Home and for Work. Not sure how to reconcile these different items with the same name.

The Arc app is free. But you can back the author. I sent $10 to the author last week as I started to use the app in earnest. After the import worked so well, I just sent another $10 as a thank you. This app is a great replacement for Moves.

I took the hardware back to my cable provider today and got the service cancelled. I made sure I got a receipt for the hardware that I handed back.

She asked why. I said that they jacked up the price another $8 a month, and it made me consider what TV I watch, and I decided I would rather read a book. She asked me if I tried to get the price reduced. I said I didn't care.

And that was that. No more cable TV.

Now, I expect that the cost of Internet will start getting jacked up on me.