Hello I've decided that I want to use smtp auth and tls. The thing is that I want to use smtp only with tls, and auth over it. I want my users to authenticate against the system passwords, so I thought to use checkpassword-pam, which works with auth plain or login. Because of that I didn't want qmail to advertise the CRAM5 auth capability... or use it. I found this page: http://www.ornl.gov/cts/archives/mailing-lists/qmail/2002/08/msg00075.html, where someone else had the same ideeas. I took the patch at the end of the page, I applied it by hand, I undefined AUTHCRAM in qmail-smtpd.c and modified /var/qmail/control/conf-smtpd: QMAIL_SMTP_AUTHHOST=$(<${QMAIL_CONTROLDIR}/me) [ -z "${QMAIL_SMTP_POST}" ] && QMAIL_SMTP_POST=/bin/true QMAIL_SMTP_CHECKPASSWORD="/usr/bin/checkpassword-pam -s smtp" QMAIL_SMTP_POST="${QMAIL_SMTP_AUTHHOST} ${QMAIL_SMTP_CHECKPASSWORD} ${QMAIL_SMTP_POST}" smtp is a copy of the imap pam config from courier-imap. The thing is that checkpassword-pam only works if ran by root, so I made it suid root, but altered its permission so only root and user qmaild can execute it. Unfortunately I did this using extended attributes on ext3, so I don't think it's very portable. getfacl /usr/bin/checkpassword-pam getfacl: Removing leading '/' from absolute path names # file: usr/bin/checkpassword-pam # owner: root # group: root user::rwx user:qmaild:--x group::--- mask::--x other::--- Anyway, I've said all this in the hope that some of this will get incorporated in a way in gentoo... Thanks.
i don't really feel that there is such a huge demand to put all of this into the mainstream tree. I specificly chose to go the route of an additional password for SMTP AUTH because it would introduce the least other problems. I would however like the updated patch of the SMTP AUTH after TLS only patch, to give users a local USE flag to apply it if they want. I'll put that part into the package, but not your modifications to /var/qmail/control/conf-smtpd. EA are not an option for the great major of systems, so that rules out that. EA aren't even stable on several filesystems (on reiserfs they are majorly broken). Your example here is one of the reasons we ensure that people can do their own custom modifications in Gentoo if they so desire.
Anyway, it seems my setup has a problem and I don't know how to solve it... :( Some clients cannot use TLS, because qmail says: 454 TLS not available due to temporary reason I tried using telnet server 25. If the client is running windows, qmail gives the error above. If the same client is running linux, qmail doesn't complain and starts tls... this is very weird. I've greped through qmail sources, but there is no such message, so I suspect the message comes from openssl functions called by qmail, but I don't know what triggers this error.
that error is due to some problem in your ssl certificates i think. As a good test, try out qmail -r13, and see the HOWTO document I'm currently writing: http://www.orbis-terrarum.net/~robbat2/guidexml/mailsolution.html
I found the reason for "454 TLS not available due to temporary reason" error... it's norton antivirus with its outgoing email scanning that seems to be monitoring every outgoing connexion on port 25 and corrupting it.(because even when I was connecting with telnet on port 25 it gave me that error). Now I want something else... almost everything that now ssl/tls has something like TLSCipherSuite(in ldap) or TLS_CIPHER_LIST(in courier), and want to use only the strongeste cyphers (HIGH:@STRENGTH). How can I do this in qmail ?
tlsclientciphers and tlsserverciphers see README.starttls I'm still waiting for your patch to show AUTH after TLS only.
Created attachment 20542 [details, diff] AUTH-requires-TLS.patch
Got it... thanks. Now I will have to check to see if Outlook Express will use a stronger cipher, when I reboot..
Also note that the patch disables CRAM-MD5 auth, because, as I understand it, if I use it, I have to keep the user passwords unencrypted, and, as long as the connection is already encrypted, I don't mind sending the passwords in clear (and checkpassword-pam doesn't support it because of the said reasons, I think). Anyway, my patch is the one in at the end of the link in my first post, applied by hand and rediffed, with the undefining of CRAM-MD5...
coming in -r14
if you are feeling experimental, -r14 is now out. It's hardmasked until I personally test it some more, but it should work.
You seem to have missnamed the USE keyword: notlsbeforeauth should be noauthbeforetls
No i Haven't at all. The patch I wrote up based on yours, creates a define called 'TLS_BEFORE_AUTH', which if used, requires the use of TLS before AUTH is allowed. The logical negation is not to require TLS before AUTH, hence "notlsbeforeauth". It's perfectly explained in use.local.desc: "net-mail/qmail:notlsbeforeauth - If you do NOT want to require STARTTLS before offering AUTH"
Then it means it's not working... I've enabled it thinking you've misswrote it, and now auth should be available without tls, but it is required: 220 hello, it's me, the devil... ESMTP AUTH plain 530 Must issue a STARTTLS command first (#5.7.0)
like i said, it's hardmasked until I personally test it more. as an aside, your pasted in behavior with the '220' code is non-RFC compliant. the first word after a 220 response should be the hostname of the server.