Blog by Sylvia.
Sylvia is a genius DevOps engineer at Sue. She spends lots of her spare time on GitHub where she manages various Open Source projects. Among these projects she contributes to the Ops tools she uses at assignments, really putting the Dev in DevOps. Currently over 200 of her patches have been merged, including commits to SaltStack and Ansible. Do we need to say more?
Nowadays, spam and data breaches seem to be the default. In this article I will explain how to use email aliases to help cut down on spam more effectively and how email aliases avoid the pitfalls of “the + sign trick”.
The what and why
An alias is an alternative email address that also gets delivered to your mailbox. There are different implementations of this. Some aliases can be replied from, some not. Some people implement “aliases” by simply using multiple mailboxes,, others use the + sign trick (firstname.lastname@example.org), or they forward it. In this post, we will be using a mechanism which sends emails – sent to any of the aliases – to our main mailbox, but which still allows us to respond using the alias itself to hide our main mailbox’ address.
Using aliases instead of one single mail address has multiple benefits.
First of all, it allows you to know where the email is coming from.
Secondly, in some configurations, the alias could forward the email to multiple recipients. That way, you and your team lead could both be kept into the loop on a specific subject. This is one of the ways aliases are often used within Sue, allowing employees to keep their main email account to themselves but still easily and automatically share relevant emails.
Most importantly though, it allows for a separation. Instead of getting hundreds of spam mails to your real email address, spam will end up in just a single alias. When the spam arrives, you just throw away that single alias. That way you can finally cut off the spam without cutting off everyone else.