nginx/front does not resolve IPv6 -> rspamd problems

[Niduroki]

Cause of problem found

Before you open your issue

• Check if no issue or pull-request for this already exists.
• Check documentation and FAQ. (Tip, use the search function on the documentation page)
• You understand Mailu is made by volunteers in their free time — be conscise, civil and accept that delays can occur.
• The title of the issue should be short and simple. It should contain specific terms related to the actual issue. Be specific while writing the title.

Environment & Versions

Environment

• docker-compose
• kubernetes
• docker swarm

Versions

[root@server mailu]# docker exec -it mailu-antispam-1 cat /version
1.9.20

Description

I recently enabled IPv6 on my server (following the FAQ steps of defining an IPv6 subnet, and enabling docker's ip6tables NATing).

/etc/docker/daemon.json

{
          "ipv6": true,
          "experimental": true,
          "fixed-cidr-v6": "fd00:dead:beef::/48",
          "ip6tables": true
}

It works, and IPv6 is used properly now. Instead of 192.168.190.1 in rspamd mails are received from - e.g. - 2607:f8b0:4864:20::746 (Google-Mail).

However in rspamd IPv6 PTR lookups seem to fail, meaning there's always going to be an added 2.5 spam points, via HFILTER_HOSTNAME_UNKNOWN to every mail that is delivered via IPv6.

HFILTER_HOSTNAME_UNKNOWN (2.5)
DMARC_POLICY_ALLOW (-0.5) [google.com,reject]
R_SPF_ALLOW (-0.2) [+ip6:2607:f8b0:4000::/36]
R_DKIM_ALLOW (-0.2) [google.com:s=20210112]
…

Curiosly, doing a nslookup in the rspamd container works, however:

[root@server mailu]# docker exec -it mailu-antispam-1 sh
/ # nslookup 2607:f8b0:4864:20::746 192.168.190.254
Server:         192.168.190.254
Address:        192.168.190.254:53

Non-authoritative answer:
6.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.ip6.arpa        name = mail-qk1-x746.google.com

/ # exit

Replication Steps

Send mail to mailu server, from an ipv6 enabled server (e.g. gmail).

Expected behaviour

PTR lookups work - no HFILTER_HOSTNAME_UNKNOWN for IPv6 addresses with a valid PTR entry.

Logs

logs

mailu-front-1     | 2022/02/27 14:25:29 [info] 11#11: *2056 client [2a00:1450:4864:20::535]:33682 connected to [::]:25
mailu-front-1     | 2022/02/27 14:25:29 [error] 11#11: *2056 "mail-ed1-x535.google.com" could not be resolved (3: Host not found) while in resolving client hostname, client: 2a00:1450:4864:20::535, server: [::]:25
mailu-front-1     | 2022/02/27 14:25:29 [info] 11#11: *2056 client logged in, client: 2a00:1450:4864:20::535 using starttls, server: [::]:25
mailu-antispam-1  | 2022-02-27 14:25:29 #7(rspamd_proxy) <22435d>; proxy; proxy_accept_socket: accepted milter connection from 192.168.190.7 port 41688
mailu-antispam-1  | 2022-02-27 14:25:29 #7(rspamd_proxy) <c542b3>; proxy; proxy_accept_socket: accepted milter connection from 192.168.190.7 port 41690
mailu-antispam-1  | 2022-02-27 14:25:29 #7(rspamd_proxy) <22435d>; milter; rspamd_milter_process_command: got connection from 192.168.190.3:60470
mailu-antispam-1  | 2022-02-27 14:25:29 #7(rspamd_proxy) <22435d>; proxy; proxy_milter_finish_handler: finished milter connection
mailu-antispam-1  | 2022-02-27 14:25:29 #7(rspamd_proxy) <c542b3>; milter; rspamd_milter_process_command: got connection from [2a00:1450:4864:20::535]:60470
mailu-antispam-1  | 2022-02-27 14:25:29 #7(rspamd_proxy) <c542b3>; proxy; rspamd_message_parse: loaded message; id: <[removed]@googlemail.com>; queue-id: <DD59B11941A>; size: 2796; checksum: <bba5f808b8e6ff085c4f3feea47eede1>
mailu-antispam-1  | 2022-02-27 14:25:30 #7(rspamd_proxy) <c542b3>; lua; once_received.lua:69: source hostname has not been passed to Rspamd from MTA, but we could resolve source IP address PTR 5.3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.ip6.arpa as "mail-ed1-x535.google.com"
mailu-antispam-1  | 2022-02-27 14:25:30 #7(rspamd_proxy) <c542b3>; proxy; dkim_module_key_handler: stored DKIM key for 20210112._domainkey.googlemail.com in LRU cache for 300 seconds, 1/2000 elements in the cache
mailu-antispam-1  | 2022-02-27 14:25:30 #7(rspamd_proxy) <c542b3>; proxy; rspamd_spf_maybe_return: stored record for googlemail.com (0xc6f0caade56f8346) in LRU cache for 300 seconds, 1/2000 elements in the cache
mailu-smtp-1      | 2022-02-27T14:25:29.850736+01:00 740b67e9fb8f postfix/smtpd[353]: connect from mailu-front-1.mailu_default[192.168.190.3]
mailu-smtp-1      | 2022-02-27T14:25:29.907025+01:00 740b67e9fb8f postfix/smtpd[353]: DD59B11941A: client=unknown[2a00:1450:4864:20::535]
mailu-smtp-1      | 2022-02-27T14:25:29.969103+01:00 740b67e9fb8f postfix/cleanup[763]: DD59B11941A: message-id=<[removed]@googlemail.com>
mailu-antispam-1  | 2022-02-27 14:25:30 #7(rspamd_proxy) <c542b3>; proxy; rspamd_symcache_finalize_item: slow rule: SEM_URIBL_FRESH15_UNKNOWN(261): 345.17 ms; enable slow timer delay
mailu-antispam-1  | 2022-02-27 14:25:30 #7(rspamd_proxy) <c542b3>; proxy; rspamd_symcache_finalize_item: slow rule: SEM_URIBL_UNKNOWN(273): 366.17 ms
mailu-antispam-1  | 2022-02-27 14:25:30 #7(rspamd_proxy) <c542b3>; proxy; rspamd_symcache_finalize_item: slow rule: URIBL_MULTI(257): 379.17 ms
mailu-front-1     | 2022/02/27 14:25:31 [info] 11#11: *2056 proxied session done, client: 2a00:1450:4864:20::535 using starttls, server: [::]:25
mailu-imap-1      | Feb 27 14:25:31 lmtp(489): Error: SSL context initialization failed, disabling SSL: Can't load SSL certificate (ssl_cert setting): The certificate is empty
mailu-imap-1      | Feb 27 14:25:31 lmtp(489): Info: Connect from 192.168.190.7
mailu-smtp-1      | 2022-02-27T14:25:31.250119+01:00 740b67e9fb8f postfix/qmgr[343]: DD59B11941A: from=<SRS0=yV4K=TK=googlemail.com=[removed]@[removed]>, size=3060, nrcpt=1 (queue active)
mailu-smtp-1      | 2022-02-27T14:25:31.322978+01:00 740b67e9fb8f postfix/smtpd[353]: disconnect from unknown[2a00:1450:4864:20::535] ehlo=2 xclient=0/1 mail=1 rcpt=1 data=1 quit=1 commands=6/7
mailu-antispam-1  | 2022-02-27 14:25:31 #7(rspamd_proxy) <c542b3>; proxy; rspamd_symcache_finalize_item: slow rule: RBL_NIXSPAM(263): 908.73 ms; enable slow timer delay
mailu-antispam-1  | 2022-02-27 14:25:31 #7(rspamd_proxy) <c542b3>; proxy; rspamd_redis_connected: skip obtaining bayes tokens for BAYES_HAM of classifier bayes: not enough learns 17; 200 required
mailu-antispam-1  | 2022-02-27 14:25:31 #7(rspamd_proxy) <c542b3>; proxy; rspamd_stat_classifiers_process: skip statistics as HAM class is missing
mailu-antispam-1  | 2022-02-27 14:25:31 #7(rspamd_proxy) <c542b3>; lua; greylist.lua:318: Score too low - skip greylisting
mailu-antispam-1  | 2022-02-27 14:25:31 #7(rspamd_proxy) <c542b3>; proxy; rspamd_task_write_log: id: <[removed]@googlemail.com>, qid: <DD59B11941A>, ip: 2a00:1450:4864:20::535, from: <[removed]@googlemail.com>, (default: F (no action): [1.91/20.00] [HFILTER_HOSTNAME_UNKNOWN(2.50){},DMARC_POLICY_ALLOW(-0.50){googlemail.com;quarantine;},R_MIXED_CHARSET(0.41){subject;},R_DKIM_ALLOW(-0.20){googlemail.com:s=20210112;},R_SPF_ALLOW(-0.20){+ip6:2a00:1450:4000::/36;},MIME_GOOD(-0.10){text/plain;},ARC_NA(0.00){},ARC_SIGNED(0.00){niduroki.net:s=dkim:i=1;},ASN(0.00){asn:15169, ipnet:2a00:1450::/32, country:US;},DKIM_TRACE(0.00){googlemail.com:+;},DWL_DNSWL_NONE(0.00){googlemail.com:dkim;},FREEMAIL_ENVFROM(0.00){googlemail.com;},FREEMAIL_FROM(0.00){googlemail.com;},FROM_EQ_ENVFROM(0.00){},FROM_HAS_DN(0.00){},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;},PREVIOUSLY_DELIVERED(0.00){[removed]@niduroki.net;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_THREE(0.00){3;},RCVD_IN_DNSWL_NONE(0.00){2a00:1450:4864:20::535:from;},RCVD_NO_TLS_LAST(0.00){},RCVD_VIA_SMTP_AUTH(0.00){},TO_DN_NONE(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 2796, time: 1237.310ms, dns req: 31, digest: <bba5f808b8e6ff085c4f3feea47eede1>, rcpts: <[removed]@niduroki.net>, mime_rcpts: <[removed]@niduroki.net>
mailu-antispam-1  | 2022-02-27 14:25:31 #7(rspamd_proxy) <c542b3>; proxy; rspamd_protocol_http_reply: regexp statistics: 0 pcre regexps scanned, 6 regexps matched, 176 regexps total, 73 regexps cached, 0B scanned using pcre, 1.35KiB scanned total
mailu-antispam-1  | 2022-02-27 14:25:31 #7(rspamd_proxy) <983f04>; proxy; proxy_milter_finish_handler: finished milter connection
mailu-smtp-1      | 2022-02-27T14:25:31.459238+01:00 740b67e9fb8f postfix/lmtp[765]: DD59B11941A: to=<[removed]@[removed]>, orig_to=<[removed]@niduroki.net>, relay=192.168.190.9[192.168.190.9]:2525, delay=1.6, delays=1.4/0.05/0.02/0.14, dsn=2.0.0, status=sent (250 2.0.0 <[removed]@[removed]> tWfLEst7G2LpAQAAxvTh+g Saved)
mailu-smtp-1      | 2022-02-27T14:25:31.460352+01:00 740b67e9fb8f postfix/qmgr[343]: DD59B11941A: removed
mailu-imap-1      | Feb 27 14:25:31 lmtp([removed]@[removed])<489><tWfLEst7G2LpAQAAxvTh+g>: Info: sieve: msgid=<[removed]@googlemail.com>: stored mail into mailbox 'INBOX'
mailu-imap-1      | Feb 27 14:25:31 lmtp(489): Info: Disconnect from 192.168.190.7: Logged out (state=READY)

Notable observation (regarding line 2 mail-ed1-x535.google.com could not be resolved, host not found):
mail-ed1-x535.google.com has no A record, just an AAAA record. Is this maybe related?
Edit: Unrelated, I have found other IPv6 addresses also with an A record, where this problem occurs, too.

Configuration

docker-compose.yml

version: '3.9'

services:

  # External dependencies
  redis:
    image: redis:alpine
    restart: always
    volumes:
      - "/home/mailu/redis:/data"
    depends_on:
      - resolver
    dns:
      - 192.168.190.254

  database: …
    
  # Core services
  front:
    image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}nginx:${MAILU_VERSION:-1.9}
    restart: always
    env_file: mailu.env
    logging:
      driver: json-file
    ports:
      - "25:25"
      - "465:465"
      - "587:587"
      - "110:110"
      - "995:995"
      - "143:143"
      - "993:993"
    volumes:
      - "/home/mailu/certs:/certs"
      - "/home/mailu/overrides/nginx:/overrides:ro"
    depends_on:
      - resolver
    dns:
      - 192.168.190.254
    networks:
      - default
      - nginx-proxy-net

  resolver:
    image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}unbound:${MAILU_VERSION:-1.9}
    env_file: mailu.env
    restart: always
    networks:
      default:
        ipv4_address: 192.168.190.254

  admin:
    image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}admin:${MAILU_VERSION:-1.9}
    restart: always
    env_file: mailu.env
    volumes:
      - "/home/mailu/data:/data"
      - "/home/mailu/dkim:/dkim"
    depends_on:
      - redis
      - resolver
    dns:
      - 192.168.190.254

  imap:
    image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}dovecot:${MAILU_VERSION:-1.9}
    restart: always
    env_file: mailu.env
    volumes:
      - "/home/mailu/mail:/mail"
      - "/home/mailu/overrides/dovecot:/overrides:ro"
    depends_on:
      - front
      - resolver
    dns:
      - 192.168.190.254

  smtp:
    image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}postfix:${MAILU_VERSION:-1.9}
    restart: always
    env_file: mailu.env
    volumes:
      - "/home/mailu/mailqueue:/queue"
      - "/home/mailu/overrides:/overrides:ro"
    depends_on:
      - front
      - resolver
    dns:
      - 192.168.190.254

  antispam:
    image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}rspamd:${MAILU_VERSION:-1.9}
    hostname: antispam
    restart: always
    env_file: mailu.env
    volumes:
      - "/home/mailu/filter:/var/lib/rspamd"
      - "/home/mailu/dkim:/dkim:ro"
      - "/home/mailu/overrides/rspamd:/etc/rspamd/override.d:ro"
    depends_on:
      - front
      - resolver
    dns:
      - 192.168.190.254

  # Optional services

  webdav: …

