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. |
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 |
Hi, > 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 > 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: |
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:
> 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 |
In reply to this post by Tomas Korbar
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. |
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 |
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. |
In reply to this post by 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 |
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." |
In reply to this post by Tomas Korbar
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 |
In reply to this post by Jaroslaw Rafa
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 |
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 |
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. |
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: |
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 |
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 |
In reply to this post by Tomas Korbar
* 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 |
Free forum by Nabble | Edit this page |