Inbox integration

[nebulon]

Ok so the transactional emails are now working like password reset. And upon further investigation, this is independent from the inbox integration, which is now left to the user as those seem to be using the API integrations with providers like sendgrid/postmark/...
So those make sense to not be integrated with the Cloudron email addons.

[v_shnu]

@nebulon @girish IMAP is not supported yet but it's being worked on at the moment. The email inbox setup is needed only if the user wishes to use email via Chatwoot. Regular notifications and other transactional email alerts should work with the basic SMTP setup.

For transaction/notification emails --> https://www.chatwoot.com/docs/self-hosted/configuration/environment-variables#configure-emails

For Email Channel/ Email Continuity/Email Inbox --> https://www.chatwoot.com/docs/self-hosted/configuration/features/email-channel/conversation-continuity

[mtd-sales]

@nebulon Exactly. So Chatwoot basically expects another Relay to receive and parse an e-mail and forward the parsed json result to chatwoots' webhook. This seems to be using of RoR "Action Mailbox Basics" in the background.

Since Cloudron has a build-in mail server, I was wondering if it is possible to facilitate this functionality here. I couldn't quite figure out what cloudron uses. For outbound, you seem to be using Haraka, or is it for both?

[andreasdueren]

@mtd-sales What an odd way to integrate incoming emails… Are there plans to integrate the built in mail server?

[sparkwise]

@nebulon We recently set up Chatwoot, and it's been great so far!

The work to support the IMAP Email Channel that was discussed in this thread has since been finished and released. I was able to configure an Email Channel with IMAP and SMTP details using a Google account, so presumably this could work with Cloudron email now, too. This allowed me to set up a dedicated email address for Chatwoot-based support.

The one piece that I wasn't able to get configured fully was the "conversation continuity" discussed above. I'm still seeing the "Forward to Email" address provided by Chatwoot as xxxxxxxx@false. It's not clear to me if some configuration with Cloudron Email (for the inbound email service) might address this, but it seems worth revisiting now that the IMAP integration is in place.

[nebulon]

I have looked into this and the situation is, that one can use Cloudron mailboxes fine, just like in other apps like FreeScout. What is not working are those generated mail addresses like dd22584d6eb7d5414ad83b2ecb2607b9@nebulon.space (currently the app shows @false, but that can be changed with setting MAILER_INBOUND_EMAIL_DOMAIN=${CLOUDRON_MAIL_DOMAIN}) this address though is not handled by Cloudron, so it does not lead to anything also chatwoot requires some daemon to listen on those mailboxes to fetch regularily, as explained in https://www.chatwoot.com/docs/self-hosted/configuration/features/email-channel/conversation-continuity#imap-via-getmail

It is unclear now what we should do on the package side. Generally since the other features work fine for inboxes in chatwoot, maybe we can ignore this?

[girish]

What is the goal/purpose of these auto-generated addresses ? Mail servers won't route random addresses anyway, so what does it mean to generate addresses ?

[robi]

@girish it's usually to track a specific thread or customer conversation.

wouldn't chatwoot+dd22584d6eb7d5414ad83b2ecb2607b9@domain.com be a better option to tag a specific email for further processing?

[sparkwise]

@nebulon Thank you for pointing out that setting MAILER_INBOUND_EMAIL_DOMAIN changes the @false email address. In digging in a bit deeper, I do think it may make sense to ignore this. The IMAP Email Channel does works, which would presumably be compatible with Cloudron Email. The forwarding address seems to enable automatically matching and connecting incoming emails to pre-existing conversation threads. This is nice but not strictly necessary.

[micmc]

@sparkwise

This is nice but not strictly necessary.

It is very nice indeed but being necessary or not is relative to how much features one wants to make life easier and getting nearer to what's offered by Big techs and SaaS in the like.

So, if that specific function can be fixed for that app I'd say it should be. Of course nothing is absolute lol