networks:
  default:
    enable_ipv6: true
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 192.168.190.0/24
        - subnet: fd9a:5a5b:35c1:beef::/64
  nginx-proxy-net:
    external: true
    name: nginx-proxy-net

mailu.env

###################################
# Common configuration variables
###################################

# Set to a randomly generated 16 bytes string
SECRET_KEY=[removed]

# Subnet of the docker network. This should not conflict with any networks to which your system is connected. (Internal and external!)
SUBNET=192.168.190.0/24
SUBNET6=fd9a:5a5b:35c1:beef::/64

# Main mail domain
DOMAIN=[removed]

# Hostnames for this server, separated with comas
HOSTNAMES=[removed]

# Postmaster local part (will append the main mail domain)
POSTMASTER=admin

# Choose how secure connections will behave (value: letsencrypt, cert, notls, mail, mail-letsencrypt)
TLS_FLAVOR=mail-letsencrypt

# Authentication rate limit (per source IP address)
AUTH_RATELIMIT_IP=60/hour 

# Authentication rate limit per user (regardless of the source-IP)
AUTH_RATELIMIT_USER=100/day

# Disable authentication ratelimit for this comma-separated network CIDRs (e.g. 0.0.0.0/0, ::/0 to disable it completely)
AUTH_RATELIIMIT_EXCEPTION=

