On Sun, Feb 09, 2025 at 06:55:50AM +0100, Ömer Güven wrote:
> I‘m the author of postfix-tlspol. I‘m not talking about manually adding
> „dane“ for select destinations in a static map.
> postfix-tlspol does evaluate the domain in realtime and returns the currently
> best available policy.
>
> I h
I‘m the author of postfix-tlspol. I‘m not talking about manually adding „dane“
for select destinations in a static map.
postfix-tlspol does evaluate the domain in realtime and returns the currently
best available policy.
I have to calculate the worst-case, like an user configuring „encrypt“ as
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 do a lot of
DNS and should not be using a res
On Sun, Feb 09, 2025 at 03:00:22AM +0100, Ömer Güven wrote:
> How did I misunderstand the settings if Wietse said that
> smtp_tls_dane_insecure_mx_policy only defaults to dane, when the
> smtp_tls_security_level variable is set to dane, else it defaults to
> may, regardless of the security level r
I tested it: it is true. Setting the default security level to anything other
than „dane“ (even encrypt, verify, secure…) and having the socketmap server
return „dane“ downgrades to „may“ (but then negotiates unauth TLS because the
remote of course supports encryption).
This is a major design fl
How did I misunderstand the settings if Wietse said that
smtp_tls_dane_insecure_mx_policy only defaults to dane, when the
smtp_tls_security_level variable is set to dane, else it defaults to may,
regardless of the security level returned by smtp_tls_policy_maps?
Either is Wietse wrong or you di
On Sat, Feb 08, 2025 at 11:06:08PM +0100, Ömer Güven via Postfix-users wrote:
> * Also: the current behavior is counter-intuitive and makes returning
> „dane“ completely useless unless the default is also set to „dane“,
> because postfix-tlspol only returns „dane“ if „dane-only“ isn‘t
> possible b
On Sat, Feb 08, 2025 at 04:41:53PM -0500, Wietse Venema via Postfix-users wrote:
>
> smtp_tls_dane_insecure_mx_policy = ${{$smtp_tls_security_level} == {dane} ?
> {dane} : {may}}
>
> I have one question:
>
> - Should this expression use the security level from
>main.cf:smtp_tls_security_l
Sean McBride via Postfix-users:
> Hi all,
>
> I've been setting up a fresh postfix server, and I've really appreciated
> how great the docs are. In the spirit of making them even better, I'd
> like to share a comment/suggestion.
>
> If I correctly understand the messy history of port 465 vs 587
Hi all,
I've been setting up a fresh postfix server, and I've really appreciated
how great the docs are. In the spirit of making them even better, I'd
like to share a comment/suggestion.
If I correctly understand the messy history of port 465 vs 587, for
submission port 587 with StartTLS was
* Also: the current behavior is counter-intuitive and makes returning „dane“
completely useless unless the default is also set to „dane“, because
postfix-tlspol only returns „dane“ if „dane-only“ isn‘t possible because of an
unsigned MX record. „dane“ returned while the default is „encrypt“ woul
Oh, definitely the latter! Thank you for looking deeper in the code.
Honoring the evaluated policy would ensure that Postfix tries DANE when the
default is set to for example „encrypt“ and a socketmap server like
postfix-tlspol returns „dane“ (because it detected DANE support after an
insecure
Viktor Dukhovni via Postfix-users:
> On Sat, Feb 08, 2025 at 05:28:31PM +0100, ?mer G?ven via Postfix-users wrote:
>
> >RFC 7672 says that Opportunistic DANE (security level ?dane?, but not
> >?dane-only?) may accept non-DNSSEC derived MX records be eligible for
> >DANE on the DNSSEC-s
IF Postfix appends the 'wrong domain' (usually, @$myorigin) to a
virtual alias lookup result,
THEN you need to specify the correct domain in the virtual alias
lookup result.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To u
I‘m perplexed. I never saw that configuration parameter until now and
apparently misinterpreted my Postfix logs. Glad this isn’t an issue. Thanks!
> Am 08.02.2025 um 17:42 schrieb Viktor Dukhovni via Postfix-users
> :
>
> On Sat, Feb 08, 2025 at 05:28:31PM +0100, Ömer Güven via Postfix-users w
On Sat, Feb 08, 2025 at 05:28:31PM +0100, Ömer Güven via Postfix-users wrote:
>RFC 7672 says that Opportunistic DANE (security level „dane“, but not
>„dane-only“) may accept non-DNSSEC derived MX records be eligible for
>DANE on the DNSSEC-signed (e. g. external) SMTP server.
>
>R
Hi!RFC 7672 says that Opportunistic DANE (security level „dane“, but not „dane-only“) may accept non-DNSSEC derived MX records be eligible for DANE on the DNSSEC-signed (e. g. external) SMTP server.RFC 7672 Section 2.2.1: Since the protocol in this memo is an Opportunistic Security protocol
[R
Hi everybody,
I have a problem after moving our mail server to a new machine. Everything
seems to be working so far - but not the virtual aliases. I'll try to
explain:
"test.mail.com" is a mail server administering several domains e.g.
"my.domain". Mail user and aliases are stored in a MySQ
18 matches
Mail list logo
