Word to the Wise
There is an ever increasing amount of spam I am getting from various companies asking for links here on WttW. The Answer is No. We do not have paid links. We do not have sponsored posts. Any links on the site are done at our whim and because we have something to say about your company. The only place we offer links is on the ESPs and Purchased Lists post. And, I gotta tell you, if you buy my address and then send me spam asking to be added the answer will be No because it’s clear you don’t have a policy that meets the criteria for addition. And, yes, folks have done this. We do not work with spammers, and we certainly don’t promote their services, not publicly and not to our clients.
These last few years have been something, huh? Something had to give and, in my case, that something was blogging. There were a number of reasons I stopped writing here, many of them personal, some of them more global. I will admit, I was (and still am a little) burned out as it seemed I was saying and writing the same things I’d been saying and writing for more than a decade. Taking time off has helped a little bit, as much to focus on what I really want to talk about. It helps, too, there are a lot more deliverability resources out there than when I started. I don’t have to say it all, there are other voices (and perspectives!) that are adding to the collective understanding of delivery. That’s taken some of my (admittedly internal) pressure off from having to write about specific things to explain, educate and
When we’re looking at the technical details of email addresses there are two quite different contexts we talk about. One is an “821 address” or “5321 address”. This is the email address as it’s used by the SMTP protocol, as part of the “MAIL FROM: ” or “RCPT TO: ” commands sent to the mailserver. It’s defined in RFC 821, now updated by RFC 5321, hence the name. If someone mentions the “envelope” or they’re talking about “bounce addresses”, this is the sort they mean. We’re not talking about them in this post. The other is an “822 address” or a “5322 address’. They’re the ones the recipient sees in the To: or From: headers. They’re named after their RFC, RFC 5322. This is the sort of email address most folks mean by default, unless they’re explicitly talking about the envelope of an email, but if someone describes an email
It looks like Microsoft are getting pickier about email address syntax, rejecting mail that uses illegal address formats. That might be what’s causing that “550 5.6.0 CAT.InvalidContent.Exception: DataSourceOperationException, proxyAddress: prefix not supported – ; cannot handle content of message” rejection. Why do we care? It’s good to send syntactically valid email in a warm fuzzies sort of way – it shows we know what we’re doing, and aren’t dodgy spamware – but it’s increasingly important to delivery as mailbox providers are tightening up on their syntax checks. But why are mailbox providers doing that? One reason is that authentication tech like DKIM and DMARC is built around them only being applied to email. Not to messages that kinda look like email. There are ways to bypass DKIM protections by sending invalid messages. As one example, if you send multiple copies of the From: header with different values a DKIM checker
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