Created attachment 886933 [details] EWS_DEBUG=1 output Description of problem: I have logged into evolution with three accounts. a) IMAPX to my home Linux mail server (evolution saved the credentials), b) Microsoft Exchange to my work server (Gnome-Online-Accounts setup which has saved credentials), c) IMAPZ to my GMail account (Gnome-Online-Accounts setup which has saved credentials). Twice today, I was unable to to send email using the Microsoft Exchange account. I get an error message stating that I have an invalid password. I am not prompted to change it. On this last occasion, after getting that message, I was still able to create a new calendar entry. I am able to sign into Webmail Outlook, so the password is still the same as before. I have tried to go into "Work Offline" mode, wait 30 seconds, and go online, but I still get the error. Now it says: Failed to open folder. The reported error was "Invalid Password for (my exchange account description)". Last time I fixed it by restarting Evolution completely. Running gdb --pid=xxx and then "thread apply all bt" didn't give any useful information - just: Thread 1 (process 19353): #0 0x592ea9dd in ?? () Cannot access memory at address 0x847cbfe0 I haven't changed my password and the correct one is stored. What's going on with evolution-ews? Version-Release number of selected component (if applicable): evolution-3.10.4-2.fc20.x86_64 evolution-data-server-3.10.4-3.fc20.x86_64 evolution-ews-3.10.4-1.fc20.x86_64 gnome-online-accounts-3.10.3-1.fc20.x86_64 gnome-online-miners-3.10.3-1.fc20.x86_64 gvfs-goa-1.18.3-2.fc20.x86_64 evolution-help-3.10.4-2.fc20.noarch How reproducible: Regularly Steps to Reproduce: 1. Open evolution. Use it. 2. Wait a while, and try to send an email. 3. Get the error "Invalid Password" Actual results: Expected results: Additional info:
Created attachment 886934 [details] gdb output Restarted, and ran gdb against the evolution PID when it occurred again. I had added items to the calendar, and then returned to the mail window. The preview pane showed the error message again about the invalid password.
Thanks for a bug report. The gdb doesn't help in this situation, the process is not stuck in this state, so it moved on. You also do not have installed debuginfo packages for evolution-data-server, evolution and evolution-ews. Not a big deal for the same reason, I'm only mentioning it here. The EWS_DEBUG log shows only requests sent by evolution-ews, not received by it. It would be good to retry with EWS_DEBUG=2, which will show the detailed communication between the client and the server. I noticed in the log that also the 'Global Address List' fails with the same error. I search the sources of evolution-ews and I didn't find there the "Invalid password for" string, thus I suspect it's what the server returns. Why it does that, while it lets you connect to Calendar and OWA, is something I do not understand. Could you run Seahorse ("Passwords and Keys" application) and verify the stored passwords? Alternatively, could you delete them from the keyring in Seahorse, kill all evolution processes (ps ax | grep evolution) with evolution-calendar-factory as the last, if you run gnome-shell, and then reenter the password, please? Maybe evolution doesn't use correct password for some (weird) reason.
Created attachment 887201 [details] EWS_DEBUG=2 output As requested, here is level 2 debug. I opened mail, read a message from the Exchange mailbox, then read it from my IMAPX mailbox (my Exchange messages forward to it at this time), clicked reply all and typed up my response. By the time I tried to send the reply, the authorization failed again. I had to send the message from my IMAPX/Sendmail account instead.
I have also verified my passwords. I didn't expect to find any errors there because a) they work initially, and b) this was a CLEAN INSTALL of Fedora 20, and I didn't import the accounts across from my previous system. I did copy the contents of the LOCAL Inbox, and the filters and vfolders xml files. Otherwise, the installation is completely clean. I have just restarted evolution and it's done it again. I also just verified that the calendar is still working this time. (By the way, I am pleased about this because for F18 and F19 the calendar has been a waste of time for me. It seemed to get some updates in the background, but whenever I wanted to add an entry, or accept a meeting, it would give me some kind of authentication error. I was using the evolution side defined account then - not the Gnome Online Accounts like I am now.)
Thanks for the update. I do not see from the log the exact reason why the server rejected to authenticate you, but I see other useful thing. One of your folders has quite large SyncState, it has several KB, which is quite long. There had been discussed a bug report upstream [1], which described basically the same issue as you have. As [1] mentions, the can be an issue with combination of libsoup, glib-networking and gnutls packages being used. The upstream bug also mentioned Message Corrupt error, which doesn't appear in your log. Dan, do you have any idea why the libsoup would disconnect silently from the server and need reconnect, while the same connection worked just fine a second earlier, please? [1] https://bugzilla.gnome.org/show_bug.cgi?id=707655#c30
(In reply to Milan Crha from comment #5) > Dan, do you have any idea why the libsoup would disconnect silently from the > server and need reconnect, while the same connection worked just fine a > second earlier, please? The log doesn't show any disconnecting; even after the 401 Unauthorized response it's still using "SoupSocket 1". In the old Exchange WebDAV interface, a 401 received after successfully NTLM authenticating generally meant "permission denied", not "password incorrect". Also, in the specific case of sending a message, it would return a 401 if you tried to use a From address that didn't match anything that the Exchange server considered to be a valid email address for you. A-ha, and after a little base64-decoding, I see "From: \r\n". ie, a completely empty "From" header. So, there's your bug.
(In reply to Dan Winship from comment #6) > A-ha, and after a little base64-decoding, I see "From: \r\n". ie, a > completely empty "From" header. So, there's your bug. The From is set empty intentionally, the Exchange server fills it on its own, and claims errors if it doesn't match what it expects it to be, like the logged-in user.
ah. OK, not sure about the specifics then, but I think the part about the 401 meaning "permission denied" rather than "authentication failed / password incorrect" is still probably right. I just don't know why permission was denied...
Thanks for you efforts!! Anything more you need from me? It gets to be quite frustrating, as I am sure you can imagine.
I've also not much idea, unfortunately. I use NTLM authentication and I also see 401 responses from the server, but it is usually only for the first time, when libsoup asks evolution-ews for the password and it is provided as expected by evolution-ews to it, thus the retry of the message send works properly. Just like in your log. I see a difference in headers from the beginning of the log and from the end, when the send begun to fail. At the beginning evolution includes also > Authorization: NTLM TlRMT.... header, to which the server responds: > < WWW-Authenticate: NTLM TlRMTVNT... (by the way, your server also supports kerberos authentication). After this, evolution retries with populated > Authorization: NTLM TlRMTV.... which the server accepts and everything works as expect, until after some request fails with 401 again, but this time evolution-ews retries without setting the Authorization: NTLM... header, thus the server doesn't compute NTLM request, to which would the libsoup compute proper NTLM response. Dan, does this ring any bell to you, please? Louis, could you provide package versions for libsoup, glib2, glib-networking, please? Simply run the below command in a terminal and paste here its output: $ rpm -q libsoup glib2 glib-networking
(In reply to Milan Crha from comment #10) > After this, evolution retries with populated > > Authorization: NTLM TlRMTV.... > which the server accepts and everything works as expect, until after some > request fails with 401 again, but this time evolution-ews retries without > setting the Authorization: NTLM... header, thus the server doesn't compute > NTLM request, to which would the libsoup compute proper NTLM response. > > Dan, does this ring any bell to you, please? Once a connection has been successfully authenticated, SoupAuthNTLM more-or-less stops paying attention to it. I think in the past, all (post-authentication) 401 responses I'd seen contained "Connection: close", so there was no need to worry about re-authenticating, so there was never any code to handle that case. Does the libsoup package in http://koji.fedoraproject.org/koji/taskinfo?taskID=6795073 make things better at all? (It won't fix the original error when trying and failing to send the message, but it should hopefully make libsoup recover after that so that further requests succeed.)
Hi Milan: These are the packages I have installed: # rpm -q libsoup glib2 glib-networking libsoup-2.44.2-1.fc20.x86_64 glib2-2.38.2-2.fc20.x86_64 glib2-2.38.2-2.fc20.i686 glib-networking-2.38.2-1.fc20.x86_64 Hi Dan: I have removed the above libsoup and installed your test version in its place. I am away from the office this week, but will test it next week when I am back there and feed back to you then. Many thanks for your assistance.
Hi Dan The libsoup update has worked ... mostly. I haven't had a failure occur today at all, but some of the emails (plain text) which ordinarily would be sent in a couple of seconds now take about 90 seconds to go. I guess this is when it waits and then reattempts the authentication. Nevertheless, it's STREETS ahead of where we were. On a completely side note: a frustration of mine is when I reply to a message that my colleagues have sent me (usually always from Outlook) and the moment I reply of forward, ALL their formatting is gone. It means that when they highlight text it's no longer visible. Is there ANY way to get Evolution to keep the formatting when replying and forwarding? Again, many thanks ...
(In reply to Louis van Dyk from comment #13) > On a completely side note: a frustration of mine is when I reply to a > message that my colleagues have sent me (usually always from Outlook) and > the moment I reply of forward, ALL their formatting is gone. It means that > when they highlight text it's no longer visible. Is there ANY way to get > Evolution to keep the formatting when replying and forwarding? Such formatting changes are available only in the HTML mode, but the current message composer in evolution doesn't know about CSS, which is used for such formatting by other mail clients, including Outlook, thus it doesn't show the formatting correctly even when you have enabled HTML mode. There [1] is an ongoing effort to switch to a webkit-based composer, which will likely happen for evolution 3.14.0 (which will be released in almost a year). [1] https://bugzilla.gnome.org/show_bug.cgi?id=540362
Hi Gents ... I am pleases to say that the new libsoup doesn't fail for authentication reasons, however, I do frequently find that it might take around 90 seconds before the message actually gets sent. Perhaps this is as it's trying to re-authenticate? Will you be pushing out your fix into the mainstream? Thanks L
(In reply to Louis van Dyk from comment #15) > I am pleases to say that the new libsoup doesn't fail for authentication > reasons, however, I do frequently find that it might take around 90 seconds > before the message actually gets sent. Perhaps this is as it's trying to > re-authenticate? You can see what it does, if anything I/O related, when you run evolution like before, as `EWS_DEBUG=2 evolution`, to see the communication between the server and the client. The 90 seconds delay feels quite long, like if some connection is waiting for a timeout or anything like that. Default timeout for EWS connection is 120 seconds, which can be changes in .source files, which I do not expect you touched.
I am having a "beat my head against the wall" time with Evolution at the moment. For the last week or so I can almost never use evolution-ews. Nothing is logged in the debug either .... all I get when I run it as a console is: <quote> [louis@lenovo ~]$ EWS_DEBUG=2 evolution | tee evolution.20140522.log java version "1.7.0_55" OpenJDK Runtime Environment (fedora-2.4.7.0.fc20-x86_64 u55-b13) OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode) (evolution:26444): evolution-mail-WARNING **: (mail-send-recv.c:1145):receive_update_got_folderinfo: runtime check failed: (info != NULL) (evolution:26444): evolution-mail-WARNING **: receive_update_got_folderinfo: Timeout was reached </quote> STEPS: - I kill all tasks with killev, and check that nothing is running, then try to run evolution. - My IMAPX account connects and updates, but the Exchange account times out. - Just before the timeout, there is an ABRT report that gnome-online-accounts has crashed, apparently a bug from last year. https://bugzilla.redhat.com/show_bug.cgi?id=1031257 SOMEtimes it has worked in the last week though ... It worked yesterday for a while, and then I was getting timeouts on the message I was trying to send (with two 2.5 MB attachments). Luckily I was running all day with the debug level 2 option, but the log is 28 MB in size, but only GZIPs to 19 MB. Would you like me to attach it to this ticket? I'm going to have to reboot now again and see if matters will improve since killev is not helping me.
Just to confirm: after a completely power off and reboot I am able to get into evolution-ews again. I am running it with EWS_DEBUG=2.
Feel free to delete the log, if it timeouts, then there is some issue with the connection. The next time it happens, if at all, try to 'ping server-address', whether it'll work. I'd expect it'll not, when also ews doesn't.
Hi! I have that same issue ever since my office has updated to the latest MS Exchange, MS-Exchange 2013. This wasn't happening with MS Exchange 2007. This may be a compatibility issue with the new MS Exchange.
Refer to comment 11 and install the package of libsoup for your architecture. Remember everytime you run yum updates to exclude libsoup as it will want to replace it! Sometimes I have a wait a long time for the mail to send / update, but most of the time it does, and I no longer get the timeout message with this libsoup.
I installed libsoup from the rawhide repo and it seems to have partially fixed the problem. After some time, the dreaded password prompt still pops up but the password is now accepted without much fuss: [mgogala@medo ~]$ rpm -qa libsoup libsoup-2.47.4-2.fc22.x86_64 [mgogala@medo ~]$ So, it isn't perfect, but it's usable now.
Louis, there is no download link on http://koji.fedoraproject.org/koji/taskinfo?taskID=6795073 Where can I get the "magic" libsoup?
Wow! After chasing in circles on the link above ... I have no idea how I got it from there originally!! I will mail it to you since luckily I kept the RPM. You are on Fedora 20, right?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Any progress to report on this bug? I've been having the same problem ever since I started using Evolution with Exchange Web Services, and it's driving me to the point of giving up on it entirely. I'm currently running Fedora 20 with current libsoup (2.44.2-1.fc20); evolution is 3.10.4-4 and evolution-ews is 3.10.4-1. I am happy to post any debugging information that will help. This problem typically manifests any time I do anything, including read a message (that is, I can read a message and start to reply, but I then have to save a draft to my local machine, exit Evolution, restart, then send another message based on the one in the draft/outbox directory to send a reply).
The only fix is to update to more recent libsoup. There had been discussed similar issue upstream [1], which also mentioned certain combination of libsoup and gnutls led to the same error. Updating to the upcoming Fedora 21 should finally fix this issue completely. [1] https://bugzilla.gnome.org/show_bug.cgi?id=707655
@Karl, Dan wrote a version of libsoup for me which made matters *MUCH* better. I will mail it to you directly, since the RPM is no longer on the koji site above. Just exclude it from updates in future (in F20) otherwise it will revert to the original (broken) one. @Milan, couldn't you push the libsoup that Dan wrote to the F20 repo's? It would help so many of us in the interim.
(In reply to Louis van Dyk from comment #28) > @Milan, couldn't you push the libsoup that Dan wrote to the F20 repo's? It > would help so many of us in the interim. I'm not a libsoup maintainer, Dan is. I also do not know how many other consequences are involved in his change, neither the source package for the changes at comment #11. But I agree it makes sense to create an update of libsoup. Dan, could you do that, please?
libsoup-2.44.2-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libsoup-2.44.2-2.fc20
libsoup-2.44.2-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
The same problem appeared in F21. I am being prompted for password, for no obvious reason.
libsoup-2.48.1-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libsoup-2.48.1-2.fc21
libsoup-2.48.1-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Is this fault possibly in FC22 too? I upgraded to it two days ago, and EWS continually times out, asking for my password again. Not the catastrophic failure like in the past, but it does stop working until I re-authenticate -- with the same credentials.
Hard to tell. It can be anything else than the libsoup issue, or it. It would need to investigate the root cause to be sure (preferably in a different bug report).
I haven't had a problem with F22 yet. In the two weeks since I have updated to F22, I haven't had any problems. F22 looks good so far, except for booting from Ext4. I would prefer XFS, but this is probably not the place for a conversation like that.
It seems our esteemed IT department was upgrading the Outlook Web Services and hit some problems. Since the complete collapse the other day, all seems to be working properly again. Sorry for the red herring!
(In reply to Louis van Dyk from comment #38) > It seems our esteemed IT department was upgrading the Outlook Web Services > and hit some problems. Since the complete collapse the other day, all seems > to be working properly again. Nice, thanks for the follow-up. > Sorry for the red herring! No problem.