anghenfil
commented
1 year ago Seems like it's an open relay via IPv6. Any idea why?
Closed anghenfil closed 1 year ago
anghenfil
commented
1 year ago Seems like it's an open relay via IPv6. Any idea why?
anghenfil
commented
1 year ago I - at least temporary - fixed it by re-enabling the ipv6nat container. Seems like the migration to the intern docker ipv6nat caused the open relay
gthb96
commented
1 year ago Does it indicate an open relay here too? I am also running stock mailcow setup on latest version (IPv4/native IPv6) For me it says "not an open relay" and as far as I know mine is not sending spam.
anghenfil
commented
1 year ago If you used a web service to check the result's maybe wrong, the most common ones only check via ipv4 afaik.
I checked manually via telnet from my local computer:
telnet your.mailhost.com 25
Type EHLO mailhost.com, and then press Enter.
Type MAIL @.***>, and then press Enter.
Type RCPT @.***> and then press Enter.
Type DATA, and then press Enter.
Type Subject: Test and then press Enter.
Press Enter again.
A blank line is needed between the Subject: field and the message body.
Type This is a test message, and then press Enter.
Type a period ( . ), and then press Enter.
To disconnect from the SMTP server, type QUIT, and then press Enter.
Best anghenfil
Am 23. Mai 2023 19:34:00 MESZ schrieb gthb96 @.***>:
Does it indicate an open relay here too? I am also running stock mailcow setup on latest version (IPv4/native IPv6) For me it says "not an open relay" and as far as I know mine is not sending spam.
-- Reply to this email directly or view it on GitHub: https://github.com/mailcow/mailcow-dockerized/issues/5242#issuecomment-1559872830 You are receiving this because you authored the thread.
Message ID: @.***>
CrazyLinuxNerd
commented
1 year ago Just tested this on my mailcow, and:
Trying (ipv6)... Connected to (server). Escape character is '^]'. 220 (server) ESMTP Postcow ehlo (domain) 250-(server) 250-PIPELINING 250-SIZE 524288000 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 CHUNKING mail from: jake@(my domain server 1) 250 2.1.0 Ok rcpt to: jake@(my domain at another server) 554 5.7.1 <jake@(domain): Relay access denied quit 221 2.0.0 Bye`
gthb96
commented
1 year ago If you used a web service to check the result's maybe wrong, the most common ones only check via ipv4 afaik. I checked manually via telnet from my local computer: telnet your.mailhost.com 25 Type EHLO mailhost.com, and then press Enter. Type MAIL @.>, and then press Enter. Type RCPT @.> and then press Enter. Type DATA, and then press Enter. Type Subject: Test and then press Enter. Press Enter again. A blank line is needed between the Subject: field and the message body. Type This is a test message, and then press Enter. Type a period ( . ), and then press Enter. To disconnect from the SMTP server, type QUIT, and then press Enter. Best anghenfil Am 23. Mai 2023 19:34:00 MESZ schrieb gthb96 @.>: … Does it indicate an open relay here too? I am also running stock mailcow setup on latest version (IPv4/native IPv6) For me it says "not an open relay" and as far as I know mine is not sending spam. -- Reply to this email directly or view it on GitHub: #5242 (comment) You are receiving this because you authored the thread. Message ID: @.>
Yes, I wanted to know if the website also tells it. I believe it is open relay for you but I'm still curious if mxtoolbox recognizes it for IPv6
rpasing
commented
1 year ago I have the same issue using Mailcow on Arch Linux. It is actually a bug in the Docker package of Arch Linux, as far as my research has been going. I created both a bug report for Docker: https://github.com/moby/moby/issues/45459 and also a bug report for Arch Linux: https://bugs.archlinux.org/task/78506
As you see, the interest in those bug reports is until now non-existing. Maybe you can help raising the awareness. I do think though that it's not an error in Mailcow, it's a general error in the ip6tables creation of Docker under Arch Linux.
Edit: In addition to the information provided in those 2 bug reports, the problem why we have an open relay in Mailcow due to this is the following: If the ip6tables forwarding rules for port 25 are missing, then ip6 port 25 will still be reachable from the outside: The (partially) existing ip6tables rules do open the port, and then we have that userland Docker proxy running on the host, which by default is responsible for routing loopback-traffic into the containers. That docker-proxy will accept this outside connection, and forward it into the mailcow containers. From there, it will look like a connection from the host, and not from the outside anymore. And by default, mailcow accepts internal connections without authorization.
DerLinkman
commented
1 year ago You are using Archlinux as your Operating System.
As it seems to be a Docker on Arch Linux problem it's not a mailcow issue then.
Please report bugs for mailcow only on supported OS seen here: https://docs.mailcow.email/prerequisite/prerequisite-system/#supported-os as those are tested and supported by us directly.
As mentioned in this docs page other OS Systems might work but are not officially tested.
strowi
commented
6 months ago For anyone else stumbling here.. on a default docker-24.0.7 (Ubuntu) with IPv6 disabling the userland-proxy via /etc/docker/daemon.json -> { "userland-proxy": false } solved the problem.
Only got aware of this because of the *@qq.com" mails, most blacklist/open relay tests i tried still only tested ipv4.
Contribution guidelines
I've found a bug and checked that ...
Description
Logs:
Steps to reproduce:
Which branch are you using?
master
Operating System:
archlinux, Linux version 6.1.28-1-lts
Server/VM specifications:
126 GB RAM, 12 cores
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
none
Docker version:
23.0.6, build ef23cbc431
docker-compose version or docker compose version:
2.18.0
mailcow version:
2023-04b
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: