Re: Outgoing DANE not working
On Tue, May 19, 2020 at 01:44:30AM -0400, Rich Felker wrote: > > This sounds reasonable. Will there be a way for Postfix to detect the > > new library version, so that we don't disable DANE for musl-libc > > versions that do set the AD bit? > > I'm really disappointed with the detection, which made things much > worse by producing postfix builds that won't do DANE even after > libc.so is upgraded. It should have just worked after upgrade. We have no choice, we can't ship code that silently fails to honour its configuration. I'm not worried about DANE "working", I'm worried about DANE *not* working, and the user being none-the-wiser. When remote TLSA RRs are published, and DANE is enabled in Postfix, the mail must be delivered securely, or the delivery attempt MUST fail. > The test is also somewhat broken in that it gets the wrong result if > /bin/sh is static-linked, or if you have postfix built against musl on > a system where /bin/sh is glibc-based, etc. and I don't even know what > happens if you're cross-compiling or if that's even supported at all. A better test would be appreciated. Glibc has GLIBC_PREREQ macros, we haven't found anything similar for MUSL. > There's not really a "test for versions that do set" by version; I > would expect once the patch is upstream and tested, distros like > Alpine would just apply it to their existing musl package rather than > waiting to upgrade to get it. The only real test is a runtime one, > calling res_mkquery and observing that it's set. Sorry, no such test is possible. There is no reliable canary domain to query, and DANE should in any case also work in domains disconnected from the Internet, with locally configured trust-anchors. > BTW I saw in git master you added an additional musl test of the same > form for the res_n* APIs. A simpler way to detect them is just with > __RES macro in resolv.h, which indicates the supported API version. > AIUI it's provided by all known implementations, though I haven't > actually checked that. Robust detection of MUSL features at build time would be much appreciated. Precludes any tests that depend on live DNS queries. The tests need to *statically* test the features of the platform's C library. -- Viktor.
Re: Outgoing DANE not working
Am Dienstag, den 19.05.2020, 05:06 -0400 schrieb Viktor Dukhovni: > We have no choice, we can't ship code that silently fails to honour > its > configuration. I'm not worried about DANE "working", I'm worried > about > DANE *not* working, and the user being none-the-wiser. > Just my 50cents to make clear, that out of this not only a technical issue stuck: As the one that triggered the whole thing, I can only agree with the above. I had no chance to see in regular service of postfix why DANE was not working. The logs would not even be suspicious, as you would just guess that no DANE was configured on the partner site. Only the explicit test with a wrongly configured domain - and knowing what should happen - triggered me. But again analysing this needed capturing of the DNS traffic. Nothing regular you do. => As an end user I can only say muslc needs to be very transparent on what features it supports and what not. And should pop the question on missing parts with developers and package maintainers (e.g. build time, dev testing), that actually understand what is happening. This should not be something handled by an end user. @Rich: Seeing the stubs in the muslc code was probably the worst for me in terms of reducing confidence in muslc, hence reverted all my services back to glibc
Re: easiest way to reject/process emails based on Return Path
Dnia 18.05.2020 o godz. 22:38:11 yuv pisze: > The problem of Internet email is the problem of any federated standard. > Embrace, Extend, Extinguish. Internet email is being replaced by text > messaging, and I dare betting that fax will survive Internet email, > because fax has a niche that Internet email has failed to create for > itself. > > Fax niche is the communication with adverse interest. A minimum common > denominator, that enable the less powerful of the parties to stay in the > game. Internet email could have been even better. Could have... > > I am not expecting process serving standards (though I wish mechanical > process serving could be replaced by something electronic). Just the same > reliability of fax transmission (if the message gets lost after the 250, > the fax operator is liable) would be good enough to give Internet email > more purpose than the delivery of spam. As a non-lawyer, it is hard for me to understand what you're trying to debate about. Even physical postal mail service does not give any guarantee that the recipient has actually READ your mail. (BTW, it's even a recurring theme in movies and books that person A keeps sending letters to person B, but they never get to the recipient as some other person C, who is a family member of person B, intercepts and hides them). Even if you send via registered mail and request delivery confirmation, nobody will guarantee you that the recipient hasn't thrown your letter into the trash right away after picking it up from the post office. If you have your OWN SERVER, a 250 reply to SMTP transaction is an equivalent of confirming that the message has arrived into your "mailbox". But by the "mailbox", we should consider the entire mail system here, as it's your own mail system and it's you who decides how it works. If YOU decided, that messages matching particular criteria are silently discarded (which is technically the same as deleting them right away after they are delivered), it's equal to the case I described above - where YOU throw the physical letter into the trash right away after having it delivered to you. In both cases it's the recipient who decided to discard the message without looking at it. What's ethically doubtful in this? If it were a third party who discarded the message - yes, that would be unethical (and probably against the law as well). But if the recipient does it him/herself - I can see no ethical or legal issue at all. What more do you want to expect from SMTP? Do you want to expect it to provide something that even physical mail - and similarly your glorified fax - doesn't provide? Ie. a guarantee that recipient has actually READ your mail? No asynchronous communication method will guarantee you that, simply because of the very fact it's asynchronous, ie. the delivery of the message is separated in time from the act of actually reading it by the recipient, and the latter may never happen (imagine sending e-mail to a still functioning e-mail address of a person who has just died; the same is true for postal mail and fax as well. Is a 250 reply in that case also a "lie" or "misrepresentation"?). If you want to have guarantee that your message actually got to the recipient, you must use synchronous communication - face-to-face meeting, telephone, videoconference etc. so that you can see/hear the actual response of your correspondent in real time. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "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."
On-Hold instead of sending
Sorry for asking instead of researching and testing myself (time pressure), but can someone tell me how to define a transport that would move all mail from the IP x.y.z.q to the On-Hold queue instead of sending it normally? Sorry again, I need it fast and correct, will not do this again, promise. Thank you. -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte ---
Microsoft Servers with DANE & DNSSEC
Microsoft has finally decided to add DANE and DNSSEC support to Exchange Online servers. https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494 -- Jerry pgpn6634G_3L3.pgp Description: OpenPGP digital signature
Re: On-Hold instead of sending
On 19.05.20 11:43, Daniel Ryšlink wrote: Sorry for asking instead of researching and testing myself (time pressure), but can someone tell me how to define a transport that would move all mail from the IP x.y.z.q to the On-Hold queue instead of sending it normally? header_checks on Received: header and the IP with HOLD action. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 42.7 percent of all statistics are made up on the spot.
Re: Outgoing DANE not working
Viktor Dukhovni: > Robust detection of MUSL features at build time would be much > appreciated. Precludes any tests that depend on live DNS queries. > The tests need to *statically* test the features of the platform's > C library. Agreed. You're welcome to provide a reliable static test (no live DNS). Until then, Postfix will build without DANE support. Wietse
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 05:06:10AM -0400, Viktor Dukhovni wrote:
> On Tue, May 19, 2020 at 01:44:30AM -0400, Rich Felker wrote:
>
> > > This sounds reasonable. Will there be a way for Postfix to detect the
> > > new library version, so that we don't disable DANE for musl-libc
> > > versions that do set the AD bit?
> >
> > I'm really disappointed with the detection, which made things much
> > worse by producing postfix builds that won't do DANE even after
> > libc.so is upgraded. It should have just worked after upgrade.
>
> We have no choice, we can't ship code that silently fails to honour its
> configuration. I'm not worried about DANE "working", I'm worried about
> DANE *not* working, and the user being none-the-wiser.
>
> When remote TLSA RRs are published, and DANE is enabled in Postfix, the
> mail must be delivered securely, or the delivery attempt MUST fail.
>
> > The test is also somewhat broken in that it gets the wrong result if
> > /bin/sh is static-linked, or if you have postfix built against musl on
> > a system where /bin/sh is glibc-based, etc. and I don't even know what
> > happens if you're cross-compiling or if that's even supported at all.
>
> A better test would be appreciated. Glibc has GLIBC_PREREQ macros,
> we haven't found anything similar for MUSL.
The is fundamentally no build-time test possible for this. Even if we
were willing to make flags for each bug (or missing feature) that was
ever fixed indicating the change, that would only tell you whether the
version present at build time had the property, not whether the
version present at runtime does. With a distro, unless the distro
manually makes their package file depend on a particular version of
the distro libc package (which they can do very well, since they know
what patches they applied), it's possible for a user to upgrade
postfix but not libc. And for a user building everything from source
manually, that work's on them.
> > There's not really a "test for versions that do set" by version; I
> > would expect once the patch is upstream and tested, distros like
> > Alpine would just apply it to their existing musl package rather than
> > waiting to upgrade to get it. The only real test is a runtime one,
> > calling res_mkquery and observing that it's set.
>
> Sorry, no such test is possible. There is no reliable canary domain to
> query, and DANE should in any case also work in domains disconnected
> from the Internet, with locally configured trust-anchors.
Canary domain is not needed for a runtime test. All that's needed is a
call to res_mkquery with a dummy domain and inspection of buf[3]. (Of
course you can also just set the bit at query time in exactly the same
manner, but that only works for replacing res_query not res_search. I
don't understand why you're using res_search at all in mail software
though.)
> > BTW I saw in git master you added an additional musl test of the same
> > form for the res_n* APIs. A simpler way to detect them is just with
> > __RES macro in resolv.h, which indicates the supported API version.
> > AIUI it's provided by all known implementations, though I haven't
> > actually checked that.
>
> Robust detection of MUSL features at build time would be much
> appreciated. Precludes any tests that depend on live DNS queries.
> The tests need to *statically* test the features of the platform's
> C library.
This is an area of open cross-implementation effort to provide
something meaningful. See the thread here:
https://www.openwall.com/lists/libc-coord/2020/04/22/1
Note that the "Possibly this should include the semantics for
definition with a value of 0 ("supported for compilation and might or
might not be supported at runtime")..." text applies here since a
static build-time test does not suffice here.
Rich
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 09:22:59AM -0400, Wietse Venema wrote: > Viktor Dukhovni: > > Robust detection of MUSL features at build time would be much > > appreciated. Precludes any tests that depend on live DNS queries. > > The tests need to *statically* test the features of the platform's > > C library. > > Agreed. You're welcome to provide a reliable static test (no live DNS). > Until then, Postfix will build without DANE support. And then distros will just patch out the breakage. I came at this issue trying to get a clean solution, but if the Postfix position is that the project is going to continue to hard-code incorrect "is musl libc?" tests in the build and disable important functionality because of some grudge over us being unwilling to do something that's not even possible (build-time test for a run-time property), it's just going to end up being something that distros patch around.
Re: Outgoing DANE not working
Rich Felker: > The is fundamentally no build-time test possible for this. Even if we > were willing to make flags for each bug (or missing feature) that was > ever fixed indicating the change, that would only tell you whether the > version present at build time had the property, not whether the > version present at runtime does. With a distro, unless the distro If you can provide a libc-musl runtime __version variable, then Postfix can at run time determine that the library supports the necessary functionality, and enable/disable DANE accordingly. Wietse
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote: > Rich Felker: > > The is fundamentally no build-time test possible for this. Even if we > > were willing to make flags for each bug (or missing feature) that was > > ever fixed indicating the change, that would only tell you whether the > > version present at build time had the property, not whether the > > version present at runtime does. With a distro, unless the distro > > If you can provide a libc-musl runtime __version variable, then > Postfix can at run time determine that the library supports the > necessary functionality, and enable/disable DANE accordingly. We've been over this countless times from folks requesting version numbers. A version number does not tell you what you want to know. Distros will patch the functionality into whatever version they're shipping. A 1.1.25 (if it ever happens) will likely have the patch backported (just applied; no conflict). Querying features has to be done on a per-feature basis not based on version numbers. See the proposal on libc-coord.
Re: Outgoing DANE not working
Rich Felker: > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote: > > Rich Felker: > > > The is fundamentally no build-time test possible for this. Even if we > > > were willing to make flags for each bug (or missing feature) that was > > > ever fixed indicating the change, that would only tell you whether the > > > version present at build time had the property, not whether the > > > version present at runtime does. With a distro, unless the distro > > > > If you can provide a libc-musl runtime __version variable, then > > Postfix can at run time determine that the library supports the > > necessary functionality, and enable/disable DANE accordingly. > > We've been over this countless times from folks requesting version > numbers. A version number does not tell you what you want to know. > Distros will patch the functionality into whatever version they're > shipping. A 1.1.25 (if it ever happens) will likely have the patch > backported (just applied; no conflict). Querying features has to be > done on a per-feature basis not based on version numbers. See the > proposal on libc-coord. Do let us know when libc-musl provides an indication whether a DNS lookup result is authentic (DNSSEC pass). Then a year or two later we can consider to re-enable DANE for libc-musl builds. Wietse
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote: > Rich Felker: > > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote: > > > Rich Felker: > > > > The is fundamentally no build-time test possible for this. Even if we > > > > were willing to make flags for each bug (or missing feature) that was > > > > ever fixed indicating the change, that would only tell you whether the > > > > version present at build time had the property, not whether the > > > > version present at runtime does. With a distro, unless the distro > > > > > > If you can provide a libc-musl runtime __version variable, then > > > Postfix can at run time determine that the library supports the > > > necessary functionality, and enable/disable DANE accordingly. > > > > We've been over this countless times from folks requesting version > > numbers. A version number does not tell you what you want to know. > > Distros will patch the functionality into whatever version they're > > shipping. A 1.1.25 (if it ever happens) will likely have the patch > > backported (just applied; no conflict). Querying features has to be > > done on a per-feature basis not based on version numbers. See the > > proposal on libc-coord. > > Do let us know when libc-musl provides an indication whether a DNS > lookup result is authentic (DNSSEC pass). It is now in master. I've also recommended the patch to Alpine. > Then a year or two later > we can consider to re-enable DANE for libc-musl builds. You're welcome to give us a ping when distros no longer need to patch the broken check out, but I imagine they'll discover this themselves. Rich
Re: Outgoing DANE not working
Rich Felker: > On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote: > > Rich Felker: > > > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote: > > > > Rich Felker: > > > > > The is fundamentally no build-time test possible for this. Even if we > > > > > were willing to make flags for each bug (or missing feature) that was > > > > > ever fixed indicating the change, that would only tell you whether the > > > > > version present at build time had the property, not whether the > > > > > version present at runtime does. With a distro, unless the distro > > > > > > > > If you can provide a libc-musl runtime __version variable, then > > > > Postfix can at run time determine that the library supports the > > > > necessary functionality, and enable/disable DANE accordingly. > > > > > > We've been over this countless times from folks requesting version > > > numbers. A version number does not tell you what you want to know. > > > Distros will patch the functionality into whatever version they're > > > shipping. A 1.1.25 (if it ever happens) will likely have the patch > > > backported (just applied; no conflict). Querying features has to be > > > done on a per-feature basis not based on version numbers. See the > > > proposal on libc-coord. > > > > Do let us know when libc-musl provides an indication whether a DNS > > lookup result is authentic (DNSSEC pass). > > It is now in master. I've also recommended the patch to Alpine. A pointer to how one would use the updated code would be welcome, perhaps a pointer to the submit message. I won't comment on distro maintainers who willingly break Postfix's security guarantees of DANE, without informing the user. Wietse
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 10:28:57AM -0400, Rich Felker wrote: > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote: > > Rich Felker: > > > The is fundamentally no build-time test possible for this. Even if we > > > were willing to make flags for each bug (or missing feature) that was > > > ever fixed indicating the change, that would only tell you whether the > > > version present at build time had the property, not whether the > > > version present at runtime does. With a distro, unless the distro > > > > If you can provide a libc-musl runtime __version variable, then > > Postfix can at run time determine that the library supports the > > necessary functionality, and enable/disable DANE accordingly. > > We've been over this countless times from folks requesting version > numbers. A version number does not tell you what you want to know. > Distros will patch the functionality into whatever version they're > shipping. A 1.1.25 (if it ever happens) will likely have the patch > backported (just applied; no conflict). Querying features has to be > done on a per-feature basis not based on version numbers. See the > proposal on libc-coord. So long as they don't remove support for the new functionality, there's no problem. Users will only get DANE support in Postfix + MUSL if the C library version is high enough. Again, it is fine if DANE support is disabled, the users will deploy a system where it is not (a later base, before patches, version of MUSL), if they care enough. What is NOT fine, is believing that DANE is enabled and working when the library simply ignores RES_USE_DNSSEC. Postfix MUST disable DANE support on such systems. Please provide a static compile-time mechanism to determine whether the platform's libc will return the AD from the local resolver when RES_USE_DNSSEC is set (perhaps provide a new macro we can test for at compile-time). We could perhaps indeed call res_mkquery and look whether the AD bit is set in the header, though this is rather complicated, because many systems will instead set the DO bit in the EDNS header, and so we'd need to parse the query, check the additional section looking for an OPT RR with the DO bit set. I am not particularly keen on doing this. Rather, if you're claiming to support RES_USE_DNSSEC, but not actually setting the DO bit, please provide a macro that indicates you'll be setting the AD bit instead, and we can test for that at build time. -- Viktor.
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 01:25:52PM -0400, Wietse Venema wrote: > Rich Felker: > > On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote: > > > Rich Felker: > > > > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote: > > > > > Rich Felker: > > > > > > The is fundamentally no build-time test possible for this. Even if > > > > > > we > > > > > > were willing to make flags for each bug (or missing feature) that > > > > > > was > > > > > > ever fixed indicating the change, that would only tell you whether > > > > > > the > > > > > > version present at build time had the property, not whether the > > > > > > version present at runtime does. With a distro, unless the distro > > > > > > > > > > If you can provide a libc-musl runtime __version variable, then > > > > > Postfix can at run time determine that the library supports the > > > > > necessary functionality, and enable/disable DANE accordingly. > > > > > > > > We've been over this countless times from folks requesting version > > > > numbers. A version number does not tell you what you want to know. > > > > Distros will patch the functionality into whatever version they're > > > > shipping. A 1.1.25 (if it ever happens) will likely have the patch > > > > backported (just applied; no conflict). Querying features has to be > > > > done on a per-feature basis not based on version numbers. See the > > > > proposal on libc-coord. > > > > > > Do let us know when libc-musl provides an indication whether a DNS > > > lookup result is authentic (DNSSEC pass). > > > > It is now in master. I've also recommended the patch to Alpine. > > A pointer to how one would use the updated code would be welcome, > perhaps a pointer to the submit message. https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633 > I won't comment on distro maintainers who willingly break Postfix's > security guarantees of DANE, without informing the user. I'm not encouraging any to do that; rather I've encouraged them to take measures to both: (1) ensure that DANE is not silently ignored, by either patching Postfix to work with old musl (prior to the above commit) or patching the musl package and adding a dependency from the postfix package on the updated musl package, and: (2) not ship Postfix packages with DNSSEC/DANE disabled, because that would encourage admins to switch DANE off in their config files to "fix the breakage" after upgrading, then forget to turn it back on once updated packages are available to make it work. I haven't been through this with other distros yet, but Alpine folks were committed to both of these principles. Rich
Re: Outgoing DANE not working
Rich Felker: > > > > Do let us know when libc-musl provides an indication whether a DNS > > > > lookup result is authentic (DNSSEC pass). > > > > > > It is now in master. I've also recommended the patch to Alpine. > > > > A pointer to how one would use the updated code would be welcome, > > perhaps a pointer to the submit message. > > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633 I understand that the AD (authentic data) bit now is 'true' if DNSSEC validation was successful. Thanks for that. Meanwhile I'll look into the possibility of a quick runtime check whether AD is propagated. It may be missing for reasons that have nothing to do with libc-musl. That would harden the DANE implementation agains accidental deployment in an environment that does no DNSSEC validation. Wietse
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 04:08:32PM -0400, Rich Felker wrote: > I'm not encouraging any to do that; rather I've encouraged them to > take measures to both: > > (1) ensure that DANE is not silently ignored, by either patching > Postfix to work with old musl (prior to the above commit) or patching > the musl package and adding a dependency from the postfix package on > the updated musl package, and: Patching Postfix "work" with old MUSL would be a terrible mistake. Please make it quite clear to them that they MUST NOT do that. It would cause massive breakage, and just give DANE a bad name. > (2) not ship Postfix packages with DNSSEC/DANE disabled, because that > would encourage admins to switch DANE off in their config files to > "fix the breakage" after upgrading, then forget to turn it back on > once updated packages are available to make it work. That's a better outcome than having DANE enabled and causing active breakage. > I haven't been through this with other distros yet, but Alpine folks > were committed to both of these principles. Then they still don't understand the issues well enough to do the right thing... -- Viktor.
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 05:19:26PM -0400, Wietse Venema wrote: > > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633 > > I understand that the AD (authentic data) bit now is 'true' if > DNSSEC validation was successful. Thanks for that. > > Meanwhile I'll look into the possibility of a quick runtime check > whether AD is propagated. It may be missing for reasons that have > nothing to do with libc-musl. But keep in mind that the AD bit (in outgoing queries) is not required in outgoing queries if the DO bit is instead present in the EDNS OPT RR. Indeed that's what happens with "old glibc" and BSD libc. We set RES_USE_DNSSEC and the library sets the DO bit. Setting just the AD bit is a recent innovation with new glibc, where we may/must set RES_TRUST_AD instead, and with future MUSL where RES_USE_DNSSEC is a NOOP, but the AD bit may be set in res_mkquery(), which we can perhaps check by inspecting the output of a suitable res_mkquery() call during initialization. For the initialization call be to general, it needs to include detection and parsing of EDNS OPT psuedo-RRs, with success either if the AD-bit is set or the DO bit is set. Another option, is to use res_mkquery() + res_send() rather than res_search(), in which case we can set the AD bit, and not even bother with RES_USE_DNSSEC|RES_EDNS0. -- Viktor.
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 06:51:57PM -0400, Viktor Dukhovni wrote: > On Tue, May 19, 2020 at 04:08:32PM -0400, Rich Felker wrote: > > > I'm not encouraging any to do that; rather I've encouraged them to > > take measures to both: > > > > (1) ensure that DANE is not silently ignored, by either patching > > Postfix to work with old musl (prior to the above commit) or patching > > the musl package and adding a dependency from the postfix package on > > the updated musl package, and: > > Patching Postfix "work" with old MUSL would be a terrible mistake. > Please make it quite clear to them that they MUST NOT do that. > It would cause massive breakage, and just give DANE a bad name. By patching it *to work*, I mean so that DANE is enforced correctly. Not so that it silently ignores DANE records. Sorry for not making that more clear. > > (2) not ship Postfix packages with DNSSEC/DANE disabled, because that > > would encourage admins to switch DANE off in their config files to > > "fix the breakage" after upgrading, then forget to turn it back on > > once updated packages are available to make it work. > > That's a better outcome than having DANE enabled and causing active > breakage. > > > I haven't been through this with other distros yet, but Alpine folks > > were committed to both of these principles. > > Then they still don't understand the issues well enough to do the > right thing... I think we just had a miscommunication here and we're all actually on the same page. Rich
Re: Outgoing DANE not working
On Tue, May 19, 2020 at 07:00:57PM -0400, Viktor Dukhovni wrote: > On Tue, May 19, 2020 at 05:19:26PM -0400, Wietse Venema wrote: > > > > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633 > > > > I understand that the AD (authentic data) bit now is 'true' if > > DNSSEC validation was successful. Thanks for that. > > > > Meanwhile I'll look into the possibility of a quick runtime check > > whether AD is propagated. It may be missing for reasons that have > > nothing to do with libc-musl. > > But keep in mind that the AD bit (in outgoing queries) is not required > in outgoing queries if the DO bit is instead present in the EDNS OPT RR. > Indeed that's what happens with "old glibc" and BSD libc. We set > RES_USE_DNSSEC and the library sets the DO bit. > > Setting just the AD bit is a recent innovation with new glibc, where we > may/must set RES_TRUST_AD instead, and with future MUSL where > RES_USE_DNSSEC is a NOOP, but the AD bit may be set in res_mkquery(), > which we can perhaps check by inspecting the output of a suitable > res_mkquery() call during initialization. > > For the initialization call be to general, it needs to include detection > and parsing of EDNS OPT psuedo-RRs, with success either if the AD-bit > is set or the DO bit is set. Indeed, that sounds like a bigger task than I initially expected. > Another option, is to use res_mkquery() + res_send() rather than > res_search(), in which case we can set the AD bit, and not even > bother with RES_USE_DNSSEC|RES_EDNS0. That's exactly what I proposed from the beginning, and it's the patch Alpine is currently testing, though they also plan to patch musl so they may end up not needing it. I think with latest glibc though you'd also need to force the trust-ad flag, or glibc would strip AD from the result. Given how AD interacts with DANE, it seems like stripping it is a really bad idea (disables DANE), and we should probably push for glibc to reconsider doing it at all... Rich
Re: On-Hold instead of sending
Thank you most kindly, it works. -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 19. 05. 20 12:50, Matus UHLAR - fantomas wrote: On 19.05.20 11:43, Daniel Ryšlink wrote: Sorry for asking instead of researching and testing myself (time pressure), but can someone tell me how to define a transport that would move all mail from the IP x.y.z.q to the On-Hold queue instead of sending it normally? header_checks on Received: header and the IP with HOLD action.
