smtp
Email supports TLS (Transport Layer Security), what we used to call SSL. Unlike the web, which split it’s TLS support off into a completely different protocol – https, listening on port 443 vs http listening on port 80 – SMTP implements it inside it’s non-encrypted protocol. A mailserver advertises that it supports this by having the word “STARTTLS” in the banner it sends after you connect to it. Before you do much else you send the command “STARTTLS”. At this point the tcp connection to the mailserver stops speaking SMTP and is ready for the complex binary dance that is a TLS handshake. Once the negotiation of protocols and ciphers and session tokens is done SMTP comes back. It looks just like it did before, but now it’s all being tunneled over a secure, encrypted TLS session. Sometimes you want to find out a few more details about how a
Deliverability folks from a few different email sending platforms have mentioned seeing a new bounce from Comcast, in response when trying to mail certain comcast.net subscribers:550 5.2.0 – Account Closed, Please RemoveWhat does it mean? Nobody home! That’s a dead account. The user is an ex-parrot. Send them no more mail. Seems simple enough to me, but people always have questions about this kind of thing, so I figured I’d share it with you all.And of course, there’s still this usual bounce:550 5.1.1 – Not our CustomerMeaning that’s not a valid Comcast subscriber address, either. Same deal, nobody home. It likely means nobody was ever home at that address, but even if I’m slightly wrong about that, the net here is the same; time to stop mailing that address.And then there’s also a slightly rarer 4xx bounce that looks like this:450 4.2.0 – Recipient temporarily unavailableThose ones, you should retry per
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
If you want to learn more about SMTP response codes and error messages, here’s a couple of resources you’ll want to check out and bookmark for future reference. First, here’s John Porrini from SocketLabs: 21 SMTP Response Codes That You Need To Know.And after you’ve checked that out, you’ll want to bookmark the SMTP FIELD MANUAL: A collection of raw SMTP error codes spotted in the wild from Postmark. Very useful to try to understand what kind of rejects (bounces) certain mailbox providers will send back and sometimes it has come in handy when I can’t access to a client’s actual bounce message, so I can review what common ones that particular mailbox provider sends, and develop a thoery of what might have happened, based on that.
Need a fake SMTP server for testing? Chadwan Pawar of PostBox Services suggests Mailhog. It’s an open source SMTP server that captures all mail and gives you a visual dashboard showing you what was received. Much fancier than /dev/null (but that can come in handy sometimes, too).Read more about it over on PostBoxServices and here’s a link to the Mailhog project on Github.