# Opt-out of statistics, replace with "True" to opt out
DISABLE_STATISTICS=False

###################################
# Optional features
###################################

# Expose the admin interface (value: true, false)
ADMIN=true

# Choose which webmail to run if any (values: roundcube, rainloop, none)
WEBMAIL=none

# Dav server implementation (value: radicale, none)
WEBDAV=radicale

# Antivirus solution (value: clamav, none)
ANTIVIRUS=none

###################################
# Mail settings
###################################

# Message size limit in bytes
# Default: accept messages up to 50MB
# Max attachment size will be 33% smaller
MESSAGE_SIZE_LIMIT=50000000

# Message rate limit (per user)
MESSAGE_RATELIMIT=200/day

# Networks granted relay permissions
# Use this with care, all hosts in this networks will be able to send mail without authentication!
RELAYNETS=

# Will relay all outgoing mails if configured
RELAYHOST=

# Fetchmail delay
FETCHMAIL_DELAY=600

# Recipient delimiter, character used to delimiter localpart from custom address part
RECIPIENT_DELIMITER=+

# DMARC rua and ruf email
DMARC_RUA=dmarc-report
DMARC_RUF=dmarc-report

# Welcome email, enable and set a topic and body if you wish to send welcome
# emails to all users.
WELCOME=true
WELCOME_SUBJECT=Welcome to your new email account
WELCOME_BODY=Welcome to your new email account, if you can read this, then it is configured properly!

