[pfx] Re: [Proposal] Allow unknown tags returned by TLS policy socketmap servers

That‘s great news. Happy to see that Postfix isn’t just maintained but rather steadily developing. Have a nice evening! Ömer > Am 05.02.2025 um 21:00 schrieb Wietse Venema via Postfix-users > : > >  >> >> What do you think about the other one? >> Not for the next release (I'm really looki

[pfx] Re: [Proposal] Allow unknown tags returned by TLS policy socketmap servers

> What do you think about the other one? > Not for the next release (I'm really looking forward to a stable > v3.10, so it's great news that you have frozen the code ) > > but as an idea for the future releases? I just opened a discussion with Viktor about working towards a future where SMTP over

[pfx] Re: [Proposal] Allow unknown tags returned by TLS policy socketmap servers

That is indeed plausible! Forget about the first proposal. What do you think about the other one? Not for the next release… (I‘m really looking forward to a stable v3.10, so it‘s great news that you have frozen the code 👍🏻) … but as an idea for the future releases? > Am 05.02.2025 um 19:53 schr

[pfx] Re: [Proposal] Allow unknown tags returned by TLS policy socketmap servers

?mer G?ven via Postfix-users: > Hi! > > For the next release (3.10), I'd like to propose that unknown tags > returned by TLS policy socketmap servers are logged as warnings, > but never regarded as an invalid policy. This would avoid delivery > errors introduced by future additions, when an older

[pfx] [Proposal] Allow unknown tags returned by TLS policy socketmap servers

Hi! For the next release (3.10), I‘d like to propose that unknown tags returned by TLS policy socketmap servers are logged as warnings, but never regarded as an invalid policy. This would avoid delivery errors introduced by future additions, when an older Postfix version doesn‘t support a tag y

[pfx] Re: Feature: IP discard for authenticated e-mails

On 2/5/25 5:57 PM, Wietse Venema via Postfix-users wrote: The following is now part of Postfix 3.10, which is back in the code freeze stage. Thank you so much for working on this, this is amazing!! Regards, ell1e ___ Postfix-users mailing list -- p

[pfx] Feature: IP discard for authenticated e-mails

The following is now part of Postfix 3.10, which is back in the code freeze stage. Wietse smtpd_hide_client_session (default: no) Do not include SMTP client session information in the Postfix SMTP server's Received: message header. o The default setting,

[pfx] Re: IP discard for authenticated e-mails

On Wed, Feb 05, 2025 at 15:31:44 +0100, Ömer Güven via Postfix-users wrote: > At least the big companies like GMail never complained about it, the > Authenticated Received Chain (ARC) always passes without errors, even > for forwarding. :-) Yes, the message is still RFC 5322 compliant, as Viktor

[pfx] Re: IP discard for authenticated e-mails

At least the big companies like GMail never complained about it, the Authenticated Received Chain (ARC) always passes without errors, even for forwarding. :-) > Am 05.02.2025 um 15:28 schrieb Geert Hendrickx via Postfix-users > : > > On Wed, Feb 05, 2025 at 14:58:48 +0100, Ömer Güven via Post

[pfx] Re: IP discard for authenticated e-mails

On Wed, Feb 05, 2025 at 14:58:48 +0100, Ömer Güven via Postfix-users wrote: > My solution does completely remove the Received header, so that the > next-hop adds an appropriate one, usually pointing to the sending MX‘ > ip address. Which is also not RFC 5321 compliant, just not visibly so :) >

[pfx] Re: IP discard for authenticated e-mails

Geert Hendrickx via Postfix-users: > On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users wrote: > > This reduces the Received: header from: > > > > Received: from > > by servername (Postfix) with id yyy; server-date-stamp > > > > to: > > > > Received: by

[pfx] Re: IP discard for authenticated e-mails

On Wed, Feb 05, 2025 at 02:01:27PM +0100, Geert Hendrickx via Postfix-users wrote: > It seems that such reduced Received header would not be RFC5321 compliant, > as the "from " clause is mandatory according to section 4.4. It is still a valid Received header, just like the ones added by submissi

[pfx] Re: IP discard for authenticated e-mails

My solution does completely remove the Received header, so that the next-hop adds an appropriate one, usually pointing to the sending MX‘ ip address. The MX doesn’t have to forward any sensitive information about the MUA to the receiving MTA. Ömer > Am 05.02.2025 um 14:02 schrieb Geert Hendri

[pfx] Re: IP discard for authenticated e-mails

On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users wrote: > This reduces the Received: header from: > > Received: from > by servername (Postfix) with id yyy; server-date-stamp > > to: > > Received: by servername (Postfix) with id yyy; server-date

[pfx] Re: Sanity check for check_sasl_access

On Wed, 5 Feb 2025 at 11:06, Allen Coates via Postfix-users < postfix-users@postfix.org> wrote: > > In my access lists I have found that 0.0.0.0/0 matches every IPv4 > address, and ::/0 matches every IPv6 address. > > (Unless, of course you are expressly testing for a specific IP address) > I se

[pfx] Re: Sanity check for check_sasl_access

On 05/02/2025 10:50, Gilgongo via Postfix-users wrote: > > And have the following in my access file: > > user1 192.x.x.x     PERMIT > user1 2001:x:x:x::x PERMIT > user1 REJECT > > In my access lists I have found that  0.0.0.0/0 matches every IPv4 address, and ::/0 matches every

[pfx] Re: Sanity check for check_sasl_access

On Wed, 5 Feb 2025 at 09:32, Gilgongo wrote: > I just wanted to make sure I've read the docs > correctly. > I'd like to restrict a couple of sasl users by IP4/6 (I can't test this on > my sandbox setup), so if I have this in my master.cf

[pfx] Sanity check for check_sasl_access

I just wanted to make sure I've read the docs correctly. I'd like to restrict a couple of sasl users by IP4/6 (I can't test this on my sandbox setup), so if I have this in my master.cf: submission inetn - n-