I had complaints that eudora was unable to send mails using a server since I updated to qmail-1.03-r16. after initial investigations, it turns out that AUTH LOGIN and PLAIN work well, but AUTH CRAM-MD5 is no longer working for me in -r16. the following test works with -r15: prodan@peter ~/_1 $ ./smtp-client.pl --verbose --auth-cram-md5 --host=192.168.82.10 --user='test' --pass='qwe123' --from=foo@bar.org --to=foo@bar.org --data=/tmp/test [220] 'muttley.sunspire.org ESMTP' > EHLO localhost [250] 'muttley.sunspire.org' [250] 'STARTTLS' [250] 'PIPELINING' [250] '8BITMIME' [250] 'SIZE 0' Starting TLS... > STARTTLS [220] 'ready for tls' Using cipher: DHE-RSA-AES256-SHA Subject Name: /C=US/ST=Alabama/L=Mobile/O=Foobar Systems/OU=Automatically-generated Qmail SMTP SSL key/CN=localhost/emailAddress=postmaster@localhost Issuer Name: /C=US/ST=Alabama/L=Mobile/O=Foobar Systems/OU=Automatically-generated Qmail SMTP SSL key/CN=localhost/emailAddress=postmaster@localhost > EHLO localhost [250] 'muttley.sunspire.org' [250] 'PIPELINING' [250] '8BITMIME' [250] 'AUTH LOGIN PLAIN CRAM-MD5' [250] 'SIZE 0' AUTH method (LOGIN PLAIN CRAM-MD5): using CRAM-MD5 > AUTH CRAM-MD5 [334] 'PDIyNjE1LjExMjI2MzYwNzJAbXV0dGxleS5zdW5zcGlyZS5vcmc+' > dGVzdCBhMDExNzA4NDc0OGNhNDBhZTQ4OGQ2NTI1YzJkMTY3Mw== [535] 'authentication failed (#5.7.1)' AUTH failed: '535'. > QUIT [221] 'muttley.sunspire.org' muttley control # emerge -pv cmd5checkpw qmail [ebuild R ] net-mail/cmd5checkpw-0.22-r3 0 kB [1] [ebuild R ] mail-mta/qmail-1.03-r16 -logmail -mailwrapper -noauthcram -notlsbeforeauth +selinux +ssl 0 kB [1] muttley control # ps ax |grep tcpserver 12994 ? S 0:00 /usr/bin/tcpserver -p -v -R -x /etc/tcprules.d/tcp.qmail-smtp.cdb -c 40 -u 201 -g 200 0.0.0.0 smtp /var/qmail/bin/qmail-smtpd /bin/cmd5checkpw /bin/true smtp-client.pl is available here: http://www.logix.cz/michal/devel/smtp/index.xp?show_selected=1&msgid=390 any ideas?
Created attachment 64633 [details] tcpserver strace strace -o /tmp/trace -f -p 30247 -s 65000
I think I found a lead. if one compares the strace output between -r15 and -r16 in the moment cmd5checkpw receives data on descriptor 3 (man 8 cmd5checkpw), this will come up: using qmail-1.03-r15: 11132 read(3, "test\0<31492.1122660986@muttley.sunspire.org>\00072ec577fe31557f5a2eaaa4d3c7f8b3b\0", 513) = 78 using qmail-1.03-r16: 15822 read(3, "test\000477cc55b4d80a7da69428c55113f5720\0<28139.1122659275@muttley.sunspire.org>\0", 513) = 78 so it looks like -r16 is sending the data in the wrong order.
Created attachment 64668 [details, diff] cram.patch this patch fixes my problem
my proposed patch breaks non-CRAM-MD5 authentications, so do not use it as it is now. substdio_put(&ssauth,chal.s,chal.len) should only happen if auth_cram has taken place, otherwise it won't play nice with other authentication techniques. I will let you find the best way to do that.
an easier way out would be to provide an update of our net-mail/cmd5checkpw. Erwin Hoffmann has a version of cmd5checkpw that actually works with his authpatch that you started using in -r16. see http://www.fehcom.de/qmail/smtpauth.html for details. I will provide an ebuild soon for that cmd5checkpw-0.30
if cmd5checkpw-0.30 from bug #100886 will get into portage then you can close this one /me will stop talking to himself now
cmd5checkpw-0.30 is now in portage. Can you test again, please?
thumbs up cheers, peter
Thanks for testing.