# Maildir Compression
# choose compression-method, default: none (value: bz2, gz)
COMPRESSION=gz
# change compression-level, default: 6 (value: 1-9)
COMPRESSION_LEVEL=1

# IMAP full-text search is enabled by default. Set the following variable to off in order to disable the feature.
FULL_TEXT_SEARCH=off

###################################
# Web settings
###################################

# Path to redirect / to
WEBROOT_REDIRECT=/admin

# Path to the admin interface if enabled
WEB_ADMIN=/admin

# Path to the webmail if enabled
WEB_WEBMAIL=

# Website name
SITENAME=[removed]

# Linked Website URL
WEBSITE=[removed]

###################################
# Advanced settings
###################################

# Log driver for front service. Possible values:
# json-file (default)
# journald (On systemd platforms, useful for Fail2Ban integration)
# syslog (Non systemd platforms, Fail2Ban integration. Disables `docker-compose log` for front!)
# LOG_DRIVER=json-file

# Docker-compose project name, this will prepended to containers names.
COMPOSE_PROJECT_NAME=mailu

# Number of rounds used by the password hashing scheme
CREDENTIAL_ROUNDS=12

# Header to take the real ip from
REAL_IP_HEADER=X-Real-IP

# IPs for nginx set_real_ip_from (CIDR list separated by commas)
REAL_IP_FROM=172.18.0.0/16

