I have access to my server : Through SSH | through the webadmin | direct access via keyboard / screen | neuromancy Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : not yet …
Description of my issue
I’d like to add a second mail server to my domain, but I lack some knowledge and skills. I am not quite sure where to start.
The bit where I put Yunohost on a second server and got two MX records for my domain should work.
Where I am not sure whether it will work out as expected, is the storage of mails and lists of valid mail addresses.
I could find some help in setting Yunohost to use another server as relay, but in this case I think the second server is relaying for the first? Or does it have nothing to do with relay?
Anyway: how is this outside of Yunohost configured when having a second mailserver? I expect other mailservers will lookup the MX record, and then connect to the highest priority server first (that would be my original Yunohost, let’s call it MX10 for short), and if it is down for the moment, it will try the next one in line (the newly created server, MX20).
Now somewhere there is some validation of the recipient mail address. Would I have to duplicate the users from Yunohost at MX10 to Yunohost at MX20? And my mail client, how will it receive the new mail on MX20 when it connects to MX10?
I imagine there is no readily made configuration for cases like this yet. I would like it if you can give just a hint where to start looking!
What I read about this, is that the backup MX is not a post office. It will only hold the received mails queued, ready for delivery once the primary MX comes back up.
This is also solved by knowing that MX20 only holds mail temporarily before sending it on to MX10. Postfix’s configuration does support spam control for the secondary MX.
The key lesson for me are:
It is not a distributed system in which both MX have full functionality;
One MX can be secondary mailserver for more than one primary mailserver
IMO there is an underlying problem in this.
When an inbound piece of e-mail is rejected during reception (e.g. mailbox unknown, sending IP is blacklisted, …) it is good behaviour to reject the e-mail during the transmission (either after RCPT TO or DATA). In this situation the sending server has the responsibility to issue a non-delivery report to the sender.
When the receiving server (here MX20) accepts the e-mail for queuing at the end of the transmission, and is finally unable to deliver the e-mail, it becomes its responsibility to issue a NDR to the sender.
If the recipient is unknown and the e-mail contains harmful contents or spam, your MX20 becomes a spamming machine and can get blacklisted.
This means that all backup MX must keep an up-to-date list of valid recipients in order to be able to bounce messages at transmission time.
Moreover spammers (and other big names) do not always respect the order of priorities in the MX chain, especially as the backup MX are often more permeable than the primary MX.
