GNOME Bugzilla – Bug 331969
[PATCH] evolution-exchange: Exchange 2003 sends disposition-notification (read receipts) regardless of settings
Last modified: 2013-07-23 14:32:34 UTC
When "Send message receipts" under accounts editor->defaults is set to "never" a receipt is still sent (by the exchange server itself, not by evolution.) When "Send message receipts" is set to "ask each time" and you respond "no" upon opening a message with RR requested, a receipt is still sent. When you respond "yes" TWO receipts are sent, one by evolution and one by exchange. When "Send message receipts" is set to "always" TWO receipts are always sent. I will attach sample read-receipts momentarily. This is a major bummer for us, since it exposes information about internal mailreading that we'd rather not share outside the company. Some testing has shown that this is occurring for all versions of evolution used in-house, from 2.0.x through my 2.5.91. Using the Outlook Web Access through a browser does NOT send any read-receipts when the user has configured their options not to do so. If fixing this problem is a question of access to an exchange 2003 server we can provide said access. If this bug cannot be fixed we will have to migrate several developers (plus yours truly) off of Evolution, which will be painful.
Created attachment 59809 [details] disposition-notification sent when "send message receipt" is set to "always" This is email sent (apparently by evolution) when "send message receipts" is set to "always", or when set to "ask each time" and the user acquiesces
Created attachment 59811 [details] disposition-notification that is ALWAYS sent this type of email is always sent when RR is requested, regardless of "message receipt" settings -- This is the one I need to stop from happening!
With E2K_DEBUG set to 5, grepping through my log output for "readreceipt" produces this: <FONT size=2>Choose how to respond to requests for read receipts:</FONT><BR><INPUT TYPE='radio' name="http://schemas.microsoft.com/exchange/readreceipt" ID="chkSRRAlways" value="1" ><LABEL for="chkSRRAlways"><FONT size=2>Always send a response</FONT></LABEL><BR><INPUT TYPE='radio' name="http://schemas.microsoft.com/exchange/readreceipt" ID="chkSRRNever" value="0" checked><LABEL for="chkSRRNever"><FONT size=2>Do not automatically send a response</FONT></LABEL> ...which seems to match what I sniffed when I loaded OWA into a browser and connected without SSL. Yet still the browser session allowed me to read email without sending involuntary RRs, and the evolution session did not. (While testing with "send receipts" set to "ask every time" I noticed that the involuntary receipt was sometimes sent before I'd even had a chance to respond to the dialog popup asking whether I wanted to send a receipt...) :-( Ole
Is there any other information I can provide that would help nail this bug?
I tested in my local server and it seems to happen in the same way you have mentioned. Assigning to myself. will have to check if there is any server setting or is there anything that we hafta do.
I spent several hours with my exchange admin looking for server settings and generally brainstorming this. If there's a server-side setting we were unable to find it. WHat's interesting is that the exchange web client (aka OWA) doesn't have this problem -- if you set the option in the options tab to ignore RRs, it ignores them. Tested this morning with a freshly-built 2.6.0 (1.6.0 for EDS) and the problem still exists there. I'd change the version number in the bug but bugzilla doesn't seem to be aware of the existence of 2.6 yet...
See bug #272985
This is a major problem for those SPAM sites that find out about this. All of a sudden, you now have a way to confirm email addresses. Of course I can just let the server admins deal with this mess.
<?xml version="1.0" encoding="utf-8" ?><D:propertyupdate xmlns:D="DAV:" xmlns:a="urn:schemas:httpmail:" xmlns:T="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"> <D:target> <D:href>Eric%20Clapton.EML</D:href> </D:target> <D:set><D:prop> <a:read>1</a:read> </D:prop></D:set> </D:propertyupdate> After reading the message, we update the status of the message and at this instant the Exchange server sends the receipt by default. There must be some property that I need to set as part of this message. Needs some MSDNing.
From what I could read from MSDN, We need to set SUPPRESS_RECEIPT (flag=1) as part of the read element it seems. Will have to try it once am back.
Glad to see you've got a lead on something to chase down! In the meantime (for Robin, and anyone else that stumbles across this bugreport) the workaround I've put in place is to have a filter in Evolution (first filter in the list) that matches on the existence of the 'Disposition-Notification-To' header, and moves matching messages to a special folder. When I see that the DSN folder has unread contents, I open it in OWA directly using a browser and I can read the messages there without fear of receipts. Plus, (once Evo has been shutdown and restarted) Evolution sees that the messages are no longer new and if I want to I can reread them in Evo without causing a receipt to be sent.
Created attachment 79279 [details] [review] Fix (EDS)
Created attachment 79280 [details] [review] Fix (Exchange)
I have set SUPPRESS_RECEIPTS so that read-recipts will never be sent by the server automatically. Patch to EDS should be applied before applying the patch to Evolution-exchange. Needs some testing and review.
Thanks for your efforts! Unfortunately, it doesn't look like they had the desired effect... I've just applied these patches and rebuilt EDS and EE; no change in behavior after an "evolution --force shutdown" and restart. My current settings for read-receipts are to ask every time; when I send myself a message with Disposition-Notification-To set, evo asks me whether I want to send the read receipt but even if I answer "no" a read receipt is sent. :-( Ole
Sankar: Any updates to the above response?
We've been through a couple release iterations, but I notice the problem still occurs (running 2.10.1 at the moment, courtesy of Gentoo.) Replication of this issue should be dead easy, since Evo will respond to the read-receipts that it sends itself.
Setting the patch status from comment #15
[nag] Still exists in 2.12.1. [/nag] Interestingly, I've noticed that the receipt is not sent until after I click "no" in the modal dialog that pops up when "ask every time" is selected -- even if I wait a half-hour. The receipt is sent only after the dialog box closes. If I don't answer the modal dialog and instead kill evo from a shell with "evolution --force-shutdown" no receipt is sent (but I will still be prompted the next time I open that email, and a receipt will be sent when the dialog closes.)
Is there any hope of ever fixing this bug? I filed it almost two years ago, and it's still broke, and every time it bites me it sends my blood pressure skyrocketing. (My workaround doesn't work so good now that autofiltering is broken too, cf. bug #44503 comment 15.)
Sankar, You have any updates to this bug?
*** Bug 490429 has been marked as a duplicate of this bug. ***
The "evolution-exchange" package only supports Exchange 2000 and 2003 servers. Newer versions such as Exchange 2007 and 2010 are not supported by "evolution-exchange". It is required to use the package "evolution-ews" (or to some extend "evolution-mapi") for newer version fo Exchange servers. If the problem/request described in this report still happens with a recent version of "evolution-ews" or "evolution-mapi", please add a comment to this report (and update the "product" setting accordingly if possible). There are currently no plans to continue the development of the package "evolution-exchange", so this report will soon be closed as WONTFIX. Thanks for your understanding and sorry that the reported problem was not solved in time in the package "evolution-exchange".
evolution-exchange only supports the older Microsoft Exchange server versions 2000 and 2003. The last stable release of evolution-exchange was 3.4.4 which took place a year ago. evolution-exchange is now deprecated and not under active development anymore. It is unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. Also feel free to reopen this ticket and change the "Product" field accordingly if the reported issue still happens with a recent version (newer than version 3.6) of one of those Exchange backends that are still supported. Please see https://help.gnome.org/users/evolution/3.8/exchange-connectors-overview.html for more information on available backends.