@vjvanjungg Let me read up on what config is required and get back here.

@NCKNE Which app did you use the sieve filters in. Often, the filter in one app is not visible in another! The sieve filters are located at /home/yellowtent/boxdata/mail/vmail/<mailbox>/sieve. Can you check if they are there on the filesystem atleast?

@girish Okay. Would be nice to see in the future! E.g. "Ignore PTR".

This appears to be a case of https://forum.cloudron.io/post/6533 . Applying the linked setting change fixed the issue.

@jensbee4 If you have reason to believe this is legitimate email that is getting dropped, can you please send me the IP address to support@cloudron.io. It looks like that server is mis-configured

Are you hosting a custom domain on mailbox.org or do you have a @mailbox.org address? If it's the latter, mailbox is then not really an email relay. Generally, email relays are able to forward all addresses of a domain i.e anything@cloudrondomain.tld.

@rfg You have to setup a mail relay for your outbound mails. The big cloud providers like aws, gce, azure will all block emails from VMs directly. See https://cloudron.io/documentation/email/#relay-outbound-mails

@hendrikvl said in sender rewriting when using external SMTP: And no, my mail relay does not accept IP whitelisting. It's not a proper mail relay service to be exact, but just a regular mail service with outgoing smtp for authenticated users. Ah yes, someone was trying to do this with a gmail account as well sometime back (and more recently with a mailbox.org account). I think we have to implement this feature in Cloudron to make this use case work.

thanks for the explanations. I have already contacted digital ocean requesting the release of port 25. at first, strangely, they claimed that there is no output block on port 25 (although I did the test with the command 'telnet' in the cli).

To explain...: When you add a domain in Cloudron, you are just adding a domain for installing apps under that domain. The only DNS configuration it will do is to fix up the SPF record so that Cloudron can send mail on behalf of that domain (it adds itself to an existing SPF record). So, if you install say gitlab, gitlab can send mail to you. When you go to Email -> Enable Incoming mail, at that point, Cloudron will start receiving incoming email for that domain. It will setup DKIM/MX/DMARC records as well at this point. You can send/receive email without any of the webmail apps (rainloop, roundcube) installed. The webmail apps are really just frontends just like thunderbird or your android/ios mail client. On Cloudron, we pre-configure these apps to work only with Cloudron email. We could make a package that does not do this but that use case is quite rare because most email providers have their own web ui anyway. I think @necrevistonnezr just wants to add a domain into rainloop. This is the equivalent of adding an account in thunderbird. It has no effect on Cloudron mail server whatsoever.

@JOduMonT Currently, the 'email is not configured properly' notification is updated every 30 minutes. So, it's very much possible that those email settings are fine now and that notification will go away after 30 minutes. If you click on the notification, it should expand to give information on what exactly is not setup properly. Can you tell me what you see if you click the notification ? Also, zen.spamhaus.org being disabled is not good! Do you have a custom DNS setup by any chance? Under system -> services, is unbound running OK?

@girish WOrked like a charm, thanks!

Hi @girish , I see, it seems to be that indeed. The server runs on Upcloud actually. I will try one of the solution you propose. Many thanks for your help, d

Indeed, @subven is correct. Cloudron does not support POP3. I wasn't aware of this gmail feature. What does it do? Pull all email into gmail periodically? Very cool actually. Does it allow you to reply with that email id as well?

@girish Just wanted to say that this resolved the issue. Thank you! So to clarify, this was not a Cloudron issue but a simple DNS issue for the SPF records.

For the TLS, it is safe without TLS because the connection from mautic to the mail server is entirely internal to the server. For the other issues, we have to investigate.

@jasonh Ah got it. It looks like adding sender_bcc/recipient_bcc is quite doable. Cloudron uses haraka internally and not postfix and this feature is not available out of the box. We will look into adding this. I will reach out to you by email to double check some of the finer details.

@d19dotca This is fixed in 4.3 (will be released in the coming days)

@subven Have you read https://docs.microsoft.com/en-us/office365/securitycompliance/use-the-delist-portal-to-remove-yourself-from-the-office-365-blocked-senders-lis ? You should be able to get your specific IP delisted.

Looks like it was in fact getting sent to the catchall. Thanks everyone for your input.