Aborted login by logging out

[JustSomeGuy]

I'm getting the following from legitimate clients on the server:

Jan 10 14:09:27 srv06 dovecot: pop3-login: Disconnected: Aborted login by logging out (auth failed, 1 attempts in 2 secs): user=<[email protected]>, method=PLAIN, rip=CUSTOMER_IP, lip=SERVER_IP, session=<qwzslkHVIspMRYT0>
Obviously I've taken out the actual email address, and IP's.

Anyone know why all of a sudden the last few weeks this is happening? In the end, LFD is blocking these legitimate customers.

 

[quietFinn]

These " legitimate clients" may have a (forgotten) device trying to connect with wrong credientials.

 

[laxbobber]

@quietFinn - definitely not (but I know exactly why that was your reaction!). We have been investigating these, too.

@JustSomeGuy - in the last few days we have also been seeing LFD blocking these legitimate customers, too. It seems to happen during the upcp run. In our case, maillog has things like:

Jul 25 00:16:35 www dovecot: imap-login: Disconnected: Aborted login by logging out (auth failed, 5 attempts in 26 secs): user=<[email protected]>, method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS, session=<iz8WSJr3wYCDXcqu>

This happens a few times and then LFD blocks these legitimate users. Had LFD not caught it things would pick right up and they'd be OK later. It is almost like upcp causes the mail daemon to not have access to (or have access to the wrong) user database temporarily.

Anyone else seen this? It is happening on a handful of servers for us so it's not isolated to one box.

 

[LiroyvH]

Jul 25 00:16:35 www dovecot: imap-login: Disconnected: Aborted login by logging out (auth failed, 5 attempts in 26 secs): user=<[email protected]>, method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS, session=<iz8WSJr3wYCDXcqu>

This happens a few times and then LFD blocks these legitimate users. Had LFD not caught it things would pick right up and they'd be OK later. It is almost like upcp causes the mail daemon to not have access to (or have access to the wrong) user database temporarily.

Anyone else seen this? It is happening on a handful of servers for us so it's not isolated to one box.

I was debugging this with a client today. It turned out the culprit was Microsoft Outlook (running on a Mac).
Outlook for whatever reason appeared to be trying to, on each login attempt, scan the server to see if it could login without TLS. Our servers are configured to not allow any login when TLS isn't enabled. So what happens is: Outlook connects, tries to go through without TLS. Server rejects to go to the authentication phase and thus the connection is severed after several attempts, which shows up as "aborted login". Then, Outlook proceeds to login *with* TLS, and the connection is accepted. Rinse and repeat multiple times per minute.

The solution was to err... Simply stop using Outlook and migrate to Mail.app. Problems instantly solved. I have no idea why on earth Outlook kept trying to authenticate without TLS. The checkboxes for secure connection were checked in the account settings, it had no business trying non-TLS. But it did. *shrugs* I'm not sure if Outlook on Windows pulls the same crap, but it might be worth looking for a fix. Either way, this error is mostly related to clients attempting to authenticate with either a broken protocol or over non-TLS whilst TLS is forcefully enabled on your server. (As it should be. )

Please note that the solution proposed in another topic about this (imap login: Disconnected / TLS: Connection closed) to "simply tell them not to use TLS" is imho dangerous. Nobody should be using non-TLS connections anymore and in this day and age: the mailservers and FTP server (if present) should have the options to force SSL/TLS enabled. "Just use an insecure connection" is not a solution, it's creating a much bigger problem in the form of a huge security risk; so please don't try something like that. Mac's are perfectly capable of using TLS with a proper mailclient.