It's time to define another email technology-related term for the DELIVTERMS series here on Spam Resource. Today, what we'll explain is SMTP AUTH, short for Simple Mail Transfer Protocol Authentication.
This one goes way back. Back in the day, and I mean the real "you've got mail" days, when you connected to the internet through your home ISP, things worked a little differently. If you got your home internet access from, say, Earthlink, your internet connection would put you specifically and directly on Earthlink's network. You'd set up your email app (perhaps Outlook Express, Eudora, or Netscape Mail) to send mail through smtp.earthlink.net, and that server would happily accept and relay your messages simply because you were connecting from within EarthLink's own network. The call (your attempt to send email) was coming from inside the building, as it were.
The Earthlink mail server didn't need you to provide a username or password. It trusted you simply because your IP address belonged to EarthLink. Most ISPs worked this way: your ability to send email depended entirely on being on their network. If you dialed in from home, it worked fine. But if you tried to send email while visiting a friend who used a different ISP, or later, when you connected through the Wi-Fi at a hotel or coffee shop, your mail client would suddenly fail to send. The remote mail server would say, "Sorry, you're not one of us," and block the relay attempt.
Sending email on the road was, at the time, a huge pain in the rear end. And we can thank spammers for that, because spammers ruin everything.
Open relays and spam abuse
Once upon a time, most email servers accepted mail for relaying (forwarding) from anyone, anywhere, in the spirit of an open and collaborative internet. In the mid-to-late 1990s, spammers figured out that this was a great way to bounce spam to you through servers other than their own, to sidestep blocking. This is what led folks (including yours truly) to begin to block, and publish blocklists of, "open relaying" email servers, because spammers were exploiting them to send spam. The fix for an internet service provider was to lock down their mail server so that it would relay (forward on) mail only for their own customers.
But what if your customer wasn't connected via your network? That was the ISP's dilemma. What if your user was on the road, or you didn't actually offer an internet connection, only a mail service?
That's where SMTP AUTH came in. It added a mechanism for your mail client to log in, usually with the same username and password you used for your mailbox, before sending. Instead of relying on the IP address to prove you were a valid customer, you could now authenticate directly. Once the mail server saw valid credentials, it would allow the message through, no matter where in the world you were connecting from.
It was a small technical change that made a huge difference in usability. Every ISP and hosting provider eventually adopted it, and every mail client supported it. Check the box labeled "My outgoing mail server requires authentication," enter your credentials, and suddenly your email could travel with you, whether you were at home, at work, or using your brand-new laptop over a hotel modem line in 1999.
But times change
Today, SMTP AUTH is showing its age. While it's still widely supported, it relies on basic username and password credentials, often transmitted or stored in ways that aren't ideal by modern security standards. Attackers learned long ago that compromised SMTP AUTH logins were a quick way to turn an innocent mail server into a spam cannon, so the industry started tightening things up.
Modern systems are shifting toward OAuth2 or SSO (Single Sign-On) authentication, which replace static passwords with secure tokens managed by identity providers like Microsoft 365 or Google Workspace. Instead of every mail client holding onto your password, authentication happens through a centralized, encrypted handshake, which can even be part of a process that includes multi-factor authentication and a little bit of bot detection. It's safer, easier to manage, and much harder to abuse.
You'll still see "SMTP AUTH" in configuration guides and logs (and I do actually think that Earthlink still supports it), but increasingly, administrators are turning it off for everyday users. Microsoft and Google have both announceddeprecations, and modern API-based mail submission is the new default. The old "just set the username and password in the mail client" model is fading into history.
A fond remembrance
SMTP AUTH was a bridge technology. It solved the very real problem of sending email when you weren't sitting at your home ISP connection, back when that concept was still new. It brought flexibility to the email world and made mobile and remote access possible. But as the internet grew and attackers got smarter, the industry had to move on.
Think of SMTP AUTH as the flip phone of email authentication: it had its time, we all once used it, and every once in a while you hear about somebody still using it, but technology, and security requirements, are marching onward.
Want to learn more about deliverability terminology? Be sure to visit the DELIVTERMS section here on Spam Resource.
It's time to define another email technology-related term for the DELIVTERMS series here on Spam Resource. Today, what we'll explain is SMTP AUTH, short for Simple Mail Transfer Protocol Authentication.
This one goes way back. Back in the day, and I mean the real "you've got mail" days, when you connected to the internet through your home ISP, things worked a little differently. If you got your home internet access from, say, Earthlink, your internet connection would put you specifically and directly on Earthlink's network. You'd set up your email app (perhaps Outlook Express, Eudora, or Netscape Mail) to send mail through smtp.earthlink.net, and that server would happily accept and relay your messages simply because you were connecting from within EarthLink's own network. The call (your attempt to send email) was coming from inside the building, as it were.
The Earthlink mail server didn't need you to provide a username or password. It trusted you simply because your IP address belonged to EarthLink. Most ISPs worked this way: your ability to send email depended entirely on being on their network. If you dialed in from home, it worked fine. But if you tried to send email while visiting a friend who used a different ISP, or later, when you connected through the Wi-Fi at a hotel or coffee shop, your mail client would suddenly fail to send. The remote mail server would say, "Sorry, you're not one of us," and block the relay attempt.
Sending email on the road was, at the time, a huge pain in the rear end. And we can thank spammers for that, because spammers ruin everything.
Open relays and spam abuse
But what if your customer wasn't connected via your network? That was the ISP's dilemma. What if your user was on the road, or you didn't actually offer an internet connection, only a mail service?
That's where SMTP AUTH came in. It added a mechanism for your mail client to log in, usually with the same username and password you used for your mailbox, before sending. Instead of relying on the IP address to prove you were a valid customer, you could now authenticate directly. Once the mail server saw valid credentials, it would allow the message through, no matter where in the world you were connecting from.
It was a small technical change that made a huge difference in usability. Every ISP and hosting provider eventually adopted it, and every mail client supported it. Check the box labeled "My outgoing mail server requires authentication," enter your credentials, and suddenly your email could travel with you, whether you were at home, at work, or using your brand-new laptop over a hotel modem line in 1999.
But times change
Today, SMTP AUTH is showing its age. While it's still widely supported, it relies on basic username and password credentials, often transmitted or stored in ways that aren't ideal by modern security standards. Attackers learned long ago that compromised SMTP AUTH logins were a quick way to turn an innocent mail server into a spam cannon, so the industry started tightening things up.Modern systems are shifting toward OAuth2 or SSO (Single Sign-On) authentication, which replace static passwords with secure tokens managed by identity providers like Microsoft 365 or Google Workspace. Instead of every mail client holding onto your password, authentication happens through a centralized, encrypted handshake, which can even be part of a process that includes multi-factor authentication and a little bit of bot detection. It's safer, easier to manage, and much harder to abuse.
You'll still see "SMTP AUTH" in configuration guides and logs (and I do actually think that Earthlink still supports it), but increasingly, administrators are turning it off for everyday users. Microsoft and Google have both announced deprecations, and modern API-based mail submission is the new default. The old "just set the username and password in the mail client" model is fading into history.
A fond remembrance
SMTP AUTH was a bridge technology. It solved the very real problem of sending email when you weren't sitting at your home ISP connection, back when that concept was still new. It brought flexibility to the email world and made mobile and remote access possible. But as the internet grew and attackers got smarter, the industry had to move on.Think of SMTP AUTH as the flip phone of email authentication: it had its time, we all once used it, and every once in a while you hear about somebody still using it, but technology, and security requirements, are marching onward.
Want to learn more about deliverability terminology? Be sure to visit the DELIVTERMS section here on Spam Resource.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.