Sending mail via authentication stopped working overnight [case 50280]

[jerrybell]

I started seeing errors like this overnight (id obscured):
535 Incorrect authentication data (set_id=test@test.org)
in mainlog. This is happening to everyone who tries to send using authentication, on any domain on the system. Any ideas what could be wrong?

[jerrybell]

So, it looks like lsearch of /etc/userdomains is failing... I started exim in debug mode and saw this:

10:26:34 25242 search_open: lsearch "/etc/userdomains"
10:26:34 25242   cached open
10:26:34 25242 search_find: file="/etc/userdomains"
10:26:34 25242   key=""stelesys.com"" partial=-1 affix=NULL starflags=0
10:26:34 25242 LRU list:
10:26:34 25242   6/etc/userdomains
10:26:34 25242   5/etc/relayhosts
10:26:34 25242   5/etc/trustedmailhosts
10:26:34 25242   6/etc/trustedmailhosts
10:26:34 25242   End
10:26:34 25242 internal_search_find: file="/etc/userdomains"
10:26:34 25242   type=lsearch key=""stelesys.com""
10:26:34 25242 cached data used for lookup of "stelesys.com"
10:26:34 25242   in /etc/userdomains
10:26:34 25242 lookup failed
10:26:34 25242 expanding: $value
10:26:34 25242    result:
10:26:34 25242 skipping: result is not used
10:26:34 25242 expanding: ${lookup{"stelesys.com"}lsearch{/etc/userdomains}{$value}}
10:26:34 25242    result:
10:26:34 25242 expanding: ${perl{checkuserpass}{$1}{$2}}
10:26:34 25242    result: no
10:26:34 25242 expanded string: no
10:26:34 25242 expanding: $1
10:26:34 25242    result: jerry@stelesys.com
10:26:34 25242 SMTP>> 535 Incorrect authentication data

This part:
10:26:34 25242 expanding: ${lookup{"stelesys.com"}lsearch{/etc/userdomains}{$value}}
10:26:34 25242 result:

Should return the user name associated with stelesys.com, but does not and so the rest fails because it doesn't know where to go to look at the passwords.

[cpanelnick]

So, it looks like lsearch of /etc/userdomains is failing... I started exim in debug mode and saw this:

10:26:34 25242 search_open: lsearch "/etc/userdomains"
10:26:34 25242   cached open
10:26:34 25242 search_find: file="/etc/userdomains"
10:26:34 25242   key=""stelesys.com"" partial=-1 affix=NULL starflags=0
10:26:34 25242 LRU list:
10:26:34 25242   6/etc/userdomains
10:26:34 25242   5/etc/relayhosts
10:26:34 25242   5/etc/trustedmailhosts
10:26:34 25242   6/etc/trustedmailhosts
10:26:34 25242   End
10:26:34 25242 internal_search_find: file="/etc/userdomains"
10:26:34 25242   type=lsearch key=""stelesys.com""
10:26:34 25242 cached data used for lookup of "stelesys.com"
10:26:34 25242   in /etc/userdomains
10:26:34 25242 lookup failed
10:26:34 25242 expanding: $value
10:26:34 25242    result:
10:26:34 25242 skipping: result is not used
10:26:34 25242 expanding: ${lookup{"stelesys.com"}lsearch{/etc/userdomains}{$value}}
10:26:34 25242    result:
10:26:34 25242 expanding: ${perl{checkuserpass}{$1}{$2}}
10:26:34 25242    result: no
10:26:34 25242 expanded string: no
10:26:34 25242 expanding: $1
10:26:34 25242    result: jerry@stelesys.com
10:26:34 25242 SMTP>> 535 Incorrect authentication data

This part:
10:26:34 25242 expanding: ${lookup{"stelesys.com"}lsearch{/etc/userdomains}{$value}}
10:26:34 25242 result:

Should return the user name associated with stelesys.com, but does not and so the rest fails because it doesn't know where to go to look at the passwords.

You can rebuild this file by running /scripts/updateuserdomains

[jerrybell]

Thanks for the tip, Nick. Unfortunately, it didn't help. I can't see any problems with the format of the file. After running updateuserdomains, I get the very same problem when I look at the debug.

[cpanelnick]

Thanks for the tip, Nick. Unfortunately, it didn't help. I can't see any problems with the format of the file. After running updateuserdomains, I get the very same problem when I look at the debug.

I think the best bet is to open a ticket at https://tickets.cpanel.net/submit/ or from WHM and post the case number here.

[jerrybell]

I have cpanel through a reseller, so I have requested my hosting provider to open the ticket. I will post the number once I have it.

Thank you

[cpanelnick]

You can still open a ticket by going to this link or doing it though WHM when logged in as root.

https://tickets.cpanel.net/submit/in...&product=cpwhm

[xspace]

The same happen on my VPS after upgrade to 11.30 build 23 overnight. User can't authenticate via SMTP /535/, but can via Webmail.

[fdnven]

Hi,

Currently production servers were up-dated to 11.30 stable (build23). After the update users are unable to send mail SMPT. The error is always the same Error message: "Login to server mail.********.net failed." Nothing has changed on the users end.

I have tried the Fix Permissions and ended up with alot of :
Fixed permissions of /home/*****/mail/***** : was (0751), now (0750)

Still has not cured the SMPT issue.

Thanks

[slago]

Some problem here!!

Now we can't send mail, and squirremail show:

535 Incorrect authentication data

I do a lot of things, update, fix demo files, etc... and nothing happend.

Some idea?

I open a ticket at least 3 hours and nothing happend. case ticket is 1559702

[jerrybell]

I believe you are having the same problem that I and a few others are having. I started a thread about it here. Cpanel support has been working on the issue for me. Hopefully we can figure out what is causing it soon.

[cpanelnick]

Troubleshooting Steps. Try each step, then try authenticating again.

• 1) Update to 11.30.0.25
  
• 2) Make sure have imap enabled.
  WHM >> Service Configuration >> Service Manager
  
• 3) Make sure courier and dovecot are set to "Inherit" and not "Never"
  WHM >> Server Configuration >> Update Preferences
  
• 4) If you have not selected a mail server during the initial setup phase, please use the mail server selection tool to do this now.
  WHM >> Service Configuration >> Mailserver Selection
  
• 5) Run the following in a root shell:

  /scripts/mailperm

• 6) Open a ticket using Support >> Contact cPanel or https://tickets.cpanel.net/submit/ and post the ticket # in this thread

The SMTP auth problem is being investigated and has been assigned case 50280.

We are aware servers still running mbox instead of maildir ceased to have functional mail upon upgrading to 11.30. August 1, 2008 was date support for mbox was discontinued. However, we plan on issuing an update to restore mbox functionality to 11.28 levels in the next 48 hours. The mbox fixes have been assigned case 50270.

[fdnven]

Hi,

Your Request id is: 1562301
And
Support Request Id 1562325

[jerrybell]

For those impacted by this problem, cpanel support provided a workaround... Change from courier to dovecot. I was quite skeptical that it would do anything to help, but after changing to dovecot, a new authenticator is added to exim, which is used to authenticate SMTP connections, and at least in my case, it's working. Here's how I fixed it:

1. log in to WHM as root
2. navigate to "mailserver selection"
3. choose "dovecot" and click the "save" button. It takes a few minutes to complete and smtp authentication should start working.

Best of luck to all

[cpanelnick]

We have released 11.30.0.25 which repairs the fallback code that is used when dovecot or courier is not available to authenticate. On a side note, I would personally recommend switching your server to dovecot as its performance is drastically better then courier in most situations.