[RFE] - Resolving of SRV records

[Tomas Korbar]

Hi guys,

I would like to start a discussion about support for SRV records, mainly record for submission service of a domain.

As is stated in [0], domain can publish dns record, which tells services where the submission service of this domain is.

This could be used for auto configuration of postfixs relayhost option.

I used this patch [1] to make postfix 3.5.4 support resolving of this:

"relayhost = [_submission._tcp.$mydomain]:587"

as a valid host for submission of mail in my domain. This will allow users to automate their configurations a little more.

I would like to know your opinion and whether this could be officially supported.

Thanks for any help.

[0] - https://tools.ietf.org/html/rfc6186#section-3

[1] - https://tkorbar.fedorapeople.org/postfix-3.5.4-relayhost.patch

[Wietse Venema]

Tomas Korbar:

> Hi guys,
> I would like to start a discussion about support for SRV records, mainly
> record for submission service of a domain.
> As is stated in [0], domain can publish dns record, which tells services
> where the submission service of this domain is.
> This could be used for auto configuration of postfixs relayhost option.
> I used this patch [1] to make postfix 3.5.4 support resolving of this:
> "relayhost = [_submission._tcp.$mydomain]:587"
> as a valid host for submission of mail in my domain. This will allow users
> to automate their configurations a little more.
> I would like to know your opinion and whether this could be officially
> supported.
> Thanks for any help.
>
> [0] - https://tools.ietf.org/html/rfc6186#section-3
> [1] - https://tkorbar.fedorapeople.org/postfix-3.5.4-relayhost.patch

Is "_submission._tcp" special only in the SMTP client? What happens
with "_submission._tcp.$mydomain in other Postfix programs?

The patch changes the global proto_info structure. That is unnecessary,
and I have changed Postfix 3.6 to use "const INET_PROTO_INFO *"
pointers everywhere, to prevent such unnecessary changes in the future.

What is the difference in behavior between

    [_submission._tcp.$mydomain]:587

and

    _submission._tcp.$mydomain:587

What happens when DNS lookup is disabled (smtp_lookup = native)?
I suppose the same thing that happens in other Postfix programs?

Where is the documentation that describes how this works?

The SRV handler in libpostfix-dns should parse the entire record.

These questions may seem unhelpful, but the onus is not on me to
solve the problems when someone writes new code.

        Wietse

[Tomas Korbar]

Hi,

> Is "_submission._tcp" special only in the SMTP client? What happens
> with "_submission._tcp.$mydomain in other Postfix programs?

_submission._tcp is special only to SMTP client. Behaviour of all other

programs remains the same.

> The patch changes the global proto_info structure. That is unnecessary,
> and I have changed Postfix 3.6 to use "const INET_PROTO_INFO *"
> pointers everywhere, to prevent such unnecessary changes in the future.

You are right. Fixed in the new patch posted on

https://tkorbar.fedorapeople.org/postfix-3.5.4-relayhost.patch

> What is the difference in behavior between
>
>     [_submission._tcp.$mydomain]:587
>
> and
>
>     _submission._tcp.$mydomain:587

In the first case, smtp client will perform directly lookup for SRV record of submission

service of domain specified with $mydomain.

In the second case, smtp client will at first try to perform lookup for MX record of

"_submission._tcp.$mydomain" domain, which will most likely fail and in response

to that, smtp_host_addr function will be called and that will cause the name to be

resolved the same way as in the previous case.

> What happens when DNS lookup is disabled (smtp_lookup = native)?
> I suppose the same thing that happens in other Postfix programs?

This behaviour is not changed in any way. if enclosed in square brackets

smtp client will perform lookup in /etc/hosts for A record of

"_submission._tcp.$mydomain".

On the other hand, i either do not understand the code correctly or smtp_lookup

option does not have any effect when the hostname is not enclosed in square

brackets. Either way the result is the same as in the first case. Please correct

me if i am wrong.

> Where is the documentation that describes how this works?

Please point me where I should write it.

>The SRV handler in libpostfix-dns should parse the entire record.

Ok. What is your preference on how this should be done? Should i leave it with

hostname within the buffer that gets passed to dns_rr_create function and

