exim auth problem

[mazek]

Hi,

Ive found many similar problems in archive but none of give solutions helped. Quite common problem with smtp authorization:

fixed_plain authenticator failed for ([172.19.9.24]) [x.x.x.x]: 535 Incorrect authentication data ([email protected])

I have tried:
- turning off pop3 befor smtp, antirelayd turnde off, exim restarted
- turning off "Attempt to prevent pop3 connection floods" in setting tweak
- eximup & upcp
- /etc/doemodomains and demousers is empty
- /etc/relayhosts relayhostsusers emptied & exim restarted
- resolved logrotate /tmp noexec issue

and no idea what has changed after last update.

WHM 10.8.0 cPanel 10.9.0-S9966
CentOS 4.5 x86_64 - WHM X v3.1.0


any ideas?

thank You.

 

[jerrybell]

So, I ran into the same problem. After looking at the exim config, I tried using the "unix" username and password - not the email account id and password - sure enough it works. In order to get it to work the way it should work, we'll have to figure out how to check a password against the database where the email account id's are stored.

 

[jerrybell]

So, I just had a little time to play with this, and I found the problem - at least the one I was having. In a nutshell, it's permissions and ownership of the /home/%user%/etc/%domain%/shadow file and directory heirarchy.

Exim calls a perl subroutine that expands out which shadow file it should be referencing. I created a brand new domain, added an account and noticed that smtp auth worked. So, I looked at the permissions on the directory structure, and found that I had munged them up while I was trying to fix some other web problems.

/home/%user%/etc and /home/%user%/etc/%domain% should be owned by the unix user, with a group of "mail".
/home/%user%/etc/%domain%/shadow should have a group of mail and the permissions should be 640

Once I took care of that, it worked fine. Hopefully that helps someone else.

Jerry

 

[panayot]

Thank you Jerry! This worked pefectly for me :D

So, I just had a little time to play with this, and I found the problem - at least the one I was having. In a nutshell, it's permissions and ownership of the /home/%user%/etc/%domain%/shadow file and directory heirarchy.

Exim calls a perl subroutine that expands out which shadow file it should be referencing. I created a brand new domain, added an account and noticed that smtp auth worked. So, I looked at the permissions on the directory structure, and found that I had munged them up while I was trying to fix some other web problems.

/home/%user%/etc and /home/%user%/etc/%domain% should be owned by the unix user, with a group of "mail".
/home/%user%/etc/%domain%/shadow should have a group of mail and the permissions should be 640

Once I took care of that, it worked fine. Hopefully that helps someone else.

Jerry

 

[Sabaote]

Thanks jerrybell

it worked perfectly

 

[expertis]

Hi Jerry,

Thanks for the post, this fixed a problem I just experienced with one domain. I had to go in and set the permissions on 'shadow' to 640 and the users were then able to send out mail.

Does anyone know why this shadow files permissions would have changed? This domains users weren't having any problem sending or receiving until 2 days ago. From that point forward they could receive email, but not send email. It would stay in the Outlook outbox.

Thank you,

Spencer

 

[mterrats]

@Jerry: thanks for the tip, I had this issue after migrating some sites from Ensim X to cPanel.

I did a small/fancy/dirty php script that will do what Jerry said, copy/paste the code and execute it, it will walk through all your domains and check if those files have the right ownership and permissions. If you see some site is not ok you can do it manually or set the $debug variable in the script to false and let it fix it for you

#!/usr/bin/php -q
<?
// file: fix_auth_perms.php
// turn it off if you want to fix them
// based on http://forums.cpanel.net/showpost.php?p=323248&postcount=3
// more details http://xux.in/blog/post/cpanel-535-incorrect-authentication-data/
$debug = true;
 
$maps = file("/etc/domainusers");
if (!is_array($maps)) die("No users found!\n");
 
foreach ($maps as $map) {
  list($user,$domain) = explode(": ",trim($map));
  if (!$user || !$domain) continue;
  echo "\nChecking $domain ...\n";
  _file_fix("/home/$user/etc",$user,"mail");
  _file_fix("/home/$user/etc/$domain",$user,"mail");
  _file_fix("/home/$user/etc/$domain/shadow","","mail","0640");
  //exit;
}
 
// $file = full dir/file path
// $nuser = desired user name
// $ngroup = desired group name
// $perms = desired permissions in octal mode (0640)
function _file_fix($file="",$nuser="",$ngroup="",$perms="") {
  global $debug;
  $uname_array = posix_getpwuid(fileowner($file));
  $gname_array = posix_getgrgid(filegroup($file));
  $file_perms = substr(sprintf('%o', fileperms($file)), -4);
  echo "  $file owned by $uname_array[name].$gname_array[name] ($file_perms)\n";
    //wrong ownership, fixing it now!
  if (!$debug) {
    if ($nuser && $nuser != $uname_array[name]) {
      if (!chown($file, $uname_array[name])) echo "  couldn't change file owner to $nuser\n";
      else echo "  changed file owner to $nuser\n";
    }
    if ($ngroup && $ngroup != $gname_array[name]) {
      if (!chgrp($file, $gname_array[name])) echo "  couldn't change group owner to $ngroup\n";
      else echo "  changed group owner to $ngroup\n";
    }
  }
  if ($perms && $perms != $file_perms) {
    if (!$debug) {
      if (!chmod($file,octdec($perms))) echo "  couldn't change file mode to $perms\n";
      else echo "  changed file mode to $perms\n";
    }
  }
  //making a nice output :P
  if (!$nuser) $nuser = $uname_array[name];
  if (!$ngroup) $ngroup = $gname_array[name];
  if (!$perms) $perms = $file_perms;
  echo "  $file should now be owned by $nuser.$ngroup ($perms)\n";
}
 
?>

 

[RACKSET]

So, I just had a little time to play with this, and I found the problem - at least the one I was having. In a nutshell, it's permissions and ownership of the /home/%user%/etc/%domain%/shadow file and directory heirarchy.

Exim calls a perl subroutine that expands out which shadow file it should be referencing. I created a brand new domain, added an account and noticed that smtp auth worked. So, I looked at the permissions on the directory structure, and found that I had munged them up while I was trying to fix some other web problems.

/home/%user%/etc and /home/%user%/etc/%domain% should be owned by the unix user, with a group of "mail".
/home/%user%/etc/%domain%/shadow should have a group of mail and the permissions should be 640

Once I took care of that, it worked fine. Hopefully that helps someone else.

Jerry

Also make sure that files under /home/%user%/etc/%domain%/@pwcache be owned by the unix user, with a group of "mail".

That was the issue with one of our clients, and no one mentioned the solution. Hope this help others have the same issue.

 

[PDW]

I have this same error coming up for both Harde, Squirrell Mail and then RC doesnt show anything or work.

Ive checked the owner permissions, the folder and file permissions
backdated and updated cpanel. I did get SQM to work by going in and changing the sendmail $useSendmail = false; to $useSendmail = true; but stil lat a loss for everything else.