Other certificate options
Certificate-based authentication adds additional security over regular usernames and passwords—as long as you can trust your CA. In the case we've outlined, the CA is actually you, so you'd want to keep tight control over your CA private key—it wouldn't be a bad idea to store it on a separate server from your mail server (or maybe even on a USB stick, too).
But you're not limited to validating certificates against your own
CA—you can actually validate certificates against any CA at all, as long
as you have access to that CA's root certificate. For example, say you
wanted to use a StartSSL-issued personal certificate for validation. All
you'd need to do is download StartSSL's root and intermediate CA bundle
from their site, and instead of supplying your own CA root certificate
lines, you'd put StartSSL's certificate. Then, Nginx would check to
make sure client certificates were signed by StartSSL. If you don't want
to screw around with setting up your own CA and instead just want to
use existing personal certificates, this is the way to go.
There's a problem, though: because we're keying off of the Subject DN, you have to trust the CA to issue correct and unique DNs. In our example, if you're going to check for "firstname.lastname@example.org" against certificates issued by StartSSL, you'd want to be certain that StartSSL (or whomever you're validating your certificates against) isn't issuing a personal certificate for "email@example.com" to someone who's not you.
Of course, this is the very purpose of trusted root CAs: to issue valid certificates and to perform identity verification as part of that issuing process. But how much you actually trust the validity of a certificate is ultimately up to you; if you're using certificate authentication, you must be cognizant of the limitations behind the fragile web of trust that underlies SSL-TLS.
We've made it to the end of part four, and we've got a wholly functional mail server out of it! You can send and receive e-mail, from desktop applications or smartphones or even a web interface, and you can do it securely and with considerable assurance that your mail won't get batted aside as spam by your recipients.
But as long a road as it feels like we've walked (and, believe me, at about 35,000 words total, this four-part guide has been a long road!), there's tons of additional steps you can take and configuration optimizations or changes you can make.
Sieve filtering: getting advanced
Sieve is extremely powerful, and I use the heck out of it for filtering (and sometimes discarding) mail, but it's got a lot of potential we haven't even looked at. Dovecot's Sieve example page has a lot of neat tips, including a way to implement an out-of-office autoresponder (complete with per-day reply rate limiting).
If you're having a hard time with Sieve, one of the modules we enabled allows you to create Sieve rules via Roundcube's web interface. This greatly simplifies the process of building complex server-side rules without having to construct regular expressions or parse out the Sieve language RFP for just the right syntax.
You might also want to add push notifications to your e-mail server—if so, you'll want to look at Z-Push, an open source implementation of Microsoft's ActiveSync. Z-Push is also available in the Ubuntu repositories as "D-Push," due to branding restrictions—it's also a few versions out of date, and so I'd recommend just installing it directly rather than via the repos.
Z-Push/D-Push is a web application and it uses PHP; getting it operational will require you to have a functional Web server and PHP interpreter (no problem if you've been sticking with the guide). There are a number of tutorials on getting it working, including one on Drew Crawford's site and another here. If you decide to implement Z-Push, pay particular attention to where and how your files are laid out in your web root; you'll want to make sure that the application is securely configured.
This is an area that I stayed wholly away from, but I know it's one that lots of folks are going to be keenly interested in. OwnCloud is one possible option, though OwnCloud carries with it a lot more than just calendaring—it's really a DIY Dropbox type of application. SabreDav looks promising, though it also appears to require a lot of setup.
If I were going to set up a calendaring solution for myself, I'd probably go with RadiCale: it looks simple and friendly, and it appears to be compatible with a wide range of clients. Your mileage may vary, though.
If you look at how Google has implemented two-factor authentication for Gmail, you'll note that they offer a second authentication method for situations where you can't use Google Authenticator: application-specific passwords. You can somewhat mimic application-specific passwords with our flat-file Dovecot setup, which will leave you with multiple passwords for single virtual user accounts. Daniel Siegel has an excellent tutorial on this.
This is handy if you want to spin up a new password to use in an untrusted location—for example, if you're going to go on travel and you suspect you might need to log on to your domain's webmail from someone else's computer, you could set an additional password before you leave and only use that password for that one purpose; when you return home, you can delete the password without affecting access on your other devices.
Self-service password resets and databases
We've also made a very deliberate choice with our configuration: as noted in the previous couple of paragraphs, we're not using a SQL database to store our messages. Roundcube is using a database, but it's separate from anything having to do with Postfix and Dovecot; Roundcube's database stores only Roundcube-specific data and (if configured to do so) cached e-mails.
However, it's also possible (at the cost of system resources and some complexity) to store your virtual user information passwords in a SQL database. This opens up a whole new realm of management opportunities: with your virtual user account info stored in a database, that information can be manipulated programmatically. That in turn means you can use tools like Postfix Admin to let users set their own passwords.
If you're using your server to host mail just for you and immediate family, this isn't a big deal. If you're using it to host mail for a few friends, though, having a method for people who aren't you to set their own passwords is an important security step.
(For large installations, using a SQL database will also likely be more performant than flat files; that's not anything we need to worry about at our small scale, though.)
Encrypted e-mail with PGP/GPG
This is worth its own article, but briefly, consider using PGP encryption as often as possible. Packages like GPGTools for OS X and GPG4Win for Windows make this...well, if not easy, then at least nowhere near as stupidly difficult and annoying as it used to be.
As long as your messages traverse the public Internet and get stored on servers outside of your control, you cannot be totally sure that they won't be intercepted and read. If you're discussing anything personal or sensitive, wrapping your e-mails in client-side encryption will go a long way toward ensuring your privacy.
Closing remarks: keep it updated!
Stay on top of updates. This cannot be stressed enough. Stay on top of updates. For the love of all that is good in this world, stay on top of updates. Consider enabling your server's automatic update installation function—it's almost certainly worth doing. For applications that you've installed manually, like Roundcube, keep track of when new releases are coming out and update as soon as they're available.
The security of your server is your responsibility. Don't let it rot. Rotting servers are terribly, terribly dangerous. I said it back in the beginning of part one, and I'll repeat it at the end of part four: running an e-mail or web server is like owning a particularly needy puppy. You wouldn't neglect a baby black lab, would you? No! Because when baby black labs are neglected, they have sad little puppy faces and then they chew and destroy everything you love. A neglected e-mail server isn't going to chew up your remote control and your table, but it sure as hell will catch an infection and start trying to hawk h3rb4l v14gra to the whole Internet. And it will be your fault if it happens.
On the other hand, a well-maintained and well-managed e-mail server is a wonderful thing. E-mail wasn't always solely a thing offered by ISPs and webmail providers, and running your own e-mail server is one of the purest sysadmin activities you can do on the modern Internet—it's a lot like growing your own vegetables rather than relying on store-bought packaged produce.
So enjoy your server. Send some encrypted, subversive e-mail. It's the right thing to do.