-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
security(Postfix): Protect against "SMTP Smuggling" attack #3727
Changes from 1 commit
f7df902
d466ec5
b409de3
b19c133
d447294
497a5a8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -56,6 +56,9 @@ smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject | |
smtpd_sender_restrictions = $dms_smtpd_sender_restrictions | ||
smtpd_discard_ehlo_keywords = silent-discard, dsn | ||
disable_vrfy_command = yes | ||
smtpd_data_restrictions = reject_unauth_pipelining | ||
# TODO enable when possible, see https://github.com/docker-mailserver/docker-mailserver/issues/3719#issuecomment-1868287208 | ||
#smtpd_forbid_bare_newline = yes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "When possible" could better clarify that the blocker is waiting on Debian to provide an updated package of Postfix (3.8.4, 3.7.9, 3.6.13 and 3.5.23). For Bookworm that'd be The comment also only refers to enabling the parameter, despite obsoleting the short-term workarounds. The longterm-fix also references an optional 2nd parameter to configure:
We shouldn't configure it by default in the image though (since Docker with IPv6 hosts but IPv4 only containers with default |
||
|
||
# Custom defined parameters for DMS: | ||
dms_smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unknown_sender_domain | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this exists already on
smtpd_client_restrictions
andsmtpd_recipient_restrictions
, introduced 7 years ago in #165Both of those restrictions occur before
smtpd_data_restrictions
(section describes order), and probably should be removed in favor ofsmtpd_data_restrictions
(based on information that follows below)The PR that introduced
reject_unauth_pipelining
to the those two restrictions has a dead link, and while it does seem common enough to see in configs online, I'm not sure if they're correct. This comment also advises moving the restriction tosmtpd_data_restrictions
.Amavis config for Postfix clearly communicates this configuration requirement for
smtpd_data_restrictions
:The Postfix docs note that it is applicable during any SMTP command context, but also mentions:
Since
smtpd_data_restrictions
is pretty much at the end of the session, I think that is why earlierreject_unauth_pipelining
restrictions aren't likely to provide any benefit? 🤷♂️ (other than rejecting at an earlier stage, which should technically only beRCPT TO
due to defaultsmtpd_delay_reject=yes
, which we for some reason set explicitly)Also related I think is the postscreen Command pipelining test (Postfix docs for postscreen):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth adding some context of the restriction.
Keeping it in
main.cf
should be fine AFAIK, Amavis will inherit it and it may still make sense when Amavis is not used? (although I kinda prefer to keep it explicit on the Amavis snippet, instead of implicitly inferring it frommain.cf
)The documented short-term workaround for the SMTP smuggling vulnerability is:
but once we have v14 of DMS we'll have Postfix 3.7.6 and can use the original short-term workaround:
Only benefit then is to get this in for 13.1, but you've got it marked for v14? In which case the Postfix 3.7.6 fix is more appropriate.