GNOME Bugzilla – Bug 548863
SMTP CRAM-MD5 AUTH failure
Last modified: 2009-06-17 13:06:51 UTC
Moving this from downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=459691 For some reason, Evolution has started failing to authenticate to the SMTP server. I get an endless stream of... sending : AUTH CRAM-MD5 CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call') sending : AUTH CRAM-MD5 CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call') sending : AUTH CRAM-MD5 CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call') sending : AUTH CRAM-MD5 CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call') sending : AUTH CRAM-MD5 CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call') ... and no error dialog or anything else. I'm not sure _why_ the authentication is failing; I'm about to debug that. But I haven't changed anything at the server side either. Whatever the underlying reason for the failure, Evolution's _handling_ of it is broken. The server is saying: 2008-08-21 09:00:20 +0000 cram authenticator failed for pmac.infradead.org [2001:8b0:10b:1:20d:93ff:fe7a:3f2c]: 535 Incorrect authentication data (set_id=dwmw2) ============================================================================= I've tried changing my configuration to use AUTH PLAIN and I've restarted Evolution (and checked that it really thinks it's supposed to use PLAIN). But it's _still_ in an endless loop trying CRAM-MD5 after I hit Send/Receive. ============================================================================= I managed to flush my Outbox by double-clicking to re-edit the first mail in it, then deleting that mail from the Outbox. After that, the other mails queued there went out OK. When I looked at the compose window which opened when I double-clicked on that mail, it seems it was set to use my News account (which has an SMTP config which did still use CRAM-MD5; I'd forgotten about that and hadn't changed it). So part of the problem (or just _another_ problem) seems to be that Evolution uses the wrong account settings to send mail it finds in the Outbox at startup. ============================================================================= Having reminded myself how CRAM-MD5 works, it looks like the underlying fault is with Evolution. It's giving incorrect responses -- and it's the md5 part which is incorrect, so I can't see why.
Created attachment 117358 [details] test case The problem is in the md5 routines in libedataserver, and it goes away when I locally build the supposedly identical evolution-data-server-2.22.3-2.fc9 package from Fedora CVS. I made a simple test program for testing, and even a simple md5_init() followed by md5_final() gives inconsistent results between my own working version (now installed on the system) and the Fedora build (in /tmp/buggered): pmac /home/dwmw2 $ LD_LIBRARY_PATH=/tmp/buggered ./foo After init: buf 67452301 efcdab89 98badcfe 10325476 bits 00000000 00000000 in 0ffeffdc0000000eff8f80300ffba8d0 After final: buf 227b7f48 d21283f6 3bc9bbc1 5b44ea1a bits 00000000 00000000 in 80000000000000000000000000000000 MD5 is 227b7f48d21283f63bc9bbc15b44ea1a pmac /home/dwmw2 $ ./foo After init: buf 67452301 efcdab89 98badcfe 10325476 bits 00000000 00000000 in 0ffeffdc0000000eff9550500ffba8d0 After final: buf d41d8cd9 8f00b204 e9800998 ecf8427e bits 00000000 00000000 in 00000080000000000000000000000000 MD5 is d41d8cd98f00b204e9800998ecf8427e
I can reproduce the brokenness of libedataserver by turning the _byte_reverse() function in md5-utils.c into a no-op. It looks like the Fedora package somehow got built in a way such that the '#if G_BYTE_ORDER == G_BIG_ENDIAN' tests didn't trigger -- how is that possible? If that's a Fedora-specific problem, Evolution still has the bug that it doesn't respond appropriately to the SMTP error. It shouldn't just go into an endless loop retrying authentication -- it should assume that the password is wrong or something, and prompt again.
Fedora's glib2-devel-2.16.4-1.fc9.ppc.rpm package contains a glibconfig.h file which defines G_BYTE_ORDER G_LITTLE_ENDIAN. HowTF did that happen?
(In reply to comment #2) > If that's a Fedora-specific problem, Evolution still has the bug that it > doesn't respond appropriately to the SMTP error. It shouldn't just go into an > endless loop retrying authentication -- it should assume that the password is > wrong or something, and prompt again. I think this part was bug #532472, fixed now.
Hi David, could I ask you to retest with recent Evolution on ppc, please? It should be fixed, but it seems it came back again. Thanks in advance.
Downstream bug had been closed as a duplicate of a bug, where the other reporter stated the problem got fixed since update of 2.24.5-1.fc10, thus closing this as well.