Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quarantine option for relayed domains (Relay this domain + Relay all recipients) #5325

Open
expertaz-zz opened this issue Jul 22, 2023 · 3 comments

Comments

@expertaz-zz
Copy link

Summary

Just now quarantine option working only for local mailboxes.
There are options on E'mail>Configuration>Domain:
Relay this domain + Relay all recipients .
When adding Relayed domain to mailcow, quarantine option not working for mailboxes of relayed domains.
Is it possible make it working for relayed domain mailboxes also?

Motivation

Just now mailcow has Relay this domain and Relay all recipients options.
It will be very userfull having quarantine option for mailboxes of relayed domains.

Additional context

data/conf/rspamd/meta_exporter/pipe.php

@pquan
Copy link

pquan commented Jan 8, 2025

I must chime in, with this request too.

There's a use case for using mailcow dockerized as an antispam solution and relaying the mails to another mailserver.

The administrator of the mailcow domain can be notified of quarantined items via the currently available "redirect notify" and "bcc-notify" options of quarantine and could manage the quarantine for all users of the domain.

+1

Digging further, in the pipe.php code, around line 131 we have the loop trying to figure out who are the final recipients for each mail. The loop terminates without saving the quarantined mail because there are no "local" recipient for a relayed domain.

Grepping the php-fpm-mailcow container log for "RCPT RESOVLER" (note the typo in the code), we get an unexpected return code error on each mail that is to be quarantined but that is not local. This is to be expected.

Here's the relevant code, around line 207:

      // Force exit if loop cannot be solved
      // Postfix does not allow for alias loops, so this should never happen.
      $loop_c++;
      error_log("RCPT RESOVLER: http pipe: goto array count on loop #". $loop_c . " is " . count($gotos_array) . PHP_EOL);

The "error_log" will (I think) terminate the php with a 505 error and log it.

Now, for the fix, it could be "patched" by simply adding a default recipient to all mails, say the administrator. This would insert the quarantined mail to the administrator user. However, I'm not sure what will happen when said administrator user "releases" the mail from quarantine. Will it be delivered to him, or will it be delivered to all final recipients ? To be tested.

Another proposed solution might be to just quarantine the mail for all local domains, regardless if the mailbox exists or not. Skip all the "goto" stuff and just give the administrator access to all quarantined mails. This could be a switch in the Quarantine configuration: Either drill down to the user mailboxes and give them access OR administrator-handled quarantine where only the admin users are entitled to quarantine handling.

Could this be implemented?

@0csic
Copy link

0csic commented Jan 31, 2025

I would like to have this feature as well, but would also like to not be forced defining an administrator for the quarantine!? Why not still have the option to use it with the mailbox-owner itself? Mailcow is allowed to send mails to the same mailbox even if it's forwarded, should be no issue then!?

I tried using mailcow as a forwarder for an already existing mailserver which is integrated in my hosting-platform and do not want to split this to keep most parts managed on one system, but to be honest: I hoped for this feature to work already with forwarding mailboxes as well - which it's not (at the moment).

So +1 not only for the general feature using a domain-wide admin for the quarantine, but also for the mailbox-users themself :)

@pquan
Copy link

pquan commented Jan 31, 2025

@0csic you can't have users on mailcow as they are not defined in mailcow. Unless you want to write the code to connect mailcow to your provider hosting.

What this patch does, is insert the mail in the quarantine database under the mail address of the final recipient. In theory, after it is inserted, mailcow COULD authenticate against an external pop3/imap server and it COULD show the quarantine to the authenticated user, in ADDITION to the domain admin who always has access to quarantined mail.

However, patches must be fed upstream in small chunks to be accepted. Give Lunuss more than 100 lines of code and he will reject it in the kernel. Here the same logic applies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants