solaris SMTP auth /sendmail ?

biscotti
biscotti used Ask the Experts™
on
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)
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2005

Commented:
Yes, if you use Unix authentication (against passwd/shadow files) you are limited to PLAIN. The reason is that Unix authentication only has the DES (on Solaris) encrypted form of the password. An email client using PLAIN sends the plaintext password to the SMTP server, which encrypts that using the DES method and compares the encrypted form against what is in the passwwd file. When any other method is used (CRAM-MD5, DIGEST-MD5, LOGIN, etc) the client sends an encrypted copy of the password to the server. Since Unix authentication doesn't have a copy of the user's password encrypted with that mechanism it can't verify the password.

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.

Author

Commented:
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
Top Expert 2005

Commented:
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.

Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
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...

Top Expert 2005

Commented:
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.

Author

Commented:
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.

Author

Commented:
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.

Author

Commented:
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.
Top Expert 2005
Commented:
Oops, my bad. I went back and carefully re-read the SASL documentation and you are correct in that LOGIN and PLAIN can use the same auth database. So you could use pwcheck as a method and reference passwd/shadow. However, other email clients would prefer to use one of the safer mechs, which would require something other than Unix authentication.

Yes, there are a lot of advantages to being able to run a 'black box' mail server. With the Cyrus implementation you get, as a bonus, the ability to have share mailboxes, quotas, and server side filtering (Sieve). The security implications can be important also. On a black box mail server only administrator accounts are needed and ordinary email users have no rights w/respect to the server.

I know that SquirrelMail (a Webmail implementation) has a plugin to allow user SASL password changes and there are probably other Web interfaces that can do the same. I've never needed one, but it would be pretty easy to implement a Web front end that does SASL passwd updates.

Author

Commented:
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::)

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial