Cloudron Forum

@girish
Unfortunately, I don't know how to find out... but I'll keep an eye on it and update when I find out! Thanks!

@girish
Yep, there have been a number of commits on it in the past 2 months, but this one is the one that changed the header "From" field:

https://github.com/souramoo/commentoplusplus/commit/81ff377f419c9bb853418e76fe9754bea1ad8101

I'm not sure this would fix it, but previously, the code had this:

headers["From"] = "Commento <" + from.String() + ">"

Which led to our FROM address populating like

Commento <<cloudron.app@ourdomain.com>>

And the code removes that portion in the latest commits.

Do you think the changes would fix this issue? I also wasn't sure if something about Cloudron input the email address with the brackets when the Commento app does not expect it (hence why it adds it), leading to the double brackets. I don't have a non-Cloudron installation of Commento to know for sure.

Thanks again!

Ah, I just saw the new commits on the commento++ repository and it looks like they have fixed it. The previous file smtp_send.go seemed to add the brackets and cause issues, but the new formatting is simplified and should work.

I assume there is no easy way to bring in these changes to my Cloudron instance beyond simply waiting for the next update?

Thanks!

@girish Thanks for the update on this! I just updated to the latest Commento++, and tested the Amazon SES credentials and it continued to fail on outbound email notifications. PurelyMail's SMTP still works. Do you think this would be able to be addressed with Commento++, being this one is actively managed? Thanks again!

EDIT: The double bracket problem listed above still occurs. I did notice if i bring it in Gmail, it has a slightly different output in the header.

As before, in Roundcube:

From: Commento <<commento.app@mydomain.com>>
To: My Name <<me@mydomain.com>>

And then if I pick up the email in Gmail, the headers show like this:

From: "Commento <>" <commento.app@mydomain.com>
To: "My Name <>" <me@mydomain.com>

@girish
So I tested it with Amazon SES relay and then with a different SMTP server (PurelyMail's). It works with PurelyMail's but not with Amazon SES. The error message refers to the '<' character.

So now, looking at emails sent to me using the working SMTP server, I am noticing that Commento's app does something different with the headers:

Here's a typical test email header sent from the Cloudron email settings page:

From: Cloudron <no-reply@mydomain.com>
To: me@mydomain.com

Here's one sent from Commento's app. Note that this is the one that I received via PurelyMail's SMTP server. This would have failed with Amazon SES:

From: Commento <<commento.app@mydomain.com>>
To: Joe Smith <<me@mydomain.com>>

I swapped out the domain to mydomain.com. But notice that Commento has the extra brackets, and whereas PurelyMail's SMTP server handles it fine, Amazon SES chokes on it. Is this something in Cloudron's implementation of Commento that adds this?

Thanks for taking a look!

I have the same problem, and the fundamental reason, I believe is that emails don't work for Commento with the SMTP relay I am using (Amazon SES). I can't use SMTP directly due to unavailable outbound port.

My workaround (for registration only!) is to enable the email on the Cloudron server and set a catchall.

When you register for Commento, it won't work, but you will get an undeliverable message sent from commento.app@yourdomain.com. And then you will receive the bounce message at your catchall. Then you can register.

However, admin/moderator emails will not work after that... but at least you can register and get it to work. But after that, no notification emails will work. I wonder if there is a fix for this? Looking at the log, I see the following:

"554 Transaction failed: Missing '<'"

I am currently using the Cloudron mail server for incoming mail and set the outgoing SMTP to use Amazon SES. It works very well, and the SPF, DKIM, and DMARC settings are all working.

When checking headers on mail sent from my domain (through SES), I notice the following:

• 2 dkim=pass results. Both of these match headers of the Amazon DKIM CNAME records (Amazon provides 3 of them, and it always checks 2 of them).
• 1 dim=fail result for the cloudron header, which was initially set when first setting up the email server (before adding the external relay).

I attempted removing the cloudron header DKIM TXT record, and it resulted in a dkim temporary error as it was still expecting a signed DKIM result.

The emails are getting delivered just fine (including to Google and Microsoft accounts), so I think the settings aren't hurting anything.

But I'm wondering what the best setting is when choosing to use the DKIM records for the external relay? After setting it up, I noticed the Cloudron docs for Amazon SES suggests not using the DKIM settings for AWS and to simply rely on the Cloudron ones. However, I don't remember that being an option when I initially set up my domain in AWS SES.

Thanks!