biscotti
asked on
solaris SMTP auth /sendmail ?
Would like to install sendmail with smtp auth on new solaris-9 box which is to replace an older solaris box .the machine is an all-in-one mailserver (incoming and outgoing smtp, not currently using auth, using old version of sendmail, also pop, imap and some shell-based email clients (pine))
I want to know-
do I understand correctly that the only auth method available is plain if I want to use pam/unix (files) for authentication?
otherwise, I have to create a separate sasl database for sendmail to talk to??? (or else use ldap?)
could someone explain to me why this is? is it the type of encryption used in /etc/shadow (crypt) passwords?
supposing I put the smtp auth on a linux box instead, and split that functionality off of this machine. and used this machine just for mailbox storage (imap, pop,) and incoming smtp, and relaying restricted to the local net.
would there be any way to sync passwords between the two machines so that pop and imap passwords matched smtp passwords? assuming people generally need to be able to change them on the solaris machine (shell users)
I want to know-
do I understand correctly that the only auth method available is plain if I want to use pam/unix (files) for authentication?
otherwise, I have to create a separate sasl database for sendmail to talk to??? (or else use ldap?)
could someone explain to me why this is? is it the type of encryption used in /etc/shadow (crypt) passwords?
supposing I put the smtp auth on a linux box instead, and split that functionality off of this machine. and used this machine just for mailbox storage (imap, pop,) and incoming smtp, and relaying restricted to the local net.
would there be any way to sync passwords between the two machines so that pop and imap passwords matched smtp passwords? assuming people generally need to be able to change them on the solaris machine (shell users)
ASKER
thanks so much for your prompt response, and clear explanation of why solaris/des/crypt passwords cant be used for anyting put PLAIN auth.
the issue for us with using sasldb as I see it, is that then we need a mechanism to sync
the sasldb password with the unix password. moving to cyrus imap doesnt fix much for us, since at least 30% of our people use their unix accounts for shell access, including: shell-based email clients (e.g. pine), and ftp in addition to imap &/or pop email clients.
The UW imap works well for those that use both pine and an imap mail client, since the same folders are available to both apps.
The thought with splitting smtp auth to another machine was that, since linux can store password hashes in another format(md5?), I thought that possibly would help, and somehow sendmail could use those for other types of authentication.
In order not to have to add an additional password, I am wondering if you know of any way commonly used to sync the passwords between the sasldb and /etc/shadow. I spose I could write some kind of wrapper or replacement for /bin/passwd which also shoved the password into the sasldb,or updated both files.
The other option I see, is to use TLS and PLAIN auth for smtp auth, then I can use unix passwords for everything... do you know if I will have any problems supporting the popular email clients with this setup (e.g outlook, outlook express, netscape messenger, eudora)
downside being that all remote mail users now must get a certificate, and I have to get a cert for the mailserver (do you know if mail clients will have problems with a self-signed cert ?)
TIA
the issue for us with using sasldb as I see it, is that then we need a mechanism to sync
the sasldb password with the unix password. moving to cyrus imap doesnt fix much for us, since at least 30% of our people use their unix accounts for shell access, including: shell-based email clients (e.g. pine), and ftp in addition to imap &/or pop email clients.
The UW imap works well for those that use both pine and an imap mail client, since the same folders are available to both apps.
The thought with splitting smtp auth to another machine was that, since linux can store password hashes in another format(md5?), I thought that possibly would help, and somehow sendmail could use those for other types of authentication.
In order not to have to add an additional password, I am wondering if you know of any way commonly used to sync the passwords between the sasldb and /etc/shadow. I spose I could write some kind of wrapper or replacement for /bin/passwd which also shoved the password into the sasldb,or updated both files.
The other option I see, is to use TLS and PLAIN auth for smtp auth, then I can use unix passwords for everything... do you know if I will have any problems supporting the popular email clients with this setup (e.g outlook, outlook express, netscape messenger, eudora)
downside being that all remote mail users now must get a certificate, and I have to get a cert for the mailserver (do you know if mail clients will have problems with a self-signed cert ?)
TIA
Yes, if you use sasldb you do have to provide a means of synchronizing the passwords if they have to be the same. The point about Cyrus being able to work against a sasldb and not requiring mail accounts to correspond to Unix accounts is that the mail server can be isolated from ordinary user access & home dirs. The UW IMAP implementation requires that each mail user have a home dir available to the mail server. And that means that you have to do one of:
1) Run the mail server on the home dir server.
2) Automount the user's home dir on the mail server
3) Have special home dirs on the mail server just to satisfy UW IMAP.
Since Cyrus doesn't access a user's home dir the mail server can be a "standalone machine". And all of a user's mail folders live on the mail server itself.
Linux uses MD5, be default, for password encryption, but that doesn't help for the same reason that you can only have PLAIN on Solaris.
Yes, you could use TLS and continue to use PLAIN as an auth method. But that brings with it the certificate problem. TLS, in my opinion, is used when it's the mail data that you are trying to protect, not the username/password. And there could be problems with some clients.
1) Run the mail server on the home dir server.
2) Automount the user's home dir on the mail server
3) Have special home dirs on the mail server just to satisfy UW IMAP.
Since Cyrus doesn't access a user's home dir the mail server can be a "standalone machine". And all of a user's mail folders live on the mail server itself.
Linux uses MD5, be default, for password encryption, but that doesn't help for the same reason that you can only have PLAIN on Solaris.
Yes, you could use TLS and continue to use PLAIN as an auth method. But that brings with it the certificate problem. TLS, in my opinion, is used when it's the mail data that you are trying to protect, not the username/password. And there could be problems with some clients.
ASKER
ok, well thanks. I think that I am going to go with plain and login as auth methods,
and use TLS. Either that or force people to use a VPN if they want remote SMTP.
The pain of maintaining two separate password databases, seems difficult.
It would seem that using an LDAP database is the best solution in the long term, since when that is done, the 'authtokens' are available to any number of systems/applications which can use ldap...
and use TLS. Either that or force people to use a VPN if they want remote SMTP.
The pain of maintaining two separate password databases, seems difficult.
It would seem that using an LDAP database is the best solution in the long term, since when that is done, the 'authtokens' are available to any number of systems/applications which can use ldap...
I guess I didn't make it clear enough. Using Unix authentication the only method you have available is PLAIN. And the last time I looked at the issue an Outlook client can only do LOGIN when authenticating to an SMTP server.
LDAP looks attractive, but judging by the number of problems people seem to have with it (as mentioned on the Cyrus mailing list), I'm not sure that I'd want to use it.
FWIW: All of the mail servers that I manage now use only sasldb for authentication and Cyrus as the IMAP/POP server. Those installations were changed from using Unix authentication to be able to separate the mail server from the rest of the network resources, partly from availability considerations and partly for load issues. It took a while for folks to get used to the idea of one password for Unix access and another for mail, but they like the idea now. In the process of switching to the new system we also installed IMP as a webmail interface and that has received great approval from the users.
LDAP looks attractive, but judging by the number of problems people seem to have with it (as mentioned on the Cyrus mailing list), I'm not sure that I'd want to use it.
FWIW: All of the mail servers that I manage now use only sasldb for authentication and Cyrus as the IMAP/POP server. Those installations were changed from using Unix authentication to be able to separate the mail server from the rest of the network resources, partly from availability considerations and partly for load issues. It took a while for folks to get used to the idea of one password for Unix access and another for mail, but they like the idea now. In the process of switching to the new system we also installed IMP as a webmail interface and that has received great approval from the users.
ASKER
Allright, you obviously have a bunch more experience than I do with this, and that is why I am coming for help... but I am confused. I thought that LOGIN used plaintext, so sasl should be able to use unix passwords, if it gets plaintext ? I looked up the cyrus sasl documentation.
http://asg.web.cmu.edu/cyrus/download/sasl/doc/sysadmin.html
and saw:
"The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does. "
however, the cyrus 'black box' setup is appealing. If I could just get rid of the shell/pine users it would be great. with the servers that use sasldb do you have a mechanisim for people to reset passwords themselves??? that sounds like the only sticking point for me.
http://asg.web.cmu.edu/cyrus/download/sasl/doc/sysadmin.html
and saw:
"The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does. "
however, the cyrus 'black box' setup is appealing. If I could just get rid of the shell/pine users it would be great. with the servers that use sasldb do you have a mechanisim for people to reset passwords themselves??? that sounds like the only sticking point for me.
ASKER
Allright, you obviously have a bunch more experience than I do with this, and that is why I am coming for help... but I am confused. I thought that LOGIN used plaintext, so sasl should be able to use unix passwords, if it gets plaintext ? I looked up the cyrus sasl documentation.
http://asg.web.cmu.edu/cyrus/download/sasl/doc/sysadmin.html
and saw:
"The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does. "
however, the cyrus 'black box' setup is appealing. If I could just get rid of the shell/pine users it would be great. with the servers that use sasldb do you have a mechanisim for people to reset passwords themselves??? that sounds like the only sticking point for me.
http://asg.web.cmu.edu/cyrus/download/sasl/doc/sysadmin.html
and saw:
"The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does. "
however, the cyrus 'black box' setup is appealing. If I could just get rid of the shell/pine users it would be great. with the servers that use sasldb do you have a mechanisim for people to reset passwords themselves??? that sounds like the only sticking point for me.
ASKER
Allright, you obviously have a bunch more experience than I do with this, and that is why I am coming for help... but I am confused. I thought that LOGIN used plaintext, so sasl should be able to use unix passwords, if it gets plaintext ? I looked up the cyrus sasl documentation.
http://asg.web.cmu.edu/cyrus/download/sasl/doc/sysadmin.html
and saw:
"The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does. "
however, the cyrus 'black box' setup is appealing. If I could just get rid of the shell/pine users it would be great. with the servers that use sasldb do you have a mechanisim for people to reset passwords themselves??? that sounds like the only sticking point for me.
http://asg.web.cmu.edu/cyrus/download/sasl/doc/sysadmin.html
and saw:
"The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does. "
however, the cyrus 'black box' setup is appealing. If I could just get rid of the shell/pine users it would be great. with the servers that use sasldb do you have a mechanisim for people to reset passwords themselves??? that sounds like the only sticking point for me.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ok, thanks for clearing that up.
for now I am going to stick with the unix passwords, cause I dont want the overhead of migrating mailboxes and accounts, but I am definitely going to migrate to use of sasldb
for smtp auth, (when I split it off to another machine, it will make it really easy to just
export/rsync the sasldb file) we will either write something in house, or I will look into
a feature I saw mentioned in the sasl documentation (something like "auto update" or "auto migrate") which said that it created a sasldb entry automagically everytime plaintext auth is done against unix password)
thanks for the tip about squirrelmail. I run another webmail right now, and had heard of it.
I totally agree that from a security perspective, the blackbox mailserver is preferable.
hope you had a good thanksgiving ! :)
I'm going to roll up my sleeves and get to work::)
for now I am going to stick with the unix passwords, cause I dont want the overhead of migrating mailboxes and accounts, but I am definitely going to migrate to use of sasldb
for smtp auth, (when I split it off to another machine, it will make it really easy to just
export/rsync the sasldb file) we will either write something in house, or I will look into
a feature I saw mentioned in the sasl documentation (something like "auto update" or "auto migrate") which said that it created a sasldb entry automagically everytime plaintext auth is done against unix password)
thanks for the tip about squirrelmail. I run another webmail right now, and had heard of it.
I totally agree that from a security perspective, the blackbox mailserver is preferable.
hope you had a good thanksgiving ! :)
I'm going to roll up my sleeves and get to work::)
The easiest (and most robust) method of enabling the other auth methods is to use a sasldb. SMTP AUTH in sendmail only uses SASL, but that can be configured to then use LDAP to obtain the encrypted password. Doing so adds another layer to the authentication and thus is just another place to have problems. And don't forget that LDAP will have to support all of the encryption methods that you intend to enable in Sendmail.
I don't really see what you'd gain be splitting the outgoing mail server off from you mailhub. Unless you have a really large volume of outgoing mail so that splitting the functions makes sense from a load standpoint, it seems to me that it causes more problems than it solves. It is easy enough to build a sendmail (and SASL) on Solaris with SMTP AUTH enabled.
If you are going to be using SMTP AUTH it makes sense to me to also use the Cyrus IMAP implemetation (which uses SASL). Then the entire email system can use the same authentication database (and all of the mechanisms). And when using sasldb you can have the email authentication completely separated from the Solaris authentication. As a bonus, the Cyrus implementation doesn't need to access a user's home dir, allowing the mail server to be run in a black box mode where ordinary users don't have accounts and can't login.