**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](https://github.com/docker-mailserver/docker-mailserver/blob/72517d3f824859cb15a3ccc653ad8cc4bb1a4c32/target/postfix/main.cf#L57), 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`](https://github.com/docker-mailserver/docker-mailserver/pull/3572), 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.

---

**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 🤷‍♂️