Use getmail to get e-mail simply and securely

I like my e-mail approach to be quick, simple, and above all, secure. I use GnuPG with Mutt for digital signatures and message encryption, TLS encryption to keep my mail server sessions safe from the prying eyes of malicious security crackers, and my mail retrieval tool of choice is getmail. Here's how it all works together.

Many computer users like using monolithic, fancy, massively multi-function, GUI-fied mail clients. This is particularly true of people whose workday tends to revolve around Microsoft Office and its "personal information manager" application, Microsoft Outlook. It's such a huge, integrated collection of functionality that it can't properly be called a mere mail client any longer.

Others, like me, prefer their daily e-mail dealings to be quick, simple, and devoid of distractions. We often prefer separate tools for each part of the process -- one for retrieving incoming mail from the server, another for reading, managing, and composing e-mail, and another for sending it. Aside from the aesthetic simplicity of such an arrangement, this affords far greater control over the workings of the system, which not only allows for greater customizability for one's preferences, but also greater control over the security of the system. It requires greater understanding of how your tools work, however.

My choice for retrieving e-mail these days is called getmail.

Secure mail server authentication

In addition to preferring the quick, simple, and undistracted approach, I also like my e-mail to be secure. I use GnuPG with Mutt for digital signatures and message encryption, but that is only part of the story. There's also the matter of my relationship to my e-mail account on the mail server that receives my e-mails for me.

To ensure the best possible protection of that relationship, I use TLS encryption to keep my mail server sessions safe from the prying eyes of malicious security crackers. This provides general protection against eavesdropping on connections I establish with the server, but more specifically it protects authentication so that some script kiddie with Wireshark running on his computer won't be able to pick up my passwords.

As I explained in an article about basic Web security, TLS is the next generation of encryption to follow SSL. In fact, SSL and TLS are essentially different versions of the same thing. This is what protects your sessions at Web sites where the URI scheme in your browser's address bar is https://. TLS/SSL can be used for more than just protecting Web pages, though -- it is also useful for securing your connection to your e-mail server.

Configuring getmail

To establish a secure connection with your mail server, it has to support encrypted sessions. Check with whoever manages the server -- your ISP or hosting provider, corporate IT department network administrator, et cetera. If the mail server does not support some form of encrypted authentication, get a different provider if at all possible. As I pointed out in the article, "Basic email security tips," it's always a good idea to make sure your e-mail authentication process is encrypted.

I am providing my own getmail configuration file (with syntax modifications to protect my privacy, of course), called getmailrc, to illustrate how you might use getmail to secure connections with your incoming mail server when receiving e-mail. The contents of the file are:


delete = true


type = SimplePOP3SSLRetriever

port = 995

server =

username = username

password = password


type = Mboxrd

path = ~/Mail/Inbox

user = user

I'll explain each line in the file in turn:

  • [options] : While options exist in other sections, this section heading indicates that the immediately following lines refer to general getmail options.
  • delete = true : Because I am using a POP account, where I download emails from the server to store (and deal with) them locally, I set the delete option so that once an email is successfully downloaded it is deleted from the server. This saves space on the server, since I do not need copies of emails to languish there for eternity when I have copies of them here on my laptop.
  • [retriever] : Options following this section heading configure the behavior of the part of getmail that actually gets your e-mail from the mail server.
  • type = SimplePOP3SSLRetriever : The getmail utility offers several different "retriever types" that it uses to indicate the type of connection that should be made. The names of each are fairly self-explanatory, and this one in particular means it will use an SSL-encrypted POP3 protocol session.
  • port = 995 : SSL's default port for e-mail retrieval session encryption is 995. Some servers may use a different port number, but this is the most common when port 25 needs to remain free for those who wish (for some inexplicable reason) to use unencrypted sessions.
  • server = : Of course, getmail needs to know where to find the e-mail. Instead of "", you should use the hostname of the mail server where you have an e-mail account. Mine, like yours, is not "".
  • username = username : Here, you specify the username for your account on the mail server (instead of "username", unless that really is your account username) for authentication purposes. Depending on mail server configuration, it is probably either the part of your e-mail address that comes before the @ symbol, or the entire address -- possibly with the @ replaced by +.
  • password = password : This is why your getmailrc file (probably stored at ~/.getmail/getmailrc) should have 600 permissions (read/write for the owner and not for anyone else -- or even 400 when you aren't modifying it, for read-only access). It is the password used to authenticate with the mail server.
  • [destination] : Lines following this section heading are used to specify how and where to deposit e-mails once they have been downloaded.
  • type = Mboxrd : I use an "mbox" style of inbox file for my e-mails. Your value for the type option in the [destination] section may vary from this example. See the getmail manpage for more details.
  • path = ~/Mail/Inbox : Because I use mbox mail files, and I want the inbox to be called "Inbox" and reside in the ~/Mail directory, I need to have this line set as indicated. Mutt, my Mail User Agent, is configured to look there for e-mail when I want to read it, and getmail is configured with this line to put the e-mail there when it downloads it.
  • user = user : The name of your user account on the computer used for reading your e-mails -- in my case, my laptop -- goes here. Replace the "user" on the right side of the = with your user account name on the local system, and you're done.

The key parts for ensuring your e-mail download sessions are properly configured for encrypted connections are the type, port, username, and password options.

Securing the other tools:

In addition to getmail, of course, you should secure the other e-mail tools you use as well. You can use GnuPG and Mutt to encrypt email, and tools for handling outgoing mail like sSMTP can be configured to use TLS/SSL encryption as well.


Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.


Many things to read my emails, Getmail + GnuPG + sSMTP for reading my email in secure way. Really it makes reading an email very complicated !! My opinion is the outlook is fantastic, SSL and TLS are working with outlook.


I know I will have to go to something like this eventually, and use junk email for those that refuse to go encrypted. I will just have to withhold information or call those people. I also appreciate your response to tony; I like to see people treated so patiently; and I'm not a huge expert in this area either. In previous contract we had a few dial up clients that we switched to https:\ using OWA Outlook. With no endpoint security, I assume this could be compromised by man-in-the-middle attacks. Do you feel this is any better than nothing? Like you said, they probably used Kerberos, but our team leader was an old Unix hand and may have used the same tricks. I don't remember any round table discussions about GnuPG, but I'd lay bets he was good with Mutt. Just curious. It was the only solution we had at the time as we didn't have them on VPN yet.


Hello, I am very interested in the idea of securing my email connection. But this seems to be geared towards more advanced users. I am not very savvy to the whole process and don't know where to begin. First, my email provider is Verizon. How do I find out if they provide "Encrypted Sessions"? If they don't provide the "Encrypted Session", do you have suggestions as to who does? Second, if you are using Getmail to retrieve your mail, do I still want to use a client like Thunderbird to view my mail? If not, again, what do you have for suggestions? Remember that I am not an old hand at this stuff. Third, if you are sending and receiving encrypted email, don't the people who you are communicating with have to have a key and do the same for this to work? Forgive my lack of understanding but not everyone is able to follow this clearly. I would hate to lose all my mail trying to do this.


Do you use getmail, or something else? What is your favorite email retrieval tool? You [b]do[/b] encrypt your mail server connections -- right?


If you were using a URL with an HTTPS URI scheme, I have to assume you were using SSL or TLS encryption -- which means the connection was as secure as the client and server themselves are. In other words, the encryption for email authentication with OWA (assuming you mean Outlook Web Access) is essentially identical to that of using TLS/SSL encryption with getmail. Of course, a bunch of websites implement TLS/SSL encryption incorrectly, so that everything [b]but[/b] authentication is encrypted (an incredibly stupid way to do things) -- but I'm pretty sure OWA doesn't do that. So . . . if nobody compromised the server or the client system used to connect to OWA, it should be pretty secure. That might be a big "if", though.


"[i]First, my email provider is Verizon. How do I find out if they provide 'Encrypted Sessions'?[/i]" From [url=]the Verizon website[/url] you can click on the [url=]Email[/url] link under "Top Help Topics" on the right-hand side of the webpage. Assuming you're using standard Verizon DSL, you can then click on the "High Speed Internet" link to select that service type. In the menu on the left, then, you should see another Email link, just under General Support. When you click on that, it expands the menu with some email-specific options. Since I don't have a Verizon account, I choose to refuse cookies from the Verizon website, so it won't let me proceed any further -- but that should be a good start. My guess would be that you could find what you're looking for in "Setup & Use", "Security", or "Profile Settings". In fact, check in that order, since that list is pretty much in descending order of probability that it's the right place to look. If there isn't anything there, you may have to call up telephone tech support to talk to someone there. When looking this stuff up or talking to someone on the telephone about it, you should make sure that they are answering your questions about SSL or TLS encryption for email connections, and not Kerberos-based "secure authentication" as commonly provided by MS Exchange servers. While there's nothing wrong with using "secure authentication", per se, the really important part is the SSL/TLS session encryption. I don't know about specific ISPs that offer encrypted connections to mail servers. I haven't used an ISP email address in years, so I haven't kept up with which ISP's offer what services for email. All of my email addresses, with the exception of a GMail account I just use for collecting junk mail, are through the webhosting accounts for my own registered domain names. "[i]Second, if you are using Getmail to retrieve your mail, do I still want to use a client like Thunderbird to view my mail? If not, again, what do you have for suggestions?[/i]" If you're using Thunderbird as your email client, you should just use Thunderbird's built-in functionality for downloading and sending email. I've been planning an article or three about setting up Thunderbird for secure email use at some point, but haven't gotten around to it yet. I'm glad that you are interested in securing your email, regardless of what client applications you're using for handling email, and I'm sorry I haven't addressed how to get all this stuff working with Thunderbird yet. If you have trouble getting it working, you can wait for me to get any relevant articles written to help you with that. You are also welcome to ask me for help as you determine you need it, and I'll do what I can to help out if the articles are too slow in coming to be of much use to you right now. "[i]Third, if you are sending and receiving encrypted email, don't the people who you are communicating with have to have a key and do the same for this to work?[/i]" For dealing with encrypted emails, it's true that both sides need to be set up to deal with encryption and decryption of messages. Sometimes, you just can't get someone else to use encryption, of course. Under those circumstances, my suggestion is that if you have any information that should be kept secure from prying eyes, you find some other way to communicate it to each other than email -- something where the other person [b]is[/b] willing to use encryption, or where encryption isn't really an issue (such as speaking in person). Sending usernames and passwords through unencrypted email is just asking for trouble. "[i]Forgive my lack of understanding but not everyone is able to follow this clearly. I would hate to lose all my mail trying to do this.[/i]" No problem. I want to help. Better to ask than to remain silent and cause trouble for yourself later. Let me know if you have more questions.


HIPAA had us locked down pretty tight; we had no breaches from those remote users. But I was hovering over them like a mother hen,trying to keep nest clean. They had to logon to the server and it was under https:// but as you have pointed out in previous articles that doesn't mean it was properly secured. It worked very well in the utility sense. I wished I would have had the time to visit the exchange side, to learn more about it. I really appreciate your articles on this apotheon; can't thank you enough!

Editor's Picks