Hi, I just see the patch on 3.5 Thank you !
— Thierry Fournier Web Performance & Security Expert m: +33 6 68 69 21 85 | e: thierry.fourn...@ozon.io w: http://www.ozon.io/ | b: http://blog.ozon.io/ > On 9 Jan 2020, at 10:47, Thierry Fournier <thierry.fourn...@ozon.io> wrote: > > > >> On 8 Jan 2020, at 13:02, Wietse Venema <wie...@porcupine.org> wrote: >> >> Thierry Fournier: >>> Hi, sorry for the response delay, I?m very busy at this time. >>> >>> >>>> On 5 Jan 2020, at 17:35, Wietse Venema <wie...@porcupine.org> wrote: >>>> >>>> Thierry Fournier: >>>>> smtp_dns_request_filter (default: empty) >>>> >>> >>> >>> [...] >>> >>> >>>> Support for multiple destinations could be implemented with: >>>> >>>> - An "smtp_fallback_relay_maps" feature that produces an additional >>>> destination depending on the domain in the delivery request. >>> >>> >>> It seems not so clean using fallback for the main target. >>> >>> >>>> - An "smtp_nexthop_override_maps" feature that replaces the domain >>>> in the delivery request with one or more domain names. You decide >>>> the order of names in the result, and if the original domain >>>> should be part of the result. Specify [name], [name] to get >>>> comparable control as with your synthetic MX records. >>> >>> >>> I like this idea, but it add a little bit of complexity for >>> understanding configuration. >>> >>> >>>> - Or, add support for multiple next-hop destinations in "relayhost", >>>> "transport_maps", and "default_transport". This changes the syntax >>>> and semantics of existing Postfix features. Again, specify [name], >>>> [name] to get comparable control as with your synthetic MX records. >>> >>> >>> I like this idea. >>> >>> >>>> Each would require about a similar number of lines of code as they >>>> would require in documentation, or less than that. That's significantly >>>> less than ~200 lines of code for the MX lookup override. >>>> >>>> I think that "smtp_nexthop_override_maps" could do the trick, with >>>> documentation updates for "transport_maps", "default_transport", >>>> and "relayhost" that point to "smtp_nexthop_override_maps". >>>> >>>> - It gives comparable control over multi-destination selection as >>>> with your proposed feature, unlike "smtp_fallback_relay_maps" >>>> which can only add a destination. >>>> >>>> - It does not change the syntax or semantics of "relayhost", >>>> "transport_maps", or "default_transport", unlike a change that >>>> would support for multiple next-hop destinations in those features. >>> >>> >>> Ok, it seems a right idea. >>> >>> I propose this kind of syntax for the ?smtp_nexthop_override_maps? >>> entries (read start to the ?entry? tag): >>> >>> dest : nexthop >>> | ?[? nexthop ?]" >>> | ?[" nexthop ?]" ?:? port >>> >>> option : name ?=? value >>> >>> options : option >>> | options ?;? option >>> >>> full-dest : nexthop >>> | nexthop ?@? options >>> >>> dests : full-dest >>> | dests ?,? full-dest >>> >>> entry : key <map-separator> dests >>> >>> >>> The only option supported in v1 is ?prio? with a numeric value. This option >>> ensure a weight in the random choice. >>> >>> For example: >>> >>> yahoo.com [mx01.local]:25@prio=10;other=example,[mx02.local]:25@prio=5 >>> >>> in the transport map: >>> >>> yahoo.com smtp:yahoo.com >>> >>> The comma and semicolon separator seems a right choice because it is >>> forbidden in ipv4 ipv6, domains name and port syntax. This choice >>> >>> Once the smtp_nexthop_override_maps is called, it perform lookup. If >>> the lookup is success, it decodes the format specially option, it >>> perform a random choice using weight. and finnaly, it decodes the nexthop >>> using internal postfix functions. >>> >>> Maybe we can use the specified syntax directly in the transports maps, >>> because it is a syntax compatible with the existant. In this case, I just >>> modify the postfix nexthop internal decoder to support the format. >> >> I would not implement the priority stuff. Users can specify preference >> by listing the 'higher' priority nexthop first. Instead of saying >> something like "foo@prio=3;bar@prio=1" one can say "bar, foo" and >> get the same behavior. > > > I agree, it is simpler than my proposal. > > >> So that means: >> - Split the lookup result into nexthops on comma/whitespace. >> - Use each nexthop in order, that's how the SMTP client already works. >> >> The looked up nexthop syntax is exactly the same as the syntax that >> Postfix already supports. This means no impact on future work. >> >> I can do that on the train to work. > > > It would be great ! Many thanks > > Thierry
