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.
Thierry
