Monday, July 17, 2017

Informed Delivery

I know the idea of receiving email from the post office is probably not high on your list of things you'd like to get working, but I came across Informed Delivery yesterday and the idea looks interesting.

In the United States, the Postal Service is the sole authorized agency responsible for and required to provide uniform postal service to all citizens regardless of geography and at a uniform price.  Your opinions of whether or not this is a reasonable agency to have or how the US Postal Service is run are of no interest to me.  I have opinions to that you likely don't care about.  One thing we can probably agree on is that the Postal Service has to compete with technological advancements while still meeting their legal obligations and that can be very difficult.

Things that didn't exist when the Postal Service was created:  UPS, FedEx, DHL, email, or telephones.  The Postal Service has to compete with all of these and still provide what are effectively baseline services that many people take for granted.

So enough of that, what is Informed Delivery?  I don't know, but I signed up.  As explained, it seems to be a system where you can get emails (opt-in) indicating what mail is headed your way.  Expecting something important?  They could, in theory, scan it and notify you on the sending end and you'll know it's en route.  The possibilities for this service seem interesting, but I'll remain somewhat cautious as to what they will implement.  What would be nice is if I could go to a web page and uncheck the things I don't want delivered, say, on a weekly basis.  Reduce what the letter carriers have to move around and let me filter my physical mail somehow.  We'll see.

Monday, July 10, 2017

Using ssh-agent for Remote Login Sessions

I work on a lot of remote systems via ssh logins.  It's very common for me to be remotely logged in to several systems throughout the day.  Not everything I do is from my workstation's login session.

A lot of the things I do, such as source code control with git, rely on ssh keys.  I have passphrases on my keys so every time I use git, ssh will prompt for the passphrase -or- will ask the running ssh-agent for the credentials.  On my graphical workstations, I have my X sessions set up to start ssh-agent upon log in and add all of the keys in ~/.ssh to the agent.  That way things like git push and git pull work quickly and without prompting me for the passphrase.  When I log out, the session goes away.

This does not work for remote sessions.  Once I log in to a system, I cannot use the agent running on my workstation.  I have added a block to my ~/.zshrc file to start an ssh-agent if one is not already running.  This handles interactive shell logins via ssh or at the console.  There are many ways to do this, but here's how I'm doing it (lines broken for posting here, anywhere there is a backslash, join it with the previous line and remove the backslash):

if [ -d "${HOME}/.ssh" ] && \
   [ ! -f "${HOME}/.noagent" ] && \
   [ -z "${TMUX}" ]; then
    # Start the SSH agent
    if [ -z "${SSH_AGENT_PID}" ] && \
       ( [ -z "${SSH_AUTH_SOCK}" ] || \
         [ ! -r "${SSH_AUTH_SOCK}" ] ); then
        eval $(ssh-agent)

        for pubkey in ${HOME}/.ssh/*.pub ; do
            privkey="$(basename ${pubkey} .pub)"
            [ -f ${HOME}/.ssh/${privkey} ] && \
                ssh-add ${HOME}/.ssh/${privkey}

Like I said, there are many ways to do this, but this is how I managed it.  I will walk through how this works:
  1. First, you need to have ~/.ssh.  I should modify this to make sure you have at least one public key, but I've made that assumption here because that will always be the case for.
  2. I also honor the ~/.noagent file in my home directory.  I can disable this entire block by touch ~/.noagent and it will skip right over it.  This file does not require anything in it, just that it exists.
  3. The test for ${TMUX} is important to ensure that each new pane I open in tmux does not start a new ssh-agent.  If you are using GNU screen, I am sure there's a similar test.
  4. The nested if will then check to see if an existing agent is running.  That's the test for SSH_AGENT_PID and SSH_AUTH_SOCK.  If those exist, I am going to assume ssh-agent is running because I otherwise do not use those environment variables,
  5. The eval line runs ssh-agent (which will background itself) and then sources in its stdout, which contains the SSH_AGENT_PID and SSH_AUTH_SOCK environment variables.
  6. The for loop iterates over all of your public keys and will add each one to the agent if there is a corresponding private key.  This part is interactive as ssh-add will prompt you for the passphrase for each key.
Another thing to note with zsh, which is the shell I'm using, is to avoid having this block in both ~/.zshrc and ~/.zprofile.  If you have both files and they are different, put this block in ~/.zprofile.  If you have one and the other is a symlink to the other, get rid of the symlink because the block will execute twice on interactive shell logins.

Lastly, you should make sure you kill the agent when you log out of your session.  For zsh, I add this to my ~/.zlogout file:

# Kill any running ssh-agent for this session
[ -z "${SSH_AGENT_PID}" ] || ssh-agent -k

Other shells have other mechanisms of running commands on logout.

So it's not perfect, but it does get me an agent running in my remote login sessions and that was my main goal.  I may make some tweaks to this over time, but for now this is what I'm using.

Sunday, July 2, 2017

Default Sorting and Threading in Thunderbird

I've recently set up Thunderbird at work for my email.  I was a long time console email user starting first with elm, then pine, the mutt, then pine again, then mailx, then mutt again.  Eventually I started using gmail and since we use that at work as well, the web interface became the path to least resistance.  But I've never really liked it.

Perhaps I've grown to a point where I don't find setting up mutt and maintaining a stack of support programs fun anymore.  Or maybe it's that when I find I need to slightly change something, I have to dig around online for a long time trying to figure out one obscure setting.  But I really think it's the searching archived mail that has caused to favor the web email client and now Thunderbird.

As I iron out the kinks with having my email in Thunderbird, I've collected some notes on how to change behavior for some things.  First on my list was getting it to sort email the way I prefer and thread messages correctly.  I found I could change this for each folder for an IMAP account, but the settings didn't seem to stick consistently.  Thunderbird offered no obvious default, so I poked around online and found that you can change the defaults via the config editor.

This is similar to the about:config editor in Firefox.  Access it through the Preferences dialog though.  There's a button for Config Editor.  The usual warning stops you, but proceed on.  Here are the changes I made:
  • By default, I want all IMAP folders polled for new messages, not just the Inbox.  Set mail.check_all_imap_folders_for_new to true.
  • I'm not sure what the default sort type is for mailnews, but everyone online seems to insist that having it set to 18 is what you want.  So I changed mailnews.default_sort_type to 18 (technically I didn't because it was already 18).
  • I prefer email messages to be sorted by date in descending order, so I changed mailnews.default_sort_order to 2.
  • I prefer email messages to always show threaded conversations, so I changed mailnews.default_view_flags to 1.
Now any other accounts I add will behave this same way.  I still have some other settings I want to tweak, but this is what I've done so far.