then handle it inside smtp_addr_one function or do you have something

else in mind?

> These questions may seem unhelpful, but the onus is not on me to
> solve the problems when someone writes new code.

On the contrary, they were very helpful.

Thanks for your help.

On Mon, Jul 27, 2020 at 4:04 PM Wietse Venema <[hidden email]> wrote:

Tomas Korbar:
> Hi guys,
> I would like to start a discussion about support for SRV records, mainly
> record for submission service of a domain.
> As is stated in [0], domain can publish dns record, which tells services
> where the submission service of this domain is.
> This could be used for auto configuration of postfixs relayhost option.
> I used this patch [1] to make postfix 3.5.4 support resolving of this:
> "relayhost = [_submission._tcp.$mydomain]:587"
> as a valid host for submission of mail in my domain. This will allow users
> to automate their configurations a little more.
> I would like to know your opinion and whether this could be officially
> supported.
> Thanks for any help.
>
> [0] - https://tools.ietf.org/html/rfc6186#section-3
> [1] - https://tkorbar.fedorapeople.org/postfix-3.5.4-relayhost.patch

Is "_submission._tcp" special only in the SMTP client? What happens
with "_submission._tcp.$mydomain in other Postfix programs?

The patch changes the global proto_info structure. That is unnecessary,
and I have changed Postfix 3.6 to use "const INET_PROTO_INFO *"
pointers everywhere, to prevent such unnecessary changes in the future.

What is the difference in behavior between

    [_submission._tcp.$mydomain]:587

and

    _submission._tcp.$mydomain:587

What happens when DNS lookup is disabled (smtp_lookup = native)?
I suppose the same thing that happens in other Postfix programs?

Where is the documentation that describes how this works?

The SRV handler in libpostfix-dns should parse the entire record.

These questions may seem unhelpful, but the onus is not on me to
solve the problems when someone writes new code.

        Wietse

[Wietse Venema]

Tomas Korbar:

> Hi,
>
> > Is "_submission._tcp" special only in the SMTP client? What happens
> > with "_submission._tcp.$mydomain in other Postfix programs?
>
> _submission._tcp is special only to SMTP client. Behaviour of all other
> programs remains the same.
>
> > The patch changes the global proto_info structure. That is unnecessary,
> > and I have changed Postfix 3.6 to use "const INET_PROTO_INFO *"
> > pointers everywhere, to prevent such unnecessary changes in the future.
>
> You are right. Fixed in the new patch posted on
> https://tkorbar.fedorapeople.org/postfix-3.5.4-relayhost.patch
>
> > What is the difference in behavior between
> >
> >     [_submission._tcp.$mydomain]:587
> >
> > and
> >
> >     _submission._tcp.$mydomain:587
>
> In the first case, smtp client will perform directly lookup for SRV record
> of submission
> service of domain specified with $mydomain.
>
> In the second case, smtp client will at first try to perform lookup for MX
> record of
> "_submission._tcp.$mydomain" domain, which will most likely fail and in
> response
> to that, smtp_host_addr function will be called and that will cause the
> name to be
> resolved the same way as in the previous case.

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.

Thwn 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 neither MX nor SRV lookup

If it turns out that smtp_srv_addr() and smtp_host_addr() are almost
the same then that code can be factored out into a helper function.

I wrote the above before I realized that SRV lookup can return more
than one record, and that 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.

This means that we'd have to extend the DNS_RR with at least a
field for the port. Maybe we can encode priority in one number.

BTW I think that your code has a memory leak - it does not free the
address returned from SRV lookup.
 
> > Where is the documentation that describes how this works?
>
> Please point me where I should write it.

If we can identify the behavior than I can add that.

> >The SRV handler in libpostfix-dns should parse the entire record.
>
> Ok. What is your preference on how this should be done? Should i
> leave it with hostname within the buffer that gets passed to
> dns_rr_create function and then handle it inside smtp_addr_one
> function or do you have something else in mind?

Whoa. SRV specifies a lot of things that your patch is ignoring.

- TCP or UDP port
- priority and weight
- there can be more than one record

Is that kosher?

        Wietse

