I guess the title says it all
I love the mail app but it has been so unreliable lately because 90% of the times it asks me to insert my credentials again and sometimes there’s no way to make it work (other than check the mail via browser)
This does happen only with microsoft accounts
I have 6 mails configured, 3 of which are from ms and they are the only one having problems, as the other 3 are totally fine
Has anybody had the same problem?
Yes, i deleted the account, because i forwarded the mails earlier to gmail. Now i only use gmail
Deleting the account only works for a day or two then it start again with the same exact behaviour
Hi,
Microsoft are in process of tightening up security with a cut off point of September 16, Microsoft will no longer support the use of third-party email and calendar apps which ask you to sign in with only your Microsoft Account username and password, To keep you safe you will need to use a mail or calendar app which supports Microsoft’s modern authentication methods.
What the fak, are they kidding me?so what are we gonna do we sailfish users?
Hasn’t this been implemented? The Microsoft type flow for OAuth should suffice for this, right?
maybe this has something do with it; https://www.youtube.com/watch?v=-0zjxuNqZRY
nope, cause it’s months that’s happening
Yes, this would be fine. Oauth is modern.
However, in my case, anything that has to do with activesync in Sailfish isn’t reliable. Appointments not getting saved, mails not being send. Not on o365, not on exchange on-prem and not on my own kopano (z-push) server.
As someone said, it’s a global problem, e.g Blackberry hub+ ( android) has the same problem). Other third party mail clients might work, such as Bluemail.
I created a simple imap account on my sailfish phone, which works fine, however you don’t get any synchronisation with calendar, person etc.
that’s what i already have, and having tons of problems…
So, people with a microsoft mail should say bye to the mail client?
I would expect an update to the email authentification… or…? Can’t just be thrown away, next trouble to come would be gmail I guess!
now we’re up to the point i cannot even add my account anymore
no it can’t be left this way as MS is the second mail provider after gmail, and considering private mails like tutanota or proton does not work in sf, we are left with not much choices…
Edit: i tried with profimal for android and it works flawlessy (i guess until the date described in the deadline)
Please do something
You can pick any other mail provider I guess, between outlook/gmail to tutanota/proton there is a whole list of other valid options I would hope.
I have a vivaldi account and that works flawlessy, but you know what?
1 most mails are from ms, how do they plan to sell a system who’s not working with the largest mail provider in the world (or second largest)?
2 as much as you are right and i would definitely switch to something else i can’t, cause my ms account is the one that i have registered anywhere, like forums, curriculum vitae and so on
On a sidenote, i now this is surely a problem on microsoft end, but they should still do something in my opinion. Not having the mail working is not a good advert for the system…
I’d advise to move away from MS regardless.
It is going to be cat-and-mouse with MS upping requirements (and reducing options). I predict:
They will shut you off from your email and other data sooner or later. Migrate to sone trustworthy provider while you still can.
Here’s some cautionary tales, also explaining why this is happening:
Thank you @nephros for your warning. I totally agree with it and the advice to migrate away. I understand that it’s still an issue to have an email address that is not long-term valid. It requires to warn many people, like when changing phone number or bank account.
Coming back to the authentication point, currently the email application can do OAuth2 only with Google as far as I know, and it relies on several proprietary pieces of software in Sailfish OS. In my opinion, it could be good to change this matter of fact and work on having OAuth2 authentication working for any provider (Microsoft is using it by the way, for how long, I don’t know though).
Doing OAuth2 from the email application is quite simple, it requires to get the access token and send it as a challenge duting the authentication. There is no code for IMAP, POP and SMTP at the moment, and it’s handled in qmf-oauth2-plugin which is closed sources. But I’m working on a rewrite of this authentication part in QMF and I’m adding the access token stuff in the open source part, see https://codereview.qt-project.org/c/qt-labs/messagingframework/+/573489.
Then, the access token is stored by Signgle Sign On (SSO). It’s handled by the OAuth2 plugin to SSO which is opensource, see GitHub - sailfishos/signon-plugin-oauth2
Then, the largest part of the stack, is how to retrieve this access token. It is done in the setting application, so completely closed source. It means first to register once and for all for a client id. Jolla has done it for Google. It must be done for every provider. Especially, they must do it for Microsoft if desired. With this client id during account creation on device, the setting application must submit for an access token providing the client id and its associated secret. This is done in a HTML page where the user grant permission to the Jolla application to access his / her emails. Then, the page return the access token and a refresh token that can be stored in SSO, with additional information on how to use the refresh token. There is a dedicated QML page for Google at the moment in the application. It can be duplicated for Microsoft I guess. But it’s not very future proof and scalable for other providers. I don’t want to have a dedicated page for every providers. Another possibility would be to write a small application presenting the HTML page and saving the tokens in SSO. Later on, Jolla may be interested in moving this to the setting application.
To summarize, I don’t have a plan and it won’t be ready in the immediate future.
Thank you a lot for the detailed overview and status, @dcaliste .
For people desperate enough about this, email-oauth2-proxy may be a workaround. It appears to be similar to hydroxide (a “bridge” application for protonmail), which does work with Jolla’s General Email account type as discussed here.
The email-oauth2-proxy README alone is very interesting and provides a lot of insight.
Of course, getting this to run (which I have not tried) looks like considerable manual work.
Does Microsoft not allow for configuring an MS-Mail account to stubbornly forward every incoming email to another email account?
Side note: If not, Microsoft’s mail service is even more dreaded than I thought.
IMO this is the wrong mindset and consequence: They should say “bye” to Microsoft instead.
As @nephros nicely depicted, this is a cat & mouse game you cannot win; this applies to Google and other “big”, integrated providers, too.