Problems with updated, but long used versions of Evolution

[Dr. John H. Lauterbach]

Please see information below that I sent to the experts on Evolution. On two
installations of Evolution (both the ones for 18.04 and 18.10), addition of a
second IMAP email account, causes Evolution to "lock up". For example, use of
CAMEL_DEBUG=imapx:io evolution give the following when a second IMAP account

[imapx:A] I/O: 'A00103 LOGIN ...'
[imapx:A] I/O: 'A00103 NO [AUTHENTICATIONFAILED] Authentication failed.'

As soon as the second IMAP account is disabled, the problems goes away.

Thank you, John

I set up evolution 3.30.1-1build1 on another PC that I had just upgraded from
Ubuntu 18.04 to 18,10. I added all my email accounts as IMAP and they all ran
fine together just as they do under another popular email program.
The IMAP problem exists with both the evolution on my PC and the evolution on

my

secretary's PC. They have been around for several updates in evolution and

the

underlying Ubuntu OS. Both of them have the same problem when you add second
IMAP account. Since they have different folders and the number of e-mails in
each folder (one folder for each client, and one folder for each vendor or
professional society), I suspect that something in the evolution code is

corrupt

and not the database folders.
Is the following a correct course of action to solve the problem?
1. Back up evolution data files onto a USB hard drive using the Back Up
Evolution Data function.
2. Totally remove evolution from the system.
3. Reinstall evolution and set up all e-mail accounts as IMAP.
4. If they all work together, restore the data files.
If the above steps are the correct ones and I still have problems, what do I

do

next?

Removing and reinstalling Evolution is probably pointless, all the more
so as you say the same problem occurs on two different machines. Linux
isn't Windows. You're just restoring all the Evolution components to
what they were before you removed them. You can also verify the package
installation. On Fedora this would be "rpm -V <package-name>". On
Ubuntu I assume there's something similar. That would check that there
isn't bit-rot in the installed components, but frankly the likelihood
of this manifesting as anything other than a crash is infinitesimal.

Before doing all this however, check the number of concurrent
connections to the mail server, under <account>->Receiving Options. See
if it's different between the machines that work and those that don't.

If all else fails, by all means try recreating the accounts. There may
be some configuration error.

poc