[Wietse Venema]

Wietse Venema:
> Whoa. SRV specifies a lot of things that your patch is ignoring.
>
> - TCP or UDP port
> - priority and weight
> - there can be more than one record

Looking at RFC 6186, the Postfix client definitely should not ignore
the port in the SRV record.

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.

        Wietse

[Viktor Dukhovni]

On Mon, Jul 27, 2020 at 09:46:10AM +0200, Tomas Korbar wrote:

> Hi guys,
> I would like to start a discussion about support for SRV records, mainly
> record for submission service of a domain.
> As is stated in [0], domain can publish dns record, which tells services
> where the submission service of this domain is.
> This could be used for auto configuration of postfixs relayhost option.
> I used this patch [1] to make postfix 3.5.4 support resolving of this:
> "relayhost = [_submission._tcp.$mydomain]:587"
> as a valid host for submission of mail in my domain. This will allow users
> to automate their configurations a little more.
> I would like to know your opinion and whether this could be officially
> supported.
> Thanks for any help.
>
> [0] - https://tools.ietf.org/html/rfc6186#section-3
> [1] - https://tkorbar.fedorapeople.org/postfix-3.5.4-relayhost.patch

This RFC introduces a serious security issue.  If you're using
password-equivalent authentication (PLAIN, LOGIN) or even bearer token
for tokens that are replayable (so perhaps also OAUTH), then you MUST
NOT trust insecurely (non-DNSSEC) SRV records to redirect you to an
unknown server.

The Postfix smtp(8) client is not an interactive user-agent that can pop
up a dialogue box to confirm the validity of the purported MSA.  [And we
all know how well security-relevant user-dialogues work in any case...]

So unless you're only using client certs or CRAM or similar (the latter
stores password-equivalent secrets on the server, which is also not so
great), use of SRV records to locate the MSA has some questionable
security properties.

The MSA needs be authenticated before password-equivalent authentication
is performed.

--
    Viktor.

[Wietse Venema]

Viktor Dukhovni:

> On Mon, Jul 27, 2020 at 09:46:10AM +0200, Tomas Korbar wrote:
>
> > Hi guys,
> > I would like to start a discussion about support for SRV records, mainly
> > record for submission service of a domain.
> > As is stated in [0], domain can publish dns record, which tells services
> > where the submission service of this domain is.
> > This could be used for auto configuration of postfixs relayhost option.
> > I used this patch [1] to make postfix 3.5.4 support resolving of this:
> > "relayhost = [_submission._tcp.$mydomain]:587"
> > as a valid host for submission of mail in my domain. This will allow users
> > to automate their configurations a little more.
> > I would like to know your opinion and whether this could be officially
> > supported.
> > Thanks for any help.
> >
> > [0] - https://tools.ietf.org/html/rfc6186#section-3
> > [1] - https://tkorbar.fedorapeople.org/postfix-3.5.4-relayhost.patch
>
> This RFC introduces a serious security issue.  If you're using
> password-equivalent authentication (PLAIN, LOGIN) or even bearer token
> for tokens that are replayable (so perhaps also OAUTH), then you MUST
> NOT trust insecurely (non-DNSSEC) SRV records to redirect you to an
> unknown server.
>
> The Postfix smtp(8) client is not an interactive user-agent that can pop
> up a dialogue box to confirm the validity of the purported MSA.  [And we
> all know how well security-relevant user-dialogues work in any case...]
>
> So unless you're only using client certs or CRAM or similar (the latter
> stores password-equivalent secrets on the server, which is also not so
> great), use of SRV records to locate the MSA has some questionable
> security properties.
>
> The MSA needs be authenticated before password-equivalent authentication
> is performed.

Authenticate what hostname? The SRV record is like an MX record on
steroids, there are no guarantees about what hostname to expect.

Is DNS over HTTP supposed to be the answer for that?

        Wietse

[Viktor Dukhovni]

On Tue, Jul 28, 2020 at 02:02:06PM -0400, Wietse Venema wrote:

> > The MSA needs be authenticated before password-equivalent authentication
> > is performed.
>
> Authenticate what hostname? The SRV record is like an MX record on
> steroids, there are no guarantees about what hostname to expect.

