mail-server VS email-oauth2-proxy

* [1] should be https://stalw.art

It's a neat project though, that I hadn't heard of before. I have ran Postfix to do domain-wide email forwarding (to Gmail coincidentally) but going the other way around and having the end destination be self hosted is on my to-do list.

We're thrilled to announce the release of Stalwart Mail Server version 0.7.0, a significant update that brings a wealth of features and improvements to enhance the performance and manageability of your email services. This release marks a pivotal moment in our journey to provide an email server solution that combines ease of use with robust performance, ensuring that your email infrastructure is both secure and efficient.

Also take a look at Stalwart: https://github.com/stalwartlabs/mail-server

I haven't used it, but have used some of the sub-crates for some email-parsing problems, and it worked great.

Yes, still using Maddy + Dovecot + Rspamd and everything works fine, but I've been thinking about trying out https://stalw.art/ to be able to try out the new JMAP protocol that is intended to replace IMAP.

Check our https://stalw.art

Just wanted to share that we rolled out a Spam & Phishing Filter in the latest release of Stalwart Mail Server.

Excited to announce that Encryption at Rest has just been added to the open source Stalwart Mail Server. With this addition, the mail server will now automatically encrypt all incoming plaintext emails, utilizing either OpenPGP or S/MIME, before they are written to disk. Importantly, the keys are owned and controlled by the end user, ensuring that not even system administrators can decrypt these messages. More details available in the documentation.

What makes you say the protocol is different for each provider?

I maintain a proxy that transparently adds support for OAuth 2.0 support to IMAP/POP/SMTP clients (https://github.com/simonrob/email-oauth2-proxy), and for normal use it doesn’t need to know anything about which service it is connecting to. Apart from advanced features such as CCG or ROPCG which are mostly O365 only, what is different?

When it became clear many major email providers were going to require OAuth for IMAP/POP/SMTP access, I was pretty frustrated that I’d have to stop using clients/scripts that didn’t support this method.

Rather than spending lots of effort on migration, or switching clients entirely, I made a local proxy so that any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.

If you are not familiar with Email OAuth 2.0 Proxy by Simonrob, I would recommend you check it out. Star the repo or whatever you normally do. I wanted to acknowledge his repository because my work is built directly off what he maintains and creates.

https://github.com/simonrob/email-oauth2-proxy

"Just works" I run it with mbsync at the command line.

You do need a client id and some interaction with your O365 admin.

One potential solution I found is a proxy. Are you able to utilize an app password for this task?

You do still need details for an authorised client, but it’s possible to use those of one that’s already approved. See the readme section that explains this aspect: https://github.com/simonrob/email-oauth2-proxy#oauth-20-clie...

If you use this proxy of mine then any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy

maybe you can use https://github.com/simonrob/email-oauth2-proxy while you wait for official oauth2 support but I wonder why you are using another email server if you already have exchange online