Description of problem: After upgrade to Fedora 17, some emails has incorrect field "from". I see base64 representation of field "from" instead.
Created attachment 567488 [details] problem email
Thanks for a bug report. This is because the From field doesn't contain real email address, but only the user name (I suppose), same as the > Reply-to: Кредитная служба АФ Банк If I change the From field to something like > From: =?utf-8?B?0JrRgNC10LTQuNGC0L3QsNGPINGB0LvRg9C20LHQsCDQkNCkINCR0LDQvdC6?= <a> then the <a> works here as a real email (SMTP) address and evolution is able to decode it properly. "From" header, instead of "Reply-To" header, seems to rely on a proper email address. I suppose this message was created by evolution-mapi, am I right? Are you able to reply to such message, and is the message properly received?
> I suppose this message was created by evolution-mapi, am I right? Yes, right. > Are you able to reply to such message, and is the message properly received? If I reply on this message from evolution, "Field To" filled with "=?utf-8?B?0JrRgNC10LTQuNGC0L3QsNGPINGB0LvRg9C20LHQsCDQkNCkINCR0LDQvdC6?=" instead must be "Кредитная служба АФ Банк". So worked Outlook and in evolution 3.2.3. In Evolution 3.3.90 we see this regression.
I copy past here headers from Outlook: Received: from CHERRY1.afbank.ru (10.10.4.182) by CHERRY2.afbank.ru (10.10.4.242) with Microsoft SMTP Server (TLS) id 14.0.722.0; Tue, 6 Mar 2012 11:02:02 +0600 Received: from lnmp-prod-int.afbank.ru (10.10.4.23) by mail.afbank.ru (10.10.4.182) with Microsoft SMTP Server id 14.0.722.0; Tue, 6 Mar 2012 11:01:16 +0600 Received: from lnmp-prod-int.afbank.ru (lnmp-prod-int.afbank.ru [127.0.0.1]) by lnmp-prod-int.afbank.ru (8.13.8/8.13.8) with ESMTP id q26520hV031260 for <m.gavrilov>; Tue, 6 Mar 2012 11:02:00 +0600 Received: (from nginx@localhost) by lnmp-prod-int.afbank.ru (8.13.8/8.13.8/Submit) id q2652084031259; Tue, 6 Mar 2012 11:02:00 +0600 Date: Tue, 6 Mar 2012 11:02:00 +0600 Message-ID: <201203060502.q2652084031259.ru> MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" From: =?utf-8?B?0JrRgNC10LTQuNGC0L3QsNGPINGB0LvRg9C20LHQsCDQkNCkINCR0LDQvdC6?= Subject: =?utf-8?B?0JjQt9C80LXQvdC10L3QuNC1INGB0YLQsNGC0YPRgdCwINGB0LTQtdC70LrQuCDihJYzMjcyNCwg0LfQsNC10LzRidC40Log0JHRg9GA0YbQtdCyINCg0YPRgdC70LDQvSDQodC10YDQs9C10LXQstC40YcsINGB0YPQvNC80LAgMzIzODAw?= To: =?utf-8?B?0JPQsNCy0YDQuNC70L7QsiDQnNC40YXQsNC40Lsg0JLQuNGC0LDQu9GM0LXQstC40Yc=?= <m.gavrilov> Return-Path: nginx.ru Received-SPF: Fail (cherry1.afbank.ru: domain of does not designate 10.10.4.23 as permitted sender) receiver=cherry1.afbank.ru; client-ip=10.10.4.23; helo=lnmp-prod-int.afbank.ru; X-MS-Exchange-Organization-SCL: -1 X-MS-Exchange-Organization-Antispam-Report: v=1.1 cv=B8mNN9pSePbCLeopm+8CChv/m0kzhMU9agv4RVRgeCw= c=1 sm=1 a=jPJDawAOAc8A:10 a=IkcTkHD0fZMA:10 a=ztabeVi-vOo777eyV14A:9 a=QEXdDO2ut3YA:10 a=4Uf+zGw5eJWxfksfNjx2mw==:117;OrigIP:10.10.4.23;SCL:-1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-AuthSource: cherry1.afbank.ru X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Antispam-Report: MessageSecurityAntispamBypass
Aha, so the server can send to such addresses, even when there is no real email (SMTP) address. That's interesting (I know it's possible, I only thought it works mainly with user names). I tried to open your test email in 3.2.3 and it's broken there too, thus I guess this is not a regression from Fedora 16's evolution.
Created attachment 567969 [details] saved also correct message from evolution 3.2.3
The message from 3.2.3 seems kinda broken, it shows only garbage in gedit, if I open it. but that's OK, I think I found a solution.
Created attachment 568004 [details] proposed eds patch for evolution-data-server; This ensures that mail address is also "decoded" for cases when there is no name set. It's what your massage shows. It seems to work for me, but I would rather like you to test it. Here [1] is building a test package with the patch included. Please let me know whether it helped. Note this is built upon 3.3.91, which is supposed to be in updates-testing, but for some bodhi issue it isn't. In case you see strange things happening, please downgrade (yum downgrade evolution-data-server), but I do not expect any issue. Also note that this patch doesn't fix already downloaded messages, in the message list, but when you select the message then the address is shown properly. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3858571
Created attachment 568129 [details] mbox after applying patch, now "From" field filled correct value
Thanks now "From:" field after patch filled correctly. And even so I'm curious as developer, why value in one variable affects to base64_decode will work or not will work.
Thanks for testing it. Can you even reply to such address and the message is received by the other side? I'm just wondering. I'm committing the patch to sources now. (In reply to comment #10) > And even so I'm curious as developer, why value in one variable affects to > base64_decode will work or not will work. I'm not sure I understand. If it's about "what the patch does", then the reason is that evolution tries to decode the string as an email address, which usually consists of two parts "name email", sometimes only with "email" part. The name part can be encoded as that yours, where the email part cannot. The parser code, for your encoded name, decided that the encoded part is the email part and that there is no name part, which then led to no decoding of the "name". I couldn't just swap email and name parts, because it seemed to me that addresses without email are not supported. Thus the patch cheats a bit, but as long as it works... :)
Created commit 68cacfc in eds master (3.3.92+)
I downgraded because founded problem. With patched evolution-data-server, when I try refer to my global address book on Exchange server my Domain account is blocked.
Hmm, how do you "refer to your GAL"?
> Hmm, how do you "refer to your GAL"? Two ways: 1) Open contacts. 2) When fill "To:" field name in new letter. Seems this is another issue. With downgraded evolution-data-server my account block's too. And at the time of block coincides with the moments when I reffer to GAL.
(In reply to comment #15) > > Hmm, how do you "refer to your GAL"? > Two ways: > 1) Open contacts. > 2) When fill "To:" field name in new letter. > > Seems this is another issue. With downgraded evolution-data-server my account > block's too. And at the time of block coincides with the moments when I reffer > to GAL. I agree, it should be just a coincidence, because this change doesn't influence your address books, at least not directly. Do you know the reason why they blocked your account? The access to GAL is all changed in evolution-mapi 3.3.91 (and few versions below), same as for contacts, but it would surprise me if they block you only because of NSPI searches in GAL. The interesting part is that the NSPI connection is always done, together with EMSDB connection, thus this might not be due to connection itself. I prefer to open a new bug report for this, to not steal the original report.