Exactly, and yet, implicit (or perhaps even explicit, I don't recall the
details) in RFC6186 is the expectation that the hostname to be checked
in the certificate will be the *target* of the SRV RRset.

There are of course SRV-ID subject alternative names, which would be fit
for purpose, but no mainstream CA that I know of issues such
certificates.

> Is DNS over HTTP supposed to be the answer for that?

No, that's just a transport, what's needed is authenticity of the data,
while DoH and DoT are only about privacy.  For authentic DNS records,
what's needed is DNSSEC.

Now of course a particular domain's MSAs could include in their
certificates some fixed name associated with the owner-name of
the SRV RRset, and the SMTP client could be configured to expect
that name, rather than the SRV target, but I wonder how common
such deployments are in the wild.

What I see much more often than RFC6186 is various "autodiscover"
names in DNS, which serve XML data describing service location
in more detail than an SRV record:

    https://www.blackhat.com/docs/asia-17/materials/asia-17-Nesterov-All-Your-Emails-Belong-To-Us-Exploiting-Vulnerable-Email-Clients-Via-Domain-Name-Collision-wp.pdf

Deployment of RFC6186 is AFAIK rather thin at present.

--
    Viktor.

[Wietse Venema]

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

[Jaroslaw Rafa]

Could anybody explain *why* using this record by Postfix is needed at all?

As far as I understand, SRV records are meant to be use by mail *clients*, to
simplify MUA configuration by the end user (no need to type in hostnames of
IMAP and SMTP servers, etc.)

Postfix is not supposed to be configured by an end user. If you configure
Postfix to deliver mail via submission to another server, there are much
more things you need to configure (authentication being probably the most
important) and configuring the hostname and port for the submission server
is only a small part of what you need to do.

I see no big problem in manual configuration of these parameters, because
you usually do it once. You don't re-configure Postfix every day to use a
different submission server each time. Or I don't understand something.

What is the actual usage scenario you're thinking about preparing this
patch? What actual problem is it trying to solve?
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

[Peter Ajamian]

On 27/07/20 7:46 pm, Tomas Korbar wrote:
> I used this patch [1] to make postfix 3.5.4 support resolving of this:
> "relayhost = [_submission._tcp.$mydomain]:587"
> as a valid host for submission of mail in my domain.

I don't particularly care for this syntax because it clashes with syntax
for a valid domain name.  However minute, it *is* possible that
_submission._tcp.$mydomain resolves to a current valid A or AAAA record,
in which case the behavior of current postfix will differ from what it
does in the future.  I instead propose this:

relayhost = SRV:[_submission._tcp.$mydomain]:587

...the "SRV:[...]" being a unique designator that tells postfix to look
up and follow the SRV record for this hostname.  This also opens the
possibility for other designators which would offer similar-types of
functionality in the future without having to invent whole new syntax
each time.


Peter

[Peter Ajamian]

On 29/07/20 8:19 am, Jaroslaw Rafa wrote:
> Could anybody explain *why* using this record by Postfix is needed at all?
>
> As far as I understand, SRV records are meant to be use by mail *clients*, to
> simplify MUA configuration by the end user (no need to type in hostnames of
> IMAP and SMTP servers, etc.)

The discussion is for smtp, which *is* a mail client.

> I see no big problem in manual configuration of these parameters, because
> you usually do it once. You don't re-configure Postfix every day to use a
> different submission server each time. Or I don't understand something.
>
> What is the actual usage scenario you're thinking about preparing this
> patch? What actual problem is it trying to solve?

The usage scenario is for relayhosts that use an SRV record to specify
an alternate port or hostname for the server.  It means that if the SRV
record changes then you won't have to reconfigure Postfix each time
manually.


Peter

[Bastian Blank-3]

Hi Peter

On Wed, Jul 29, 2020 at 02:46:55PM +1200, Peter wrote:
> On 29/07/20 8:19 am, Jaroslaw Rafa wrote:
> > Could anybody explain *why* using this record by Postfix is needed at all?
> > As far as I understand, SRV records are meant to be use by mail *clients*, to
> > simplify MUA configuration by the end user (no need to type in hostnames of
> > IMAP and SMTP servers, etc.)
> The discussion is for smtp, which *is* a mail client.

