Change overview (see review feedback for insights):

• Add smtpd_data_restrictions to main.cf, remove the client and recipient restriction for reject_unauth_pipelining.
  • This defers rejection to a later stage (assuming a permit rule didn't skip restrictions prior), where any detected pipelining in the exchange would trigger the restriction, not just within DATA command.
• Keep smtpd_data_restrictions in Amavis config.
• For a v14 target, smtpd_data_restrictions is not necessary to workaround SMTP smuggling vulnerability.
  • We would have Postfix 3.7.6, this makes smtpd_forbid_unauth_pipelining = yes available. It should be adopted instead (but the smtpd_data_restrictions checklist above is valid (perhaps as a separate PR).
  • Both short-term workarounds also reference enabling smtpd_discard_ehlo_keywords = chunking. This conflicts with the same existing parameter already configured, prepending/appending to that should be fine, but it should be assessed that the feature doesn't have any logic that would accidentally remove chunking, the feature tests may not be sufficient for that, but should be obvious looking over the PR diff (EDIT: Doesn't look like a concern 👍 ).
• Additional context in comments should be added regarding the long-term fix:
  • It replaces the short-term fix parameters as workarounds.
  • It's unclear when Debian Bookworm will update Postfix package with the available fix, but we can mention the min version needed to toggle the long-term fix.

EDIT: smtpd_data_restrictions review feedback has been deferred to a separate PR, with tracking issue: #3728

Overview for smtpd_data_restrictions:

• smtpd_data_restrictions = reject_unauth_pipelining should probably remain on Amavis config, even though it'd be technically redundant (since it would now inherit from main.cf). Reasoning is for maintenance, where this is an explicit Amavis config (official docs), and DMS main.cf could change again as review feedback implies. Better for maintenance visibility to retain it.
• smtpd_data_restrictions = reject_unauth_pipelining on main.cf still may make sense, regardless of Amavis integration.
  • Presently we have this check at earlier restriction phases (client and recipient), but those seem unnecessary and can be dropped in favor of deferring to the data restriction which Postfix docs seem to indicate would be sufficient. Only difference would be rejecting due to the restriction slightly earlier (at the RCPT TO SMTP command).
  • Potentially breaking, but only in the sense that a client is not respecting waiting their turn at the DATA command, but for some reason was respectful earlier 🤷‍♂️

Updated to use the long-term fix discussed in prior review feedback.

Prior review feedback on the smtpd_data_restrictions = reject_unauth_pipelining is no longer required as part of this PR. I've reverted that, but we can have a separate PR handle that (add to main.cf, keep duplicate in postfix-amavis.cf).

Technically if we make a v13.1.1 release, while it's a fix against the attack, it may be breaking for clients unintentionally? Which is why the default is no for existing releases.

• Release as v13.1.1?
• Release as v13.2?
• Release with feature disabled, but add a postfix-main.cf override suggestion in changelog?
• Delay until v14 release?

UPDATE: I've had over 5 runs fail now with the Fail2Ban multiple failed logins test-case. Although failure is due to timeout:

not ok 52 [Fail2Ban] ban ip on multiple failed login in 11659ms
# (from function `assert_success' in file test/test_helper/bats-assert/src/assert_success.bash, line 42,
#  in test file test/tests/parallel/set1/spam_virus/fail2ban.bats, line 82)
#   `assert_success' failed
#
# -- command failed --
# status : 1
# output : Timed out on command: _exec_in_container /bin/bash -c fail2ban-client status postfix-sasl | grep -F '172.17.0.5'
# --

I can only assume this is due to smtpd_forbid_bare_newline = yes, as the expectation is for CR LF not LF, and I believe the PR that added .gitattributes normalized all our nc input files to LF... yet this is the only test-case failing 🤷‍♂️

Reply with Error: bare <LF> received and disconnect when a remote SMTP client sends a line ending in <LF>, violating the RFC 5321 requirement that lines must end in <CR><LF>.

The failed login attempts were presumably rejected before they'd log anything that Fail2Ban monitors to ban the IP. A workaround in the test would be to leverage PERMIT_DOCKER=network to be excluded from the restriction.

#3732 should be compatible, and could be part of a v13.2 release?