SSLCertificateFile /etc/letsencrypt/live/support.moonpoint.com-0001/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/support.moonpoint.com-0001/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/support.moonpoint.com-0001/chain.pem

When I checked the expiration of that security certificate, I saw it was valid until May 17.

# openssl x509 -enddate -noout -in /etc/letsencrypt/live/support.moonpoint.com-0001/cert.pem
notAfter=May 17 04:02:51 2024 GMT
#

You can determine the location of the .pem file used by Dovecot by looking for the ssl_cert variable in /etc/dovecot/conf.d/10-ssl.conf.

[ More Info ]

[/network/email/dovecot] permanent link

A user reported that she was unable to check her email today; she had also reported the problem yesterday. When I checked Sendmail, which would handle her outgoing email, by using Telnet to connect to the well-known port for Simple Mail Transfer Protocol (SMTP) on the server with telnet mail.example.com 25, I saw the Sendmail banner as expected, so I presumed her problem was likely with Dovecot, the software on the system that would allow her to receive her incoming email. I tried connecting to port 110, the well-known port for Post Office Protocol version 3 (POP3) connections using Telnet. When I saw the "Connected to" and "Escape character is" messages, I entered the POP3 user command followed by the user's name, but I would shortly thereafter see a "Connection closed" message every time I tried the connection with Telnet. I never saw the "Dovecot ready" prompt appear.

# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user nell
Connection closed by foreign host.
You have new mail in /var/spool/mail/root
#

[ More Info ]

[/network/email/dovecot] permanent link

A user reported that she wasn't receiving any email. When I logged into the mail servers, which runs Dovecot for POP3/POP3S and used Telnet to connect to port 110, the well-known port for POP3, I didn't get any response after I entered the user command, so I exited to the telnet prompt with Ctrl-].

$ telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user nell
^]
telnet> quit
Connection closed.
$

I logged into the root account and checked today's and yesterday's maillog files for any references to Dovecot or POP3 issues, but saw none.

# grep -i dovecot /var/log/maillog
# grep -i dovecot /var/log/maillog.1
# grep -i pop3 /var/log/maillog.1
# grep -i pop3 /var/log/maillog
#

[ More Info ]

[/network/email/dovecot] permanent link

Microsoft Telnet> open mail.example.com 110
Connecting To mail.example.com...

So I logged into the mail server, which is a CentOS 7 Linux server running Sendmail and Dovecot, and tried connecting to the localhost address, 127.0.0.1, but Dovecot never responded with a banner, nor did I receive any response when I issued a user command to provide login credentials. I had to hit Ctrl-] to exit from the Telnet program, since I wasn't getting any response from Dovecot.

# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user lila
^]
telnet> quit
Connection closed.
#

[ More Info ]

[/network/email/dovecot] permanent link

$ telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 moonpoint.com ESMTP Sendmail 8.14.7/8.14.7; Sat, 6 Aug 2016 09:26:06 -0400
quit
221 2.0.0 moonpoint.com closing connection
Connection closed by foreign host.
$

Since the Sendmail SMTP service seemed to be functioning properly, I next checked the Dovecot POP3/POP3S software on the system. I entered the commands an email client would submit to authenticate with the server on the POP3 port, port 110, i.e., pass followed by the user's login id then pass and the password for the user's account. I received an immediate response to the user command, but when I entered the pass command followed by the password and hit Enter I didn't see any response even after waiting much longer than I would expect to have to wait for a response. So I hit Ctrl-], i.e., the Ctrl and ] keys to return to the Telnet prompt and then exited from the telnet program.

[ More Info ]

[/network/email/dovecot] permanent link

# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user nell
Connection closed by foreign host.
#

So I then checked Dovecot's log file. I saw many entries similar to the following ones in that file:

# grep dovecot /var/log/maillog | tail -5
Jul  4 09:15:44 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:18:55 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:19:57 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:21:01 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:26:13 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
#

[ More Info ]

[/network/email/dovecot] permanent link

# grep "Permission denied" /var/log/maillog.1 | tail -n 3
Jun 17 18:56:08 moonpoint dovecot: pop3(nell): Error: open(/home/nell/mail/.imap
/INBOX/dovecot.index.log) failed: Permission denied (euid=503(nell) egid=1002(ne
ll) missing +x perm: /home/nell/mail/.imap/INBOX, dir owned by 0:0 mode=0700)
Jun 17 19:26:44 moonpoint dovecot: pop3(nell): Error: open(/home/nell/mail/.imap
/INBOX/dovecot.index.log) failed: Permission denied (euid=503(nell) egid=1002(ne
ll) missing +x perm: /home/nell/mail/.imap/INBOX, dir owned by 0:0 mode=0700)
Jun 17 19:57:29 moonpoint dovecot: pop3(nell): Error: open(/home/nell/mail/.imap
/INBOX/dovecot.index.log) failed: Permission denied (euid=503(nell) egid=1002(ne
ll) missing +x perm: /home/nell/mail/.imap/INBOX, dir owned by 0:0 mode=0700)
#

