When using qmail 1.03-r13 with vpopmail 5.4.0, the vchkpw auth doesn't work with cram-md5 authentication for smtp traffic. login/plain work fine. There is a patch, available at http://www.fehcom.de/qmail/smtpauth.html (down at the bottom, qmail-smtpd-auth-0.4.3). However, I was unable to apply this patch, and either manually remake qmail, or use the existing ebuild. I know there are already several different patches in the Gentoo ebuild of qmail, I was hoping you could add this as well. The cross-platform problem comes from the Windows version of Eudora, which defaults to cram-md5 smtp-authentication. There is no way to disable this server-side. Client side disabling still has some errors. Reproducible: Always Steps to Reproduce: 1. Set up a mail server with vpopmail 5.4.0 and qmail 1.03-r13. 2. Create a domain/user in vpopmail (vadddomain, vadduser) 3. Enable smtp-auth by uncommenting the last 4 lines of /var/qmail/control/conf-smtpd, and edit it to use vchkpw 4. Use cram-md5 authentication, and watch it fail when sending a message, from the user you added with vadduser. Actual Results: The server responds with "553 Sorry- that domain isn't on my allowed list of rcpthosts (#5.7.1)". The /var/log/messages file contains "vchkpw-smtp: password fail: user@domain.com". Not really a bug, but it would be nice if the patch was integrated to the qmail ebuild. Expected Results: The user should be able to authenticate with cram-md5, and send mail through a server that is not an open relay. No additional- as I said, if the patch could be added to the ebuild, that would be great.
is your vpopmail compiled with plaintext passwords? this is REQUIRED for CRAM-MD5 auth. USE=clearpasswd emerge vpopmail (and this will probably break any existing users you have).
I'm not sure how vpopmail is compiled- if that is the default option with the 5.4.0 ebuild, then yes. How would I check?
it's NOT the default, as it's consider a potential security problem to store plaintext passwords. 'emerge -pv vpopmail' should show you if it's enabled or not.
I believe this is caused by something other than the lack of clear text passwords. I just installed 1.03-r15 and vpopmail 5.4.0-r1, and I can't get SMTP auth to work with clear text passwords enabled. If I don't have vchkpw suid, I get this: 220 ************* ESMTP EHLO ******** 250-************* 250-AUTH LOGIN CRAM-MD5 PLAIN 250-AUTH=LOGIN CRAM-MD5 PLAIN 250-SIZE 0 250-PIPELINING 250 8BITMIME AUTH LOGIN 334 VXNlcm5hbWU6 ************************ 334 UGFzc3dvcmQ6 ************ 535 authorization failed (#5.7.0) If I do have it suid, I get this: 220 *************** ESMTP EHLO ******** 250-************** 250-AUTH LOGIN CRAM-MD5 PLAIN 250-AUTH=LOGIN CRAM-MD5 PLAIN 250-SIZE 0 250-PIPELINING 250 8BITMIME AUTH LOGIN 334 VXNlcm5hbWU6 ******************* 334 UGFzc3dvcmQ6 ************* 454 oops, problem with child and I can't auth (#4.3.0) I'm going to go look through my system logs for possible errors there too, since I hadn't thought of looking there.
Here's the relevent error I could find in my logs: current:Aug 17 10:05:36 [vpopmail] vchkpw-smtp: vpopmail user not found user@domain.com:0.0.0.0 (obviously editted for security purposes)
I'm not sure on this, but I would expect the qmail patch would take in to account the cleartext password problem. I still haven't been able to find any more information on this. I still believe that simply adding the patch to qmail will make this work.
clearing up my bug tracking
To disable cram-md5, you can unpack qmail, delete the file "#define AUTHCRAM" from qmail-smtpd.c, compile, install and merge. That way clients will not complain (nor have CRAM-MD5 support). I've exchanged some mails with vchkpw mailing list and they say: "It looks like the client is trying CRAM-MD5, failing, and then using PLAIN authentication. You probably have an older patch, or a version problem between the smtp-auth patch and vpopmail. The older patch sent the information in the incorrect order, and vpopmail was written to accept it in that order. We fixed vpopmail for the 5.4.0 release, but it required updating to the correct SMTP AUTH patch. If you're using vpopmail 5.4.0 and later, make sure you're using an up-to-date patch that passes the MD5 challenge and response in the correct order. The patch in vpopmail's contrib directory works properly." I tried to use that patch (it wasn't easy, but I think I was succesful), but the result was just the same :(
Well it must be just me cause I use CRAM-MD5 for my password check with latest qmail & vpopmail without a problem, yes I do smpt before imap/pop and all is fine and working without a problem.
well I knew I should have kept my mouth shut I have managed to break my cram-md5 check after playing with it to write a howto on how i got it to work :(
I just installed qmail and vpopmail (following http://www.gentoo.org/doc/en/qmail-howto.xml), I use clear text passwords and MySQL backend for vpopmail. And, CRAM-MD5 does not work. AFAIK the problem lies in vpopmail's vchkpw, it works with SMTP AUTH but only PLAIN and LOGIN. It needs a patch to work with CRAM-MD5. There is a patch for 5.4.x vchkpw here: http://alex.zeitform.de/qmail/qmail-popup-auth_cram_md5/ - it says: To use this patched version of (net)?qmail you need a checkpassword [3] compatible password checking tool that understands to manage CRAM-MD5 authentication. [...] This patch does work with current versions of vpopmail (5.4.x) only if you patch vchkpw.c to enable CRAM-MD5 authentication for POP3. This can be done by adding two line to vchkpw.c or applying the following patch So it seems that the vpopmail-5.4.x.patch there will fix this bug. There is a separate patch to use if you are using qmailqueue (BTW: qmailqueue isn't just a patch to qmail? we are talking about vchkpw here...) I'll have a look at those patches as soon as I've got some spare time, but it's not gonna happen soon :(
The problem you are encountering seems to be the same bug I originally opened this bug report with using 5.4.0 and qmail 1.03-r13. The patch for vpopmail exists, I even put the link up. The problem that I am encountering, is that I simply can't take a raw qmail build, apply the patch and go on my merry way because I lose the existing patches for qmail in the qmail ebuild. All I really wanted was this patch to be added to the qmail ebuild. Why this has been open for almost a year with no progress made is beyond me. Can anyone else out there modify the ebuild to add in the qmail patch, recompile and still install? If I had any skills as a C programmer I'd do it myself, but I'm trying to leave this to the pros w/o totally screwing up my more or less nicely working Gentoo system.
qmail -r13 is at a stage of maintenance only. Bugs will be fixed, but no new functionality is being worked on. CRAM-MD5 is supported and should be working in our qmail for -r15 and -r16. I haven't specifically tested vpopmail-5.4* and qmail-r1[56] with CRAM-MD5 myself, because I don't have a simple client to conduct such a test and debug it with (if somebody were to tell me a sequence of manual values to test using telnet, I'd be happy too). I only have reports that say it works. At the very worst case, this is the only patch we need: http://alex.zeitform.de/qmail/qmail-popup-auth_cram_md5/vpopmail-5.4.x.patch
Ok... well, since r-13 is what I installed originally when I opened this bug, it'd be nice if it worked. However, since you say that qmail-r15/6 has it, and it seems to work, is there anything special I need to do in order to upgrade? The mail system works as it is, and I'd hate to break it. Just emerge r16? It should keep all my old settings and such, right? I assume the ebuild has all the necessary patches that were included with r13, so no worries there. I'd also expect that vpopmail 5.4.0 will still work, unless the core functionality has somehow changed. Sorry for being a pest, just want it work, with as little trouble as possible. As the old saying goes "If it ain't broke, don't fix it".
If you are on ~arch, try -r16, and file a bug for absolutely anything that you see wrong with it (we're trying to test it better hardmasked before releasing it to ~arch). If you are on arch and not ~arch, I really don't recommend moving yet to -r15 or -r16 (there are a LOT of configuration tweaks that such an upgrade would need at the moment).
I have the same problem with qmail R15 and vpopmail (5.4.6-r1). With Mozilla as an Email Client the first CRAM login is denied, the second try with PLAIN is wrking. I have this problem on several servers. Mar 28 08:27:10 [vpopmail] vchkpw-smtp: password fail USER@DOMAIN:192.168.1.251 Mar 28 08:27:15 [vpopmail] vchkpw-smtp: (PLAIN) login success USER@DOMAIN:192.168.1.251 master qmail-smtpd # equery uses vpopmail [ Found these USE variables for net-mail/vpopmail-5.4.6-r1 ] U I - - mysql : Adds mySQL support - - ipalias : Enables enable-ip-alias-domains + + clearpasswd : Enables cleartext password storage in the vpasswd files master qmail-smtpd # equery uses qmail [ Found these USE variables for mail-mta/qmail-1.03-r15 ] U I + + ssl : Adds support for Secure Socket Layer connections - - noauthcram : If you do NOT want AUTHCRAM to be available + + notlsbeforeauth : If you do NOT want to require STARTTLS before - - selinux : !!
Created attachment 56561 [details, diff] Patch to enable vpopmail and qmail to talk CRAM-MD5 Simply reverses the parameters to the MD5 check, rather than doing a proper job and renaming the fields etc
I have experienced the same problem with R13 and vpopmail 5.4.6-r1. There were two problems: the first is the need for clear-text passwords. At this point I was still getting the fail with cram, succeed with plain message, depending on my mail client (some would fall back others would not) It is my understanding that the parameters expected in vchkpw are reversed as compared to cmd5checkpw, so does not match what qmail is providing. Can't remember what I read that suggested this, but I proved it experimentally. The provided patch, applied as part of vpopmail emerge using clearpasswd should get the systems talking.
It has been so long since I've done an emerge for the mail program using patches (and not wanting to break what I have now) - can you give a detailed set of instructions on how to proceed? I don't mind re-emerging, as long as the patch is applied correctly, and I won't lose my mail server for an extended period of time. Glad to see it almost resolved!! -=Geof
Created attachment 56640 [details] Ebuild adding patch to enable vpopmail and qmail to talk CRAM-MD5 You will need to re-do the digest step when you have added this file; start the emerge as normal and follow the instructions, something like: ebuild /usr/local/portage/net-mail/vpopmail/vpopmail-5.4.6-r2.ebuild digest
Created attachment 56641 [details] Ebuild adding patch to enable vpopmail and qmail to talk CRAM-MD5 The patch also works against vpopmail-5.4.9
For some reason, the patch wouldn't work, so I just edited the file directly, as the patch would have. It compiled, then in Eudora, I removed the SMTPAuthBanished=CRAM-MD5 line. It works on-network, still waiting to see if it'll work off-network. I also turned on the default Eudora option of SSL - If available, STARTTLS - which I think will break, since I don't have SSL capability, yet it seems to think I do. But that's neither here nor there, and another story. I am however, seeing some strange messages in /var/log/messages- more specifically, I get this: Apr 20 00:36:15 enterprise vpopmail[2396]: vchkpw-smtp: vpopmail user not found crymson@crymson.org:192.168.1.1 Apr 20 00:36:15 enterprise vpopmail[2396]: vchkpw: can't write MySQL logs Apr 20 00:36:29 enterprise pop3d: Connection, ip=[::ffff:192.168.1.1] Apr 20 00:36:30 enterprise pop3d: LOGIN, user=crymson@crymson.org, ip=[::ffff:192.168.1.1] So, the smtp was when I tried sending an email- which went, I can only assume because I'm on-network. I have no idea why vchkpw can't write the SQL logs... perhaps something else changed inbetween 5.4.0 and 5.4.6-r2? I also noticed there doesn't seem to be any problem letting me in to check mail, which I received, again, because I'm on-network. More tomorrow, but just a heads up.
> vchkpw-smtp: vpopmail user not found crymson@crymson.org:192.168.1.1 > vchkpw: can't write MySQL logs These are a permissions problem. My vchkpw is: -rws--x--x 1 root vpopmail 70016 Apr 19 09:23 /var/vpopmail/bin/vchkpw If I remove the SUID bit I have the same problem you do. Try chown root:vpopmail /var/vpopmail/bin/vchkpw chmod 4711 /var/vpopmail/bin/vchkpw To see if that works. Then check to see if those are the official permissions since I'm not willing to make that a guarantee.
Did as you said, and it doesn't give me the SQL error, just that on vchkpw-smtp, password-fail. As I recall, that was the same error I got before, which is why I disabled CRAM-MD5 in the first place (since Eudora doesn't fall back on plain login). Did I perhaps edit the wrong vchkpw.c file? Is there a way to see what it's trying to match, and what it's trying to match to? I can't believe that with your help, I'm so close to solving this annoying bug, yet can't quite seem to get there! Thanks again for your help...
I have created a forum thread: http://forums.gentoo.org/viewtopic-p-2330461.html#2330461 Since that's probably a more appropriate place to discuss the building/applying patches side of things.
The patch works - you need to have the vpopmail-5.4.6.tar.gz file in your /usr/portage/distfiles/ directory, and the patch needs to reside in /usr/portage/net-mail/vpopmail/files. Then, emerge like normal. Don't forget to reset the permissions on vchkpw: (in /var/vpopmail/bin) chown root:vpopmail vchkpw chmod 4711 vchkpw This patch really needs to be added to the "official" ebuild to solve the problem. To be brutally honest, I can't figure out why this has been up for so long and so hard to fix. It's switching two things in one line of code. As I suspected earlier, a simple fix. Anyone can get it working now though, I verified it in Eudora and several other mail programs. It works as it should.
Created attachment 56852 [details] source code and patch for vpopmail 5.4.6 This is the attachment. There are 2 files, one is the source code, the other is the patch. See previous comment on where to put them. Emerge as normal, and it should work, once you make the appropriate changes to vchkpw as noted in previous comment.
Geof Fang: Is this still needed with newer version of vpopmail. If there is no response on this bug, it will be closed with NEEDINFO on Dec 14.
I can't speak for Geoff, but I no longer use the patch with the latest ebuilds, and CRAM authentication appears to work as I would expect.
(In reply to comment #29) > I can't speak for Geoff, but I no longer use the patch with the latest ebuilds, > and CRAM authentication appears to work as I would expect. > I haven't updated to the latest version ("If it ain't broke, don't fix it") and the patches got CRAM authentication working for me. If Phil says it's working, then I'd expect it's working. Thanks for resolving it, and thanks to Phil for helping me get the patch working on my version. -=Geof
thanks Phil and Geof.