Nope, Postfix is not a MUA.  Any the whole submission stuff is for MUA
with specific requirements.

> > I see no big problem in manual configuration of these parameters, because
> > you usually do it once. You don't re-configure Postfix every day to use a
> > different submission server each time. Or I don't understand something.
> > What is the actual usage scenario you're thinking about preparing this
> > patch? What actual problem is it trying to solve?
> The usage scenario is for relayhosts that use an SRV record to specify an
> alternate port or hostname for the server.  It means that if the SRV record
> changes then you won't have to reconfigure Postfix each time manually.

Why would the SRV record suddenly change?  RFC 6186 section 4[1] allows
the MUA to store the target information and not look at the SRV record
ever again for subsequent connections.  This somehow negates the
possibility of sudden changes to those records.

However, please describe how you would implement the requirements of RFC
6125 section 6[2]?  You can't use SRV records without support for useful
server authentication.

Bastian

[1]: https://tools.ietf.org/html/rfc6186#section-4
[2]: https://tools.ietf.org/html/rfc6125#section-6
--
What kind of love is that?  Not to be loved; never to have shown love.
                -- Commissioner Nancy Hedford, "Metamorphosis",
                   stardate 3219.8

[Michael Ströder]

On 7/29/20 9:53 AM, Bastian Blank wrote:
> However, please describe how you would implement the requirements of RFC
> 6125 section 6[2]?  You can't use SRV records without support for useful
> server authentication.

Full ack.

That's something most people overlook / ignore when naively asking for
support of SRV RRs: There's no cryptographic binding between a
configured name and the public key of the TLS server. (I see this
discussion quite often in the LDAP world.)

An RFC could specify such a name binding, e.g. by specifying a
subjectAltName form based on URLs (GeneralName.uniformResourceIdentifier).

But even if such an RFC exists public CAs would have to check the
validity of such a name / URL before issuing a TLS server cert. Which
would be another can-of-worms...

Ciao, Michael.

[Tomas Korbar]

Hi,
I'm glad that so many of you stated your opinion.
To be honest, i did not expect this feature to have any security implications.
Before i post another version of patch i would like to answer to your
questions and then summarize current opinion how this should be done,
so nobody is wasting their time.

Wietse Venema:
> 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.

Yes, definitely right approach.

>
> Thwn 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 neither MX nor SRV lookup
>
> If it turns out that smtp_srv_addr() and smtp_host_addr() are almost
> the same then that code can be factored out into a helper function.
>

Looks ok to me.

> I wrote the above before I realized that SRV lookup can return more
> than one record, and that 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.
>
> This means that we'd have to extend the DNS_RR with at least a
> field for the port. Maybe we can encode priority in one number.

I was not sure whether you would agree with the extension of DNS_RR
structure, so i was not pushing that way but yes that would be
IMHO the best approach.

>
> BTW I think that your code has a memory leak - it does not free the
> address returned from SRV lookup.

Yes, i missed it.

> Whoa. SRV specifies a lot of things that your patch is ignoring.
>
> - TCP or UDP port

Well, since port can be specified in relayhost value, i ignored it but
if DNS_RR structure will now be able to store port number then it should
be used and port specified after ':' in relayhost should be ignored instead.

> - priority and weight
> - there can be more than one record
>

I did not implement processing of multiple records since i thought that
there will be a lot comments on how this should be done and i wanted
to start the discussion and get the information first.
In the final implementation at least priority should be considered.


Viktor Dukhovni:

> This RFC introduces a serious security issue.  If you're using
> password-equivalent authentication (PLAIN, LOGIN) or even bearer token
> for tokens that are replayable (so perhaps also OAUTH), then you MUST
> NOT trust insecurely (non-DNSSEC) SRV records to redirect you to an
> unknown server.
>
> The Postfix smtp(8) client is not an interactive user-agent that can pop
> up a dialogue box to confirm the validity of the purported MSA.  [And we
> all know how well security-relevant user-dialogues work in any case...]
>
> So unless you're only using client certs or CRAM or similar (the latter
> stores password-equivalent secrets on the server, which is also not so
> great), use of SRV records to locate the MSA has some questionable
> security properties.
>
> The MSA needs be authenticated before password-equivalent authentication
> is performed.