Checking the permissions and ownership on the referenced mail/.imap/INBOX file for her account and comparing it to other accounts, I saw that root was listed as the owner and the group for the file under her home directory, but for other users the same file under their home directory was owned by the user's account and the group matched the user name for the user.

[ More Info ]

[/network/email/dovecot] permanent link

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

You can find the location of dovecot logs using the doveadm log find command.

# doveadm log find
Looking for log files from /var/log
Debug: /var/log/maillog
Info: /var/log/maillog
Warning: /var/log/maillog
Error: /var/log/maillog
Fatal: /var/log/maillog
#

Since the user had not connected from his PC to check his email account for several days, I looked in a maillog file from several days ago to determine the IP address from which he connected then and saw the following.

# grep benny /var/log/maillog.4 | grep pop3 | grep "rip="
Jun 13 02:57:23 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=21212, secured, session=<RDFhZiM1NgBILQJI>
Jun 13 04:59:10 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=32662, secured, session=<REgGGiU1CgBILQJI>
Jun 13 17:53:04 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=30622, secured, session=<6ka06S81BwBILQJI>
Jun 13 18:23:14 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=1243, secured, session=<Gl+PVTA1LABILQJI>
Jun 13 18:53:23 moonpoint dovecot: pop3-login: Login: user=>benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=3769, secured, session=<hqpuwTA1TABILQJI>
#

[ More Info ]

[/network/email/dovecot] permanent link

She told me the password she was using, so I established a telnet connection to port 110, the Post Office Protocol version 3 (POP3) port from another system using PuTTY and entered her userid and password. The email server, which uses Dovecot to provide IMAP and POP3 service, acknowledged that was the correct password.

+OK [XCLIENT] Dovecot ready.
user nell
-ERR Unknown command.
user nell
+OK
pass Rugs1234
+OK Logged in.
stat
+OK 52 483564
quit

