feat: support setup with only an IPv4 address, but no domain

[missytake]

replaces #894
fix #936

This is a slightly alternative approach to ipv4-only relays. It splits up mail_domain in 3 different possible config values:

• mail_domain: can be the domain of a relay, or 13.12.23.42: this is used for routing
• mail_domain_deliverable: can be the domain of a relay, or [13.12.23.42]: this is used in the email addresses
• mail_domain_hostname: can be the domain of a relay, or 42.23.12.13.in-addr.arpa: this is used as myhostname in postfix

todo:

• fix tests
• look up every usage of mail_domain and see whether it's correctly used
• let cmdeploy dns fail gracefully
• make cmdeploy status work
• document experimental IPv4-only setups
  • explain that strict TLS & DKIM checking is disabled for them
• make CI test IPv4-only setups with feat(cmdeploy): add --no-dns option for deploying & testing IPv4-only relays cmlxc#4

[j-g00da]

I'm not sure of benefits of this approach, do we need so much control over these?

[missytake]

I'm not sure of benefits of this approach, do we need so much control over these?

I think it's much less confusing in the long run, if we separate these different usages of mail_domain consistently. It only makes sense if there is IPv4-only CI though, so we can see if mail_domain_* is used wrongly somewhere.

[missytake]

The documentation linkchecker fails, but the internal link works (locally and in the staging documentation preview): https://staging.chatmail.at/doc/relay/919/getting_started.html

Any idea how we can link to pages in the same documentation in a way that the CI is happy?

edit: fixed

[dot-file]

Just tested it on my VPS. cmdeploy run worked fine, however I can't connect to other profiles. If it's two profiles on my own server it throws the 'This QR code has been reset' error and with other servers that have domain names it hangs on 'establishing connection'.

Also, is it possible to use an IP based TLS certificate?

[missytake]

Just tested it on my VPS. cmdeploy run worked fine, however I can't connect to other profiles. If it's two profiles on my own server it throws the 'This QR code has been reset' error and with other servers that have domain names it hangs on 'establishing connection'.

Have you previously deployed on the same VPS with a domain? Can you send me your IP so I can check myself?

Also, is it possible to use an IP based TLS certificate?

In many situations which we want to support that isn't possible (i.e. local IP addresses, IP addresses in areas where Let's Encrypt is blocked, ...)

[dot-file]

Have you previously deployed on the same VPS with a domain? Can you send me your IP so I can check myself?

I just tried deploying on a new VPS and it's the same result. Here's the IP: https://45.39.33.245/

In many situations which we want to support that isn't possible (i.e. local IP addresses, IP addresses in areas where Let's Encrypt is blocked, ...)

Sure, that's reasonable, but maybe there could be an option to use a certificate for situations where this is possible?

[missytake]

If it's two profiles on my own server it throws the 'This QR code has been reset' error

The "QR code has been reset error" appears if you create two profiles with the same address :D when creating the second profile, refresh the webpage before clicking on the link, that will create a new QR code.

and with other servers that have domain names it hangs on 'establishing connection'.

I tested it with nine.testrun.org, it could send to your no-dns relay, it just didn't receive messages from it. I tried sending back and forth, somehow your relay doesn't try to deliver messages to domain-based relays. Maybe journalctl -f offers some insight?

[dot-file]

The "QR code has been reset error" appears if you create two profiles with the same address :D when creating the second profile, refresh the webpage before clicking on the link, that will create a new QR code.

Okay, that was a dumb mistake 😅
It works perfectly now, I was even able to make a call. Thanks!

Maybe journalctl -f offers some insight?

I did journalctl -fu postfix@- and then tried connecting to a profile on nine.testrun.org. After thirty seconds it throws the following error:

Apr 30 18:18:42 delta postfix/smtp[30857]: connect to nine.testrun.org[77.42.49.41]:25: Connection timed out
Apr 30 18:18:42 delta postfix/smtp[30857]: connect to nine.testrun.org[2a01:4f9:fff1:59::1]:25: Network is unreachable
Apr 30 18:18:42 delta postfix/smtp[30857]: 255AFB1AA: to=<0n722gz3q@nine.testrun.org>, relay=none, delay=30, delays=0.01/0/30/0, dsn=4.4.1, status=deferred (connect to nine.testrun.org[2a01:4f9:fff1:59::1]:25: Network is unreachable)

It also gave a bunch of these one of the times I tried that:

Apr 30 18:24:37 delta postfix/error[30933]: D9386B16C: to=<vtw2m21on@staging1.pool.testrun.org>, relay=none, delay=38275, delays=38245/31/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to staging1.pool.testrun.org[46.225.132.204]:25: Connection timed out)

Same thing with arcanechat.me. I tried pinging both addresses and the connection is good, so it must be something to do with smtp.

[missytake]

Same thing with arcanechat.me. I tried pinging both addresses and the connection is good, so it must be something to do with smtp.

Ah right - probably your hosting provider doesn't allow outgoing traffic to port 25. In many cases, you can ask them to unblock it because you want to run a mail server, some of them have specific criteria to allow it.

[dot-file]

Yes, it turned out they block it. Thank you for your help!

[j4n]

looks good! re-skimmed, tested deployment and interop on a fresh vm :)