MoonPoint Support Logo


Shop Amazon Warehouse Deals - Deep Discounts on Open-box and Used ProductsAmazon Warehouse Deals

Advanced Search
Sun Mon Tue Wed Thu Fri Sat

Wed, Jul 08, 2015 11:39 pm

Plaintext authentication disallowed on non-secure (SSL/TLS) connections

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
pass Rugs1234
+OK Logged in.
+OK 52 483564

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 > 

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- 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 > 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 > localhost.localdomain.pop3: Flags [P.], seq 76:78, 

ack 120, win 256, length 2
10:27:30.475264 IP localhost.localdomain.pop3 > Flags [.], ack 78, win 

115, length 0
10:27:30.475319 IP localhost.localdomain.pop3 > Flags [P.], seq 

120:125, ack 78, win 115, length 5

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

256, length 0
10:27:36.602821 IP > 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 > localhost.localdomain.pop3: Flags [P.], seq 91:93, 

ack 125, win 256, length 2
10:27:36.603007 IP localhost.localdomain.pop3 > Flags [.], ack 93, win 

115, length 0
10:27:36.735972 IP localhost.localdomain.pop3 > 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
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.                              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 =

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

Once You Know, You Newegg AliExpress by

Shop Amazon Local - Subscribe to Deals in Your Neighborhood

Valid HTML 4.01 Transitional

Privacy Policy   Contact

Blosxom logo