Skip to main content

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=, method=PLAIN, rip=CUSTOMER_IP, lip=SERVER_IP, session= 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.

Comments

3 comments

Date Votes
  • quietFinn
    These " legitimate clients" may have a (forgotten) device trying to connect with wrong credientials. :rolleyes:
    0
  • 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=, method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS, session= 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.
    0
  • LvH
    Jul 25 00:16:35 www dovecot: imap-login: Disconnected: Aborted login by logging out (auth failed, 5 attempts in 26 secs): user=, method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS, session= 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 (
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post