Damian via Postfix-users:
> > It really does not matter much, but leaving BDAT enabled can help in
> > some cases. It is not necessary to go this deep down the rabbit hole.
>
> So what could be smuggled into a Postfix that defines
> "reject_unauth_pipelining" but does not define
>
It really does not matter much, but leaving BDAT enabled can help in
some cases. It is not necessary to go this deep down the rabbit hole.
So what could be smuggled into a Postfix that defines "reject_unauth_pipelining" but does not define "smtpd_discard_ehlo_keywords
= chunking"?
On Wed, Dec 27, 2023 at 11:40:56PM +0100, Damian via Postfix-users wrote:
> > The attack can be mitigated by using BDAT.
>
> Can someone clarify?
It really does not matter much, but leaving BDAT enabled can help in
some cases. It is not necessary to go this deep down the rabbit hole.
If both
SHORT-TERM WORKAROUNDS
A short-term workaround can be deployed now, before the upcoming long
holiday and associated production change freeze.
NOTE: This will stop only the published form of the attack. Other forms
exist that will not be stopped in this manner.
* With all Postfix versions,
On 12/27/2023 1:03 PM, Vince Heuser via Postfix-users wrote:
Wietse, Happy 25th birthday of your creation!
I recently upgraded to mail_version = 3.4.23
Postfix no longer logs IP addresses with the connections.
What did I break?
My wild guess is that your chroot environment is incomplete. To
Wietse, Happy 25th birthday of your creation!
I recently upgraded to mail_version = 3.4.23
Postfix no longer logs IP addresses with the connections.
What did I break?
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an
