Specify multiple transport destinations postfix

email-serverpostfix

My question is in a similar vein to this one, but not in the sense that I want email to always go to two destinations. Rather, I'm trying to find a way to provide Postfix with multiple nexthop destinations per-recipient domain, such that if I'm relaying mail to an external destination that has multiple MX's and one goes down, it tries the next.

"Solutions" to this problem I've found that won't work here:

  1. bcc :: this wouldn't solve the issue if I'm trying to send to the same address a different way
  2. create new protocol (like this) :: this solution I think exemplifies the problem in that postfix DOES appear to allow fallback transports, but only on a global scale (read: send all mail regardless of recipient to the following servers if the recipients main transport is down). New protocols in my setup is impractical as I may have many domains being relayed.

  3. Whatever this is :: This seems to talks about what I'm trying to accomplish, but again, I get the feeling this is only meant for a global capacity. It's also confusing since it seems to imply that you can specify multiple transports, but of course Postfix will have none of that if you try:

    Using multiple lines:

    postmap: warning: duplicate entry

    Using the same line:

    fatal: garbage after "]" in server description

    I don't know, maybe I'm just misunderstanding the syntax or something.

  4. DNS :: Some suggestions involve setting up like internal DNS and setting up MX records to point to the multiple destinations. This is also an impractical solution.

It just seems so weird to me that Postfix wouldn't have the capacity to allow the definition of multiple transports as having domains having multiple MX's is so common, so I'm just assuming that Postfix DOES have this capcity that I've just not found documented or understood, and that wonky "workarounds" are unnecessary.

Does anyone happen to know if my assumption is right (in which case, how can I get this set up?) or wrong (in which case, have you found a scalable solution?)?

###EDIT###

To explain my setup, this is an inbound spam filter (among other things), such that a domain that uses it would set their MX records to point to this server for mail filtering, and then after filtering it forwards it to the destination transport(s). Due to this, simply asking Postfix to do DNS lookups for MX records wouldn't work because it'd simply get itself as the result.

Best Answer

The premise in your edit note is wrong. The MX protocol/decision tree/whatever is designed to handle this.

To explain my setup, this is an inbound spam filter (among other things), such that a domain that uses it would set their MX records to point to this server for mail filtering, and then after filtering it forwards it to the destination transport(s). Due to this, simply asking Postfix to do DNS lookups for MX records wouldn't work because it'd simply get itself as the result.

The way MX records work is that given something like

MX    10 mail.example.com.
MX    20 backupmx.example.com.
MX    30 mail.virusco.com.
MX    40 backupmx.virusco.com.

mail.example.com is set to only accept incoming SMTP connections from the 3 other servers (think firewall and connecting to port 25). The backupmx.example.com server is set to only accept mail from the 2 virusco.com servers. the two virusco.com servers are configured to accept mail from the world as MX servers for example.com

My server - foo.org - can't get to mail.example or backupmx.example (by configuration design) so it delivers to mail.virusco, which is configured to forward the mail to mail.example via normal SMTP MX decision.

This means that if mail.example is down, AND backupmx.example is down, mail.virusco simply holds the mail and tries again "later"

If mail.virusco is down for a bit, mail goes to backupmx.virusco, gets scanned, and then backupmx.virusco follows the MX decision tree and tries delivery to mail.example, backupmx.example, mail.virusco in that order, and if none are successful it too will sit on the mail for "a while" and then retry delivery.

You can even take backupmx.example out of the system entirely and it will still work in that fashion. A lower priority (higher value) MX server will try to deliver to the highest priority (lowest number) server, until it reaches itself, at which point it will sit on it and try again later.

Related Topic