Hacker News Reader

Comment by dotancohen | Hacker News Reader

If your company uses Office 365, these guys have a plugin that I think parses the HTML website to get your mail (and calendar!) into Thunderbird: https://www.beonex.com/owl/

Just this week I gave them 10 Euros for the addon because my company refuses to enable IMAP for Office 365. I'm not affiliated with them, but I've been using the Tbird addon for a few weeks and it works perfectly. The license is per-year, though I guess that makes sense because I expect that it needs to be updated whenever the Office 365 site is updated.

View on HN

Did you get this extension audited by your security team? It sounds insane to me that you’re bypassing IMAP restrictions, with a plug-in that monitors and parses the entire O365 website…

To be fair, it’s the security team’s idiotic position on IMAP that prompted the parent commenter to find a workaround.

It’s like how having super draconian password reset and complexity requirements ends up being less secure because users will start writing their impossible-to-remember passwords on post-it notes.

The IMAP blocking is for different draconian reasons. Office365 does not support Modern Auth with IMAP, which is considered a security baseline now.

Office365 supports Kerberos with IMAP, which would be the proper thing to do anyways. Giving passwords to a browser or email application is wrong.

"modern Auth" means OAUTH, so, you aren't giving passwords to the email application.

If you have IMAP on GMail you get two choices, you can admit you're sacrificing security, and they'll mint a random password just for that IMAP application, or you can use OAUTHBEARER. As I understand it if enabled IMAP for Office365 can do OAUTHBEARER.

The nice thing about OAUTH is that it's a natural integration for your multi-factor authentication, which as I understand it doesn't fit well into Kerberos. But to be sure Kerberos is much better than yet another human memorable secret password exchange.

I'm pretty sure they do? I definitely set up a O365 account in Thunderbird using IMAP and OAuth, which I assume is sufficiently "modern auth."

It's the complete opposite, Office365 only supports OAuth with IMAP and is phasing out/has phased out Basic Auth for IMAP. Additionally more often than not organizations are actually running Microsoft Exchange under the hood -- the majority of MS Exchange servers have Basic Auth disabled for IMAP (I believe since 2017 it's been off by default).

There’s a big difference between password reset rules, and giving third-parties access to emails and calendar.

There is nothing draconian about restricting IMAP - any app could exfiltrate confidential emails once granted access. It’s a very sane rule to disallow everything except webmail or first party apps.

It's a terrible process for the users. And as we can see what did it get them, a third party logging into there webmail.

The service is protected with a username and password, didn't matter if it was IMAP or webmail.

Of course it does matter! Webmail is quite restricted and optimized for viewing and replying to emails. IMAP is great for that, while also facilitating exporting (exfiltrating) the entire mailbox.

An employee who redirects company emails to get around a security rule becomes an ex-employee very quickly.

That addon got the exact same stringent audit by my security team as did the Firefox web browser that I installed to browse the entire O365 website to begin with.

The trust level for Firefox as a browser, versus a random extension that parses O365, would be very different for me. And at the company I work at.

I’m surprised you got this one approved.

I interpreted his comment as saying he did not ask permission. Probably he'll be fine as long as nothing he did was explicitly against any rules, even if it is clearly against the spirit of the rules. More likely still, no one will ever find out.

He’ll be fine as long as the extension doesn’t steal data. The moment that happens, his job is on the line.

What happened to vetting sources? Beonex is Ben Bucksch, a Mozilla true believer who's been around since before Firefox even existed. The chances that it will suddenly turn into malware is about as likely a distro's coreutils package maintainer going rogue—and far less likely than the revolving door at Mozilla Corp leading to the Firefox product team deciding to do something untoward themselves.

Vetting sources is only basic due diligence. Auditing source code, infrastructure, and data storage is crucial regardless of how “prolific” the author is.

> Vetting sources is only basic due diligence.

Right, which is my point.

You’re saying this individual is more trustworthy than Mozilla, because of employee churn? There’s a bus factor of 1 vs N in this example.

I trust indie devs for lots of software, tools, and apps; but absolutely not an extension that reads my privileged communications.

See https://sourceforge.net/projects/davmail/ for a FOSS solution (similar approach, but it lives outside of Thunderbird).

DavMail was a life saver when I was in an Outlook Web Access office a few years ago.

The plugin works, but barely. I have to use it on the job. It does not for example deal with JS on the login page. If there is a JS "button" that has an event handler for clicks, you are screwed. Do not expect support from them. I once wrote them about this problem and their response was basically "Oh, that's unfortunate!" and that for a paid product. They are basically living off of people having few other choices, not, because their stuff was so high quality.

Interesting, too bad it's not FOSS though. I would like to see how it works.

It's written in unminified JS.

Reply on news.ycombinator.com