IP address is determined incorrectly

[link2xt]

Maybe we should not try to determine IP address at all?

Here LAN address was determined by the script: https://support.delta.chat/t/how-to-handle-private-ip-and-missing-ipv6-in-dns-configuration-for-chatmail-deployment-on-oci-cloud/3173

A records are set up already anyway since SSH is working. IPv6 should be optional.

PTR record checks we can drop completely I think, this practice of checking PTR records is even worse than DMARC itself and we should stop encouraging it: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-reverse-mapping-considerations-06

[hpk42]

how about we check

• at start of 'run' serverside via socket.getaddrinfo(mail_domain", None, socket.AF_INET*) if we can resolve ipv4 and/or ipv6 address and bail out if not.
• at end of 'run' the reverse PTR records and give an interoperability warning if they don't resolve correctly but exitcode remains 0

[link2xt]

at start of 'run' serverside via socket.getaddrinfo(mail_domain", None, socket.AF_INET*) if we can resolve ipv4 and/or ipv6 address and bail out if not.

This is better checked by running the tests against the mail server to ensure we can actually connect to SMTP and IMAP. By resolving A and AAAA records (and it is better done with dig than getaddrinfo) we will get some IPs, but how do we know there is our server behind these IPs?

This is not part of the issue anyway, issue is about reverse DNS and PTR records.

at end of 'run' the reverse PTR records and give an interoperability warning if they don't resolve correctly but exitcode remains 0

This warning will be annoying if you never set this PTR record.

Even with Mailgun it is optional. They can get dedicated IP and ask you to add it into zonefile so it resolves both ways, but even they don't require it.

[hpk42]

as you wrote the issue, it's not just reverse-dns but also about ip-address detection, no?

[link2xt]

For A and AAAA records, maybe we should replace them with tests that try to connect over IPv4 and IPv6 after setting up the server, and if this works, then these records are ok. Checking A and AAAA against local address is not always correct.

[hpk42]

348 removed the need for reverse PTR, and there is no attempt to automaticlaly detect A AAAA records (which are required to be set now).