Thanks for separating. Forwarded the remaining thread that was decoupled from the mailing list:
> Von: Ömer Güven <omer.gu...@zuplu.com> > Datum: 9. Februar 2025 um 18:30:08 MEZ > An: akritrim® Intelligence™ <inli...@akritrim.net> > Betreff: Aw: [pfx] Re: [Bug report] Allow opportunistic DANE when non-DNSSEC > signed MX points to DNSSEC-signed SMTP server with TLSA enabled > > Please ensure that your DNS resolver is set up correctly. Maybe it queried a > „not found“ and cached that before you corrected the DNS setting in > config.yaml. This seems the most likely case as manual querying returns a > normal result. Normally querying should not take more than 50-100 ms for both > lookups. > After about 10-15 minutes, the cache should be cleared. > I‘ll add a method to purge the cache manually in the next release. > >> Am 09.02.2025 um 18:19 schrieb akritrim® Intelligence™ >> <inli...@akritrim.net>: >> yup i did. also i get >> >> INFO: No Policy found for gmail.com >> >> however manual query returns the right result. >> >> i tested outlook.com and it works perfectly. >> >> so i don't think there is any issue with my setup. >> >> there is one observation however. the manual query for dane takes more than >> 1 second for gmail while for outlook it takes around half of that and for >> some domains even less than that. >> >> i am wondering if this is the problem. I am not sure if a bug report can be >> filed for this. >> >> >> cheers >> >>> On February 9, 2025 3:45:34 PM UTC, "Ömer Güven via Postfix-users" >>> <postfix-users@postfix.org> wrote: >>> Please open an issue in GitHub for problems with postfix-tlspol in the >>> future. >>> I can say that you probably misconfigured something. It has to say >>> ‚Verified TLS‘, so it didn‘t work in your case. >>> >>> Did you use the correct port and socketmap verb? >>> It isn‘t the same as postfix-mta-sts-resolver >>> (socketmap:inet:127.0.0.1:8461:postfix), but rather >>> socketmap:inet:127.0.0.1:8642:QUERY >>> >>> Best, >>> Ömer >>> >>>> Am 09.02.2025 um 16:36 schrieb Ömer Güven <omer.gu...@zuplu.com>: >>>> I can only endorse this. Simply setting it to „dane“ should solve the >>>> hassle and make the operation more consistent and predictable. >>>> Thanks, >>>> Ömer >>>>> Am 09.02.2025 um 15:58 schrieb Wietse Venema via Postfix-users >>>>> <postfix-users@postfix.org>: >>>>> I think that the mistake was to make smtp_tls_dane_insecure_mx_policy >>>>> dependent on smtp_tls_security_level >>>>> Will it please Viktor and Omer if I change the default to >>>>> smtp_tls_dane_insecure_mx_policy = dane >>>>> That seems to have less of a WTF factor. >>>>> Here is my motivation to make make dane policy evaluation NOT >>>>> dependent on smtp_tls_security_level. >>>>> In today's world it seems natural, to me at least, to set >>>>> smtp_tls_security_level to 'may' as a default baseline for all >>>>> deliveries, and then use policy lookup for sites that are ready for >>>>> stronger security. >>>>> For this reason alone, smtp_tls_security_level is not a good >>>>> way to express how to handle a DANE half-edge case. >>>>> Asking people to configure different transports for this case, >>>>> kind of defeats the purpose of having smtp_tls_policy_maps. >>>>> Thus, I propose to decouple smtp_tls_dane_insecure_mx_policy >>>>> from smtp_tls_security_level >>>>> Starting with today's baseline level of 'may', Over time one can >>>>> evolve the baseline to 'encrypt', and eventually use 'secure' as >>>>> the baseline, and (NOTE: role switch!) use samtp_tls_policy_maps >>>>> for sites that need weaker security. >>>>> So there is my longer-term perspective: today, use policy maps to >>>>> harden security for specific sites. In the future, use use policy >>>>> maps to weaken security for specific sites. >>>>> Decoupling smtp_tls_dane_insecure_mx_policy from smtp_tls_security_level >>>>> will delay the Postfix 3.10.0 stable release by another day, but it >>>>> would be worth it. >>>>> Wietse >>>>> _______________________________________________ >>>>> Postfix-users mailing list -- postfix-users@postfix.org >>>>> To unsubscribe send an email to postfix-users-le...@postfix.org >>>> _______________________________________________ >>>> Postfix-users mailing list -- postfix-users@postfix.org >>>> To unsubscribe send an email to postfix-users-le...@postfix.org >> >> akritrim® Intelligence™ > Am 09.02.2025 um 18:28 schrieb Wietse Venema via Postfix-users > <postfix-users@postfix.org>: > > This is not a tlspol question. > >> sending to gmail shows up as verified connections but > > With Postfix, 'verified' means that the certificate matched, either > by name or by fingerprint (from certificate or public key). > >> recieving from gmail shows up as trusted connections > > With Postfix, 'trusted' means that the chain of trust is valid, > from the root all the way to the server certificate. > > Postfix by default does not 'verify' client certificates. The TLS > stack does not know what certificate name or fingerprint to expect > ***DURING THE TLS HANDSSHAKE***. > > Wietse > _______________________________________________ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
