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.
Already said i agree, but it’s not that easy
Never heard of that function any’ay, will have a look into it, althought i doubt
Still, despite being clearly a wrong mindset, i say that not supporting the second biggest mail provider in the world is like shooting in the foot for jolla
And like newes esr and newest camera api it’s something jolla should do themselves and not relying on the community
I think you that you have understood the purpose of Sailfish completely wrong. The idea is that we should be able to, as much as possible, get away from Microsoft/Google/Apple, not to be compatible.
And how do you plan to attract users, if they already know their mail (not a weird banking app, not some weird crypto app, a basic service like mail) is not gonna work?
And exactly, how do you plan to make money on sailfish, since it’s already demostrated that we (as in users right now) do not provide jolla the right income to stay afloat?
It’s sad i know, but it’s the reality, i can live by checking mails on my pc, most people can’t and need to have a working phone for that, and anyway to me mail is a basic feature
I have experience the PROBLEM with ms also.
I have now my own domain with my e-mail and the calendar I use my Synology.
I don’t plan to make money from Sailfish, that is a task for Jolla, as also the MS mail problem is. And I’m pretty sure they will solve it… in time.
In the meantime you could do what @olf is suggesting. Get an email account from any other respectful provider and start forwarding your MS mail to the new one, that works with Sailfish mail app. Then you should have at least a couple of years to liquidate your MS account and slowly but surely establish the new address. by updating your email address in all the places you deem necessary.
I know it’s doable, because I did it myself some 20 years ago, when I got my first own domain.
Even big player GMX is not able to handle this atm. Right now I had a look into the options of my GMX account and there was no other option for the mail fetching service than enter mail address and password, No option for this new 2FA authentification of MS.
It’s not as easy just to ditch MS mail in all situations. If it’s your personal e-mail, sure… But if your employer uses MS mail and calendar then its practically not in your control.
Being able to use my Sailfish phone in these (unfortunate) situations would be important to me. And unfortunately MS Mail/Calendar usage in corporations is not a rare occurrence.
I think we all know that it is not entirely straightforward, but if MS mail is a requirement from your employer, he/she should provide you with a work phone. In any case, he/she can hardly require you to run a certain MS compatible operating system on your personal mobile phone.
The least you can ask for is that he allows you to forward your work emails to an email address that works on your personal phone.
Sorry, but I don’t agree with most points.
Username/password authentication has issues, and TOTP also has it’s best time. Using that will get your company hacked, simple as that. There are better alternatives. Microsoft uses OPEN standards like oauth2 and webauthm. It doesn’t force businesses to use MS authenticator(app, it’s just ‘free’ with a lot of contracts, and more secure then TOTP). Administrators can use a multitude of authentication methods, completely supported. Yubikey, other hardware tokens, SMS , phone call, TOTP(they rightfully recommended against the last 3, because it is susceptible to fishing and it can be stolen without anyone knowing and usable on multitude devices. Real world hackers took advantage of those flaws).
I’m no MS fanboy. I’m using Sailfish as my daily phone. But blaming MS for it’s mail/calendar not functioning well in Sailfish is dumb.
Oauth2 exists for YEARS, is well documented, and it is there for good reasons. Just implement it, or drop support.
Well, I don’t want to carry and check on two phones to be honest.
Much better that Sailfish supports MS Mail/Calendar as long as its widely in use in corporations, regardless of my personal distaste regarding all things Microsoft.
How does this all relate to the new Microsoft (365 with oauth) account option that was added a year or two back? Is it that which is unreliable; or is this about some other class of accounts, still using the “Exchange” flavor? Or are you adding it as plain email?
It still doesn’t make any sense for some old deprecated auth method to just be unreliable. Either it is allowed, or it isn’t - and they should also be telling you.
I have something similar as the described issue when using Evolution towards Microsoft 365 - but i just close the login dialog and it keeps working until next password change. Presumably the server throws some weirdo error that gets mapped to reauth, but actually shouldn’t.
MS365 is just exchange online. And exchange online is basically the same as exchange ‘on premise’ but authentication is a different beast because it could be protected by ‘conditional access’ (which could also leverage device authentication /device compliance - but this is kinda off topic ).
But with exchange online you can stills use activesync(mail, calendar, contacts) protocol which Sailfish supports.
In my case it(activesync) never worked reliably. It happened too often that mail didn’t get send, appointments didn’t get saved, me missing appointments.
It happened with exchange on prem, with my own home server(kopano with activesync support) and with exchange online.
Nowadays my company(i’m the senior IT admin) uses exchange online and i’m using Davmail (https://davmail.sourceforge.net/ , basically converts Activesync to imap/caldav/carddav) to get work mail reliable .
Edit: so for me, reliability was always sub-par and unrelated to authentication protocols, but related to Activesync.
May very well be so on the backend; but i’m talking about the account types in SFOS settings. They are very different.