On 9/6/23 09:17, Richard Troy wrote:
However if your dovecot SASL is broken, say always permitting access with or without correct password, then there will be a problem
I DID find a discrepancy: smtpd_helo_restrictions did NOT have permit_sasl_authenticated. I made the change, of course and with that done, am now going to open the ports and renew my vigil for relays!
Fingers crossed!
Thanks, Jeremy - even if it doesn't work, it's a good clean shot at a fix! And, if that was it, it's easy to see how that could be overlooked. . .
Richard
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
Is most useful to you. The defer means reject after a delay - tarpitting
This leaves you to verify if the sasl authentication is working correctly. That is a real exercise as it has multiple config elements in dovecot and then PAM
/etc/pam.d/dovecot
then calls multiple configs in /etc/pam.d and specifically
/etc/pam.d/common-auth
in my case I am using only the local user database for dovecot
grep -v '^#' common-auth
auth [success=1 default=ignore] pam_unix.so nullok auth requisite pam_deny.so auth required pam_permit.so
It is quite possible to use remote servers such as ldap and kerberos rather than your local user table