[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-devel
Subject:    Re: New functionality proposal
From:       Thierry Fournier <thierry.fournier () ozon ! io>
Date:       2020-01-13 6:57:59
Message-ID: 1B264853-E7CE-4069-84D2-8936C1794F21 () ozon ! io
[Download RAW message or body]

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.fournier@ozon.io
w: http://www.ozon.io/    | b: http://blog.ozon.io/

> On 9 Jan 2020, at 10:47, Thierry Fournier <thierry.fournier@ozon.io> wrote:
> 
> 
> 
>> On 8 Jan 2020, at 13:02, Wietse Venema <wietse@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 <wietse@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

[prev in list] [next in list] [prev in thread] [next in thread]