After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 758374 - Do not restrict/remove From address on message send
Do not restrict/remove From address on message send
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Mail
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
: 770754 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-11-20 00:58 UTC by Jan Vesely
Modified: 2016-09-07 15:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed ews patch (5.21 KB, patch)
2016-09-06 08:13 UTC, Milan Crha
none Details | Review

Description Jan Vesely 2015-11-20 00:58:33 UTC
From header is missing from the saved sent message and the received mail contains server default.
Comment 1 Milan Crha 2015-11-23 18:29:56 UTC
Thanks for a bug report. I tried to reproduce this and the result is that if the 'From field override' is used in the composer the evolution-ews claims that it cannot send messages with other than the configured email address. I noticed that the Message object can contain Sender and From, but once the From is filled it overrides the one inside the MIME content. That makes me believe that the server cannot send as other users.

I can remove the check for the matching email address of the From and the one configured for the server, but that might make things worse for the users, I'm afraid. Also because the server returns errors in English and the corresponding one is (ErrorSendAsDenied):
   The user account which was used to submit this request does not have
   the right to send mail on behalf of the specified sending account.

I'm closing this as WontFix, even with a more accurate meaning "Cannot Fix".
Comment 2 Jan Vesely 2016-08-30 18:53:02 UTC
Hi,

sorry for reopening an old bug. I did some more testing (and got access to another o365 account).

