Multiple transport:nexthop results in transport map?

[Ralph Seichter]

I'm currently using the following transport map on a server:

# /etc/postfix/transport
domain1.tld :
.domain1.tld :
.domain2.tld :domain2.tld
* :relay.domain3.tld

For the wildcard line, I'd like to use something like

* :relay.domain3.tld, :relay.domain4.tld

to tell Postfix "try relay.domain3.tld first, and if the server is not
available, try relay.domain4.tld". If I understand the section "RESULT
FORMAT" of <http://www.postfix.org/transport.5.html> correctly, I can
only have one transport:nexthop, but not two as I have shown above. Is
that correct? If so, should I use "fallback_relay = relay.domain4.tld"
to make Postfix (version 2.2.7) use a fallback server?

[Wietse Venema]

Ralph Seichter:
[ Charset ISO-8859-1 unsupported, converting... ]

Post by Ralph Seichter
# /etc/postfix/transport
.domain2.tld :domain2.tld
* :relay.domain3.tld
For the wildcard line, I'd like to use something like
* :relay.domain3.tld, :relay.domain4.tld
to tell Postfix "try relay.domain3.tld first, and if the server is not
available, try relay.domain4.tld". If I understand the section "RESULT
FORMAT" of <http://www.postfix.org/transport.5.html> correctly, I can
only have one transport:nexthop, but not two as I have shown above. Is
that correct?

Indeed. Only the documented behavior is supported from one
Postfix release to the next one.

Behavior that isn't documented will break without warning.

Post by Ralph Seichter
If so, should I use "fallback_relay = relay.domain4.tld"
to make Postfix (version 2.2.7) use a fallback server?

That would be an option.

I am revising the SMTP client connection management code, and it
is so ridiculously complicated that there will not be multi-nexthop
support in the forseeable future.

Wietse

[Ralph Seichter]

Post by Wietse Venema

Post by Ralph Seichter
If so, should I use "fallback_relay = relay.domain4.tld"
to make Postfix (version 2.2.7) use a fallback server?

That would be an option.

I was not sure about this, because "relayhost" is empty, but using
"fallback_relay" as described above seems to suit my purpose

Post by Wietse Venema
I am revising the SMTP client connection management code, and it
is so ridiculously complicated that there will not be multi-nexthop
support in the forseeable future.

I see your point.

[Victor Duchovni]

Post by Ralph Seichter

Post by Wietse Venema

Post by Ralph Seichter
If so, should I use "fallback_relay = relay.domain4.tld"
to make Postfix (version 2.2.7) use a fallback server?

That would be an option.

I was not sure about this, because "relayhost" is empty, but using
"fallback_relay" as described above seems to suit my purpose

Post by Wietse Venema
I am revising the SMTP client connection management code, and it
is so ridiculously complicated that there will not be multi-nexthop
support in the forseeable future.

I see your point.

If people really needed a variable smtp_fallback_relay (postfix 2.3
notation) with a lot of different destination dependent fallback
domains, what would be possible without major surgery to the logic is:

smtp_fallback_relay_maps = hash:/etc/postfix/fallback_table

fallback_table:
# LHS = verbatim nexthop, RHS = list of fallback nexthops
example.com [backup.example.com]
[example.org] [backup1.example.org], backup-all.mx.invalid
[example.net]:587 [backup-msa.example.net]
...

So far I have not seen much evidence that a couple of transports in master.cf
for the one or two exeptional sites don't solve the problem equally wel
without adding the burden of new code to support fallback relay table lookups.
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ralph Seichter]

Post by Victor Duchovni
So far I have not seen much evidence that a couple of transports in
master.cf for the one or two exeptional sites don't solve the problem
equally wel without adding the burden of new code to support fallback
relay table lookups.

Could you give an example for the required changes to master.cf to
allow the following:

if target is *.foo.tld {
use relay.domain1.tld if it is available;
try fallback.domain1.tld as a fallback;
} else if target is *.bar.tld {
use relay.domain2.tld if it is available;
try fallback.domain2.tld as a fallback;
} else {
use relay.domain3.tld if it is available;
try fallback.domain3.tld as a fallback;
}

