Summary: | qmail smtp auth with tls [done for -r14] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrei Ivanov <andrei.ivanov> |
Component: | Current packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | enhancement | CC: | rajiv |
Priority: | High | ||
Version: | 1.4 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | AUTH-requires-TLS.patch |
Description
Andrei Ivanov
2003-10-18 10:20:47 UTC
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. |