A Developer’s Guide to Managing Email Accounts

ship tossed by the waves: navigating a sea of emails

One email address for everything? A separate email address for every different service? Forwarders? Aliases? Spam? In this article, Mike Citarella takes you on an odyssey through the rough seas of email management, finding safe landing with his company’s own elegant solution in Bulc Club.

As developers, we rely on an email account to register and maintain online repositories, send and receive correspondence for projects we build and contribute to, promote and market this work through social media and other channels, and provide support lines for projects throughout their life cycles.

The more we rely on this simple communication tool, the more time we spend organizing and refining how we use it. We still share a personal email address with friends and family because we can generally trust them not to spam us. However, a work email address can easily get out of hand with the number of messages received (both wanted and unwanted) and the time and effort required to keep it organized.

It’s difficult to ensure that email helps make our work more efficient, rather than distracting and preventing us from being productive. At some point, we may all ask is there a more effective way of doing this? If you haven’t yet found your own solution, feel free to follow my Odyssean journey through the many approaches I’ve taken, so that maybe it will help you decide which is best for you.

One Address

The obvious starting point is the “One (or Two) Addresses for Everything” principle.

Some users might prefer fewer email addresses, with the understanding that one address is one inbox to check, and less overall work. They’ve got virus scanners and spam filters in place to help try and safeguard that single address, and hope that these counter-measures curb the abuse.

However, the convenience of one inbox may not outweigh the potential for catastrophe: if that single email address is exposed, and spam filters fall short, it can take a lot of work to rid the abuse or else shut it down and start again with a new, clean account.

Many Addresses

Others might prefer the opposite approach — separate and distinct addresses for each unique function — knowing that if one becomes compromised, it can be replaced with a new address without too much hassle.

This method is more controlled, isolating the address and making it easier to determine fault when it’s being abused. But it also increases the burden, with more inboxes to check.

Most mail services like Gmail or Outlook allow you to link accounts: logging into one inbox will also grant you access to the linked ones. This is a huge convenience for users who follow the many-addresses-for-many-things approach, cutting way back on the time required to log-in-and-out of many accounts and see what’s waiting for them inside.

Aliases

A third, hybrid model involves the use of aliases. Aliases are like photo tags, but for email addresses. They inform mail users of how they previously shared the address, and instruct mail services of automated measures that can be taken when these aliases are applied.

For example: myaddress@gmail.com has no alias, but if I share myaddress+github@gmail.com, the messages sent to this address will still arrive at the same inbox, but rules can be applied to add a label to them, color-code them, or move them to a folder. As long as those services that have my aliased addresses respect the aliases, I can theoretically treat an alias like a separate email address. I can even add filters that move messages to a spam folder (or delete them) if I’ve identified a sender as abusive.

Do senders respect aliases? Yes, usually. But I have also received mail tagged with aliases that I never created or shared. So it’s apparent some spammers have realized the simplicity of spoofing this useful mechanism and have used it to their advantage.

Forwarders

A forwarder (provided by a forwarding service) is another useful, albeit somewhat time-consuming, method of dealing with email. Forwarding services provide you with a new/unique address that simply forwards email to your real address. You can’t send mail from forwarders, only receive. These services are generally free to use, and they act as intermediaries between the senders and your actual address. The senders will never know it’s a forwarder unless/until you reply, as you’ll need to use your real email address to do so.

Forwarders are a more-or-less perfect option for the problem of sharing your address to potentially abusive senders, since they can often be individually switched off. Unfortunately, logging into the forwarding service to create, manage, and disable your forwarders can be cumbersome.

Now, my Odyssey

All things being equal, the Aliases method was the one I liked the best. So as an experiment, I created a new email address and began refining this homemade paradigm with aliases, inbox labels, and filtering. I may not yet be willing to admit it, but it’s quite possible that my behavior in the matter might have bordered on obsessive.

MyProjectEmail@gmail.com was where I started. I never shared this address. I only used it to log in to Gmail. Then, I started modifying all of my existing service accounts to use this new address, but with context specific aliases:

MyProjectEmail + service + trello@gmail.com, MyProjectEmail + system + trafficlogs@gmail.com etc.

… and so on.

With Gmail filters, my mail all got labeled and sorted for me. I could read, reply and archive, directly from their appropriately colored mail folders. I knew I couldn’t reply using an email alias, but that didn’t concern me, since I was only using this workflow with services for which I needed the inbound mail — not the ability to send a response.

It was a thing of beauty. And I was impressed by the organization and happy with my work — for about two days. The flaws in my flawless system began exposing themselves right away:

  • I wouldn’t be creating a separate Dropbox, GitHub, etc., for every project, so categorizing that mail by project wouldn’t be possible.
  • Using aliases in any application that exposes the address also exposed the alias, meaning the address could be scraped, the alias removed, and the abuse untrackable and unmanageable. The whole email account would be compromised, and my elegant system of separating and organizing would fall apart.

I had been speaking to a number of friends in the development community about my hardships and received “a host” of solutions from each, based on their own idiosyncrasies and styles. Literally. They recommended hosting my own solution.

This involved purchasing a domain and tinkering with the mail service provided by my web host. Since server-side mail agents are equipped with what’s called a “Catch-All” (or a master mailbox that will “catch all” of the emails sent to my domain where I didn’t specifically set up an individual account), I could disable that option to greater reduce, but not eradicate, spam.

Then, with each new service, product, and support offering, I would log in to the server and create specific email addresses. These addresses could be simply deleted if they became compromised, and all future mail sent to that address would bypass the catch-all and be automatically discarded.

And while this solution seemed to solve all my needs, it also had a number of drawbacks:

  • Like the forwarder method, I needed to create the addresses manually each time I needed one.
  • To use an alias, I would have to forward mail to Gmail (or another alias-able email service) instead of using an address that showed my own domain.
  • Each year I would need to pay to renew the domain and the mail server hosting account.

While I can justify the annual costs for this option, the time it took to create and manage the accounts was again almost as much of a burden as dealing with separate emails in the first place. Remember, my whole purpose for this pursuit was to maximize my workday and minimize time spent on email.

Hosting a solution also did nothing to thwart the potential for spam like a forwarder/intermediary would. Whether I’m using one address, many addresses, aliases, forwarders, or my own hosted email, I knew that once an address starts receiving junk mail, until it’s deleted, it will most likely always continue to receive junk. Basically, an odyssey that ends with a shipwreck.

There just didn’t seem to be a solution that simply said “here’s a way for you, and only you, to contact me, and if you abuse it, I’m taking it away.”

Continue reading %A Developer’s Guide to Managing Email Accounts%


Source: Sitepoint