I think an “overreceptive” local maildir override option could actually be a positive feature:
It could avoid sending out emails to accounts set up on the local yunohost, but not existing at the external MX. It could allow for “local first” email between local accounts, and only send out to the external MX for users unknown locally.
But the current MX override (loop to self errors) may actually prevent/cover up part of that feature.
These are the use-cases I had in mind with my tests below:
- external email
- email_in disabled for domains
- email_out enabled for notifications etc. (and allowance added to global SPF)
The “overreceptive” local maildirs might collect admin emails in a local mailbox, and avoid sending out email to “yunohost only” accounts, but users may need to disable this “feature” to set up and use external mailboxes.
- backup yunohost
- accounts must be synced (import/export, backup, whatever)
- email_in and out enabled and set up completely for domains, to start working as soon as the MX is switched over in the DNS
- Unsure if preconfiguring a local MX override to avoid the DNS update propagation time would make sense here. The “overreceptive” local maildirs could be enough to make client requests work already before the DNS MX update propagates to this server? (Emails enter local IMAP.)
- experimental yunohost (test installation/replication)
- Mostly identical configuration to main server, but not necesarrily configured with all the same apps and users.
- MX pointing to main server, so if not in need to test local email delivery, mail_in disabled for the local domains in order to make all email going to the admin’s usual IMAP inbox at main server.
The “overreceptive” local maildirs seem a problem here. Because email to root@main-domain does not reach the admin at the main-domain server.
However, unfortunately the current results from testing the available combinations of options don’t seem useful for any of the use cases.
The MX override seems a central problem, but I hope my experiments can help you to identify the further causes of the problems, and thus find the simplest true solutions in the implementation of underlying options.
Testing Results:
I. Global DNS settings “production”: main-domain MX set to public ynh IP, and secondary-domain MX pointing elswhere)
with mail_in settings: main-domain on, secondary-domain on
→ email to main-domain should be delivered locally
(+) delivered to main-domain mailbox
→ email to enabled secondary-domain should be delivered to external MX (only optionally to existing local mailbox)
(-) delivered to existing user
(-) not sent to extrnal MX (“user unknown”)
Current behavior is not the optionally desireable “to local mailbox if one exists” either.
with mail_in settings: main-domain off, secondary-domain on
→ email to mail_in disabled main-domain should be rejected (optionally accept locally to existing local mailbox)
(+) email to the main-domain and local emails (without @domain) fail with “local loop”
Though, it’s currently not ok to reject, because the main-domain is used for local email. It will only become ok to reject, once local email (not using any domain, or @localhost) works independent of an enabled main-domain, i.e. after according adaptions.
The loop error message may or may not be helpful/correct (as either redirecting the public primary-domain MX record, or enabling mail_in can solve the problem).
Solution?: Expansion of local emails to @localhost instead of the main-domain?
That could likely also distinguish between local “accept/unknown” and a main-domain MX loop. It would have to make sure to never send out any email from @localhost, and that all domains still use the main-domain as email-hostname (“ehlo”) when sending (to match the IPs rDNS).
Note, current “Issue D” (@localhost emails breaking inboxes).
→ email to enabled secondary-domain should go to external MX (optionally to existing local mailbox)
(-) email to existing user/alias fails “local loop”
(-) email to unknown user/alias is bounced “unknown” (and the following mailer-daemon message to the local sender fails with “local loop”, as above)
(Loop probably fixable by issue A removing mx-host lines from dnsmasq.)
Current behavior is not the optionally desireable “to local mailbox if one exists” either.
with mail_in settings: main-domain off, secondary-domain off
→ email sent to disabled secondary-domain should go to external MX
(-) email to existing username/alias addresses fails “local loop”
(Issue C: “overreceptive” local maildir?)
(+) email to non-existing username/alias address gets sent to MX
II. Global DNS settings “spare”: main-domain MX and secondary-domain MX pointing elswhere)
[separate test install of the main-domain server]
with mail_in settings: main-domain on, secondary-domain on
→ email to main-domain should be delivered to external MX (optionally to existing local mailbox)
(-) delivered to main-domain mailbox
→ email to enabled secondary-domain should be delivered to external MX (optionally to existing local mailbox)
(-) delivered to existing user
(-) not sent to external MX (“user unknown”)
Current behavior is not the optionally desireable “to local mailbox if one exists” either.
with mail_in settings: main-domain off, secondary-domain on
→ local delivery to disabled main-domain should go to external MX,
(-) local emails (without domain) and to the main-domain fail “local loop”
(Loop not fixable by issue A removing mx-host lines from dnsmasq.)
(Because locally, the external MX of the main-domain (i.e. the main-domain) will still resolve to local IPs [on a separate test install of the main-domain server])
Solution?: Expansion of local emails to @localhost instead of the main-domain? To have those work locally and independent from the main-domain.
Also not possible: Explicitly overriding the MX with dnsmasq also in this very special case (MX with local domain name but foreign public IP), letting it point to the external MX by referencing the IPs rDNS result? becuse it would (ideally) be the same domain.
Possibly?: A way to disable the webserver for the main-domain and with that also the dnsmasq domain->IP override.
→ email to enabled secondary-domain should go to external MX (only optionally to existing local mailbox), local delivery only once corresponding MX propagated
(-) email to known user/alias succeeds (delivered to local inbox)
(Issue C: “overreceptive” local maildir?)
(-) email to unknown user/alias is bounced “unknown” (and the following mailer-daemon info-reply to the local sender fails with “local loop”, as above)
(Loop probably fixable by issue A removing mx-host lines from dnsmasq.)
Current behavior is not the optionally desireable “to local mailbox if one exists” either.
with mail_in settings: main-domain off, secondary-domain off
→ email sent to disabled secondary-domain should go to external MX
(-) email to existing username/alias addresses fails “local loop”
This happens even though there is no dnsmasq override with mail_in off, and the secondary-domain does not have a MX that resolves to a local IP, they are external servers!
(Issue C: “overreceptive” local maildir?)
(+) email to non-existing username/alias address gets sent to MX
BTW: Once the dovecot IMAP maildir became “bogus” (after some user/app has sent @localhost):
(+) email to existing username/alias addresses got sent to external MX
(+) email to non-existing username/alias address got sent to external MX
However, local delivery to the dovecot maildir @main-domain was broken.
