I wrote:
> SRV lookup can return more than one record, and those records
> specify a TCP or UDP port. It basically means that SRV returns
> someothing similar to MX lookup except that it also returns a port
> to connect to.
And:
> This means that we'd have to extend the DNS_RR with at least a
> field for the port. [and do something for the SRV 'weight' field]
And:
> Also, the Postfix DNS client should handle a null SRV record as
> "service unavailable", similar to how the Postfix DNS client returns
> DNS_NULLMX for a null MX record.
And:
> Maybe it is better for the SMTP client to not look up MX records
> if the domain starts with _submission._tcp. Then the decision to
> look up SRV could be made higher-up, at the point where the SMTP
> client decides if it wants to do MX lookups or non-MX lookups.
>
> Then we end up with a hierarchy like:
>
> smtp_connect_remote
> calls smtp_domain_addr if it really wants to do MX lookup
> calls smtp_host_addr if MX record does not exist
>
> calls smtp_srv_ddr if it really wants to do SRV lookup
> calls smtp_host_addr with the SRV lookup result
>
> calls smtp_host_addr if it wants [A or AAAA lookup]
Based on this, there is large delta between RFC 6186 and the patch
that currently exists.
- Don't do MX or A/AAAA lookups for _submission._tcp.* in the Postfix
SMTP client.
- Do support multiple SRV records, null records, and the fields for
priority, weight, and port.
Also, should there be a default sanity check for hostnames that SRV
lookup is allowed to return, such as "must be a name within the
domain after _submission._tcp"? Just imagine people using this
feature over coffeeshop or hotel WIFI.
Wietse