So what you are saying is that SRV record should only be accepted if
its authenticity can be verified with DNSSEC?

Peter:

> ...the "SRV:[...]" being a unique designator that tells postfix to look
> up and follow the SRV record for this hostname.  This also opens the
> possibility for other designators which would offer similar-types of
> functionality in the future without having to invent whole new syntax
> each time.

I do not agree as there are already "unix:" and "inet:" prefixes. I do not
think that people should have A records _submission._tcp in their domains.
Also _submission._tcp.$mydomain should not be present in default configuration
so i doubt that this would affect anyone.

------------------------------------------------------------------------------

Finally,
This feature is useful for container deployment as you can have unified
configuration for multiple images.

So how this should be implemented?

Postfix will look for "_submission._tcp" prefix in relayhosts value.
Postfix will handle "_submission._tcp" the same as "[_submission._tcp]" to
prevent confusion. Also port specified after ":" is ignored because
we will get port from the SRV record.
If this prefix is found then it will perform lookup for SRV record
and accepts it only if the response is verified with dnssec. After retrieval of
all records with priorities and ports, record with the lowest priority
is choosen and postfix will try to submit mail to it. Postfix will repeat
submitting until one of the servers accepts mail. If no SRV record is found
or the response can not be verified with dnssec then postfix will respond
as service unavailable.

This is the ideal implementation as I understand it right now.
Please correct me anywhere where it is needed.

Thanks again for your opinions and information.

On Wed, Jul 29, 2020 at 10:54 AM Michael Ströder <[hidden email]> wrote:

On 7/29/20 9:53 AM, Bastian Blank wrote:
> However, please describe how you would implement the requirements of RFC
> 6125 section 6[2]?  You can't use SRV records without support for useful
> server authentication.

Full ack.

That's something most people overlook / ignore when naively asking for
support of SRV RRs: There's no cryptographic binding between a
configured name and the public key of the TLS server. (I see this
discussion quite often in the LDAP world.)

An RFC could specify such a name binding, e.g. by specifying a
subjectAltName form based on URLs (GeneralName.uniformResourceIdentifier).

But even if such an RFC exists public CAs would have to check the
validity of such a name / URL before issuing a TLS server cert. Which
would be another can-of-worms...

Ciao, Michael.

[Wietse Venema]

Tomas Korbar:
> Finally,
> This feature is useful for container deployment as you can have unified
> configuration for multiple images.

Well, I think I solved THAT problem 20 years ago, with:

    relayhost = $mydomain

which nowadays might look like

    relayhost = $mydomain:587

or

    relayhost = submission.$mydomain:587

Instead of asking sites to configure an SRV record for $mydomain,
you could ask them to configure an A record or MX record.

20-year old technology may not be as sexy as implementing the support
for an entire RFC, but it has fewer moving parts.

        Wietse

[Gerard E. Seibert]

On Wed, 29 Jul 2020 11:00:52 -0400 (EDT), Wietse Venema stated:

>Tomas Korbar:
>> Finally,
>> This feature is useful for container deployment as you can have
>> unified configuration for multiple images.  
>
>Well, I think I solved THAT problem 20 years ago, with:
>
>    relayhost = $mydomain
>
>which nowadays might look like
>
>    relayhost = $mydomain:587
>
>or
>
>    relayhost = submission.$mydomain:587
>
>Instead of asking sites to configure an SRV record for $mydomain,
>you could ask them to configure an A record or MX record.
>
>20-year old technology may not be as sexy as implementing the support
>for an entire RFC, but it has fewer moving parts.
>
> Wietse

+1

[Ralph Seichter-3]

* Tomas Korbar:

> This feature is useful for container deployment as you can have
> unified configuration for multiple images.

If you are, for some reason I cannot fathom, unable to provision each
container with a transports table (i.e. a text file), you are doing
containers wrong. ;-) It is not Postfix's job to work around that.

-Ralph