Hi Viktor,
I think it is more:
1. "reject_unauthenticated_sender_login_mismatch" implies to a
reasonable person that "unauthenticated senders" for our trusted domains
would be rejected (not logging in is a form of login mismatch).
2. Perhaps adding to my confusion but the wording "when SASL is enabled"
could be (mis)read as "(elsewhere?) on the Postfix server" rather than
"on the specific port" too.
3. The documentation does not (currently) explicitly call out what
happens if SASL is disabled on a port and the user is unauthenticated
(i.e. nothing, effectively a NO-OP, no reason to include it). So part of
the exercise for the reader is reading between the lines on this edge case.
I understood "unauthenticated_sender" to always be where one has not
logged in.. not "only when a sender is not logged in but would otherwise
have the capability to log in".
Perhaps incorrect but I (and I suspect others) viewed the only possible
states a user could be as unauthenticated or authenticated - not a third
state of "neither authenticated or unauthenticated".
It's easy of course for me to critique, I cannot propose a way of fixing
the wording to make this clear and until I saw Matus' prior discussion
didn't realise this was already warned about in the log.
Maybe all this takes to reduce the number of people accidentally
mis-interpreting the functionality is the documentation to call out that
if SASL is disabled on a port (perhaps on a submission port) one should
consider "check_sender_access" instead.
Submission port is getting more and more common, so the desire to turn
off SASL on port 25 I can't imagine is entirely uncommon.
I'm happy check_sender_access is achieving its intended purpose.. my
only suggested benefit of there being native functionality instead and
the changing of "reject_unauthenticated_sender_login_mismatch" or an
additional separate restriction is the ability to use
$smtpd_sender_login_maps
<https://www.postfix.org/postconf.5.html#smtpd_sender_login_maps> over
typing out each domain into a table and realising that you need to
maintain it if an additional domain is ever added in future to prevent
spoofing. Thankfully no relay risk with this just spoofing of a local
domain and as my server is purely a personal server used solely by me
you would think I would notice if someone pretends to be me to me :).
Kind Regards,
Matthew
On 22/06/2025 13:50, Viktor Dukhovni via Postfix-users wrote:
On Sun, Jun 22, 2025 at 01:39:09PM +0100, Matthew via Postfix-users wrote:
Thank you for your e-mail. I thought I had searched for similar discussions
beforehand but obviously I had not done a very thorough job. Yes, exactly
the same observations.
It is rather odd to apply a login-mismatch filter in a context in which
no logins are possible. Since the non-existent plays no role in the
outcome, you're really impossing a sender address access(5) check, for
which there's already check_sender_access.
Sure it is tempting to try to econimise on tables, but the access(5)
approach is the clean way to handle this.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
