On Fri, 24 Jun 2005, Marc Haber wrote: > There might be a way to use PAM, or to directly read /etc/passwd, but > I'd advise against doing so.
I recognise what you're getting at, but that advice seems to me to be muddled. PAM -is- a solution to the problem. Sure, you have to evaluate it in the context of your other security policy, but IMHO it's a viable approach. If you insist on password changes at some specified interval (3 months or whatever your security audit considers appropriate) it isn't too risky. Indeed if certain mail users never log on, you can set their shell to /bin/false and their password won't be good for anything other than mail. If you insist on operating two separate password regimes, then what you risk is that users will set the same password for both, thus defeating your supposed enhancement of security. Reading /etc/passwd should be pointless, as anyone interested in security would be storing them in shadow, where the mail system will not be able to access them. > System passwords are way too valuable to use for e-mail > authentication which usually means storing them in clear text on the > client. What's this with "storing"? Once per session isn't too much to ask. The client then presents the password over a secured channel to PAM on the server, and it'll tell you whether it validated or not, even though the mail software couldn't validate it for itself. That's what PAM is for (and it facilitates migration to other forms of authentication, e.g kerberos, if that proves to be desirable later). > At least make absolutely sure that your exim only advertises SMTP AUTH > over an encrypted connection, or the valueable system password will be > sent in the clear. Absolutely! -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
