Even with the delay, I don't think complete deprecation of basic SMTPAUTH auth is the best choice if it's pushing users towards poorer choices, which it does in my opinion. For small businesses I see 3 options that don't involve signing up with an additional mail provider that supports SMTPAUTH (PLAIN):
- Replace perfectly good devices that rely on SMTPAUTH (PLAIN).
- Use a 3rd party service that accepts mail via SMTP using SMTPAUTH (PLAIN) and relays that mail using OAUTH. This eliminates the primary benefit of OAUTH which is token validation without needing to store the authentication secret in a reversible format like SMTPAUTH (PLAIN) does. However, instead of having reversible (aka plain text) secrets managed by Microsoft, people opting for this will have their authentication secrets stored in plain text by a 3rd party. Right?
- Use Azure Communication Services Email. This adds complexity [1] and ultimately gives users more downsides. Unless I'm mistaken, that link is explaining how to set up SMTPAUTH (PLAIN), but calling the password a secret. Assuming that's correct, how is that a better option for my security? Instead of a simple user you're going to have people trying to fumble their way through setting up an Entra App. Even worse, for the user, they're going to have to attach a credit card to Azure which many small businesses don't need (or want).
I realize that option 3 will have a narrower scope in terms of what the user can do, and rate limits if you configure them, but that comes down to a choice by Microsoft. Basic SMTPAUTH could have an app password that's scoped down to sending email. In fact, for small business users, there are advantages to sending that mail from a monitored account that has an inbox since it makes it easier to discover a compromised account that's sending phishing emails (ie: no inbox rules with proper scoping means users see replies immediately).
Notice how those linked instructions in option #3 don't describe a solution for setting a reply-to address? That's a little more complexity, if your device even supports the proper format, and you very quickly end up with option #2 above being the path of least resistance. If that becomes popular enough, you run the risk of 3rd parties building misconfigured OATUH apps. The Synology incident last year is a good example [2].
What you're doing here is shifting responsibility and liability. Instead of giving customers a simple solution to continue using basic SMTPAUTH, like an app password and rate limits, you deprecate it from one product (MS365), but are going to leave it as an option in another (Azure) more complex product with a (proverbial) warning label. People might opt for that and be worse off for it.
For small businesses that don't have a MSP, this is what would work better IMO:
- Make basic SMTPAUTH an addon product with warnings about using it and an additional monthly cost. Charge 2x a Business Basic subscription to penalize it's use if you need to.
- Add an app password for basic SMTPAUTH that's narrowly scoped to sending mail.
- Maybe add rate limits. For something like scan to email, no one needs to send bulk mail.
Small businesses are cost conscious. If you can add to the 5-year cost of a device that doesn't include OAUTH capability, that'll have an impact on their next purchase.
I know it's unlikely any work will be done to improve the existing product when deprecation is a funnel towards Azure services, but, in my opinion, we'd get better security in the short term if Microsoft hardened the usage around basic SMTPAUTH instead of shutting it off and leaving people with band-aid solutions.
1. https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/send-email-smtp/smtp-authentication
2. https://modzero.com/en/blog/when-backups-open-backdoors-synology-active-backup-m365/