# Whether to not send ISG Root X1 in TLS handshakes. Incompatible with Android older than 7.1.1
LETSENCRYPT_SHORTCHAIN=True

# choose wether mailu bounces (no) or rejects (yes) mail when recipient is unknown (value: yes, no)
REJECT_UNLISTED_RECIPIENT=

# Log level threshold in start.py (value: CRITICAL, ERROR, WARNING, INFO, DEBUG, NOTSET)
LOG_LEVEL=WARNING

# Timezone for the Mailu containers. See this link for all possible values https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
TZ=Europe/Berlin

###################################
# Database settings
###################################
DB_FLAVOR=postgresql
DB_USER=[removed]
DB_PW=[removed]
DB_HOST=[removed]
DB_NAME=[removed]

POSTGRES_PASSWORD=[removed]

---

Can anybody even reproduce this, or is this some weird problem with my setup … Edit: It is not, see comment.
I just can't figure out how to debug this, any pointers in the right direction, if no one can reproduce this, would be greatly appreciated.

Thanks for your time!

[Niduroki]

Found the problem/fix:

nginx/front does not resolve IPv6 adresses because of core/nginx/conf/nginx.conf#L257:

resolver {{ RESOLVER }} ipv6=off valid=30s;

introduced by #1967 due to this (wrong? -b [::]:80 seems to listen to both ipv4 and ipv6 from my experience with gunicorn) comment on PR#1802.

I will try to check if changing admin to listen on [::] still works with IPv4, and if it still works fine in a normal non-ipv6 setup I'll create a PR for it (considering how stale this issue is).

[peterpramb]

The Rspamd web interface will also not be available via Admin when IPv6 is enabled, as the internal v6 subnet is not authorized.

• /conf/worker-controller.inc:
  secure_ip = "{{ POD_ADDRESS_RANGE or SUBNET }}";

[Niduroki]

Curiosly I didn't run into any problems, when testing rspamd access in my ipv6 enabled containers in #2272 - I will try to double check the logs though, if something seems amiss/is just gracefully failing.

[nextgens]

Odds are the hostname is looked up at startup... and cached forever... this may be why it appears to work (using v4).

I suggest you increase the verbosity of unbound and ensure that:

1. the lookups are made
2. they return results in a timely fashion

[nextgens]

I will try to check if changing admin to listen on [::] still works with IPv4, and if it still works fine in a normal non-ipv6 setup

Try with echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 on the host. Here it prevents the socket from being bound at all when "::" is used.

[Niduroki]

@peterpramb have you run into the rspamd web-interface problem yourself, or is this an observation through reading the code?

Whatever I tried I could not get access from nginx to rspamd to use IPv6, and had to resort to hard-coding the rspamd-container's IPv6 address into nginx's nginx.conf to test this scenario.
It works now, anyways. Progress in the related PR.

