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