> 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