---

Same thing with more IPv4 testing, as suggested with net.ipv6.conf.all.disable_ipv6

[nextgens]

@Niduroki it's the "bind()" operation that fails: when the container is created; Try docker-compose down && docker-compose up -d

[peterpramb]

Yes, I hit it when I manually enabled IPv6 resolver support in Front, which produced multiple access exceptions in the Rspamd web interface when accessed via Admin.

But I should have mentioned that I'm not using Docker but Podman with dynamic name resolution using dnsname and used IPv6 right from the beginning, sorry for that.

[nextgens]

We've talked about IPv6 in our last developer meeting, the consensus was that it's hard to get right:

• requires an experimental feature that needs to be enabled on the host; Failure to have a recent enough version of docker will lead to silent (no firewalling -> open-relay) breakage.
• postfix/the SMTPd will start making v6 outbound connections with an address that's either not routable (SUBNET6 is supposed to be site-local) or doesn't have rDNS (not documented in any case)

Most of the functionality (being able to receive emails from IPv6 enabled hosts) can be implemented by tweaking the docker-compose & front: no v6 support is required elsewhere, begging the questions: is it worth it? Getting emails reliably delivered in inboxes over v4 is hard enough (deliverability).

[peterpramb]

Well, just my personal opinion (not sure if I was asked at all ;-):

Given that new IPv4 addresses are now only available on the free market to horrible prices and providers start to provide servers with IPv6 only, where you have to pay for IPv4 extra, it is probably not a good idea to stick to IPv4 alone.

[Niduroki]

@Niduroki it's the "bind()" operation that fails: when the container is created; Try docker-compose down && docker-compose up -d

