A Postfix mail server is configured to use Dovecot SASL for authentication. Users report that they can send emails but are prompted for password repeatedly and see "SASL authentication failed" in the logs. The Dovecot SASL socket is configured correctly. What is the most likely cause?
Permission issues prevent SASL communication, causing authentication failures.
Why this answer
The correct answer is B because the most common cause of repeated password prompts and 'SASL authentication failed' errors when Postfix is configured to use Dovecot SASL is a permissions issue on the Dovecot auth socket. Even if the socket path is correct in Postfix's `smtpd_sasl_path`, the Postfix process (typically running as the `postfix` user) must have read/write access to that socket file. Without proper permissions, Postfix cannot communicate with Dovecot's authentication service, causing SASL failures despite correct authentication mechanisms and enabled settings.
Exam trap
The trap here is that candidates often focus on authentication mechanism mismatches or network-level settings, overlooking the fundamental Unix permission issue on the SASL socket, which is a classic gotcha in Postfix-Dovecot integration.
How to eliminate wrong answers
Option A is wrong because `mynetworks` controls which clients can relay mail without authentication (i.e., trusted subnets), not SASL authentication failures; a misconfigured `mynetworks` would allow relaying without auth or block it, but would not cause repeated password prompts with SASL errors. Option C is wrong because Dovecot's default auth mechanism is 'PLAIN' and Postfix typically expects 'PLAIN' or 'LOGIN'; if the mechanism were mismatched, the error would be about unsupported mechanism, not a generic 'SASL authentication failed' with repeated prompts. Option D is wrong because if `smtpd_sasl_auth_enable` were set to 'no', Postfix would not offer SASL authentication at all, and users would not be prompted for passwords; the fact that they are prompted indicates this parameter is enabled.