Nah, not K-9 but silly behaviour on the Exchange Server. The way outgoing mails are handled depends not on you MTA entirely, but in large chunks on the way you communicate with them. Here, M$ has a naming scheme that you need to manually set in K-9.
As a workaround, in the account’s settings you can change the outgoing folder to drafts.
Hi tchara, thanks for reply! Forgive me… I cannot find any setting where to change folder name in K9. There are setting which existing forder I want to use for drafts/sent/deleted/spam, but nothing to rename one.
And frankly speaking, I did not understand yr meaning ‘naming scheme to be manually set in K9’.
Hi!
Unable to login with imap and office 365 either. Created an app-password but the response is always:
(Command: *sensitive*; response: #3# [NO, LOGIN failed.])
You need to provide more details for people to try to help you:
Hello, same problem than @ruapho here (same error message). I had an app password working for several years, this just stopped working yesterday, without any config change in my client setup or our Office365 tenant Exchange setup.
The problem is only (for now …) with the incoming email server (IMAP), SMTP is working fine. IMAP config:
I read that Microsoft will eventually drop support for Basic auth IMAP login, and will support only IMAP with OAuth 2.0. But this shall only be enforced in October 2022.
Thus:
This is what I assume that will be implemented in 6.200
Actually I saved the (not working) settings and after some time the just start working… Maybe there is some delay in office 365 in propagating the app password to imap?
I’ve been having this trouble too, just cropped up today.
K9Mail 6.000 with Office365 email account, failing to authenticate.
I suspect it’s to do with MS dropping basic auth, but I don’t know enough about it to check that out.
I actually tackled it a little differently, I have been using DavMail to sync my calendars and contacts from O365 to my device. DavMail has IMAP and SMTP configuration as well, so I enabled those and changed my server url in K9Mail settings and it works, for me, pretty well.
Not ideal for K9 to implement something like that, but it’s a pretty decent workaround for now for anyone still struggling with Office365 I think.
For those on this thread, were you using straight up user/password credentials in K9 to Microsoft’s mail servers?
Two thoughts come to mind:
I’ve been using an app password in K9 with my personal account for ages.
For my work O365 tenant, I know that IMAP is enabled for my account. This is what stopped working some days ago. Until then it worked OK with an app password.
For my personal account (Hotmail), the app password still works OK
I’d check with work, IT, helpdesk whomever and whatever they may be called, and ask them why your mail check stopped working. I’d still bet that they made a configuration change and blocked your use of K9.
Thanks, but I am the tenant admin 
. So I know there was no change on our side. What is left to do for me is to open a service ticket to Microsoft support (who is usually not great at resolving things).
You also could try to send a debuglog here - maybe this will give more details:
Settings / General Settings / Debugging / Enable Debug Logging.
Once you have recreated the error you go at same menu / 3dot menu / Export logs.
Make sure that no sensitive data e.g. passwords are included.
The problem went away as surprisingly as it came: I am now able to sync my O365 emails through IMAP in both K9 mail and Thunderbird (still no config change on our side …).
I opened a service ticket to Microsoft, asking if there were any operation on our tenant this week-end (as last Thursday was a public holiday in France, this was a long week-end for most people).
If the problem happens again, I’ll upload a debug log here.
Thanks for your support.
We’ve been getting notifications from MS for a few weeks that they were going to require OAUTH for IMAP on our O365 tenant account, and it looks like it just happened this morning!
I had an answer from Microsoft O365 support. They confirmed they had an incident on May 24th that affected many IMAP users. The incident is now closed on their side. The guy from the support did not get details about the incident, but all I wanted to know is that it was a temporary incident, nothing definitve.
Support referred me to this article, which I read and replied, “It’s not October yet.”
Also read on that page:
IMPORTANT: Sometime in second quarter of 2022 we will selectively pick tenants and disable Basic Auth for all affected protocols except SMTP AUTH for a period of 12-48 hours. After this time, Basic Auth for these protocols will be re-enabled, if the tenant admin has not already re-enabled them using our self-service tools.
So it could be that you are one of the chosen ones if it works later again. Can you still send mails?
Yep, SMTP never failed. However, I did go thru their little reenablement procedure, and it’s all working again, so thanks!
I just started getting this issue a day ago. It must be that my organization’s administrator clicked “apply settings” later than others x.x. I have been using plain password and do not want to enable MFA just to be able to get app passwords. I was able to get Thunderbird working by switching it to Oauth2, but K-9 doesn’t have that option. I also have a CLI script I run (to auto-unquarantine quarantined messages) which broke which I do hope to update to support Oauth2.
Anyway, based on that article, my access will be restored in about a day or so? Interesting…
What I am confused about is the way they disabled it. Thunderbird and K-9 get “LOGIN failed”. When I switched Thunderbird to other things like digest authentication, it told me that the authentication method was not supported and to try switching back to basic. So Outlook365 still continues to advertise support for basic authentication even when it is unsupported? Or maybe the IMAP protocol isn’t able to advertise LOGINDISABLED on a per-account basis so they can’t actually disable it correctly? It’d’ve been nice if the response could have at least explained what was happening instead of being the same error as a mistyped password.