Viktor Dukhovni:
> On Mon, Aug 08, 2022 at 12:22:05PM -0400, Wietse Venema wrote:
>
> > Could this not better be done with a transport_maps plugin, for example
> >
> > transport_maps = tcp:host:port
> > transport_maps = socketmap:inet:host:port:name
> > transport_maps = socketmap:unix:pathname:name
> >
> > Just asking, because Postfix is primarily an MTA, MUA is not
> > core fucntionality, and these are fairly invasive changes.
>
> I'd want to avoid magic nexthop names, and if this were to be supported,
> trigger it via a new smtp(8) parameter, that would be turned on for a
> custom transport. Something along the lines of:
>
> sumitc unix ... smtp
> -o smtp_query_submission_srv=yes
>
> And then route various domains to that transport:
>
> transport:
> example.net submitc:example.net:587
I still don't understand why SRV support necessitates the implementation
of dedicated smtp_connect_addr() functions and invasive changes to
the Postfix connection management code.
All we need is a small bit of code that transforms SRV lookup results
into a list of [host]:port forms that the Postfix SMTP client already
understands.
The submitc delivery agent could be implemented as a small program
that does SRV lookups, transformd the result into a list of [host]:port
forms, generates a delivery request for the existing Postfix SMTP
client, and then invokes deliver_pass_all() for the result to pass
it to an unmodified Postfix SMTP client.
Or that new code could be inside the SMTP client as something that
transforms the delivery request without ever touching any connection
management code.
Either way, there is no need to change any of the Postfix SMTP
client connection management code. All we need is to transform
a delivery request.
Wietse
