Basic Authentication Deprecation in Exchange Online – May 2022 Update

Thanks ViliusS .

Yes, in the past (with bigger customers) I've always opted for Service type mailbox/es (as appropriate), with the function being separate to the Users themselves. SMB customers tend to more readily see cost (making that a barrier), no matter how much one manages to prove the real value.

I will see if I can re-assert that position with our customers (which is all the harder, given cost translation of subscriptions to NZD, recently increased too & comparing with ISP/mailbox costs for SMB customers).

I'll approach the 3rd Party directly to see re what (if any) progress, they're making towards their App (which by the way, I've confirmed they recommended use of IMAP to keep their software's local mail cache footprint size down) using Modern Auth, as that would definitely be a big one, as I could then seriously push to use the KIOSK A/c, & as you say, SMTP AUTH & hopefully - job done & customer (hopefully) happy too.... BUT .... to keep SMTP AUTH with Basic, one has to disable Security Defaults, thus one loses the ability of the Authenticator being required ...... unless one can enforce that on the 2 A/cs (not use SMTP AUTH at all on those) & have the KIOSK A/c with SMTP AUTH & Basic) ....... in which case - phew, possibly....

Although, I can't hold my breath re the developer having made such progress, & this wouldn't be uncommon I'd think with a lot of similar 3rd party apps out there.  I suspect, Microsoft's NOT seeing this as an issue, as customers have either NOT adopted 365 (for these needs not being met) OR have had to run secondary Mail mechanisms (thus more cost & complexity to their businesses) to get around these issues, hence MS isn't seen as the one stop shop, & with Google (yes, I'd also noted too re Google), about to do the same, well I suspect the issue will be compounded very soon....  then we may start to see the real scope of this problem come to the fore.

In an effort to raise the profile of this need, I'm but one in the world of many who are/will be in this boat with customers, I keep asking & pushing this issue..... Clear document please.....

Also, this begs the question - is there then a role for App Passwords in the future?????? This really, to me, seemed to be "Use at your risk" solution, whilst not exposing the Mailbox itself i.e. for SMTP send & not compromising the Mailbox, whilst yes, potentially could (if pwd seized) be a SPAM vector...... 

When I put this issue to Microsoft (via the 365 Support - I managed to get a very nice person, who tracked me down to keep the issue moving - wow appreciated that) ...... I pretty much expected the answer, as I'd worked it out but docs skip around the statement... Here's what was said ....

review if the goal is possible.

https://docs.microsoft.com/en-us/Exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online?redirectSourcePath=%252farticle%252f58018196-f918-49cd-8238-56f57f38d662

https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365

It looks like the first goal needs to turn on the Modern authentication to work and the 2nd goal will not work if the modern authentication is turned on.

in that case both goals are contradiction. 

Knowing that we need Authentication enabled for Customer to be challenged with Outlook & not let in if not answered, but also need ability to do the SMTP AUTH (Basic required) - it seems no go, unless have 3rd A/c (Service - KIOSK licence) & can have SMTP Auth/Basic on for that one mailbox.....

I do hope this makes sense, & again is why I ask for a simple worked example doc & I'm sure our world of MS techs would be much the happier & be better able to make cases to Mgmt persons for say Service/Kiosk A/cs when one can show - Hey this is how MS say it needs to be done.....

Am appreciative of the assists everyone... & hope with your aid I'll be able to make something work, such that we can do similarly for the next, the next & so on ...... 

Cheers

G