The scenario contains three distinct primary/fallback pairs, and I
don't currently know how I can use master.cf to achieve this.

[Magnus Bäck]

On Saturday, December 10, 2005 at 11:44 CET,

Post by Ralph Seichter

Post by Victor Duchovni
So far I have not seen much evidence that a couple of transports in
master.cf for the one or two exeptional sites don't solve the problem
equally wel without adding the burden of new code to support fallback
relay table lookups.

Could you give an example for the required changes to master.cf to
if target is *.foo.tld {
use relay.domain1.tld if it is available;
try fallback.domain1.tld as a fallback;
} else if target is *.bar.tld {
use relay.domain2.tld if it is available;
try fallback.domain2.tld as a fallback;
} else {
use relay.domain3.tld if it is available;
try fallback.domain3.tld as a fallback;
}
The scenario contains three distinct primary/fallback pairs, and I
don't currently know how I can use master.cf to achieve this.

transport table:
foo.tld smtp-foo:[relay.domain1.tld]
bar.tld smtp-bar:[relay.domain2.tld]

main.cf:
relayhost = [relay.domain3.tld]
fallback_relay = [fallback.domain3.tld]

master.cf:
smtp-foo unix ... smtp -o fallback_relay=[fallback.domain1.tld]
smtp-bar unix ... smtp -o fallback_relay=[fallback.domain2.tld]

But in this case, I'd use DNS instead by setting up dummy MX entries in
a local domain and using them in the transport table and the main.cf
relayhost setting..

[Victor Duchovni]

Post by Magnus Bäck

Post by Ralph Seichter
Could you give an example for the required changes to master.cf to
if target is *.foo.tld {
use relay.domain1.tld if it is available;
try fallback.domain1.tld as a fallback;
} else if target is *.bar.tld {
use relay.domain2.tld if it is available;
try fallback.domain2.tld as a fallback;
} else {
use relay.domain3.tld if it is available;
try fallback.domain3.tld as a fallback;
}
The scenario contains three distinct primary/fallback pairs, and I
don't currently know how I can use master.cf to achieve this.

foo.tld smtp-foo:[relay.domain1.tld]
bar.tld smtp-bar:[relay.domain2.tld]
relayhost = [relay.domain3.tld]
fallback_relay = [fallback.domain3.tld]
smtp-foo unix ... smtp -o fallback_relay=[fallback.domain1.tld]
smtp-bar unix ... smtp -o fallback_relay=[fallback.domain2.tld]
But in this case, I'd use DNS instead by setting up dummy MX entries in
a local domain and using them in the transport table and the main.cf
relayhost setting..

Indeed much simpler, but there is one limitation, with fake DNS nexthops
(which I use when appropriate) one is not able to do TLS peer verification
when the remote SMTP server's certificate lists the real name.

So if one needs a TLS secure-channel (full peer verification, MX bypass,
...) and per-site fallback, the master.cf hacks are the only way for now,
for a small number of sites, this should be a acceptable.
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ralph Seichter]

[example configuration]

Ah, I get it, thanks. I will try a similar setup.

But in this case, I'd use DNS instead by setting up dummy MX entries in
a local domain and using them in the transport table and the main.cf
relayhost setting..

I had thought about that, too, but currently I prefer a solution which
relies on Postfix configuration settings only.

[Victor Duchovni]

Post by Ralph Seichter

[example configuration]

Ah, I get it, thanks. I will try a similar setup.

But in this case, I'd use DNS instead by setting up dummy MX entries in
a local domain and using them in the transport table and the main.cf
relayhost setting..

I had thought about that, too, but currently I prefer a solution which
relies on Postfix configuration settings only.

If DNS is an option, it is recommended over any Postfix-only solutions
that employ multiple transports and fallback_relay (2.3 smtp_fallback_relay).
--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:***@postfix.org?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.