[pfx] Re: Behavior of smtp_tls_security_level = dane
On Sat, Mar 16, 2024 at 11:04:46PM +0100, Dirk Stöcker via Postfix-users wrote: > From the server which has the local name server the answer has the > aa flag, but not the ad flag. That's expected when the nameserver in question is authoritative for the requested domain, no DNSSEC validation is performed, since the data is (presumably) from a trusted source. It is up to recursive servers to validate it as needed. Your configuration where the same server is both authoritative and recursive is not supported. The risk with trusting that AA-bit is that the server might be a secondary server for the zone, with an insecure channel for zone transfers, in which case the AA bit cannot be trusted. Postfix only trusts the AD bit from a validating local resolver, and trusting the AA bit would have be a new configuration option, but simpler to never mix authoritative and recursive service in the same nameserver process. On my machine, the authoriative server (BIND) only listends on the the ethernet IP interface, while the recursive server (unbound) listends only on 127.0.0.1. It validates queries for my own domain, just like for any other. > So two tasks for me: > a) fix the internal DNSSEC issue Nothing to fix in DNSSEC, rather, split the auth and recursive resolvers. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behavior of smtp_tls_security_level = dane
Hello, DANE TLSA records are strictly enforced when "well-formed", where well-formed also requires a plausible TLSA "associated data" field (expected length for SHA2-256 and SHA2-512 digests and valid DER encoding of certs or keys for matching type Full(0)). That's what I did expect. Starting with the fact that what I expect is also what should haven happened I reviewed the whole system. The reason somewhere lies in DNSSEC. The mail sending server is also the domain server for the internal target domain. When I send mail to the target from somehwere else DANE works (with updated TLSA). From the server which has the local name server the answer has the aa flag, but not the ad flag. I have to investigate what's broken here. Either a configuration change or an update broke something. It was hidden as no negative side effects were visible (I hate it when stuff fails and it's invisible, except in some logs). So two tasks for me: a) fix the internal DNSSEC issue b) monitor internal DANE as well Lesson learned: Not only external stuff must be monitored thoroughly. ;-) P.S. For https://www.postfix.org/TLS_README.html#client_tls_dane maybe the third paragraph could have added: "If there are usable, but mismatching TLSA entries, no mail is sent."? For Freedom In Peace -- http://www.dstoecker.eu/ (PGP key available) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 2024-03-15 at 14:11:03 UTC-0400 (Fri, 15 Mar 2024 13:11:03 -0500) Matt Saladna via Postfix-users is rumored to have said: Hello, I'm seeking a workaround for Microsoft's litany of IPs landing on DNSBL. They'd like all mail irrespective of DNSBL status to be delivered, which requires a skip if the sender IP is blacklisted in postscreen. With separation between postscreen and smtpd, postscreen rejects the connection before handing off to smtpd so smtpd_recipient_restrictions isn't triggered. Is there an appropriate workaround that allows postscreen to report DUNNO after DNSBL checks if the recipient matches in a table? No, which is because of how postscreen is designed, as a fit to its intended purpose. See the man page and supplementary README file for details. If you need to make recipient exceptions to postscreen, you are simply using it for the wrong function. It is a *lightweight* tool to dispose of pure spam sources without loading and using all the logic of the smtpd daemon. By default, postscreen is no longer in control by the time the greeting banner is sent. If you wish to do anything complicated with deciding whether to accept a message, you need to do it later in the SMTP transaction. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
