Support for any imap server

[Jak2k]

I would like to use inbox-zero with my own mail-server. Most clients like K-9, Thunderbird or Nextcloud Mail support automatic setup for that case too.

[riordan]

IMAP would be incredible, as it would open this up to nearly all other email services, however if there are aspects of the IMAP API that make it difficult to implement, you might want to consider looking at JMAP, a newer protocol that's closer to the modern Google Gmail API in terms of its capabilities, doing things like better server-side indexing, handling of labels, etc. Not many providers are yet, but it'd be a surefire way to get Fastmail users enthusiastically adopting it.

[elie222]

IMAP would be incredible, as it would open this up to nearly all other email services, however if there are aspects of the IMAP API that make it difficult to implement, you might want to consider looking at JMAP, a newer protocol that's closer to the modern Google Gmail API in terms of its capabilities, doing things like better server-side indexing, handling of labels, etc. Not many providers are yet, but it'd be a surefilre way to get Fastmail users enthusiastically adopting it.

Thanks for sharing! It seems like few providers support JMAP right now. Do you know which email providers do? May make more sense to stick with IMAP till we get that mainstream adoption.

[elie222]

Let's put this on hold. It's a really big feature. Changes so much of the app till we can support this :(

[joeyfigaro]

I know you guys just decided to pause on this, but I'd like to add my voice to the request. I broke up with Gmail a long time ago and have been missing out on so many good tools as a result. It's something I'd be very open to contributing to if you guys are open/prepared for contributors.

[elie222]

I know you guys just decided to pause on this, but I'd like to add my voice to the request. I broke up with Gmail a long time ago and have been missing out on so many good tools as a result. It's something I'd be very open to contributing to if you guys are open/prepared for contributors.

Hey, open to this feature being implemented if it's broken down into smaller pieces. Starting with a small POC and moving on to a full implementation.

What we'd need:

• Ability to login with email/password
• A lot of the gmail functionality is in the utils/gmail folder, but not all of it. Probably moving all gmail calls to this folder would make sense. And it could even become its own package in our Turborepo.
• Abstracting all the gmail functions so that when we do something like getThreads(), it doesn't matter whether it's getting the data from Gmail or iMap.

What I'd imagine a POC to do:

1. Choose one screen where we display emails. eg. the newsletter screen
2. Replace getThreads() with a generic getThreads that can pull from an imap.
3. Hopefully this still shows the same emails once implemented.
4. No need to update log in screen at this first stage of POC. Can just hardcode / use env vars to set the imap username and password.

Might be worth opening a test gmail account, and using imap on that just to make sure we're getting the same data back.

Challenges

Things won't map 1:1 with Gmail API, so we'd have to figure out how to handle the differences. Might also be slowness if we use imap without caching email data, but we don't need to optimise for this at this stage. Can figure that out later.

Also worth a look:

https://github.com/postalsys/emailengine "Headless email client application that makes IMAP and SMTP resources available over REST."

[joeyfigaro]

I know you guys just decided to pause on this, but I'd like to add my voice to the request. I broke up with Gmail a long time ago and have been missing out on so many good tools as a result. It's something I'd be very open to contributing to if you guys are open/prepared for contributors.

Hey, open to this feature being implemented if it's broken down into smaller pieces. Starting with a small POC and moving on to a full implementation.

What we'd need:

• Ability to login with email/password
• A lot of the gmail functionality is in the utils/gmail folder, but not all of it. Probably moving all gmail calls to this folder would make sense. And it could even become its own package in our Turborepo.
• Abstracting all the gmail functions so that when we do something like getThreads(), it doesn't matter whether it's getting the data from Gmail or iMap.

What I'd imagine a POC to do:

1. Choose one screen where we display emails. eg. the newsletter screen
2. Replace getThreads() with a generic getThreads that can pull from an imap.
3. Hopefully this still shows the same emails once implemented.
4. No need to update log in screen at this first stage of POC. Can just hardcode / use env vars to set the imap username and password.

Might be worth opening a test gmail account, and using imap on that just to make sure we're getting the same data back.

Challenges

Things won't map 1:1 with Gmail API, so we'd have to figure out how to handle the differences. Might also be slowness if we use imap without caching email data, but we don't need to optimise for this at this stage. Can figure that out later.

Also worth a look:

https://github.com/postalsys/emailengine "Headless email client application that makes IMAP and SMTP resources available over REST."

I'm going to start getting comfortable with the codebase and taking a look at putting something together if there's anything else you'd like to share–or if you have a preferred process for checking in on progress so I don't get too far out in a wrong direction. 💪🏻

[DarkPhyber-hg]

I self host exchange. While IMAP is more universal, how hard would it be to support activesync or OWA? Wondering of it's closer to Gmail api

[joeyfigaro]

I've started pulling what currently exists into Figma for us to use in planning how this feature will work. I'll be drafting some ideas to highlight how onboarding and initial configuration will work.

Inbox Zero/Onboarding (Figma)

[elie222]

I've started pulling what currently exists into Figma for us to use in planning how this feature will work. I'll be drafting some ideas to highlight how onboarding and initial configuration will work.

Inbox Zero/Onboarding (Figma)

Very cool!