GNOME Bugzilla – Bug 695332
Wrong account selected when accepting meeting request
Last modified: 2021-05-19 12:13:06 UTC
Hi, I've come accross an issue where Evolution selects the wrong account when accepting a meeting request. Initial discovery was made on Evolution 3.4.4 (Debian Wheezy), but verified to still exist in Evolution 3.6.3 on Arch Linux. It appears that Evolution looks at the 'From' header instead of the 'To' header when replying (accepting) to meeting requests. Consider these 2 scenarios, in both cases there are 3 accounts configured, 1 for IMAP, 1 for Google SMTP, 1 for the SMTP of my ISP. First scenario: A random person sends a meeting request, when clicking accept, Evolution replies using the (internal only) IMAP account. This is the case I described in my first mail. Second scenario: I send a meeting request from my Google account to my ISP address, the request is received using the IMAP account. When replying, evolution uses my Google account, instead of the IMAP like in the first case, or the ISP account that is in the To header. Regards, Steven
Thanks for a bug report. As far as I can tell, evolution works correctly. The first scenario is correct on its own, it found the attendee with your email in your configured mail accounts as expected. The second scenario is also correct. Your Google account is here an Organizer, while your ISP account is an Attendee (organizer is usually also an attendee, listed before the other attendees). That way Evolution picks Organizer's email, not Attendee's email, because the first found match between attendees is that representing the Organizer. After a code read, evolution doesn't check message headers, everything is driven by the underlying calendar component (text/calendar part of the meeting invitation).
Thanks for having a look at this Milan. However I would have to disagree about that behaviour being correct, especially in scenario 1. I also apologize for not giving the best description in my initial report, I pasted some of that from an e-mail I sent to a mailing list. Scenario 1: I'll get a bit more into the details of this one. outsider@acme.com sends me a meeting request on me@myisp.com My own server receives the message (getmail) and processes it, the message ends up in my server account with address me@myownserver.local (address not internet routable) When clicking reply evolution tries to send the reply using the me@myownserver.local account while I would expect it to use me@myisp.com. since you say Evolution looks in the text/calendar part it should definitely have used me@myisp.com. This particular invitation has 3 attendees, where I'm the last of those 3: ATTENDEE;CN=Firstname LastName;CUTYPE=INDIVIDUAL;RSVP=TRUE:mailto: me@myisp.com (I can't guarantee the whitespace at the moment, I'm looking at the request through a webinterface that mangles that up a bit) My 2 accounts in this case are me@myisp.com and me@myownserver.local, the first one is only SMTP, receiving type is set to 'none', the second one is type IMAP+ (from my own server). Scenario 2: This is debatable as your statements are true, since all involved accounts are configured on the same Evolution instance this is really a corner case. Why would someone send a meeting request to (him/her)self instead of just adding an event to the calendar. The only reason I ever tried this is for this bug report.
forgot to mark as not fixed.
Thanks for the update. There is one thing I'm not sure about now, you said > ... When clicking reply evolution tries to send the reply using ... Do you actually Reply to the message, like with Message->Reply to Sender or any other variant of the Message->Reply... to it? I ask this, because that might be my misunderstanding of the issue, where in comment #1 I was mainly talking about the "reply" being sent by evolution when you click Accept/Deny/Tentative buttons in the message preview of the meeting invitation. Using real Message->Reply... uses different rules to identify/guess the account to send from, where picking the account based on the message source is basically the first try here.
I'm clicking 'Accept' here, sorry for the confusion. All described behaviour is based on clicking 'Accept'. Reply generally works quite well except for mailing lists.
Hmm, then it seems like it failed to pair the Attendee's email address with one of your accounts. Is the me@myownserver.local account set as Default in Edit->Preferences->Mail Accounts? If so, then it might be used as a fallback account, when the search on attendee fails. Try to check the message source in evolution, by pressing Ctrl+U, or View->Message Source, then check whether the Organizer, or any of Attendee, doesn't use the same mailto as one of your accounts. And as a test on the Default account, I'd try to change it. You can answer to the messages in Offline (File->Work Offline), to not bother the organizer - in that case the message will be placed into the Outbox, where you can examine it, then delete it, then expunge the folder (Ctrl+E or Folder->Expunge while staying in On This Computer/Outbox). Message in Outbox will aslo show which attendee evolution picked (the other two will not be listed in the component).
me@myownserver.local is not set as default (because I found it cumbersome to always select another account when creating a new mail), the default is me@myisp.com. The only address in the meeting request matching (the .ics attachment) one of my own is me@myisp.com Although if evolution would look in the e-mail headers, there might be another one, yet evolution doesn't know about that one, it is in the 'Return-Path' header and contains the me@myownserver.local address with a different DNS suffix, that same address in also in the 'X-Original-To' and the 'Delivered-To' headers. The myownserver.local DNS (the same as from the account evolution tries to use) is only ever mentioned in a 'Received' header. If looking at the meeting request itself (a .ics file, type text/calendar), the only address known to evolution is me@myisp.com I'll run another test using the Arch machine this evening, that should remove some variables.
Created attachment 238625 [details] testcase invite Hello again, attached is an e-mail (saved with evolution in mbox format) where I have sent a meeting request from randomperson@gmail.com to me@myisp.com I have anonimized it a bit, but everything should be clear. Involved IP addresses and hostnames are changed (except from google). I also changed the addresses inside the base64-encoded attachment, but left it otherwise unchanged, URLs on gmail are also slightly modified. randomperson (unknown address to evolution) sends me a meeting request to me@myisp.com. My server (debian.LAN or myownserver.kwik.to, both hostnames are known on the internal network) receives the messages and processes it. Evolution uses IMAP+ to receive the message from my server using account steven@debian.LAN, the SMTP server on this account is bogus. I click accept in the meeting request, evolution then tries to send the response using steven@debian.LAN instead of me@myisp.com Configured accounts in evolution (3.6.3), in order: - me@myisp.com (default, smtp only) - me@gmail.com (smtp only, not related to this particular test) - On this computer (maildir) - steven@debian.LAN (imapx) - Search Folders (vfolder)
Thanks for the message. I tried to reproduce it here, but with no luck, the me@myisp.com is chosen for me (verified in On This Computer/Sent folder). I accept the meeting to the On This Computer/Personal calendar. Maybe that's the difference, for example CalDAV (or Google) calendars can define their own email address. What calendar type do you use for meeting invitations, please?
In my initial report (Debian Wheezy, Evolution 3.4.4) the target calendar was a google calendar I have set up in Evolution, that has an account associated with a valid (google) SMTP server. However the account Evolution selected to send the 'accept' message was debian.LAN (my own server) while the attendee was me@myisp.com. I would have found it more logical if Evolution selected the account associated with the calendar, yet it didn't. In my opinion it should have selected me@myisp.com since that was the attendee. In case of that last test case (see yesterday's attachment) there was no additional calendar configured, only the 'Personal' and 'Birthday' calendars were available, I accepted on the 'Personal' calendar. That test was run on an Arch Linux virtual machine with Evolution 3.6.3. So it doesn't look like the type of calendar affects this at all.
Created attachment 238681 [details] multiple folder structures Another thing, when you tried to reproduce this, how did you configure the e-mail account that receives the meeting request? It looks to me like that is a major factor here. In my case that account is not associated with any of the addresses in the message, only the IMAP account that actually retrieves it from the local server. That account also has its own folder structure since it's an IMAP account, it doesn't fall into the 'this computer' category. See attached screenshot for example (not actual screenshot, the meeting request would be dropped in a subfolder of the second folder structure, test@...).
Aha, that's it. I imported the invitation in one of my On This Computer folders, and it did what it should do, but when I imported it to a dedicated account (like your IMAP), then there is picked the address of the account to which the folder belongs. I've a feeling there was a request to do it that way for some reason.
The related bugs seem to be bug #322261, bug #372921 and bug #342935, all addressed for evolution 2.30.0. Either they did something wrong, or the 3.6 has another regression.
After glancing over those bugs you mention, I don't think it's a regression, but more of a corner case I hit. I propose the following solution (note that I am not familiar with the Evolution source code). 1) matching attendee If a match is found use that, in case of more matches, use the one associated with the folder (but only if that matches), otherwise use the default (from the matching accounts), or first in configured accounts (from the matching accounts). 2) no matching attendee, use account associated with the folder 3) no matching attendee, no account associated with the folder Use the default account. Note that attendee can also be the organizer in this proposal. This should cover all use cases described in those bug reports, unless I missed one.
I see the behaviour was introduced within bug #322261, in time of 2.30, thus you are right, this is not a regression from 3.6 changes. I can change the order of picking send account, but it might not do the right thing, with respect of bug #322261. They have configured two accounts, A and B, and they receive a meeting invitation to account B with address of A, but they still want to send the invitation from B, because it was received there. It makes sense to me. It's the same scenario as that yours, you only want the opposite.
err, "send the invitation _response_ from B"
The problem in my case is that the account doesn't have a valid way to send mail. Ok, new proposal, how about adding a 'none' option for sending mail as well? There is one for receiving. Then when it would now select my debian.LAN account, it would see that there is no sending behaviour configured and fall back to my earlier proposal, or something similar. Tolerable to me would be at least that it won't try to send with an invalid account, but give you the option to select an appropriate one instead. Although I feel it would be better (from a usage standpoint) to select the appropriate account. Reading through bug #322261 it doesn't seem like they want what you described, but rather that evolution was selecting the default account, instead of checking for either attendee or owning folder. Resulting in account A (default) sending the 'accept' message, for a request received on account B (even though account B is listed as attendee). Although I might have misread. If I'm correct on this, my earlier proposal would still cover that, if not, well.. it's complicated. On the regression front: even if it is a regression somehow, definitely not introduced in 3.6, as 3.4 has the same behaviour.
Right, having the None option for the Sending part, and respect this value in calendar will help. I know there is a bug report for this, but I cannot find it right now. Let's keep this opened for the both parts: a) Add None send type b) skip receive-only accounts when sending meeting invitation responses
That would definitely help my case and probably others. Unfortunately not all cases such as Bug 663827 (although this bug is about sending new messages and/or replies, not about meeting requests) Here the user has 1 account configured (like gmail through IMAP) and his gmail account is set up to receive additional mailboxes. In this case one would add 1 account for both send and receive (gmail) and a second one for sending only. In this case the accept message for foo@isp.com would still be sent using the gmail account. Although I guess one can set up 3 accounts in this case when the 'none' type for sending is implemented, it may not be 'nice', but works.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.