Hi Wietse, I see your point. But current MX support will also cause this problem. For example, if we configure the transport: "example.com smtp: mx.example.com:25" which is supported by all Postfix version. smtp daemon(smtp/smtp_connect.c) will query all MX records of "mx.example.com" and try these mx records one by one according to preference. My suggestion is that can we put such MX records into transport directly to avoid DNS querying? Suppose "mx.example.com" will return two MX records with IP addresses: 192.168.0.1, 192.168.0.2, can we set them in transport directly like: example.com smtp:192.168.0.1:25#10, 192.168.0.1:10025#20. (#10, #20 means the preference)
Currently we are hosting mail service, so each domain need to have different setting like above example, the workaround is to setup DNS server but it's more convenient if we can configure them in transport directly. I have also searched the internet and there are also several similar requirement for such multiple destination support, and all answers are DNS format. So I think this support will be useful in some scenarios. BTW, smtp_fallback_relay also support multiple destination? Will this feature enabled also impact the queue's manager? Because we also use this feature as backup solution for mail service. Regards, King Cao 2013/7/16 Wietse Venema <wie...@porcupine.org> > King Cao: > > adding several codes in "smtp/smtp_connect.c", I think it's more > convenient > > for user to set different destinations. That's why I want to add such > patch > > to current Postfix source code. > > Multiple destinations per nexthop would break queue manager's > concurrency scheduling policies or it would would break the queue > manager's independence of nexthop syntax. > > I am suspicious about applications that require manual configuration > of different fallback routes for different destinations. If you > really need such things then you can use different transports, each > having their own smtp_fallback_relay, smtp_bind_address and so on. > > Got it? > > Wietse >
