Bug 846842

Summary:	Evolution 3.4.3 can't send emails
Product:	[Fedora] Fedora	Reporter:	trog <trog>
Component:	evolution	Assignee:	Matthew Barnes <mbarnes>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	17	CC:	lucilanga, mbarnes, mcrha
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-09 11:17:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description trog 2012-08-08 21:04:47 UTC

Evolution 3.4.3 on Fedora 17 tried on desktop with dual core and on netbook with Intel Atom - affects both i386 and x64 versions.

On attempting to send an email, an error message pops up:

"An error occurred while sending. How do you want to proceed?
The reported error was "SMTP server smtp.ukservers.net does not support CRAM-MD5 authentication"."

I always used CRAM-MD5 and this has only been a problem since upgrading to f17.

In terms of reproducing the error, it is consistent - every time I try to send an email.

I tried alternatives like no-encryption, plain login etc, but nothing succeeds, only the content of the error message changes to match the selected option.

At the same time another machine on the same network with an earlier evolution on f16 could send emails without problems. It is as though something is blocking outbound communications between Evolution and the internet. Evo can receive emails over a secure connection, but can't send over any sort of connection.

Even the server probing mechanism in the sending preferences seems to hit a wall. I think I've eliminated router settings (because another machine with f16 could still connect) and firewall settings seem the same as before (in the gui).

Also tested from a live f17 CD from a magazine, the only settings I made were to create an email account. Same problem - can't send an email.

I went back to my installed version and connected to a gmail account, that worked, I sent a test email, but gmail uses protocols that my isp doesn't support.

I asked on the fedora forum, and one other user reported the same problem:
http://forums.fedoraforum.org/showthread.php?s=8fd2867748607357260eb29a5e5c8d9c&p=1592981#post1592981

That's as much technical info as I've managed to find for you.

The nearest similar bug reported is https://bugzilla.redhat.com/show_bug.cgi?id=802606 but that has a slightly different error message

Thanks

Comment 1 Matthew Barnes 2012-08-08 21:40:20 UTC

I notice your SMTP server is sending the AUTH list twice: once in the standard format and again in a non-standard format that Microsoft Outlook expects.

$ telnet smtp.ukservers.net 25
Trying 217.10.138.228...
Connected to mailprox.ukservers.net.
Escape character is '^]'.
220 auth-1.ukservers.net ESMTP SMTP Server
EHLO example.com
250-auth-1.ukservers.net
250-PIPELINING
250-SIZE 50000000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN CRAM-MD5
250-AUTH=PLAIN LOGIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

The SMTP backend is designed to handle this, but perhaps something broke in the parser.

From camel-smtp-transport.c:

/* Don't bother parsing any authtypes if we already have a list.
 * Some servers will list AUTH twice, once the standard way and
 * once the way Microsoft Outlook requires them to be:
 *
 * 250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
 * 250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
 *
 * Since they can come in any order, parse each list that we get
 * until we parse an authtype list that does not use the AUTH=
 * format. We want to let the standard way have priority over the
 * broken way.
 **/

Comment 2 Milan Crha 2012-08-09 11:17:17 UTC

Thanks for a bug report. There is filled a similar upstream bug [1], thus I'm moving this there. Please see [1] for any further updates. If possible, please CC yourself there, in case upstream developers will have additional questions.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=679488