GNOME Bugzilla – Bug 530866
Read request preferences are not honored for Exchange accounts
Last modified: 2014-05-07 10:57:16 UTC
If someone requests a read receipt when they send me an email, I cannot seem to reject this using evolution. I have tried setting send read receipts to never and also always ask. When set to never it always sends a read reciept, and when set to always ask it sends one whether I choose send or reject. Distribution: Ubuntu 8.04 (hardy) Gnome Release: 2.22.1 2008-04-15 (Ubuntu) BugBuddy Version: 2.22.0
I tried with 2.25.2 and it works as expected, no issue at all. How many accounts do you have? It tries to guess the right account based on the message itself and the folder from which you are reading the mail. I looked into the code, even for 2.22 and it's quite same as in 2.25.2. At least in gnome's svn.
Thanks Milan We have tested this again here and found that when reading emails using an imap account, refusing or sending read receipts work as expected. It is when using the exchange plugin that the problem occurs. Whether I refuse to send the read receipt or not it always sends one anyway.
Just in case, do you use the old evolution-exchange or evolution-mapi package? (I didn't try yet, only checking before trying).
Adjusting summary.
I can confirm the problems with evolution-exchange and evo 2.24.2.
When you open the OWA web interface in a web browser, going to Options and look for "Privacy and Junk E-mail Prevention", section "Choose how to respond to requests for read receipts", what do you have chosen there? I've there two possible options, "Always send a response" and "Do not automatically send a response". I guess you've set the former. This is how server responses, which is quite out of Evolution's hand (I think).
(In reply to comment #6) > When you open the OWA web interface in a web browser, going to Options and look > for "Privacy and Junk E-mail Prevention", section "Choose how to respond to > requests for read receipts", what do you have chosen there? > > I've there two possible options, "Always send a response" and "Do not > automatically send a response". I guess you've set the former. This is how > server responses, which is quite out of Evolution's hand (I think). > Great theory, but wrong. I have "Do not automatically send a response" checked, and Evo still sends a response.
OK. I did some more testing. Looks like the setting is not honored with what is selected in OWA, but is honored by what is selected in Outlook. I am lucky as I have a windows machine (I can't believe that I just typed that ;-) and can changed the settings with Outlook. When this is set with Outlook to prompt, and evo to prompt, then the rejection is honored. When set in Outlook to always accept, and evo to prompt, then evo prompts, but exchange sends it anyway. Appears that certain alleged Outlook options are actually stored on your exchange profile rather than your local machine. As you point out, Milan, this cannot be controlled completely with Evo, but I think this important enough to security, that Evo should display a warning to make sure the Outlook setting is correct.
That's strange. And honestly, I do not know eex so much to know how to check for such option. But let me dig in more. I'll report back when I will know more. Thanks for your help.
We have tried again here and we can set the option on OWA but it is ignored as Art found, We cannot set the option in Outlook as we use Outlook 2000 and there appears to be nowhere to set it in this version. When evolution asks if you wish to send a receipt, the receipt is not sent until either of the two buttons is clicked.
(In reply to comment #10) > When evolution asks if you wish to send a receipt, the receipt is not sent > until either of the two buttons is clicked. It's probably because after you push one button, the actual mail is sent to the server, where it is processed, and server sends the receipt.
Here's some interesting pieces. The "Message receipts" tab provided by Evolution are specific to Evolution only. Depending on what you select Evolution constructs a message in em_utils_send_receipt() and sends it over. So the server would always send the message receipt no matter what option you select in Evolution. And if you allow Evolution to send the receipt it would send over another receipt of its own. So you will end up with 2 read receipts, one sent by the server and the other sent by Evolution :) Ideally Evolution must cancel the request for the receipt on the server. Will need to investigate more on how to :(
Created attachment 131897 [details] screenshot of ie and owa
Today I accidentally noticed on my outgoing SMTP that "read receipt" notification get sent without my agreement. So I investigated a little. 1) When opening received message with "read receipt" header set in MSIE, there appears option to send receipt (see screenshot attached). When clicking on "Click here to send a receipt" the following IIS log lines gets logged and the receipt gets sent: 2009-04-02 08:25:27 W3SVC1 192.168.0.1 GET /exch/username/Inbox/rr.EML Cmd=open 443 username 192.168.0.222 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1) 200 0 0 2009-04-02 08:25:37 W3SVC1 192.168.0.1 PROPPATCH /exch/username/Inbox/rr.EML - 443 username 192.168.0.222 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1) 207 0 0 2) When opening in FireFox nothing appears and receipt doesn't get sent (guess because FireFox doesn't support webdav). 3) When opening in Evolution 2.24.3 the following IIS request gets logged and receipt notification gets sent: 2009-04-02 08:38:02 W3SVC1 192.168.0.1 GET /exch/username/Inbox/rrr.EML - 443 username 192.168.0.111 Evolution/2.24.3 200 0 0 2009-04-02 08:38:02 W3SVC1 192.168.0.1 PROPFIND /exch/username/Inbox/rrr.EML - 443 username 192.168.0.111 Evolution/2.24.3 207 0 0 My guess is that maybe Evolution should be fixed to execute: GET ...mail.EML with one more argument "cmd=open". Perhaps then mail just gets opened without sending receipt. Maybe someone with Exchange WebDav skills could investigate this. Thanks!
evolution-exchange is currently dead, thus I'm closing this bug report. The evolution-ews has just fixed this within bug #656805, evolution-mapi within bug #586353.