Open kiriakos opened 3 months ago
Please try to add the host as Forwarding Host under System -> Configuration -> Options -> Forwarding Hosts
Please try to add the host as Forwarding Host under
System -> Configuration -> Options -> Forwarding Hosts
Is this the nominal way? should this then be also added to the docs in Unauthenticated Relaying?
As the postfix part goes over the config files, it feels a bit unnatural to do the rspamd part over content (in the UI which presumably gets stored in a DB).
The same issue happening to me...
It worked fine before the latest update. After V.[2024-04] it fails.
It doesn't respect mynetworks
anymore at /opt/mailcow-dockerized/data/conf/postfix/extra.cf
but when adding IPv4/IPv6 at System -> Configuration -> Options -> Forwarding Hosts
it seems to send the mail NOT REJECTING
but put it on SPAM FOLDER
@FreddleSpl0it Is this the right way to do that?
Getting the same issue here as well, since updating. It's stopping some of my Linux postfix hosts from relaying emails.
I edited data/conf/rspamd/custom/ip_wl.map
and added my IP range example 192.168.0.0/24, which has fixed the issue for now. Until a proper fix is done
@FreddleSpl0it In my case, emails sent from a local unauthenticated server failed severely;
For now I've updated the ./data/conf/rspamd/custom/ip_wl.map
as indicated above to include the permitted local subnets. However, this behavior was not present after the 2024-02 update and introduced recently. The past behavior still scanned the messages, which is fine and welcome, in case a server should go rogue.
Is this change a bug or there was specific reasoning behind it?
Edit: The other option is to comment out the line from the change (line 9 at https://github.com/mailcow/mailcow-dockerized/commit/75550eeea38badeb13d9198b9acedcbf132f3cb4#diff-8e0b9a448923c546d504adad891c8b76eccfe8024cb0aff1d2425845fb7d054dR9) . This seems to bring back the old behavior unless there's some side effects to be aware of?
This is not a bug. We got a report that outgoing spam filtering was skipped for every mail that was send unauthenticated from a private network. To fix this default behaviour we have set https://github.com/mailcow/mailcow-dockerized/pull/5812.
For everyone who is using unauthenticated relaying as described here https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-unauthenticated-relaying/, try to set local_addrs
in data/conf/rspamd/local.d/options.inc
to the same value as mynetworks
in postfix extra.cf
and then restart rspamd.
For example to enable unauthenticated relaying for 192.168.2.0/24
local_addrs = [127.0.0.0/8, ::ffff:127.0.0.0/104, ::1/128, fe80::/10, 172.22.1.0/24, fd4d:6169:6c63:6f77::/64, 192.168.2.0/24]
If this works i will update the documentation.
@FreddleSpl0it Thank you for the explanation.
The above does indeed work. Is a ';' needed at the end of the line?
What happens to the /etc/rspamd/custom/mailcow_networks.map content?
Perhaps a more automated fix would be to update line 24 of https://github.com/mailcow/mailcow-dockerized/blob/master/data/Dockerfiles/rspamd/docker-entrypoint.sh to pass the contents of mynetworks
from the postfix extra.cf
file to mailcow_networks.map
?
The ;
is necessary for the configuration. The file /etc/rspamd/custom/mailcow_networks.map
remains in the directory but will not be used for the local_addrs
option anymore. This file contains mailcow's IPv4 and IPv6 networks. However, if you want to configure unauthenticated relaying, you'll need to manually set this in local_addrs
as described in my example. The default IPv4 is 172.22.1.0/24
and IPv6 is fd4d:6169:6c63:6f77::/64
.
We could consider specifying additional networks in mailcow.conf
, rather than in extra.cf
and options.inc
to automate the process.
My 2ยข,
I know it will require some additional coding, but ultimately making that change in a single location (`mailcow.conf') would be a better solution in the long term and for troubleshooting.
Revisiting weeks/months later, unless one keeps good documentation, it will be long forgotten where the change(s) were made and will make support more challenging.
would I need to move IPV6 config from data/conf/postfix/extra.cf to data/conf/rspamd/local.d/options.inc to disable IPv6 in postfix-mailcow?
From this doc https://docs.mailcow.email/post_installation/firststeps-disable_ipv6/
smtp_address_preference = ipv4 inet_protocols = ipv4
Or is /opt/mailcow-dockerized/data/conf/postfix/extra.cf still the place for this? Just got the impression that the config in extra.cf is now ignored?
@ShaunGibbins With the modification of the local_addrs parameter in data/conf/rspamd/local.d/options.inc
, all it's doing is telling rspamd not enforce spam checking on unauthenticated mail traffic originating from those networks. If you're not using ipv6 then there's no need to add any local ipv6 addresses to the line. I would however still include them to save yourself headaches in the future if you should device to use ipv6 on the mail server.
You're not moving anything from postfix/extra.cf to the rspamd..../options.inc even if you're not using ipv6. Just make the changes outlined in the doc you linked for disabling ipv6.
Recall, postfix is the MTA, while rspamd is for spam control.
Just got the impression that the config in extra.cf is now ignored?
Why are you getting this impression?
Hello everyone! After a long search I came across this entry and was able to solve my problem, great :-)
I have another e-mail system behind mailcow which sends outgoing e-mails via mailcow (DKIM is performed by mailcow here).
If I now "deactivate" the SPAM check with the entry and then send an EICAR test virus, for example, it is recognized by rspamd but not blocked. Is there any way I can counteract this so that outgoing e-mails are still checked for certain values?
Unless I list the IP in the local_addrs, rspamd always recognizes the emails as external, which I would like to avoid with the unauthenticated internal relay. At least I would like to reject / block outgoing SPAM and viruses.
Any ideas?
Hi all,
I was able to fix this by adding my LAN in System -> Configuration -> Options -> Forwarding Hosts
On the other hand, I noticed that these emails were no longer signed by DKIM? (this is starting to cause problems with Gmail & co...)
If I've an email from SOGo, everything is OK, the email has the DKIM signature.
Anyone?
EDIT: I believe that in fact the emails which do not come from the 172.22 network of mailcow were never signed. I don't believe this problem is related to this issue... I will add an custom MTA.
@Rollbacke answer is: https://github.com/mailcow/mailcow-dockerized/issues/5826#issuecomment-2041952576
Anybody here can do PR to docs to add missing parts. Automate via env var passing one line in 2 places sounds overkill, nobody will die if go in 2 configs instead of one. If every mailserver settings will be in mailcow.conf, you will get them into holy fire, nobody could manage it.
Contribution guidelines
I've found a bug and checked that ...
Description
It looks like the change to
data/conf/rspamd/local.d/options.inc
in PR #5812 introduces a behavior that softfails mail from additional hosts on themynetworks
property of postfix.This can be circumvented by adding the hosts added to
mynetworks
also to themailcow_networks.map
but it isn't documented in Unauthenticated RelayingShould this happen automatically or is the documentation missing the added step?
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
x86
Operating System:
Archlinux
Server/VM specifications:
16GB, 8 Core
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
Xen
Docker version:
26.0.0
docker-compose version or docker compose version:
2.26.1
mailcow version:
2024-04-04_2309
Reverse proxy:
Nginx
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check: