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
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
