A simple solution for translation spam
A simple solution for translation spamPresented here is a simple technical method the translation community can employ to gum up the works of the spammersâ spam machines. Why the translation community specifically? Well the method does of course apply to anyone, but the particular spam pandemic (resisting saying âspamdemicâ⊠not very well) ravaging the inboxes of LSPs with stolen CVs actually seems to originate from a particular group. We canât be sure of its scale, but weâre aware of its approximate whereabouts and some of the key playersâ true identities. Breaking this spam ring would be a great way to start the new year afresh.
This specific spamming ring I refer to has been operating for a number of years now and has proven hard to stop. This is because of their use of free email providers. None of which are particularly well policed. However, there is a glimmer of hope, in that the free providers do actually provide automated methods of canning spam emails before they leave the house. Itâs just that very few people are aware of them, or how they are employed.
Iâll keep this brief, because I could quite easily fill a book with this topic. Iâve basically been working with a colleague recently to stop email being spoofed from their domain. I think we cracked it, and want to share how, as well as explain the wider implications.
Responsible email providers, which Microsoft and Google aspire to be, check their email before sending it. They check that it isnât being sent out under a false name so as to more easily ensure delivery straight to your inbox. But itâs hard for them to tell if a brand new free account, sending via third-party software, is genuinely affiliated with some translation-related domain or not. So most of the time the email is delivered to you with a plethora of mixed information in the emailâs metadata, otherwise known as its âheadersâ. You get a from email address, a reply-to and other false information added to help the emailâs deliverability. So your inbox doesnât filter it out, basically. You might have noticed that flagging one email as spam doesnât necessarily stop the next one from a new free email account.
The following technical method only works 100% if everyone does it. This is of course not at all a realistic expectation. But the more people who are aware of the fact that they have the power to stop their domain from being used to spoof emails, blocking the spammers before they even leave Microsoft/Google servers, the harder the job of the spammers is. So to be clear, it wonât stop you receiving spam, but itâll stop your domain from being involved in the sending of spam. As well as other impacts Iâll explain below.
It also beats the other best practice of constantly reporting new spam accounts to abuse@hotmail.com, or abuse@gmail.com, especially with their onerous requirements for full message metadata (headers) and form filling. And whatâs more, it will only take 10 minutes to set this up.
##The solution
- SPF and DMARC
- (and DKIM, optional, because itâs more involved)
I suggest we all set up SPF and DMARC records because itâs quick to do and does no harm to our own deliverability (in many cases actually improving it), while blocking out the spammers. If you can follow a DKIM tutorial (Iâll provide some below) and add that too, all the better.
###Example SPF record (my own):
"v=spf1 a mx ip4:myipaddress ~all"
It is added to your domain records (look for DNS records) with your email or domain host. Your host probably has a tutorial or offers support on this. I also had to put an @ in the ânameâ, or record type field.
###Example DMARC record (my own):
"v=DMARC1; p=none; pct=100; rua=mailto:my@emailaddress.co.uk; aspf=r;"
The settings in my case are: v = version, p = policy (alternatives are reject or quarantine, neither of which are desirable at first), pct = % of bad emails to apply the policy to, rua = the report address of the domain owner to send the alert to. aspf refers to subdomains, whether or not mail can be sent from them. I kept mine r, relaxed, but s, strict, is another option.
So that should stop nearly all attempts at spoofing your domain name. By default, Iâve checked, SPF+DMARC is enough to get you started, and you will get reports if your SPF policy fails when someone tries to spoof you. It is probably better to also include DKIM, if you can get it arranged. Itâs actually relatively straightforward in Google Apps/Suite. Iâll provide some tutorial links here for after youâve set up the first two.
###Guides for G Suite and Office 365
- SPF guide on G Suite, formerly Google Apps
- DMARC guide on G Suite, formerly Google Apps
- DKIM guide on G Suite, formerly Google Apps
- MS Office 365 SPF and DMARC guide
- MS Office 365 DKIM guide
##A brief attempt at a simplified explanation
SPF and DKIM came first (ca. 2004-2007) - they are simple one-liner text records added to your domainâs public record.
SPF tells all responsible email providers who make the check what your Sender Policy is, i.e. who can send email using your domain in the headers. DKIM offers Domain Keys to prove Identified Mail. What that means is that the email has a signature appended which matches (mathematically) to the key shown publicly in the domain record. Itâs a wax seal on your emails. Itâs more complicated to set up than DKIM, but offers this additional protection and credibility.
DMARC was built on top of the others, and has been around for the last 10 years, created in 2007 by Paypal who were having trouble with spoofers pretending to be them. For obvious reasons. DMARC, as far as I understand it, checks whether or not your domain allows sending from their servers and domains. It does this by calling your domain, looking at the text records for SPF and/or DKIM and confirming eligibility. If it fails, based on your DMARC settings, it will either report details to you of the attempt made, reject the message or quarantine it. This is good because spammers, using automated software or not, will give up on domains that fail and move on to open ones.
Thatâs why it is up to the translation community - every single business and freelancer - to secure their domains against spoofing.
Now, no judgement on anyone who hasnât, or doesnât feel confident enough to do it. I consider myself to be quite technically literate and still only realised I was missing a DMARC record this week. I have had SPF and DKIM for a number of years, however.
##A word on your domainâs credibility
A final word of warning for those who think they can put this down to a triviality, or a storm in a teacup: spammers can get your domain blacklisted. In practice, this means that your own genuine emails will start ending up in Spam boxes of clients, colleagues, family, friends and prospects.
Finally, and I have nothing to corroborate this as itâs nigh on impossible to get proof of anything SEO-algorithm related, but it may also affect search ranking results if search engines by MS and Google know your domain is involved in spam operations. It may not, but itâs not beyond the realm of possibility for your domain spam score to weight your pagerank. And, frankly, itâs such a simple job, itâs not worth the risk.
Do the fix. Itâs quick, and we all win. If you donât want to get involved, please forward this post to your technical partners.