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 <mich...@stroeder.com> 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. > >
