Backup relay possible?
Hello, On our gateway server, we have: transport_maps = hash:/etc/postfix/transportmap /etc/postfix/transportmap noa.gr relay:[vmail.noa.gr] admin.noa.grrelay:[vmail.noa.gr] nestor.noa.gr relay:[vmail.noa.gr] space.noa.grrelay:[vmail.noa.gr] meteo.noa.grrelay:[vmail.noa.gr] gein.noa.gr relay:[vmail.noa.gr] technet.noa.gr relay:[vmail.noa.gr] astro.noa.grrelay:[vmail.noa.gr] Is there a way to configure a backup relay (i.e. a secondary next hop), so as to, if vmail.noa.gr does not respond, then incoming mail can be attempted to be delivered to the backup relay (for example to vmail1.noa.gr)? I understand that this complicates delivery in the sense that if the backup relay does not respond as well, postfix should decide what to do; I would think that it would keep it in the queue and retry both relay points each time, with the same sequence. Please advise on possible ways in which we can configure such a secondary relay. Thanks and best regards, Nick
Re: Backup relay possible?
Make vmail.noa.gr with multi ip then postfix will resolve it self Else make dns split view on local servers Avoid transport maps
Re: Backup relay possible?
On 27/03/2014 13:49, Nikolaos Milas wrote: Hello, On our gateway server, we have: transport_maps = hash:/etc/postfix/transportmap /etc/postfix/transportmap noa.gr relay:[vmail.noa.gr] admin.noa.grrelay:[vmail.noa.gr] nestor.noa.gr relay:[vmail.noa.gr] space.noa.grrelay:[vmail.noa.gr] meteo.noa.grrelay:[vmail.noa.gr] gein.noa.gr relay:[vmail.noa.gr] technet.noa.gr relay:[vmail.noa.gr] astro.noa.grrelay:[vmail.noa.gr] Is there a way to configure a backup relay (i.e. a secondary next hop), so as to, if vmail.noa.gr does not respond, then incoming mail can be attempted to be delivered to the backup relay (for example to vmail1.noa.gr)? http://www.postfix.org/postconf.5.html#fallback_relay -- Levi
Re: Backup relay possible?
On 27/3/2014 2:04 μμ, Birta Levente wrote: http://www.postfix.org/postconf.5.html#fallback_relay Oh, thanks! So, since the two conditions are by default fulfilled: * In main.cf specify relay_transport = relay, * In master.cf specify -o fallback_relay = (i.e., empty) at the end of the relay entry. ...it is enough to specify in transport maps: noa.gr relay:[vmail.noa.gr] noa.gr relay:[vmail1.noa.gr] admin.noa.gr relay:[vmail.noa.gr] admin.noa.gr relay:[vmail1.noa.gr] ... Right? Thanks, Nick
Re: Backup relay possible?
On 27/03/2014 15:05, Nikolaos Milas wrote: On 27/3/2014 2:04 μμ, Birta Levente wrote: http://www.postfix.org/postconf.5.html#fallback_relay Oh, thanks! So, since the two conditions are by default fulfilled: * In main.cf specify relay_transport = relay, * In master.cf specify -o fallback_relay = (i.e., empty) at the end of the relay entry. ...it is enough to specify in transport maps: noa.gr relay:[vmail.noa.gr] noa.gr relay:[vmail1.noa.gr] admin.noa.gr relay:[vmail.noa.gr] admin.noa.gr relay:[vmail1.noa.gr] ... Not really IMHO AFAIK since you have two entries with same key in transport map, postfix will choose the first. I think this is the way: main.cf: fallback_relay=[vmail1.noa.gr] transport_map: noa.gr relay:[vmail.noa.gr] admin.noa.gr relay:[vmail.noa.gr] -- Levi
RE: Backup relay possible?
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Nikolaos Milas Sent: 27 March 2014 14:27 To: postfix-users@postfix.org Subject: Re: Backup relay possible? On 27/3/2014 4:10 μμ, Birta Levente wrote: Not really IMHO AFAIK since you have two entries with same key in transport map, postfix will choose the first. I think this is the way: main.cf: fallback_relay=[vmail1.noa.gr] transport_map: noa.gr relay:[vmail.noa.gr] admin.noa.gr relay:[vmail.noa.gr] Hmm, yes; reading the docs, I understand you are right. This is the way it should be. (It was careless on my part to draw hastily a wrong conclusion.) Yet, this means that a fallback relay will be common for all entries in transport_maps (which is fine in my case), but there is no way to define fallback relays per domain as in transport_maps? Nick What I have done to mitigate this issue is to setup a DNS server with internal use only zones. The transport map would therefore read similar to the following: noa.gr relay:noa.gr.local I have then configured A records for the multiple relay destinations, queries are then balanced in a DNS round robin fashion. It's perhaps not the most elegant solution but *touch wood* it hasn't caused me any issues. Kind regards, James Day
Re: Backup relay possible?
On 27/3/2014 4:10 μμ, Birta Levente wrote: Not really IMHO AFAIK since you have two entries with same key in transport map, postfix will choose the first. I think this is the way: main.cf: fallback_relay=[vmail1.noa.gr] transport_map: noa.gr relay:[vmail.noa.gr] admin.noa.gr relay:[vmail.noa.gr] Hmm, yes; reading the docs, I understand you are right. This is the way it should be. (It was careless on my part to draw hastily a wrong conclusion.) Yet, this means that a fallback relay will be common for all entries in transport_maps (which is fine in my case), but there is no way to define fallback relays per domain as in transport_maps? Nick
Re: Backup relay possible?
On 27/03/2014 16:26, Nikolaos Milas wrote: On 27/3/2014 4:10 μμ, Birta Levente wrote: Not really IMHO AFAIK since you have two entries with same key in transport map, postfix will choose the first. I think this is the way: main.cf: fallback_relay=[vmail1.noa.gr] transport_map: noa.gr relay:[vmail.noa.gr] admin.noa.gr relay:[vmail.noa.gr] Hmm, yes; reading the docs, I understand you are right. This is the way it should be. (It was careless on my part to draw hastily a wrong conclusion.) Yet, this means that a fallback relay will be common for all entries in transport_maps (which is fine in my case), but there is no way to define fallback relays per domain as in transport_maps? I'm not sure and this is not tested, but maybe you can: transport_map: noa.gr relay1:[vmail.noa.gr] admin.noa.gr relay2:[vmail.noa.gr] add to master.cf: relay1 unix - - n - - smtp -o fallback_relay=[firstwhateverhost] relay2 unix - - n - - smtp -o fallback_relay=[secondwhateverhost] -- Levi
Re: Backup relay possible?
On 27/3/2014 4:32 μμ, James Day wrote: noa.gr relay:noa.gr.local I have then configured A records for the multiple relay destinations, queries are then balanced in a DNS round robin fashion. Yes, I undertand. However, we don't want balancing (our traffic is low - but we want failover). In my case, this scenario could be implemented by using a very low TTL for vmail.noa.gr and then use a script to monitor target and, in case it does not respond, then update the A record to point to another IP address. This assumes that Postfix observes the TTL for DNS lookups (on names used in transport maps). However, in my case I would not go for this solution because we want vmail and vmail1 to have different host names (they include Dovecot IMAP servers replicated using dsync). They cannot behave to others as being the same host. One thing that could be done would be to monitor vmail.noa.gr on the gateway servers and if it does not respond, then use a script to update transport maps and reload postfix. It does not sound very elegant to me... (Nor can we employ multiple IP addresses per server; it is a VPS service offering a single IP address per VM.) Nick
Re: Backup relay possible?
On 27.03.2014 16:01, Nikolaos Milas wrote: On 27/3/2014 4:32 μμ, James Day wrote: noa.gr relay:noa.gr.local I have then configured A records for the multiple relay destinations, queries are then balanced in a DNS round robin fashion. Yes, I undertand. However, we don't want balancing (our traffic is low - but we want failover). You do not need A records, but you can instead add MX records with priority. This way your use case is implemented. Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin signature.asc Description: OpenPGP digital signature
Re: Backup relay possible?
On 27/3/2014 5:04 μμ, Robert Sander wrote: You do not need A records, but you can instead add MX records with priority. This way your use case is implemented. No, these are not MXs. They are internal (final destination) servers. MXs are gateway servers relaying to the internal one (for which we are trying to setup failover). Nick
Re: Backup relay possible?
On 27/3/2014 4:47 μμ, Birta Levente wrote: I'm not sure and this is not tested, but maybe you can: transport_map: noa.gr relay1:[vmail.noa.gr] admin.noa.gr relay2:[vmail.noa.gr] add to master.cf: relay1 unix - - n - - smtp -o fallback_relay=[firstwhateverhost] relay2 unix - - n - - smtp -o fallback_relay=[secondwhateverhost] Interesting! It might work. I'll try to find an opportunity to test it. Yet, IMHO it might be a good idea for some future version to support full lookup tables in fallback_relay e.g. in the form (just speculating): --- fallback_relay_map: --- noa.gr relay:[vmail1.noa.gr,vmail2.noa.gr] tech.noa.gr relay:[vmail1.noa.gr,vmail5.noa.gr] ... All the best, Nick
Re: Backup relay possible?
On 27.03.2014 16:09, Nikolaos Milas wrote: On 27/3/2014 5:04 μμ, Robert Sander wrote: You do not need A records, but you can instead add MX records with priority. This way your use case is implemented. No, these are not MXs. They are internal (final destination) servers. MXs are gateway servers relaying to the internal one (for which we are trying to setup failover). I know that they are not official MX. The whole point is that you create an internal domain name with two MX records pointing to these servers. This is then used in your transport map and nowhere else. Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin signature.asc Description: OpenPGP digital signature
Re: Backup relay possible?
On 27/3/2014 6:18 μμ, Robert Sander wrote: I know that they are not official MX. The whole point is that you create an internal domain name with two MX records pointing to these servers. This is then used in your transport map and nowhere else. Hmm, interesting. It sounds a good idea! Thank you! All the best, Nick
