Steve Atkins
I’m repeating the presentation I gave at M3AAWG in London for the Certified Senders Alliance.It’s all about how to send an email by hand, and how knowing the mechanics of how an email is sent can help us diagnose email delivery issues.We’re starting in about five hours from when I post this.Register at https://register.gotowebinar.com/register/2268789893122531343
A few months ago, Google made a splash in the political press and the email marketing space when they asked the FEC the following question: May Google launch a free and non-partisan pilot program to test Gmail design features, which will be open to authorized candidate committees, political party committees, and leadership political action committees, where spam detection as applied to messages from a pilot participant on direct feedback from the recipient rather than standard spam detection, and each pilot participant will receive information regarding the rate of emails delivered into Gmail users’ inboxes, as long as the pilot will rely predominantly participant is in compliance with the program’s requirements?Google’s letter to the FEC (.pdf link) The letter is actually worth a read as many of the general press reports about the request focused on Google asking the FEC to allow politicians to spam freely. I mostly avoided discussions about
Dear Colleagues at ESPs, We have a problem. More specifically, YOU have a problem. You have a spam problem. One that you’re not taking care of in any way, shape or form. There was a point where ESPs started caring about spam out of their networks. They got blocked enough they had to take action. Because they took action a lot of the big blocklists started being nice. Spamhaus, for instance, would do ‘informational’ listings so that ESPs could fix things rather than going to a direct block. This led management at ESPs to start to think they had this spam thing under control. They stopped worrying too much about spam and compliance. I mean, to management the whole point of having a compliance desk is to stop the blocks. No blocks mean no problems with spam out of the network, right? As someone who gets a lot of B2B
I started out with the best intentions to get back into the swing of things with blogging more regularly. But between MAAWG recovery, COVID recovery and life it’s not worked out that way. This is an excerpt of something I wrote over on slack to explain why someone was still struggling with delivery even though best practices weren’t working. Hope it will be helpful for some folks. (and now I’m off to my next call…) When the issue is a mailstream that has problems that aren’t being addressed by common best practices. In order to address that we need to understand more about why the common best practices aren’t working. They may not be zebras, but they might be donkeys. So I started with listing “these are the problems I’ve seen with mailstreams of your type and why those problems aren’t being resolved by the normal practices.” Email delivery really
I did a class at M3AAWG teaching the basic mechanics of sending an email, both really by hand using dig and netcat, and using SWAKS. No slides, but if you’re interested in the script I’ve posted a very rough copy of my working notes here.
It’s been a few years since we’ve actually made it to a MAAWG. We missed much of 2018 and 2019 due to our international move. Then 2020 San Francisco conflicted with a personal engagement. Then, well, pandemic hit and it’s been virtual and then we were moving and … wow, it’s been busy! We did make it to London, though, and have started reconnecting with colleagues new and old. We also got a chance to take a trip down the river over the weekend leading to a chance to get some pretty pictures. Blues and Whites Tower Bridge south tower. Look, Kids! Big Ben! London old and new After a day of touristing, we’re now buckling down to do some hard work. Steve’s doing a training session this afternoon and I’m moderating a panel tomorrow. I’m so excited to be back in person learning from my colleagues. Don’t forget to
I don’t send a lot of spam complaints generally. Mostly I block and move on. There are some companies, though, that I offer the professional courtesy of sending a complaint or a report to their abuse@ address. Former clients, friends and colleagues generally get that courtesy. The number of ESPs that completely fail to take any action is disappointing. Too many of them can’t even manage the simple courtesy of removing addresses. A few don’t even process bounces correctly and continue to send mail even when getting a spam block or 550 user unknown. Sometimes I’ll reach out to folks who I know work at particular ESPs, although that’s less common these days as everyone seems to be moving companies and I can’t keep track. Often I get an invite to “always send me complaints directly.” That … is not a solution, people. Expecting people who are reporting spam to…
Another day, another ESP telling a client to publish a SPF include for the wrong domain. It shouldn’t annoy me, really. It’s mostly harmless and it’s just an extra DNS look up for most companies. Heck, we followed Mailchimp’s advice and added their include to our bare root domain and it’s not really a huge deal for companies with only a couple SaaS providers. Still, it’s an incorrect recommendation and it does cause problems for some senders who are using multiple SaaS providers and Google. Both Steve and I have written different posts about SPF over the years. In fact, the Authenticating with SPF: -all or ~all post is the most visited post on the blog. I’ve even written almost this same post, pointing out that a lot of ESPs have bad recommendations for SPF records. Steve’s written about the technical ins and outs of SPF records in DNS and…
Every once in a while we’ll see a rejection from Yahoo that says RFCs 554 5.0.0 Message not accepted due to failed RFC compliance. What does that mean and what can we do about it? It really does mean exactly what it says on the label: there’s something about the message that is not in compliance with any number of RFCs and are not going to accept the message in its current state. When trying to help a colleague diagnose the issue I came up with a list of things to check. Troubleshooting in the email Is there any high ASCII without quoted printable or Base64 encoding in the body or the headers?Is there a Date header? Is there any duplication in header fields?Is there a bare IP address in a link somewhere?Are the line lengths inside the message shorter than 998 characters?Are lines correctly terminated with CR/LF?Is the DKIM…
Tools that you run from the command line – i.e. from a terminal or shell window – are often more powerful and quicker to use than their GUI or web equivalents. Their output is plain text so it’s much easier to copy and paste into an email or a slack conversation – sure, you can take a screenshot of a GUI tool and share that, but then the folks you’re sharing it with can’t copy the text out of it. And you can easily run them on a remote machine, which can be particularly useful when you’re diagnosing network issues, or email reputation issues that may be IP address based. Here are some of the tools I use daily, and how to install them on your laptop. (If you’re installing these for a class I’m giving we might have an alternate way to use them if you didn’t install them…