the set of permitted emails seem to be server configurable. These are my observations using thunderbird:
Name changes are permitted (so I can use "TEST USER<permitted@email>
Changing email is restricted to a set of allowed email addresses, so
"NAME <permited@email>" and "NAME <permitted2@email>" both work OK.
using any other email address results in the above mentioned error.

I think setting From field can still be useful. In my case the preferred email address is different from my o365 login name (but permitted). Leaving the from field blank results in the server filling in the login name.

thanks,
Jan
Comment 3 Milan Crha 2016-08-31 08:18:05 UTC
DO you know where one can setup the permitted address on the server?
Comment 4 Jan Vesely 2016-09-01 09:32:20 UTC
(In reply to Milan Crha from comment #3)
> DO you know where one can setup the permitted address on the server?

I assume there is an alias configuration option in the administration panel but I don't have access to that. Also, in one of the accounts the other permitted address is not shown as alias, so the information might come from multiple sources.
Note that the thunderbird experiments were using imap/smtp, and I get the same results using Evolution imap/smtp.
Comment 5 Milan Crha 2016-09-02 12:08:26 UTC
(In reply to Jan Vesely from comment #4)
> Note that the thunderbird experiments were using imap/smtp, and I get the
> same results using Evolution imap/smtp.

Okay. That's a very important detail, because the IMAP interface of an Exchange server works very differently from the EWS interface.
Comment 6 Jan Vesely 2016-09-02 14:03:26 UTC
I don't really have tools to test this using EWS interface. I did a quick test using OWA (web access, not sure what they use). The results are similar. Only permitted addresses work (other addresses get the same "not permitted to send" error).

The difference is that the other permitted address was replaced by the account default. I believe this is Microsoft bug and alternate addresses should be allowed.

I dug up this on alternate addresses in o365:
https://oit.rutgers.edu/faq/can-i-send-email-address-other-my-actual-rutgers-connect-address

"Connect" is the university's o365 service. note the part about account having permission to use another address.
Comment 7 Milan Crha 2016-09-05 17:44:47 UTC
*** Bug 770754 has been marked as a duplicate of this bug. ***
Comment 8 Milan Crha 2016-09-05 17:47:50 UTC
Hmm, so the bug #770754 is about an Exchange2007_SP3 server which rejects MIME messages without From address. As I wrote there, it seems the SP3 update changes the behaviour for the empty From address being replaced by the correct address for the logged in user by the server. That makes your request for the From field override valid (not that it wasn't before, just that it's needed "more" now).
Comment 9 David Woodhouse 2016-09-05 20:52:37 UTC
Out of interest, why were we including an invalid empty From: header, instead of just not including a From: header at all.

That is, why include the letters 'F' 'r' 'o' 'm' and the colon? :)
Comment 10 Milan Crha 2016-09-06 08:13:03 UTC
Created attachment 334883 [details] [review]
proposed ews patch

for evolution-ews;

Could anyone of you give a try to this patch, please? I can send messages with it using evolution-ews, but I do not have a setup with "allowed other addresses" to test it. Note that even the copy of the send message in the Sent Items can show "redirected" headers, the received message may have the From header changed.

I can help to build a test package on any Fedora, just let me know.

Thanks in advance.
Comment 11 Luca 2016-09-06 09:08:04 UTC
this works for me with Amazon Workmail
Comment 12 Luca 2016-09-06 09:43:04 UTC
I forgot to say, I don't have any other addresses allowed, either.
Comment 13 Milan Crha 2016-09-06 10:10:39 UTC
(In reply to David Woodhouse from comment #9)
> Out of interest, why were we including an invalid empty From: header,
> instead of just not including a From: header at all.
> 
> That is, why include the letters 'F' 'r' 'o' 'm' and the colon? :)

I do not recall. Maybe something like "do not modify the message as that much" or similar reason.

(In reply to Luca from comment #11)
> this works for me with Amazon Workmail

Thanks fot he testing and confirmation. Jan, are you able to test it by this Friday, please? There's a release on Monday, then a hard code freeze, thus the change might be pushed into the sources by the end of this week to be part of the evolution-ews 3.22.0 release.
Comment 14 Jan Vesely 2016-09-07 04:28:25 UTC
(In reply to Milan Crha from comment #13)
> (In reply to David Woodhouse from comment #9)
> > Out of interest, why were we including an invalid empty From: header,
> > instead of just not including a From: header at all.
> > 
> > That is, why include the letters 'F' 'r' 'o' 'm' and the colon? :)
> 
> I do not recall. Maybe something like "do not modify the message as that
> much" or similar reason.
> 
> (In reply to Luca from comment #11)
> > this works for me with Amazon Workmail
> 
> Thanks fot he testing and confirmation. Jan, are you able to test it by this
> Friday, please? There's a release on Monday, then a hard code freeze, thus
> the change might be pushed into the sources by the end of this week to be
> part of the evolution-ews 3.22.0 release.

Hi,

the patch works for me.
applied on top of 3.20.5 (Gentoo), send as alias behaviour is now identical to OWA web interface.
other than the o365 account, I also confirmed that the patch works with outlook.com (when added using ews) and allows sending email using outlook.com aliases.

thanks,
Jan
Comment 15 Milan Crha 2016-09-07 10:22:19 UTC
Thanks a lot you both for a prompt testing and confirming.

Created commit caa3abc in ews master (3.21.92+)

(In reply to Jan Vesely from comment #14)
> other than the o365 account, I also confirmed that the patch works with
> outlook.com (when added using ews) and allows sending email using
> outlook.com aliases.

I have a free outlook.com address and while I was searching recently I didn't find an EWS entry point for the outlook.com server. Do you know whether there's an EWS entry point for the free outlook.com addresses, or it's only a paid service? What I found indicated only the later or no EWS at all for the outlook.com; only the office365 having the EWS entry point, but that's a paid service by it's nature.
Comment 16 Jan Vesely 2016-09-07 12:22:10 UTC
(In reply to Milan Crha from comment #15)
> Thanks a lot you both for a prompt testing and confirming.
> 
> Created commit caa3abc in ews master (3.21.92+)
> 
> (In reply to Jan Vesely from comment #14)
> > other than the o365 account, I also confirmed that the patch works with
> > outlook.com (when added using ews) and allows sending email using
> > outlook.com aliases.
> 
> I have a free outlook.com address and while I was searching recently I
> didn't find an EWS entry point for the outlook.com server. Do you know
> whether there's an EWS entry point for the free outlook.com addresses, or
> it's only a paid service? What I found indicated only the later or no EWS at
> all for the outlook.com; only the office365 having the EWS entry point, but
> that's a paid service by it's nature.

I used it with a free outlook.com account. I had to create new app password, because of 2FA, other than that adding exchange account in g-o-a worked as expected. It also allows access to contacts and calendar, which is nice. I only tried it this week, so it might be a recent thing.

I did use the outlook.com account to join the Insiders program, but I find it unlikely that it would have an effect on the availability of exchange interface.
Comment 17 Milan Crha 2016-09-07 15:40:54 UTC
(In reply to Jan Vesely from comment #16)
> I used it with a free outlook.com account. I had to create new app password,
> because of 2FA, other than that adding exchange account in g-o-a worked as
> expected. It also allows access to contacts and calendar, which is nice. I
> only tried it this week, so it might be a recent thing.
> 
> I did use the outlook.com account to join the Insiders program, but I find
> it unlikely that it would have an effect on the availability of exchange
> interface.

Hmm, I do not use the Two-step verification, thus I do not have an application specific password. It seems they provide
https://outlook.com/EWS/Exchange.asmx
but I'm always rejected and asked for the password. Bad luck for me and thanks for sharing.