On 20 Mar 2019, at 11:01, Yassine Chaouche wrote:
Dear postfix,
I don't seem to get the idea of submission, I know I must be wrong,
b/c so many articles out there preach to use a different port for
submission, but I hope to find some argument in your replies that will
make me change my mind.
If I understand correctly, submission is a means for mail server
admins to enforce some policies on port 587 w/o interfering with mail
relay which occurs on port 25. These policies are mainly :
1/ Force TLS on all incoming connexions
2/ Force users to authenticate
While 1/ can't be enforced on port 25, 2/ can be enforced for relay,
e.g. with :
smtpd_sasl_auth_enable = yes
smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
So the only thing that I need submission port for seems to be to force
TLS connexions, right ?
Anything else I am missing there ?
1. Eliminates the usual rationale for broad authentication by IP (i.e.
permit_mynetworks) which opens most Postfix systems to abuse by networks
that the admin very much WANTS to be trustworthy but which often are
not. One can do this without segregating submission but doing so spurs
the question: "Why permit_mynetworks?" The usual answer in the modern
world is that there's no good reason for permit_mynetworks, or at least
there's no reason to include submitters' networks in mynetworks.
2. Allows enforcement of SPF and SPF-like policy for local domain
senders on port 25.
3. Simplifies the common need to distinguish between "inbound" and
"outbound" mail in filtering, policy, and signing tools.
4. Eliminates the need to allow authentication on port 25, reducing the
attack surface for credential-stuffing and brute-force tactics.
Another claim for submission is that it reduces spam, but to my
understanding that's only for *sending* spam (relaying), and that's
because the admin enforces user authentication for relay, which can
safely be done on port 25 anyways (otherwise we'd be an open relay).
Spammer tactics that take advantage of 'permit_mynetworks' (and similar
policies for other MTAs) are common.
As for *reciving* spam (we're the final destination), it can still be
delivered unauthed from port 25, so that won't stop *receiving* spam,
will it ?
No, but if you don't need to allow your own users to relay through port
25, you can use tools that are designed to reject mail coming directly
from end-user devices (e.g. Spamhaus PBL, banning suspect reverse
hostname patterns, etc.) which are made cumbersome or weakened by having
end-user submissions and inbound mail flowing through a common
transport.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
