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.
My colleague just changed his settings and we got an email sent...
FORMERLY - whatdidn't work on the sending end was:
what DID work on the sending end was:
HOWEVER, this opens up it's own questions!
Postfix IS set up for "may", as I recall, and I had thought that that meant "if a client starts with TLS, take it, if not, let them try without... This behavior means that's not true.
What I thought I understood to be true appears to be wrong, but it's based on the available documentation.
But, it's late and it's time for me to retire for the night. I'll be back on this tomorrow! THANKS FOR ANY INSIGHTS!