I'm having problems with what I think is PAM. Seems that ever since Centos 5, proftpd has had problems using pam, and with Centos 6.2 64 bit, I had to quit using it altogether with proftpd.
Now I'm trying to set up SMTP AUTH using PAM as the pwcheck parm to saslauthd, and I can't setup new email accounts on my port submission (587) to work at all. We use this port of sendmail so outside users can send through our own email server. The crazy thing is that users that were setup previously before my migration from an older Centos 3 box to the new box can still use the port fine on the new server. But I can't get a new account to work. I'm not seeing any errors anywhere, but when trying to configure an account manually in Thunderbird, it fails whenever I use port 587. I've got a similar host on using old Centos 3 that still works fine and I'm using it as a model along with the settings on the original Centos 3 host that was replaced for most of my parameters.
Anyone had any experience with sendmail and this sort of thing on Centos 6.2? I've stared at this thing for days and tried about everything I can think of. The yum says pam is up to date.
I have at the least the same pam packages, if not more, on the new server as the old ones.
Any help would be appreciated.
steve campbell
On Wed, Feb 22, 2012 at 2:36 PM, Steve Campbell campbell@cnpapers.com wrote:
I'm having problems with what I think is PAM. Seems that ever since Centos 5, proftpd has had problems using pam, and with Centos 6.2 64 bit, I had to quit using it altogether with proftpd.
Do you mean some specific pam step listed in /etc/pam.d/proftpd fails, or what? And are you doing anything exotic there or just trying to read the shadow file? And when reading the shadow file, is SElinux enabled and logging errors?
On 2/22/2012 4:31 PM, Les Mikesell wrote:
On Wed, Feb 22, 2012 at 2:36 PM, Steve Campbellcampbell@cnpapers.com wrote:
I'm having problems with what I think is PAM. Seems that ever since Centos 5, proftpd has had problems using pam, and with Centos 6.2 64 bit, I had to quit using it altogether with proftpd.
Do you mean some specific pam step listed in /etc/pam.d/proftpd fails, or what? And are you doing anything exotic there or just trying to read the shadow file? And when reading the shadow file, is SElinux enabled and logging errors?
No, nothing exotic, just a generic install of Proftpd.
On the Centos 5 boxes, I started getting the following, but it would work:
Deprecated pam_stack module called from service "proftpd" pam_succeed_if(proftpd:session): error retrieving information about user 0 pam_unix(proftpd:session): session closed for user XXXX
I'd found tons of fixes for it, but most would mean just editing the /etc/pam.d/proftpd file or making /etc/pam.d/ftp file the same as proftpd file. Nothing was a clean fix. But logins would still work.
On the Centos 6.2 box, logins wouldn't work at all unless I removed the line requiring pam_shells.so.
Now on to the big problem. In the file /etc/sasl2/Sendmail.conf I've got the line:
pwcheck_method:pam
I've got the certificates all fine in the sendmail.mc/cf file just fine, I've got the port 587 defined and it's showing in netstat, but when I try and create an account to access port 587 to send email through, no matter what method I use (ssh, tls, plain ) I can't get an email to go through this. I'm guessing that since I've got these ever-increasing problems with PAM, maybe there's something I'm overlooking in the Pam config, but I'm not aware of any problems. I just can't seem to get authenticated.
I'm aware that going from Centos 3 to Centos 6.2 is a big jump. Fighting Dovecot for Imap has been the biggest hurdle, and it's just recently that people have started notifying me of some of the problems of being able to relay through our server.
My access file on both old and new are duplicates, so the problem isn't there. The other sendmail files are the same as well (local domains, etc).
There's not a wall hard enough for me to keep banging my head against, it seems, and I'm really not getting any benefit from banging it.
SeLinux is off as well as iptables and ip6tables. The firewalling is done for all servers on the network, not the individual server, and the IP of the new server took over the IP of the old server, so the firewall should still be good for all ports and services.
Proftpd is not the real problem here, but the sendmail problem is causing a few calls.
Thanks for any help and replies steve
On 2/23/2012 7:36 AM, Steve Campbell wrote:
On 2/22/2012 4:31 PM, Les Mikesell wrote:
On Wed, Feb 22, 2012 at 2:36 PM, Steve Campbellcampbell@cnpapers.com wrote:
I'm having problems with what I think is PAM. Seems that ever since Centos 5, proftpd has had problems using pam, and with Centos 6.2 64 bit, I had to quit using it altogether with proftpd.
Do you mean some specific pam step listed in /etc/pam.d/proftpd fails, or what? And are you doing anything exotic there or just trying to read the shadow file? And when reading the shadow file, is SElinux enabled and logging errors?
No, nothing exotic, just a generic install of Proftpd.
On the Centos 5 boxes, I started getting the following, but it would work:
Deprecated pam_stack module called from service "proftpd" pam_succeed_if(proftpd:session): error retrieving information about user 0 pam_unix(proftpd:session): session closed for user XXXX
I'd found tons of fixes for it, but most would mean just editing the /etc/pam.d/proftpd file or making /etc/pam.d/ftp file the same as proftpd file. Nothing was a clean fix. But logins would still work.
On the Centos 6.2 box, logins wouldn't work at all unless I removed the line requiring pam_shells.so.
Now on to the big problem. In the file /etc/sasl2/Sendmail.conf I've got the line:
pwcheck_method:pam
I've got the certificates all fine in the sendmail.mc/cf file just fine, I've got the port 587 defined and it's showing in netstat, but when I try and create an account to access port 587 to send email through, no matter what method I use (ssh, tls, plain ) I can't get an email to go through this. I'm guessing that since I've got these ever-increasing problems with PAM, maybe there's something I'm overlooking in the Pam config, but I'm not aware of any problems. I just can't seem to get authenticated.
I'm aware that going from Centos 3 to Centos 6.2 is a big jump. Fighting Dovecot for Imap has been the biggest hurdle, and it's just recently that people have started notifying me of some of the problems of being able to relay through our server.
My access file on both old and new are duplicates, so the problem isn't there. The other sendmail files are the same as well (local domains, etc).
There's not a wall hard enough for me to keep banging my head against, it seems, and I'm really not getting any benefit from banging it.
SeLinux is off as well as iptables and ip6tables. The firewalling is done for all servers on the network, not the individual server, and the IP of the new server took over the IP of the old server, so the firewall should still be good for all ports and services.
Proftpd is not the real problem here, but the sendmail problem is causing a few calls.
Thanks for any help and replies steve
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Seems I've found that dovecot is handling the auth for smtp, and it doesn't like sendmail very much since their documentation avoids sendmail like the plague.
I sure wish Centos/RH had left something for us so that I wouldn't have to learn dovecot, postfix and all the other stuff. The original tests I ran seemed to handle most of the stuff normally but now users are calling and complaining and there's not a lot I can do but forge ahead.
Not happy but it's my own fault
Thanks for the help
steve
On Thu, Feb 23, 2012 at 9:54 AM, Steve Campbell campbell@cnpapers.com wrote:
Seems I've found that dovecot is handling the auth for smtp, and it doesn't like sendmail very much since their documentation avoids sendmail like the plague.
None of that makes any sense. Dovecot should have nothing to do with smtp, so of course it doesn't have anything about sendmail in its documentation other than adding its local delivery agent which should be their only interaction and you probably don't even need to use that.
On Thu, 23 Feb 2012, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 9:54 AM, Steve Campbell campbell@cnpapers.com wrote:
Seems I've found that dovecot is handling the auth for smtp, and it doesn't like sendmail very much since their documentation avoids sendmail like the plague.
The Dovecot developer is a smart dude. :-)
None of that makes any sense. Dovecot should have nothing to do with smtp, so of course it doesn't have anything about sendmail in its documentation other than adding its local delivery agent which should be their only interaction and you probably don't even need to use that.
Actually it might. Dovecot can do the sasl auth part. I have not touched sendmail in at least 10 years, so I do not know anything about the current default sendmail config but I know dovecot sasl auth is easier to config for postfix (5 lines in the postfix main.cf IIRC).
I suppose it is possible that RH switched sendmail to user dovecot sasl in their default config.
HTH,
Regards,
On Thu, Feb 23, 2012 at 10:39 AM, me@tdiehl.org wrote:
Seems I've found that dovecot is handling the auth for smtp, and it doesn't like sendmail very much since their documentation avoids sendmail like the plague.
The Dovecot developer is a smart dude. :-)
None of that makes any sense. Dovecot should have nothing to do with smtp, so of course it doesn't have anything about sendmail in its documentation other than adding its local delivery agent which should be their only interaction and you probably don't even need to use that.
Actually it might. Dovecot can do the sasl auth part. I have not touched sendmail in at least 10 years, so I do not know anything about the current default sendmail config but I know dovecot sasl auth is easier to config for postfix (5 lines in the postfix main.cf IIRC).
I suppose it is possible that RH switched sendmail to user dovecot sasl in their default config.
Sendmail is infinitely configurable, but I don't see any uncommented Auth schemes in the stock sendmail.mc and the smtp-sendmail file in pam.d just invokes 'system-auth' on 5.x and 'password-auth' on 6.x, like most of the other things. Something else must be going on here.
On 2/23/2012 11:55 AM, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 10:39 AM,me@tdiehl.org wrote:
Seems I've found that dovecot is handling the auth for smtp, and it doesn't like sendmail very much since their documentation avoids sendmail like the plague.
The Dovecot developer is a smart dude. :-)
None of that makes any sense. Dovecot should have nothing to do with smtp, so of course it doesn't have anything about sendmail in its documentation other than adding its local delivery agent which should be their only interaction and you probably don't even need to use that.
Actually it might. Dovecot can do the sasl auth part. I have not touched sendmail in at least 10 years, so I do not know anything about the current default sendmail config but I know dovecot sasl auth is easier to config for postfix (5 lines in the postfix main.cf IIRC).
I suppose it is possible that RH switched sendmail to user dovecot sasl in their default config.
Sendmail is infinitely configurable, but I don't see any uncommented Auth schemes in the stock sendmail.mc and the smtp-sendmail file in pam.d just invokes 'system-auth' on 5.x and 'password-auth' on 6.x, like most of the other things. Something else must be going on here.
Seems that I've gotten myself into a war over on the dovecot forums. Not what I intended to do, but when using sendmail with dovecot, it appears that dovecot auth takes over what sasl auth used to do.
Pretty much over there uses postfix and postfix supports dovecot auth. sendmail doesn't. I don't know how to separate the auth stuff.
I agree with you concerning the pam files being pretty simple. If I turn off dovecot and try and connect to port 587, I get nothing including no return. If I turn on dovecot, I get dovecot auth failures in my secure logs. Sort of tells me that dovecot is taking over the auth processes from sasl. I could be wrong.
steve
On Thu, Feb 23, 2012 at 11:18 AM, Steve Campbell campbell@cnpapers.com wrote:
Seems that I've gotten myself into a war over on the dovecot forums. Not what I intended to do, but when using sendmail with dovecot, it appears that dovecot auth takes over what sasl auth used to do.
You are still not making any sense. Dovecot doesn't do anything directly to sendmail. If anything like this is happening at all, it is in the configurations as shipped by whatever packages you have installed, or some local change you have. Or maybe by the slightly-weird 'alternatives' system. Have you followed all of the symlinks that might be involved?
Pretty much over there uses postfix and postfix supports dovecot auth. sendmail doesn't. I don't know how to separate the auth stuff.
What does that mean. And what do you want to happen?
I agree with you concerning the pam files being pretty simple. If I turn off dovecot and try and connect to port 587, I get nothing including no return.
What does 'turn off dovecot' mean? And did you note the comment in sendmail.mc: ' Please remember that saslauthd needs to be running for AUTH'
If I turn on dovecot, I get dovecot auth failures in my secure logs. Sort of tells me that dovecot is taking over the auth processes from sasl. I could be wrong.
That would probably be a good thing, since you generally want the same people to authenticate the same way for imap and authenticated sending. Why not leave that part alone and focus on fixing it?
On 2/23/2012 12:44 PM, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 11:18 AM, Steve Campbellcampbell@cnpapers.com wrote:
Seems that I've gotten myself into a war over on the dovecot forums. Not what I intended to do, but when using sendmail with dovecot, it appears that dovecot auth takes over what sasl auth used to do.
You are still not making any sense. Dovecot doesn't do anything directly to sendmail. If anything like this is happening at all, it is in the configurations as shipped by whatever packages you have installed, or some local change you have. Or maybe by the slightly-weird 'alternatives' system. Have you followed all of the symlinks that might be involved?
Symlinks? I haven't found any of those yet. All files are real files
Pretty much over there uses postfix and postfix supports dovecot auth. sendmail doesn't. I don't know how to separate the auth stuff.
What does that mean. And what do you want to happen?
Meant to say pretty much everyone over on the dovecot list must be using postfix, which has support for dovecot auth. I'd like to make sendmail use cyrus sasl, and I don't really care what auth dovecot uses, but I'm guessing it's inflexible so that it probably will use dovecot auth. The suggestion to make them the same has been brought up, but all's I want to use is the PAM mechanism.
I agree with you concerning the pam files being pretty simple. If I turn off dovecot and try and connect to port 587, I get nothing including no return.
What does 'turn off dovecot' mean? And did you note the comment in sendmail.mc: ' Please remember that saslauthd needs to be running for AUTH'
turn off dovecot means "service dovecot stop" or "/etc/rc.d/init.d/dovecot stop". saslauthd is still running and so is sendmail. saslauthd is started at boot and I've made sure it really is running using ps.
If I turn on dovecot, I get dovecot auth failures in my secure logs. Sort of tells me that dovecot is taking over the auth processes from sasl. I could be wrong.
That would probably be a good thing, since you generally want the same people to authenticate the same way for imap and authenticated sending. Why not leave that part alone and focus on fixing it?
Believe me, if I knew where to start looking, I would. As far as everything I've looked out, both should be using pam, but the auth file for dovecot is a little cryptic to me. My fault, I know, but still I'm not finding out a lot about it.
This is a great suggestion, and for the time being, I'll concentrate on the auth config file for dovecot.
Sorry to all for sounding so buttish. Don't mean to be that way.
Thanks for all the help so far
steve
On Thu, Feb 23, 2012 at 12:20 PM, Steve Campbell campbell@cnpapers.com wrote:
Or maybe by the
slightly-weird 'alternatives' system. Have you followed all of the symlinks that might be involved?
Symlinks? I haven't found any of those yet. All files are real files
On a 6.x system with dovecot and sendmail, /etc/pam.d/smtp is a symlink. I haven't tracked down the significance.
Meant to say pretty much everyone over on the dovecot list must be using postfix, which has support for dovecot auth. I'd like to make sendmail use cyrus sasl, and I don't really care what auth dovecot uses, but I'm guessing it's inflexible so that it probably will use dovecot auth.
Whatever you think about sendmail, you can't say it is inflexible. And whatever issues you are having are from not understanding the configuration.
The suggestion to make them the same has been brought up, but all's I want to use is the PAM mechanism.
That should have been the default.
turn off dovecot means "service dovecot stop" or "/etc/rc.d/init.d/dovecot stop". saslauthd is still running and so is sendmail. saslauthd is started at boot and I've made sure it really is running using ps.
That's not a default, is it? Or for sendmail to use it? And it is probably the one from the cyrus-sasl package.
On 2/23/2012 1:35 PM, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 12:20 PM, Steve Campbellcampbell@cnpapers.com wrote:
Or maybe by the
slightly-weird 'alternatives' system. Have you followed all of the symlinks that might be involved?
Symlinks? I haven't found any of those yet. All files are real files
On a 6.x system with dovecot and sendmail, /etc/pam.d/smtp is a symlink. I haven't tracked down the significance.
It appears it's just a basic pam file but instead of system-auth, it has password-auth.
Meant to say pretty much everyone over on the dovecot list must be using postfix, which has support for dovecot auth. I'd like to make sendmail use cyrus sasl, and I don't really care what auth dovecot uses, but I'm guessing it's inflexible so that it probably will use dovecot auth.
Whatever you think about sendmail, you can't say it is inflexible. And whatever issues you are having are from not understanding the configuration.
I don't have a problem with Sendmail, and it's always been flexible enough to do what I've needed from it. The configuration issue may be the problem, but I've been running it for twenty years or more and until now, that's not been the case. I'd say it's more than likely I don't understand the dovecot configurations.
The suggestion to make them the same has been brought up, but all's I want to use is the PAM mechanism.
That should have been the default.
I agree. But it didn't work.
turn off dovecot means "service dovecot stop" or "/etc/rc.d/init.d/dovecot stop". saslauthd is still running and so is sendmail. saslauthd is started at boot and I've made sure it really is running using ps.
That's not a default, is it? Or for sendmail to use it? And it is probably the one from the cyrus-sasl package.
Correct again. Apparently, since sendmail is the secondary choice for MTA and dovecot is to work with postfix, nothing about my setup now is standard or default except for dovecot.
Looks like I'm going to have to push postfix into service. It means learning where all the options are, just like in dovecot, and modifying any software that depends on the sendmail package, like MailScanner and who knows what else until I hit it.
Such a shame to have to throw away such a nice program, but I don't write it, I just use it.
steve
On Thu, Feb 23, 2012 at 2:20 PM, Steve Campbell campbell@cnpapers.com wrote:
On a 6.x system with dovecot and sendmail, /etc/pam.d/smtp is a symlink. I haven't tracked down the significance.
It appears it's just a basic pam file but instead of system-auth, it has password-auth.
System-auth was normal in 5.x, 6.x should have password-auth in most or all of the same places. And since you mentioned something about pam_stack earlier, that might be from 3.x, replaced by proper 'include' now.
Correct again. Apparently, since sendmail is the secondary choice for MTA and dovecot is to work with postfix, nothing about my setup now is standard or default except for dovecot.
A yum-installed sendmail should be 'standard enough' if you haven't done something like dropping a Centos 3.x sendmail.mc on top of the new one.
Looks like I'm going to have to push postfix into service. It means learning where all the options are, just like in dovecot, and modifying any software that depends on the sendmail package, like MailScanner and who knows what else until I hit it.
There might be a little safety-in-numbers from other people who don't know how to configure sendmail, but that's not really a good reason to switch. If sendmail auth works the way you expect before installing dovecot, just rpm -q --list dovecot and figure out which piece is breaking things.
On 2/23/2012 3:57 PM, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 2:20 PM, Steve Campbellcampbell@cnpapers.com wrote:
On a 6.x system with dovecot and sendmail, /etc/pam.d/smtp is a symlink. I haven't tracked down the significance.
It appears it's just a basic pam file but instead of system-auth, it has password-auth.
System-auth was normal in 5.x, 6.x should have password-auth in most or all of the same places. And since you mentioned something about pam_stack earlier, that might be from 3.x, replaced by proper 'include' now.
Correct again. Apparently, since sendmail is the secondary choice for MTA and dovecot is to work with postfix, nothing about my setup now is standard or default except for dovecot.
A yum-installed sendmail should be 'standard enough' if you haven't done something like dropping a Centos 3.x sendmail.mc on top of the new one.
Looks like I'm going to have to push postfix into service. It means learning where all the options are, just like in dovecot, and modifying any software that depends on the sendmail package, like MailScanner and who knows what else until I hit it.
There might be a little safety-in-numbers from other people who don't know how to configure sendmail, but that's not really a good reason to switch. If sendmail auth works the way you expect before installing dovecot, just rpm -q --list dovecot and figure out which piece is breaking things.
I never tested sendmail auth after setting things up. All seemed to be fine since sendmail reported all the auth stuff I needed when running the sendmail command. This was my fault for not testing this part.
The sendmail cf file was not copied, but most of the parms were duplicated in the sendmail.mc file and sendmail was rebuilt. No errors. Auth was never working properly since once I put dovecot on, saslauthd was scrambled. Unfortunately, I needed the pop and imap server before I found out auth was failing.
I can't blame any of the software for the problems I've created. But for now, I'm going into learn-postfix-crash mode and hope it'll do better for me. I can use the second new server to test with before I bring the original new server to it's knees.
What a pain, though.
steve
On Thu, Feb 23, 2012 at 3:10 PM, Steve Campbell campbell@cnpapers.com wrote:
The sendmail cf file was not copied, but most of the parms were duplicated in the sendmail.mc file and sendmail was rebuilt. No errors. Auth was never working properly since once I put dovecot on, saslauthd was scrambled. Unfortunately, I needed the pop and imap server before I found out auth was failing.
If you are changing things, why not use cyrus instead of dovecot?
Quoting Les Mikesell lesmikesell@gmail.com:
On Thu, Feb 23, 2012 at 3:10 PM, Steve Campbell campbell@cnpapers.com wrote:
The sendmail cf file was not copied, but most of the parms were duplicated in the sendmail.mc file and sendmail was rebuilt. No errors. Auth was never working properly since once I put dovecot on, saslauthd was scrambled. Unfortunately, I needed the pop and imap server before I found out auth was failing.
If you are changing things, why not use cyrus instead of dovecot?
-- Les Mikesell> CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
If you're talking cyrus-sasl, then that's a consideration. If you're talking cyrus imap, I'd have to see what provides pop.
I'm starting to see where all of my confusion is coming from.
steve
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
On Thu, Feb 23, 2012 at 7:17 PM, Steve Campbell campbell@cnpapers.com wrote:
The sendmail cf file was not copied, but most of the parms were duplicated in the sendmail.mc file and sendmail was rebuilt. No errors. Auth was never working properly since once I put dovecot on, saslauthd was scrambled. Unfortunately, I needed the pop and imap server before I found out auth was failing.
If you are changing things, why not use cyrus instead of dovecot?
If you're talking cyrus-sasl, then that's a consideration. If you're talking cyrus imap, I'd have to see what provides pop.
I'm starting to see where all of my confusion is coming from.
Cyrus and dovecot are alternative imap/pop servers with incompatible storage formats and program and configurations. Cyrus is probably more efficient with its own layout - dovecot uses more or less normal mbox or maildirs. Not sure how the saslauthd's relate - but it sounds like your sendmail is configured for cyrus-sasl but dovecot confuses it.
yum search cyrus shows a bunch of components.
-- Les Mikesell lesmikesell@gmail.com
On Feb 23, 2012, at 8:54 AM, Steve Campbell wrote:
Seems I've found that dovecot is handling the auth for smtp, and it doesn't like sendmail very much since their documentation avoids sendmail like the plague.
I sure wish Centos/RH had left something for us so that I wouldn't have to learn dovecot, postfix and all the other stuff. The original tests I ran seemed to handle most of the stuff normally but now users are calling and complaining and there's not a lot I can do but forge ahead.
Not happy but it's my own fault
Thanks for the help
---- I've stayed out of this thread because I like many others moved from sendmail to postfix many years ago as it is much simpler to deal with external resources such as LDAP & SASL authentication and thus had little to offer in terms of help without the relatively useless suggestion that you should likewise switch from sendmail to postfix. Note that the default SMTP server now on CentOS is postfix which I take as yet another sign that a majority of people have moved on to postfix too.
That said, it seems certain that sendmail is capable of doing SASL authentication (TLS/SSL/Plain) so the choice is yours.
You should be able to indicate to cyrus-saslauthd to use pam (/etc/sysconfig/saslauthd) and thus you would need to configure sendmail to listen and handle connections on the various ports (587 and perhaps 465 for Outlook users) and to use cyrus-saslauthd but to be honest, that's something I solved long ago using postfix (and LDAP users too). SASL would normally use 'PLAIN' authentication but it can be wrapped with TLS or SSL for encryption.
Good luck
Craig
On Thu, Feb 23, 2012 at 12:42 PM, Craig White craig.white@ttiltd.com wrote:
You should be able to indicate to cyrus-saslauthd to use pam (/etc/sysconfig/saslauthd) and thus you would need to configure sendmail to listen and handle connections on the various ports (587 and perhaps 465 for Outlook users) and to use cyrus-saslauthd
Pam should be the default setting. But why would things hang if he stops dovecot?
On Feb 23, 2012, at 11:59 AM, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 12:42 PM, Craig White craig.white@ttiltd.com wrote:
You should be able to indicate to cyrus-saslauthd to use pam (/etc/sysconfig/saslauthd) and thus you would need to configure sendmail to listen and handle connections on the various ports (587 and perhaps 465 for Outlook users) and to use cyrus-saslauthd
Pam should be the default setting. But why would things hang if he stops dovecot?
---- I don't ever use dovecot but that seems illogical but I think when you start flailing with configurations you tend to make some errors that manifest in strange ways.
Craig
On 2/23/2012 3:46 PM, Craig White wrote:
On Feb 23, 2012, at 11:59 AM, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 12:42 PM, Craig Whitecraig.white@ttiltd.com wrote:
You should be able to indicate to cyrus-saslauthd to use pam (/etc/sysconfig/saslauthd) and thus you would need to configure sendmail to listen and handle connections on the various ports (587 and perhaps 465 for Outlook users) and to use cyrus-saslauthd
Pam should be the default setting. But why would things hang if he stops dovecot?
I don't ever use dovecot but that seems illogical but I think when you start flailing with configurations you tend to make some errors that manifest in strange ways.
Craig _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I'm sure I have. I'll probably just erase sendmail, postfix, saslauthd, and dovecot and start over by reinstalling. steve
On 23/02/12 20:46, Craig White wrote:
On Feb 23, 2012, at 11:59 AM, Les Mikesell wrote:
On Thu, Feb 23, 2012 at 12:42 PM, Craig Whitecraig.white@ttiltd.com wrote:
You should be able to indicate to cyrus-saslauthd to use pam (/etc/sysconfig/saslauthd) and thus you would need to configure sendmail to listen and handle connections on the various ports (587 and perhaps 465 for Outlook users) and to use cyrus-saslauthd
Pam should be the default setting. But why would things hang if he stops dovecot?
I don't ever use dovecot but that seems illogical ...
Dovecot also has it's own built in SASL implementation so the OP might be using that rather than Cyrus SASL.
-
Craig White -
Les Mikesell -
me＠tdiehl.org -
Ned Slider -
Steve Campbell