Bug 799820 - After upgrade to Fedora 17, in some mails field from has incorrect
After upgrade to Fedora 17, in some mails field from has incorrect
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-05 01:46 EST by Mikhail
Modified: 2012-03-07 13:10 EST (History)
3 users (show)

See Also:
Fixed In Version: evolution-data-server-3.3.92
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-07 13:10:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
problem email (3.29 KB, application/mbox)
2012-03-05 01:46 EST, Mikhail
no flags Details
saved also correct message from evolution 3.2.3 (3.72 KB, application/mbox)
2012-03-06 09:32 EST, Mikhail
no flags Details
proposed eds patch (547 bytes, patch)
2012-03-06 11:20 EST, Milan Crha
no flags Details | Diff
mbox after applying patch, now "From" field filled correct value (2.83 KB, application/mbox)
2012-03-06 23:52 EST, Mikhail
no flags Details

  None (edit)
Description Mikhail 2012-03-05 01:46:08 EST
Description of problem:
After upgrade to Fedora  17, some emails has incorrect field "from".
I see base64 representation of field "from" instead.
Comment 1 Mikhail 2012-03-05 01:46:43 EST
Created attachment 567488 [details]
problem email
Comment 2 Milan Crha 2012-03-05 09:09:52 EST
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@b.c>
then the <a@b.c> 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?
Comment 3 Mikhail 2012-03-06 00:12:53 EST
> 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.
Comment 4 Mikhail 2012-03-06 00:15:29 EST
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@citrus-it.ru>; 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@lnmp-prod-int.afbank.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@citrus-it.ru>
Return-Path: nginx@lnmp-prod-int.afbank.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
Comment 5 Milan Crha 2012-03-06 06:38:18 EST
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.
Comment 6 Mikhail 2012-03-06 09:32:08 EST
Created attachment 567969 [details]
saved also correct message from evolution 3.2.3
Comment 7 Milan Crha 2012-03-06 11:14:11 EST
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.
Comment 8 Milan Crha 2012-03-06 11:20:26 EST
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
Comment 9 Mikhail 2012-03-06 23:52:43 EST
Created attachment 568129 [details]
mbox after applying patch, now "From" field filled correct value
Comment 10 Mikhail 2012-03-07 00:14:49 EST
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.
Comment 11 Milan Crha 2012-03-07 02:26:16 EST
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... :)
Comment 12 Milan Crha 2012-03-07 02:32:36 EST
Created commit 68cacfc in eds master (3.3.92+)
Comment 13 Mikhail 2012-03-07 05:57:43 EST
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.
Comment 14 Milan Crha 2012-03-07 08:26:25 EST
Hmm, how do you "refer to your GAL"?
Comment 15 Mikhail 2012-03-07 10:02:15 EST
> 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.
Comment 16 Milan Crha 2012-03-07 13:10:08 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.