Someone reported to me recently that she could no longer check her email. She was using Outlook and kept getting prompted to provide the password, but when she provided it Outlook wasn't able to check her incoming email and she would be prompted for the password again.
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.
