[RFE] - Resolving of SRV records

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFE] - Resolving of SRV records

hmiller
Asking user to type in “_submission._tcp” seems like a poor workaround. This being Autodiscovery it’d be logical for Postfix to automagically derive SRV lookup address based on relayhost setting.

“relayhost = example.com” is an obvious candidate for SRV autodiscovery if an MX lookup fails or if SRV is prefered over MX. With an optional switch to disable “relayhost_autodiscovery”.
Reply | Threaded
Open this post in threaded view
|

Re: [RFE] - Resolving of SRV records

Wietse Venema
Henry Miller:
> Asking user to type in ?_submission._tcp? seems like a poor
> workaround. This being Autodiscovery it?d be logical for Postfix
> to automagically derive SRV lookup address based on relayhost
> setting.
>
> ?relayhost = example.com? is an obvious candidate for SRV autodiscovery
> if an MX lookup fails or if SRV is prefered over MX. With an
> optional switch to disable ?relayhost_autodiscovery?.

Except that a) the SMTP client does not know whether a destination is
derived from the relayhost parameter and b) it's entirely legitimate
to specify the up-stream relay with transport_maps or default_transport.

That would be an argument against making the relayhost parameter
special, and in favor of using special destination syntax.

A challenge with special destination syntax (see below) is that
we want to allow these in main.cf and transport maps, but not in
user-specified email addresses.

syntax                      |lookups
==================================================
example.com                 |MX (SMTP client only) then A/AAAA
[example.com]               |A/AAAA (all programs)
_submission._tcp.example.com|SRV (SMTP client only) then A/AAAA
<example.com>               |SRV then A/AAAA (invalid outside the SMTP client)
SRV:example.com             |SRV then A/AAAA (invalid outside the SMTP client)

The fourth example uses angle brackets instead of [].

The _submission._tcp.example.com would require extra code to block
this in user-specified email addresses; the forms SRV:example.com,
<example.com> and [example.com] are rejected by Postfix's syntax
checks for email address domains.

In any case, autoconfiguration is no good without the part that
validates the hostnames in SRV responses. That part needs to be
configurable, and needs a good default value.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: [RFE] - Resolving of SRV records

Richard Salts
On 30/07/2020 12:47 am, Wietse Venema wrote:

> Henry Miller:
>> Asking user to type in ?_submission._tcp? seems like a poor
>> workaround. This being Autodiscovery it?d be logical for Postfix
>> to automagically derive SRV lookup address based on relayhost
>> setting.
>>
>> ?relayhost = example.com? is an obvious candidate for SRV autodiscovery
>> if an MX lookup fails or if SRV is prefered over MX. With an
>> optional switch to disable ?relayhost_autodiscovery?.
> Except that a) the SMTP client does not know whether a destination is
> derived from the relayhost parameter and b) it's entirely legitimate
> to specify the up-stream relay with transport_maps or default_transport.
>
> That would be an argument against making the relayhost parameter
> special, and in favor of using special destination syntax.
>
> A challenge with special destination syntax (see below) is that
> we want to allow these in main.cf and transport maps, but not in
> user-specified email addresses.
>
> syntax                      |lookups
> ==================================================
> example.com                 |MX (SMTP client only) then A/AAAA
> [example.com]               |A/AAAA (all programs)
> _submission._tcp.example.com|SRV (SMTP client only) then A/AAAA
> <example.com>               |SRV then A/AAAA (invalid outside the SMTP client)
> SRV:example.com             |SRV then A/AAAA (invalid outside the SMTP client)
>
> The fourth example uses angle brackets instead of [].
>
> The _submission._tcp.example.com would require extra code to block
> this in user-specified email addresses; the forms SRV:example.com,
> <example.com> and [example.com] are rejected by Postfix's syntax
> checks for email address domains.

Also where does _submissions._tcp.example.com for TLS on connect rather
than STARTTLS services fit in? I assume the client autoconfig
advertising should allow this since submissions has been put back on the
table by the IETF. Would that be another reason to not use the
_submission._tcp.example.com in config? Would it maybe be better for an
option in main/overridden in master for specific transports to specify
methods of host discovery with default being current behaviour of MX
then A/AAAA but with the options of SRV-SMTP, SRV-SUBMISSION,
SRV-SUBMISSIONS being options in a list that's tried in order?

>
> In any case, autoconfiguration is no good without the part that
> validates the hostnames in SRV responses. That part needs to be
> configurable, and needs a good default value.
>
> Wietse