Hello,

On 2021-08-10, at 07:39 (UTC-0700), Stephen Satchell had the following to say:

: On 8/10/21 7:00 AM, Mono DHS wrote:
: > Are there plans to revisit the SMTP command parsing and handling logic
: > in the server in one form or another?  Are people making active use of
: > the  smtpd_forbidden_commands  parameter?
: > 
: 
: Longer answer:  See this shell sequence:
: > # postconf smtpd_forbidden_commands
: > smtpd_forbidden_commands = CONNECT GET POST
: > # postconf mail_version
: > mail_version = 3.4.13

Same here (same version), since it's the default.

Anyone added more or other tokens, like, e.g. "EXPUNGE" and "RENAME"
(both IMAP), "HAVESPACE" and "SETACTIVE" (both ManageSieve) or anything
else imaginable that may or may not be thrown at the server at any point
in time?

An open door philosophy such as the one implied by  smtpd_forbidden_commands
does and can /not/ provide protection from the big bad world, even and
especially in practical terms.  This is simply because it starts with
an "anything permitted" policy and only then selectively, more or less
arbitrarily, closes the door for specific tokens that have been observed
in the wild, perhaps as part of a deliberate action or just misconfiguration.
Administrators of such a system are relegated to eternally playing catch-up
with the outside world.

In contrast, robust protocol implementations are designed according
to a constructivist philosophy, starting with a clean slate, "nothing
permitted" policy and only ever adding what's permitted by the protocol,
and that protocol alone.  Any input such a server is presented with that
lies outside that protocol definition is rejected outright or dealt with
in other ways according to local policy.

And the right to reject non-SMTP input follows from operating an
SMTP MTA on the well-known TCP port 25, while at the same time holding
up the fundamental principle upon which the success of the Internet is
based, namely of being liberal in what one accepts and conservative in
what one sends.


Cheers,
Mono

Attachment: signature.asc
Description: PGP signature

Reply via email to