Blog: Making spam manageable

Blog: Making spam manageable

donderdag, 26 augustus 2021

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 (yourname+service@example.com), 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.

Multiple benefits

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. 

By using a different alias on every website, you will be able to tell where someone found the email address they are contacting you from. This enables you to tell if the spammer found your email address on your website, or if they somehow got access to the email address you gave to that one online store – that just seemed slightly sketchy but not sketchy enough to not give it a try. Being able to tell the source is very useful. It makes it visible if any of the places you gave your alias to are leaking your personal information or using it for something they shouldn’t be using it for. It ensures that you can hold the companies you do business with accountable. It also enables you to more easily tell apart well-designed scam emails. After all, it would make no sense for GitHub to be sending that “unexpected login” alert to the email you gave to Twitter. It would thus be very obvious that this is a scam email.

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.

Avoid the + sign trick

Some readers may wonder, why not just use the + sign trick as it is supported by many providers natively? Sadly, the + sign trick has a few important issues that makes it a weak alternative to aliases. Firstly, many services incorrectly reject email addresses with the + symbol in them, marking them as invalid email addresses. However, even if the + sign trick is allowed (because the format is so standardized) spammers can easily turn yourname+service@example.com into yourname@example.com, removing all separation and easily spamming your main address. The + sign trick is therefore not a viable alternative to aliases when it comes to spam protection.

Implementing it

Frankly, there are many ways one could go about this. For my personal usage I have gone with the Open Source service SimpleLogin. If SimpleLogin is not your vibe, there are alternatives such as AnonAddy. Alternatively, you could also set it up yourself or by using tools of your domain’s hosting provider if these exist. In this post I will talk about SimpleLogin, simply because I have more experience with that specific provider. The setup we will be going with is one secret email and many aliases, one per service, using our own domain. We will add a bit of secrecy to each service’s email, to avoid impersonation. Our end goal is to have all our email arrive in a secret mailbox, but never let this secret mailbox be known to anyone. We will be making use of SimpleLogin’s official instance, but it is possible to instead self-host the platform.

First things first we need to notice that SimpleLogin is not an email provider, but a forwarding service. They will not store our actual emails, so we will need a destination mailbox. This can be on a custom domain, but an email from a free provider such as Outlook or Gmail will work just fine too. After we have our destination mailbox set up, we can create an account on SimpleLogin. We can either create aliases on some of the domains they have provided for free, or opt for more control by using our own domain name. Do note that custom domains are not free on the official instance, so you will have to buy their premium membership or self-host.

Now we can start creating aliases. For example, I would personally create a new Custom Alias for Twitter using a random prefix. This would become something like twitter.zed81@example.com and set up our main mailbox as the destination mailbox. The random prefix (zed81 in this case) allows us to prevent this email from being guessed. We then give this email address to Twitter instead of our main mailbox. If we respond to an email sent to us by Twitter, SimpleLogin will ensure the email is translated correctly to use the alias as sender information so Twitter will still not know our main address. Simple, yet effective.

Summarizing

Using email aliases is really not as complicated as it may sound, but they are an amazing tool to keep spam under control. I personally followed this approach for roughly a full year now and don’t see myself going back any time soon. I hope this blog post has convinced you of the benefits as well. If you have not yet, give it a try yourself!

Review: KubeCon Europe 2021

Review: KubeCon Europe 2021

vrijdag, 28 mei 2021

Robin is één van Sue’s ervaren cloud native-experts. Hij werkt dagelijks met Kubernetes en verzorgt regelmatig K8s-trainingen. Logischerwijs was hij van de partij bij KubeCon Europe 2021. Benieuwd naar zijn ervaring? Lees snel verder!

Robin: “Als je praat over container deployment en cloud native-oplossingen, dan kom je al snel uit bij Kubernetes. Tot op heden is dit de orkestratie-tool voor containers, die het meest wordt gebruikt door de open source community. Zoals met vele open source-projecten bestaat er ook een conferentie voor: KubeCon!”

“Helaas was KubeCon Europe 2021 nog virtueel, maar het voordeel van online conferenties is dat je naderhand een gemiste sessie kunt terugkijken! Wellicht is één van onderstaande sessies iets voor jou?”

#1 Automating your home with K3s and Home Assistant

“Wat interessant was om te zien, is dat er dit jaar meerdere bijeenkomsten waren die de focus hadden op edge-oplossingen. Eén daarvan ging over het automatiseren van je huis met Home Assistant, die draait binnen een K3s cluster. K3s is een lichtere versie van Kubernetes die je heel goed in een edge-omgeving kan draaien. Ideaal om op afgelegen locaties te laten draaien, waar resources beperkt zijn. Het was leuk om te zien hoe er gebruik werd gemaakt van device plugins en node feature discovery om te bepalen waar een pod moet gaan draaien. Om vervolgens het apparaat dat gekoppeld is aan een node te kunnen gebruiken voor de applicatie.”