If you connect to port 110, the pop3 port, you can enter a user command to provide the userid (I don't know why dovecot always responded to the first submission of that command with -ERR Unknown command, when I used PuTTY to connect, but then accepted it on the second submission) and then a pass command followed by the password. You can then issue a stat or uidl command to check on the number of messages in the inbox and their size. For the stat command, the first number in the response is the number of messages and the second number is their size in bytes. The uidl command shows the unique message id for each message. You can end the session with the quit command.

Since the password seemed to be correct, I had her try again to download her email while I observed what was happening with tcpdump on the mail server by issing the command tcpdump -i enp1s4 'port 110' -A from the root account. I used i enp1s4, because enp1s4 is the network interface on that particular system. The -A at the end instructs tcpdump to print each packet (minus its link level header) in ASCII.

What I observed was her system sending the USER command and her userid. But then Outlook on her system would send the AUTH command and the server would reply ".-ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections"

10:29:34.219018 IP 10-45-1-012-dhcp.gsv.md.example.com.50990 > 

localhost.localdomain.pop3: Flags [P.], seq 8:19, ack 29, win 16418, length 11
E..3!.@.{...H-.H.......n.....(."P.@"....USER nell

10:29:34.219182 IP localhost.localdomain.pop3 > 10-45-1-012- 
dhcp.gsv.md.example.com.50990: Flags [P.], seq 29:115, ack 19, win 115, length 86
...-ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.

The AUTH command indicates an authentication mechanism to the server as noted in Request for Comments (RFC) 1734 POP3 AUTHentication command. RFCs are the mechanism for defining Internet standards.

When I observed what was happening with the same tcpdump command when I connected to the server from another system on its LAN by a telnet connection to port 110, I saw the following:

# tcpdump -i enp1s4 'port 110' -A

10:27:30.475105 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 67:76, 

ack 120, win 256, length 9
E..1.1@...r;...........n......Q.P.......user nell
10:27:30.475211 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 76:78, 

ack 120, win 256, length 2
E..*.2@...rA...........n......Q.P...n...
....
10:27:30.475264 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [.], ack 78, win 

115, length 0
E..(g.@.@.N..........n....Q.....P..s.u..
10:27:30.475319 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [P.], seq 

120:125, ack 78, win 115, length 5
E..-g.@.@.N..........n....Q.....P..s.z..+OK

10:27:30.534264 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [.], ack 125, win 

256, length 0
E..(.6@...r?...........n......Q.P...{.........
10:27:36.602821 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 78:91, 

ack 125, win 256, length 13
E..5.E@...r#...........n......Q.P.../...pass Rugs1234
10:27:36.602938 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 91:93, 

ack 125, win 256, length 2
E..*.F@...r-...........n......Q.P...n...
....
10:27:36.603007 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [.], ack 93, win 

115, length 0
E..(g.@.@.N..........n....Q.....P..s.u..
10:27:36.735972 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [P.], seq 

125:141, ack 93, win 115, length 16
E..8g.@.@.N..........n....Q.....P..s....+OK Logged in.

I.e., the server was accepting a plaintext password, though it wasn't accepting one from her system. When I entered the AUTH command from the telnet session to port 110, it was accepted without that error message.

+OK [XCLIENT] Dovecot ready.
user nell
-ERR Unknown command.
user nell
+OK
AUTH
+OK
PLAIN
.
pass Rugs1234
+OK Logged in.

I then remembered that she had told me her ISP replaced her network equipment recently. She has an IP that remains constant unless the router is replaced at her end in which case the new device has a different media access control (MAC) address and will be assigned a different IP address.

I put the new IP address in the /etc/mail/access file, so that sendmail would allow relaying from that IP address without any authentication. I.e., I added a line with her IP address followed by RELAY.

10.45.1.12                              RELAY

I then ran the makemap hash command to generate a new /etc/mail/access.db file.

# makemap hash /etc/mail/access </etc/mail/access

But that only allowed her to send email via sendmail without authentication. I also had to update dovecot's configuration file at /etc/dovecot/dovecot.conf and change the IP address there for her system so that she could use plaintext authentication, i.e., an unencrypted password (I need to go to her location and change the Outlook configuration there to use other than plaintext authentication). I didn't recall that change was needed until finding a note I had made previously regarding dovecot's logon_trusted_networks setting.

The relevant section of the dovecot.conf file is shown below for cases where plaintext authentication is being allowed.

# Space separated list of trusted network ranges. Connections from these
# IPs are allowed to override their IP addresses and ports (for logging and
# for authentication checks). disable_plaintext_auth is also ignored for
# these networks. Typically you'd specify your IMAP proxy servers here.
login_trusted_networks = 192.168.0.0/24 192.168.7.0/24 10.45.1.12

In this case dovecot was configured to allow plaintext logins from two 192.68 subnets and her specific IP address. But since her IP address had changed to a new one, dovecot was no longer permitting plaintext authentication from her system. After changing the login_trusted_networks line to match her particular IP address, I restarted dovecot.

# service dovecot restart
Redirecting to /bin/systemctl restart  dovecot.service

When I had her try again, she was then able to download her email.

Note: IP addresses, userid, and password are, of course, not the actual ones used.

[/network/email/dovecot] permanent link

Task 'jasmith@example.com - Receiving' reported error (0x800CCC92) : 'Your e-mail server rejected your login. Verify your user name and password for this account in Account Settings. The server responded: -ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.'

At first I thought the tech who upgraded the system had made some change to Outlook on the system, but I eventually realized that the email server using dovecot for POP3 email access was denying access, because the system had a new IP address. The user was using POP3, port 110, for downloading email and I had previously added the old IP address to the login_trusted_networks line in /etc/dovecot/dovecot.conf file on the email server. By adding an IP address or IP address range to that line, you can configure dovecot to allow users to login using an unencrypted userid and password, i.e., plaintext authentication, from the specified IP address or range of addresses. The relevant section in dovecot.conf is shown below:

# Space separated list of trusted network ranges. Connections from these
# IPs are allowed to override their IP addresses and ports (for logging and
# for authentication checks). disable_plaintext_auth is also ignored for
# these networks. Typically you'd specify your IMAP proxy servers here.
login_trusted_networks = 192.168.0.0/24 192.168.1.0/24 172.45.55.82

In the case above, the server will accept plaintext passwords from any system in the 192.168.0.0/24 address range, i.e., 192.168.0.0 to 192.168.0.255, the 192.168.1.0/24 address range, and from the specific IP address 172.45.55.82, which was the user's IP address. After updating her IP address in the file, I restarted dovecot with service dovecot restart.

The system uses sendmail for sending email and I also had to update /etc/mail/access to include her IP address, since the change to the dovecot configuration file allowed her to download her email, but sendmail would still not except any email sent from her computer, since relaying was permitted from her old email address, but not her new one. I added her IP address and a comment line to the /etc/mail/access file.

# J. A. Smith
172.45.55.82                           RELAY

I then used makemap hash to generate an updated /etc/mail/access.db file.

# makemap hash /etc/mail/access </etc/mail/access

She was then able to send as well as receive email; I didn't need to restart sendmail.

[/network/email/dovecot] permanent link