I cannot reproduce that? Do you have any special configuration options, or are you using the standard setup.mailu.io docker-compose.yml (which is what I'm basically using, with minor changes, as seen in my related PR).

[root@mailtest mailu]# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
1
[root@mailtest mailu]# docker-compose down && docker-compose up -d
Stopping mailu_webmail_1  ... done
Stopping mailu_antispam_1 ... done
Stopping mailu_smtp_1     ... done
Stopping mailu_imap_1     ... done
Stopping mailu_admin_1    ... done
Stopping mailu_front_1    ... done
Stopping mailu_redis_1    ... done
Stopping mailu_resolver_1 ... done
Removing mailu_webmail_1  ... done
Removing mailu_antispam_1 ... done
Removing mailu_smtp_1     ... done
Removing mailu_imap_1     ... done
Removing mailu_admin_1    ... done
Removing mailu_front_1    ... done
Removing mailu_redis_1    ... done
Removing mailu_resolver_1 ... done
Removing network mailu_default
Creating network "mailu_default" with driver "bridge"
Creating mailu_resolver_1 ... done
Creating mailu_redis_1    ... done
Creating mailu_front_1    ... done
Creating mailu_admin_1    ... done
Creating mailu_antispam_1 ... done
Creating mailu_smtp_1     ... done
Creating mailu_imap_1     ... done
Creating mailu_webmail_1  ... done
[root@mailtest mailu]#

(fedora 35, docker/moby 20.10.12)

---

To be completely honest, I'm not too fussed about how the original problem, of fixing ipv6 rDNS lookups and the associated HFILTER_HOSTNAME_UNKNOWN, is fixed, if you have another solution.

If you think better IPv6 support is a WONTFIX (especially considering IPv4 shortages, like peterpramb mentioned) because of the associated problems, I guess I'd have to live with that however 🤷

Edit: If you are afraid of making people do stupid things, by misconfiguring their instances causing open-relays, or something, I don't really get the reason you have a IPv6 FAQ-section however. At least one that's more than: "Please don't!!"

[nextgens]

Well, just my personal opinion (not sure if I was asked at all ;-):

Given that new IPv4 addresses are now only available on the free market to horrible prices and providers start to provide servers with IPv6 only, where you have to pay for IPv4 extra, it is probably not a good idea to stick to IPv4 alone.

Rephrasing the above: there's very little work required to make Mailu v6-only compatible if you accept that the inner traffic will be v4 (using private address space). Add an AAAA record, configure docker to bind v6 sockets, let it do NAT to v4... and it should work.

On the other hand, getting SUBNET6 to work (the inner part of Mailu) is a significant undertaking relying on broken and immature technology (experimental stuff in docker, ... complex on other stacks too), where simple failures may lead to open-relays & all kind of bad things.

[nextgens]

@Niduroki it's the "bind()" operation that fails: when the container is created; Try docker-compose down && docker-compose up -d

I cannot reproduce that? Do you have any special configuration options, or are you using the standard setup.mailu.io docker-compose.yml (which is what I'm basically using, with minor changes, as seen in my related PR).

I use debian here, I suspect it's a kernel setting somewhere that's different.

To be completely honest, I'm not too fussed about how the original problem, of fixing ipv6 rDNS lookups and the associated HFILTER_HOSTNAME_UNKNOWN, is fixed, if you have another solution.

Other related projects seem to have run into the same issue: mailcow/mailcow-dockerized#3168 ... apparently it's a timeout "somewhere/sometimes"

If you think better IPv6 support is a WONTFIX (especially considering IPv4 shortages, like peterpramb mentioned) because of the associated problems, I guess I'd have to live with that however shrug

I'm not against better IPv6 support; The question is what kind of support and when.

I hear @peterpramb's usecase (scarcity of publically routable v6 addresses); I am not sure how practical running a v6-only mailserver is going to be for the foreseeable future but agree that it's important to eventually get there. In the meantime, work should probably be done to allow the operation of a dual-stack mailserver (to v6 enable SMTP(inbound)/IMAP/POP), that's easy to do and definitely worth it.

However, I am a lot more skeptical about the benefits of going further (enabling v6 outbound or like proposed here, dual-staking the internal network). Both because it's massively more complex but also because it's just not that useful (to me :p).

I guess we should relocate this discussion into a new ticket and discuss there the type of v6 support we want.

Edit: If you are afraid of making people do stupid things, by misconfiguring their instances causing open-relays, or something, I don't really get the reason you have a IPv6 FAQ-section however. At least one that's more than: "Please don't!!"

One of the things that was agreed was to get rid of the v6 option in setup; We will do that.

[peterpramb]

I really can't talk for Docker, but I just want to mention that for other stacks like Podman with native IPv6 support in their CNI there is no such separation between internal and external networks. When you want to publish IPv6 ports for Front then you need IPv6 on the Front container's internal network as well - netfilter won't magically translate (NAT) between IPv4 and IPv6. And then you have it automatically in all containers on that network.

Anyway, I understand the concerns. The only thing I really ask for is to make the ipv6 flag for the Nginx mail (!) resolver configurable, so that people don't have to manage the full nginx.conf template themself (and keep it up2date...) just for that single one line. That way Nginx still resolves all web related internal traffic with IPv4 only and nothing else in Mailu has to be modified at all, while it allows people to use IPv6 for mailing (on their own risk).

[peterpramb]

And please don't drop any existing support for SUBNET6 in the code, that would really be a step back.

[Niduroki]

@Niduroki it's the "bind()" operation that fails: when the container is created; Try docker-compose down && docker-compose up -d

I cannot reproduce that? Do you have any special configuration options, or are you using the standard setup.mailu.io docker-compose.yml (which is what I'm basically using, with minor changes, as seen in my related PR).

I use debian here, I suspect it's a kernel setting somewhere that's different.

Now I'm even more confused.

Shell Output on Debian

root@mailtest-debain:/home/mailu# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
1
root@mailtest-debain:/home/mailu# ping ::1
ping: connect: Cannot assign requested address
root@mailtest-debain:/home/mailu# cat /etc/os-release | grep Debian
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
root@mailtest-debain:/home/mailu# docker logs mailu_admin_1 | tail -n 4
[2022-03-14 13:04:54 +0000] [18] [INFO] Starting gunicorn 20.1.0
[2022-03-14 13:04:54 +0000] [18] [INFO] Listening at: http://[::]:80 (18)
[2022-03-14 13:04:54 +0000] [18] [INFO] Using worker: sync
[2022-03-14 13:04:54 +0000] [19] [INFO] Booting worker with pid: 19
root@mailtest-debain:/home/mailu# docker-compose down && docker-compose up -d
Stopping mailu_webmail_1  ... done
Stopping mailu_smtp_1     ... done
Stopping mailu_antispam_1 ... done
Stopping mailu_imap_1     ... done
Stopping mailu_admin_1    ... done
Stopping mailu_front_1    ... done
Stopping mailu_redis_1    ... done
Stopping mailu_resolver_1 ... done
Removing mailu_webmail_1  ... done
Removing mailu_smtp_1     ... done
Removing mailu_antispam_1 ... done
Removing mailu_imap_1     ... done
Removing mailu_admin_1    ... done
Removing mailu_front_1    ... done
Removing mailu_redis_1    ... done
Removing mailu_resolver_1 ... done
Removing network mailu_default
Creating network "mailu_default" with driver "bridge"
Creating mailu_resolver_1 ... done
Creating mailu_front_1    ... done
Creating mailu_redis_1    ... done
Creating mailu_admin_1    ... done
Creating mailu_smtp_1     ... done
Creating mailu_antispam_1 ... done
Creating mailu_imap_1     ... done
Creating mailu_webmail_1  ... done
root@mailtest-debain:/home/mailu# docker logs mailu_admin_1 | tail -n 4
[2022-03-14 13:05:56 +0000] [9] [INFO] Starting gunicorn 20.1.0
[2022-03-14 13:05:56 +0000] [9] [INFO] Listening at: http://[::]:80 (9)
[2022-03-14 13:05:56 +0000] [9] [INFO] Using worker: sync
[2022-03-14 13:05:56 +0000] [10] [INFO] Booting worker with pid: 10
root@mailtest-debain:/home/mailu# docker exec -it mailu_admin_1 sh
/app # ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.071 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.071/0.071/0.071 ms
/app # ping -c 1 ::1
PING ::1 (::1): 56 data bytes
ping: sendto: Address not available
/app # tail -n 9 /start.py 
start_command="".join([
    "gunicorn --threads ", str(os.cpu_count()),
    " -b [::]:80 ",
    "--access-logfile - " if (log.root.level<=log.INFO) else "",
    "--error-logfile - ",
    "--preload ",
    "'mailu:create_app()'"])

os.system(start_command)
/app #

Ignore me typo-ing debian for this throwaway, test-machine 👀

This definitely seems like a configuration issue. (Using configuration from #2272)

---

The only thing I really ask for is to make the ipv6 flag for the Nginx mail (!) resolver configurable, so that people don't have to manage the full nginx.conf template themself (and keep it up2date...) just for that single one line. That way Nginx still resolves all web related internal traffic with IPv4 only and nothing else in Mailu has to be modified at all, while it allows people to use IPv6 for mailing (on their own risk).

While I'm not 100% sure I think removing ipv6=off from the mail block from nginx.conf also seems to resolve the issue. It is definitely a hack, even more of a hack, if it's a hidden-ish override switch, but it seems to be a middle ground where this issue can be resolved (in a pretty bad way, but still), and IPv6 is still not "enabled"/encouraged.

Edit: (Maybe this should go in the other IPv6 ticket, though):
An alternative would be to enable all the stuff I have added in #2272 iff SUBNET6 is set? internal ipv6 support seems to be experimental and unsupported anyways?

[peterpramb]

It's complicated. ;-)

Nginx tries to lookup the client's hostname to forward the complete client info to Postfix using the XCLIENT command. Postfix calls Rspamd via milter protocol and passes the client info on, so when Rspamd sees a mismatch in client IP and hostname you get additional SPAM points.

With the current resolver configuration Nginx can't lookup IPv6 clients at all, so there is always a mismatch between client IP and hostname.

[nextgens]

I'll prepare a PR:

• review the "why" I've turned off v6 resolution in nginx; if it's not a concern anymore we can definitely merge that chunk
• remove mentions of v6 in setup

It should have minimum side effects (so that we can safely backport it); "better v6 support" should be a different ticket and I suggest that the rest of #2272 is discussed there.

[Niduroki]

Copy-pasting my comment from #2351 in here, too, for better visibility:

#2351 caused a regression:

This backport (uncertain if this also happens in master, haven't tested it), causes #2260 to happen with every mail (IPv4 and IPv6), thus adding 2.5 spam points to every mail, probably because nginx has no resolver to look up IPs with, thus always failing.

Adding back the removed line (resolver 127.0.0.11 valid=30s;) fixes/doesn't add the 2.5 points for me.