A quick look into the world of PGP

Public Keys

You can think of public keys like a jewellery box with an automatic lock that you can share with your friends. You give your friends this box and, after confirming with you and only you that you are the owner of that box, they begin to put things in it. This is basically what is happening with PGP encryption. Your public key is the key you give out to everyone. People encrypt files using your public key (placing files in the box), and send you those encrypted files. Once they encrypt the files using your public key (closing the lid on the box), only the person with the associated private key can decrypt that file, or open the box. You can upload your keys to a public "keyserver" which will allow others to "sign" and verify the integrity of your key.

Private Keys

Private keys go hand in hand with public keys. For every public key, there is at least one associated private key. Never hand out your private key. Ever. To anyone. Your private key is yours and yours alone as it is associated with your person and your person only. When you create your public key, your private key is generated. You should keep this file in a safe place, away from any online sources. Make backups of your private key on flash drives and/or compact disks. A common practice is to print out a QR code of your private key, however this is unadvised due to the legal technicalities that can ensue resulting in the seizure or spread of your private key. If your private key is compromised in any way, you may generate a revocation certificate that, when uploaded to a keyserver, will inform any user attempting to encrypt using your public key that your key is no longer secure. Only your private key can generate this certificate.

History

PGP actually had kind of a dark past. It was essentially born when Zimmermann discovered that most people had all their files out in the open - it wasn't safe. There was no real way of knowing if who you were talking to was really that person. In 1991 he created a system that did just that. Thus we have "Pretty Good Privacy", a method of encryption that's based mostly on trust and backed by reliability. It worked off of an algorithm he had designed himself, "BassOmatic", and each non-commercial copy of PGP shipped with a complete copy of the source code.

Everything was going well for a while. PGP left the US borders, gaining worldwide popularity - which was a problem. Cryptography was (and still is) a grey area in US law, and having a key that was larger than 40 bits was considered illegal by the United States. PGP uses keys that are larger than 128 bits. Zimmermann was put on trial for "munitions export without a license". Munitions being defined as guns, explosives, other weapons, and software. After years of trials, the case was finally closed with no charges.

Funny enough, Zimmermann thought of a way around getting charged with violating anything "munitions" again by publishing the source code. For $60 you can buy the source to PGP in a hardcover book, shipped anywhere around the world. This made his work protected under the United State's first amendment.

Uses and Practicality

There are many uses for PGP. Whether you just want to ensure your safety amongst friends and family, or if you're hiding yourself from third parties peeking over your shoulder, PGP is a good way to keep yourself safe. Some very common mediums for PGP include emails, instant messaging, message boards, and even pen and paper! No matter how you're sharing, you can have peace of mind that what you're making is only going to be seen by you and its intended recipient.

With the use of GUI applications such as Cryptophane (for Windows), PGP has become easier than ever to use. It's as simple as selecting the name of the person, and typing in your message. Many popular mail applications, such as Mozilla Thunderbird and Flipdog's MailDroid will automatically use your keys to protect your messages from being intercepted.

Summer, the slow season for many administrative offices, leaves little to do for the general tech-support employees. Some might argue that we're really working at all. Now, when I say this, I don't mean it as an across the board comment. Of course there are many IT professionals working their asses off as you read this, making sure that everything works smoothly the first time. Though for me personally, summer means waiting for the next user error to pop up in our ticket feed. Exciting, right?

It being so slow I started to really think about what I had done with my professional career and how it could be expanded upon. Trying out the whole system admin thing has been fun, but it's not like I really have much to monitor. With that in mind, I started reading about other admins, which lead to reading about other systems, which lead to reading about Google, which lead to reading about security, which lead to reading about how we don't really have all that much control over what we use on a daily basis. It suddenly clicked why so many corporations use in-house services instead of just pre-setup services like Gmail and Comcast mail.

The thing is, we don't have control over what we use. We don't own our email. If someone acquires your email password and reads your mail, you're not protected under the federal law that says it's a felony to open others mail without express permission. If you house your email in-house and someone hacks in, you can still legally protect yourself because hacking into an unauthorized system is itself illegal. (Disclaimer- I am not a lawyer, take everything I say with three grains of salt)

This whole time I've been using other people's systems. These were free services, such as Gmail and cpanel (which, to be fair, was forced unto me by my old server hoster, which I no longer use (we good!)). I figured, if I encrypted my emails using PGP that that would be enough. What if, though, they got hacked?

Don't get me wrong, there's no one I trust more to keep my data safe than Google. A company that big could not afford to get hacked, because they're seen as the giant in the industry, the biggest. They could make companies disappear overnight if they wanted to, and I'm convinced that the only reason they're not evil is because they're already making so much money. But what if they did? What if Google was compromised and my data leaked and placed out on the web like you see with minecraft accounts every other week? What could I do about that?

Nothing.

I'm not trying to say that free email accounts are insecure and you shouldn't use them. Am I going to stop using my three gmail accounts? No. No I am not. I love my gmail accounts and they are my babies. What I'm saying is, maybe it wouldn't be too bad to have my own mail server. One I set up and have complete control over.

So with the help of a few reference here and there, and a lot of help from my good friend Eric, I set out to do what many have so fervently claimed to be "the worst part." And you know what? It wasn't so bad. Eric explained to me that you can't just set up a server and call it a day. In fact, he got on my ass about my SPF records on my other domains – to which I asked – "SPF, like the sunscreen?"

This is the part of the post where I take a step back and say that without my friends I would be nowhere. Eric has taught me so much about numerous different fields of computers. He got me into researching PGP, secure web development, preventing SQL injection, in-house solutions which lead me to researching more and eventually contributing to FOSS - he really is one intelligent guy and if you have a minute go check out his stuff.

To my understanding, there are four parts of having a secure mail server in terms of not becoming susceptible to spam, and to my surprise they all have to do with DNS. You have your SPF, your DKIM, and your DMARC; all of these are TXT records in your zone file. Then you have your MX record, which just lists the mail server address on the domain. Still with me? Good, let's break it down some more.

MX

If I send an email to "colin@colind.me", my mail server will reach out and look at the DNS records for colind.me. From there it will check the Mail Exchange (MX) record to see where exactly it should be sending the mail. In my case, the MX record was just colind.me. 1800 IN MX 10 mail.colind.me., and was definitely the easiest and fastest part of the setup. Breaking that down further, it's the domain, the TTL is 30 minutes (1800 seconds), and the MX is located at mail.colind.me with the priority of 10.

SPF

The Sender Policy Framework record is there to specify who can send mail from that domain. The best policy if you only have one domain is probably "v=spf1 mx -all". v=spf1 just means it's declaring the TXT record as an SPF record. mx is taking the place of a server – it's saying that only the MX record holders can send out mail. Alternatively, you can declare a server using ipv4:40.50.60.70 replacing the IP with your own server address, of course. ipv6: also works here. The -all just means that no one else can send mail from this domain.

DKIM

DomainKeys Identified Mail are how your recipients know that what you're sending them is legitimate. The DKIM record is there to provide authenticity and verification that the mail being sent out is actually from you. Your outgoing mail is signed using keys that are also placed in your DNS via a TXT record. They look something like mail._domainkey.colind.me 1800 IN TXT "v=DKIM1; k=rsa; p=reallylongkey" in your zone file. It's similar to how PGP works; mail gets signed, dns checks it – if it passes, it says so in the header, if it fails, it says dkim=failed in the header. This is important, but it doesn't really do anything without probably the most important record...

DMARC

Setting up DMARC (Domain Message Authentication Reporting & Conformance) was the part that gave me the most trouble solely because of lack of extensive documentation and full examples. I recommend using a DMARC generator instead of writing one yourself. DMARC tells your mail client what to do with the email if it has failed the previous checks. It absolutely needs SPF and DKIM set in order to work. If you have your DMARC policy (p) set to quarantine (for a total of p=quarantine), then your receiver is going to put that forged message into their Spam folder. I think that dmarc.org explains it easily in their overview flowmap. Using DMARC, you can have reports sent to you, the postmaster, using rua=mailto:. The difference between rua and ruf (both standard switches) is that rua is reporting uri aggregates and ruf is reporting aggregate forensics. What confused me the most about DMARC though is the name. In the end, I ended up getting it to work by setting it to _dmarc.colind.me. IN TXT ... - it's seriously easier and faster to use a generator for this one.

By now I've explained what everything does and how it works as far as setting up the DNS end of the mail server. As far as the software went, I used postfix to host the actual mail server itself, and dovecot is working with it to actually integrate with mail clients such as Thunderbird and Outlook etc. Postfix itself is working with linux's accounts (/etc/passwd) to provide an inbox to every user that hosts an account on that machine - in my case, my server. In addition to this, it uses the machine's aliases (/etc/aliases) to set up "fake" email addresses that will get forwarded to another address. For example, one of the required addresses is "postmaster", which will get forwarded to "root" by default. I don't have a postmaster account on the server, and it's bad practice to use the root email. What you do in this case is forward your root email to you. So at the end of the day your server's aliases might end up looking like mine and having:

postmaster:root
root:colin

Adding aliases is as easy as editing this file and running sudo newaliases. Dovecot on the other hand was a little bit more of a headache for me, which is odd because it's supposedly the other way around. The lesson I learned that way is that sometimes you shouldn't copy the documentation word for word. Every system is different and should be configured to work best with that setup.

After I added in all the proper elements - email was finally working. I could send it, but my test emails still weren't being recieved. Something wasn't right. I was wondering what it was until I finally gave up and asked for help. Glitch (again, see how helpful he is?) said it might have something to do with the fact that I'm not being fully authenticated. Lo-and-behold, I wasn't being marked as an "authenticated" sender. This was patched up with an SSL certificate, which was probably the easiest part to install. All that needed to be done was to change the reference in the dovecot and postfix config files and restart the services with sudo service postfix reload && service dovecot reload. With that, everything was working.

Update 1/29/2019:

I still recommend that everyone at least try to set up a mail server at least once. It's a really informative process that takes a lot of the mystery out of how email works. However, if it's an email address you plan to be using for important contacts, bills, or any other kind of communique that requires consistency, I recommend having either a dedicated server with a failover policy for it, or entrusting the hosting and setup to a third party with a fleshed-out contract and a plan in place for if the worst occurs.