Background
I've been the administrator since inception of this 24-ish year old site which hosts a lot of virtual domains, etc, and from the late '90s one important feature we had working was allowing IMAP clients to connect to both read and send from our mail server system. A key enabling feature was the pop-before-smtp option in Postfix.
The need for IMAP sends fell away with the financial crash of '08, but the need has come again, so, as administrator, I set about configuring the modern Postfix and Dovecot, of course on a modern Fedora Server (our long-chosen distribution) to do the job.
Configuring to have IMAP (IMAPS or POP3) reads was easy, but pop-before-smtp was neither rejected nor honored. Hmmm...
Configuring remote sends hasn't gone so well!
Troubles
As a guy with a long-grey-beard of experience, I did all the usual kinds of things looking for help, though I didn't do everything perfectly.
Along the way to this not-yet-solved problem, I figured out that THESE version(s) of Postfix and Dovecot don't work as advertised. In particular, we're running:
- Linux Fedora Server 5.7.16-200.fc32.x86_64
- postfix-3.5.4-2.fc32.x86_64
- dovecot-2.3.10.1-1.fc32.x86_64
With THIS set of versions, the settings for both Dovecot and Postfix didn't seem to honor the communication settings, shared by each, namely:
private/auth
Rather, things worked MUCH better, but still not fixed, with:
/var/spool/postfix/private/auth
When I say both, I mean the smtpd_sasl_path entry in Postfix's main.cf, and also Dovecot's /etc/dovecot/dovecot.d/10-master.conf file's entry for unix_listener, of course.
These entries point to a socket created by Dovecot, so Dovecot should be started first, though I haven't done any investigations into restart, or related issues. Simply, CONTRARY WITH OTHER DOCUMENTATION, THIS VERSION of Postfix WILL NOT receive inbound email if SASL auth is enabled and the smtpd_sasl_path doesn't already exist, as created by Dovecot.
I don't mean to overlook that several other Postfix parameters MUST be set for Postfix to receive emails under this scenario, such as smtpd_sasl_security_options and smtpd_sasl_tls_security_options. Without these, Postfix WILL NOT RECEIVE EMAILS if smtpd_sasl_auth_enable is set true.
To be completely clear, to cure this oversight, if you aren't able to receive email while trying to configure this, you simply MUST turn off Postfix's smtpd_sasl_auth_enable - that is, set it to false - or you will be unable to receive inbound emails, despite the available documentation's claims to the contrary. So, turn it off when you want to receive emails and back on again when you want to test.
However, even when you figure out how to get Dovecot to start enabling this service, as confirmed by the creation of /var/spool/postfix/private/auth, you can have smtpd_sasl_auth_enable set to true (along with other required sasl settings) and be able to receive emails, and still not be able to send via IMAP (imaps) clients.
As an aside I haven't taken the time to fully pursue, in my case, why or how the socket file created at /var/spool/postfix/private/auth was created as owned by root.root. After Postfix was up and receiving with sasl enabled, a chown postfix.postfix /var/spool/postfix/private/auth was required to fix that and I haven't taken the time to confirm this survives a reboot or even why it was wrong in the first place or if it fails if ownership is wrong! I'm just sharing my experience... ... It surely seems wrongly created to me.
YET, even in this instance, when Dovecot and Postfix agree on where and how to communicate via this socket file and email is received just fine, sends just do not work. That is, clients can connect and read their emails and do whatever else, but they cannot send, which all available documentation I've found so far leads one to believe the implementation of sasl done in this way is the key feature of the modern situation that permitted the deprecation and eventual removal of pop-before-smtp. What have I missed?
Before anyone asks, Postfix's /etc/postfix/master.cf's submission entry contains:
submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes
(Perhaps there is an error there, but it's not clear to me.)
When trying to send, the /var/log/maillog presently (with the aforementioned configuration fully working) and persistently includes the following error for these remote-sending clients:
400 4.5.2 Error: bad UTF-8 syntax
And, more rarely, this one:
250-SMTPUTF8
I have never found any useful information about this error.
Any and all help appreciated.
250-, the 250 signals OK and the hyphen signals it is not the end of the reply yet, that is how I could tell that neither it is the actual error itself, nor should it appear anywhere without further context.