Sean McBride:
> On 9 Feb 2025, at 10:00, Wietse Venema via Postfix-users wrote:
>
> > Please use a real resolver. RedHat tooling may be fine for desktoops
> > but not for infrastructure. That's the polite version.
>
> Gotcha, thanks.
>
> Alternatively, if I use FreeBSD, is the local-unbound(8) t
On 2025-02-09 at 12:45:00 UTC-0500 (Sun, 09 Feb 2025 12:45:00 -0500)
Sean McBride via Postfix-users
is rumored to have said:
On 9 Feb 2025, at 10:00, Wietse Venema via Postfix-users wrote:
Please use a real resolver. RedHat tooling may be fine for desktoops
but not for infrastructure. That's
On 9 Feb 2025, at 10:00, Wietse Venema via Postfix-users wrote:
> Please use a real resolver. RedHat tooling may be fine for desktoops
> but not for infrastructure. That's the polite version.
Gotcha, thanks.
Alternatively, if I use FreeBSD, is the local-unbound(8) that's installed in
base usabl
Thanks for separating.
Forwarded the remaining thread that was decoupled from the mailing list:
> Von: Ömer Güven
> Datum: 9. Februar 2025 um 18:30:08 MEZ
> An: akritrim® Intelligence™
> Betreff: Aw: [pfx] Re: [Bug report] Allow opportunistic DANE when non-DNSSEC
> signed MX points to DNSSEC-s
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'
Please consider this example:
tum.de is dane-only
mri.tum.de is dane (because they didn‘t sign the MX record, but the MX is
virtually the same signed DANE-supporting SMTP server)
The Postfix config looks like this:
smtp_dns_support_level = dnssec
smtp_tls_security_level = may
smtp_tls_policy_ma
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
(socket
On Sun, Feb 09, 2025 at 04:35:03PM +0100, Ömer Güven via Postfix-users wrote:
> I can only endorse this. Simply setting it to „dane“ should solve the
> hassle and make the operation more consistent and predictable.
The whole thing is a misunderstanding. The insecure MX setting is only
ever used
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
> :
>
> I think that the mistake was to make smtp_tls_dane_insecure_mx_policy
>
I observed that with postfix-tlspol :
mails sent to and from gmail show up as trusted connections
while with postfix-mta-sts-resolver:
srnding to gmail shows up as verified connections but
recieving from gmail shows up as trusted connections
and i was wondering why.
cheers
On February 9, 20
Sean McBride via Postfix-users:
> On 23 Jan 2025, at 9:56, Bill Cole via Postfix-users wrote:
>
> > Your solution is to run a local, caching, fully-recursive name
> > resolver. The simplest way to do that is with the Unbound resolver.
> > This is a best practice for all mail servers because MTAs
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 poli
12 matches
Mail list logo
