Hi all! Sorry for my English, this is not my native language. Sorry for the length, too... :-D We have a multiserver setup based on Debian 10, up-to-date 3.2.9 ISPconfig, and separate (virtual) servers for the panel, webmail, database (MySQL only), web (currently one), e-mail (also currently one), and two NS servers. I'm thinking on a separate mail server which serves only for outgoing mail sending for customers, instead of the currently used "combined" (default) sendig/receiving mail server. The main reason behind this is that we continuously face the following problem (at our hosting and at other hosting providers, too): when a new customer migrates to our hosting, the migration lasts for about a day to two weeks (depending on customer pace, not ours). After the e-mail domain and mailboxes initially created for them in ISPconfig, our other customer's outgoing e-mails sent to this new customer's addresses are delivered to the new local mailboxes immediately, while the new customer's mail domain isn't fully migrated yet, and the MX record(s) point to the original mail server, and customer also uses the current server for IMAP or POP3 on their mail clients. So the customer do not receive those e-mails until the migration finishes on their side. I tried to disable the not-yet-functional e-mail domain to resolve this problem, but after this, the new mailboxes become inaccessible (on IMAP I tried to migrate contents), so mailbox content migration is not possible with disabled e-mail domain. We try to do the migration as fast as possible (I did the e-mail domain and mailbox creation, then the mailbox content transfer in one night out of business hours), but if the customer is not able to switch to the new e-mail server immediately, the problem arises soon. We also faced the reverse of this problem: a customer migrated the e-mail domain to another provider (M365 or similar), while DNS management and website hosting remained in our hosting. The customer changed the DNS records accordingly, but forget to disable the e-mail domain. A few weeks later they opened a ticket (at our support and at the new server's support) stating that some e-mails never arrive to the new server. It turned out that the never-arriving e-mails originated from our other cusmoters, and delivered locally to the now-not-used mailboxes. The continuous checking of these carried-away domains is not a funny task. So I think on a separate send-only SMTP server that always resolve MX for the recipient domain, and use that information instead of local delivery. The solution I come up with: I install a second mail server in ISPconfig, and change the Postfix main.cf template to "disable" local deliver by commenting out all items related to local delivery (virtual maps, etc.), and modify the SQL query for accepted senders to not check the server ID (so mailboxes assigned to any receiving servers can send through this new server). Also I will disable receiving and retrieving ports in firewall. I think the remaining config can do outgoing spam checking, outgoing rate limiting (by rspamd) and delivery based on authorative MX record(s). The idea is based on that assumption that ISPconfig replicates all mail-related data to every mail server registered, and the individual mail servers select the records that correspond to their duty. I tried to look at the relevant source code to validate this assumption and found no evicendce (yet) that is's false. The core idea behind this full separation is that SMTP server never access mailboxes. On e-mail send, the MUA places the sent mail in "Send" folder via IMAP calls, not the sending SMTP server. So if the sending SMPT server do not have access to the mailboxes, that's not causes any problems. Of course I take into account the mailboxes "Disable send" and similar options when modifying config files for this purpose. This way (I hope) the send-only mail server remains ISPconfig manageable, and serves it's purpose. My question is that anybody have any objection or any better idea to accomplish this goal? I searched these forums and the internet in general for a convenient solution, but I didn't found any, yet. Thank you for your time!
Wouldn't it be better to just implement a feature in ISPConfig with a simple checkbox to disable local delivery? I think more users could benefit from this. If you do not have the development capacity for this, you can of course open a feature request in our GitLab (git.ispconfig.org) and eventually hire a dev to implement it for you.
I'd like to revisit this thread and join in in saying that this could benefit multiple users. The use cases may vary, but the need to disable local delivery fits them all. I found this asked and discussed in several other threads throughout the forum, some several years old, some more recent: https://forum.howtoforge.com/threads/disable-local-delivery-on-a-per-domain-basis.29143/ https://forum.howtoforge.com/threads/relaying-email-domain.89859/ https://forum.howtoforge.com/threads/how-to-route-bounce-mails-to-real-mx-instead-of-local.90209/ https://forum.howtoforge.com/threads/disable-mail-delivery-for-local-domain.90554/ In general, the gist is "If you don't want local mail delivery, don't create the domain entry in the mail module", but I think this answer no longer holds in 2024 with SPF and DKIM being enforced by a higher number of email servers. While relaying to another domain or sending mail as as a client (e.g. via the submission protocol) are alternatives, they are not ubiquitously available. Some servers, especially those we do not control, prevent relaying, some servers do not or no longer offer SMTP or even Submission protocols. I think that using ISPConfig's mail module to ensure mail sent from a hosted website is properly DKIM-signed, is a valid use-case today. Being able to set it per-domain would be an advantage. The quick and dirty solution I had to apply yesterday to prevent the postfix server from attempting local delivery was to comment out the virtual_mailbox_domains configuration setting in postfix' main.cf, but a proper solution would indeed probably entail a checkbox on the Domain tab of the Email module and an additional field in the mail_domains database table. The virtual_mailbox_domains lookup query would then e.g. change from Code: query = SELECT domain FROM mail_domain WHERE domain = '%s' AND active = 'y' AND server_id = 1 AND NOT EXISTS (SELECT source FROM mail_forwarding WHERE source = '@%s' AND type = 'aliasdomain' AND active = 'y' AND server_id = 1) to something like Code: query = SELECT domain FROM mail_domain WHERE domain = '%s' AND active = 'y' AND local_delivery = 1 AND server_id = 1 AND NOT EXISTS (SELECT source FROM mail_forwarding WHERE source = '@%s' AND type = 'aliasdomain' AND active = 'y' AND server_id = 1) I am not going to promise to start working on this shortly, given that I haven't been able to make much progress with my other project for lack of time, but I wanted to see if minds have generally changed on handling this over the past few months and maybe bump this thread a little.
I totally agree that we need something for this You describe incoming migrations, but this is also relevant also when a client decides to move their mail to a different server but would like to keep the old mailboxes available for a short while. And not only migrations scenario's but as state above it's needed to let a webserver do dkim signing. (which is another rabbit hole ... Should we enable the mailserver service in ispconfig on this webserver? then it complains if dovecot is not running....which I don't need) If we add such a 'Enable local delivery' checkbox(default true)... Turning the 'active' flag 'off' for a mail_domain then just means that all mailboxes are locked, and no more DKIM signing is done? Till's line "A mail domain is for local delivery only" from other posts here would no longer be valid... Alternatively we could re-label the 'active' flag on a mail_domain for this? And make it so that it no longer closes access to all imap accounts (./install/tpl/debian_dovecot-sql.conf.master).