#2 Petabyte scale logging with Fluentd and Fluent Bit: a use case from intuit

“Met veel Kubernetes clusters is het soms lastig om goed inzicht te krijgen wat er gebeurd in je omgeving en applicaties. Het is dus handig om logging en metrics van je applicatie (en eventueel nodes) bij te houden. Tijdens deze sessie werd mooi verteld wat er allemaal bij komt kijken wanneer je logging wilt verzamelen op grote schaal, waar je rekening mee moet houden, en wat de eventuele valkuilen zijn.”

#3 Multi tenancy vs. multi cluster: when should you use what?

“Dit was niet echt een presentatie, maar meer een discussiepanel. Toch interessant, want er werd besproken wanneer je het beste kan kiezen voor multi tenancy en wanneer je een multi cluster gebruikt. Of een combinatie van beide. Want niet alles in Kubernetes is te beperken binnen een namespace. Denk bijvoorbeeld aan custom resource definitions of persistent volumes.”

#4 Taking bare metal to the clouds with Tinkerbell

“Naar deze sessie heb ik erg uitgekeken, omdat we bij mijn huidige opdracht bezig gaan met het opzetten van Kubernetes on-premise, op bare metal. Dit houdt in dat Kubernetes dus niet virtueel gedeployed wordt, maar op eigen hardware, direct op OS-niveau. Ook cloud providers zien dat klanten hiermee bezig zijn en willen daarbij helpen. Zoals Amazon EKS Anywhere, Azure Arc, VMware Tanzu, etc. De sessie was uiteindelijk een beetje een tegenvaller, omdat er vooral besproken werd waarom het project bestaat en niet hoe het daadwerkelijk werkt. Neemt niet weg dat het Tinkerbell-project wel interessant kan zijn om bij klanten bare metal in te zetten, net zoals je instances in de cloud gebruikt.”

#5 Making dynamic admission control even more dynamic using WebAssembly

“Tijdens KubeCon waren er ook best veel bijeenkomsten over security-aspecten binnen Kubernetes. Eén daarvan was deze. De presentatie liet zien dat bedrijven het nog steeds lastig vinden om het security-beleid goed ingeregeld te krijgen en dat het nog steeds niet goed wordt aangepakt. Bij SUSE zien ze dit ook, daarom hebben zij Kubewarden bedacht. Kubewarden is een policy engine voor Kubernetes en heeft de policy-as-code-mindset. Policies kunnen in een programmeertaal geschreven worden die al bekend is bij een organisatie, zolang als deze omgezet kan worden naar WebAssembly. Een leuke sessie en zeker de moeite waard!”

Een ontwikkelomgeving in een doos

Een ontwikkelomgeving in een doos

dinsdag, 11 mei 2021

Stagiair Thijs is sinds begin dit jaar aan de slag bij Sue. Hij is druk bezig met zijn stageproject, waarbij hij diverse opensource tools gebruikt om een ‘makkelijke’ ontwikkelomgeving op te zetten. Nieuwsgierig wat daarmee wordt bedoeld? Thijs legt het uit.

Thijs: “Tijdens mijn stage bij Sue onderzoek ik het bouwen van een makkelijk op te zetten ontwikkelomgeving door middel van Docker containers en Ansible. De ontwikkelomgeving zelf bestaat uit GitLab en GitLab Runners. Met deze runners kunnen er bouw- en teststraten gemaakt en uitgevoerd worden. De authenticatie hiervan loopt via FreeIPA en de communicatie gaat via RocketChat.

Om visueel overzicht te houden over de ontwikkelomgeving, maak ik gebruik van Portainer. Hiermee kun je de verschillende machines verbinden en inzien welke containers erin gedraaid worden. Dit alles is mooi verpakt in een set Ansible playbooks, Docker compose en documentaire bestanden. Uiteindelijk hoop ik met mijn onderzoek een pakket te kunnen leveren, bestaand uit opensource software, waarmee startups gemakkelijk dit systeem kunnen uitrollen.

Ik heb tijdens mijn stage tot nu toe ontzettend veel geleerd, zowel op technisch als persoonlijk vlak. Met onderwerpen als Docker, netwerken en gebruikersbeheer binnen cloudomgevingen als Azure en AWS ben ik nu nog beter bekend. Daarnaast heb ik een training in Linux Essentials mogen volgen en daarmee meteen een certificaat gehaald!”

Ben jij ook benieuwd naar stage lopen bij Sue? Check dan de vacature!