Open Mirkk opened 1 year ago
Hi @Mirkk,
just a question to work in the right direction: you tested that there is actually a meaningful message somewhere or is this more like "I would like to have better error messages"?
Because in some, if not the most cases, the error returned from the actual mail provider does not give more information. That's why I'm curious.
Regards Johannes
Hallo @hanneshal,
If I apply that small workaround to get "LastError" printed, I get the correct error from the mail provider. In my case, the error was just "Could not select: " and happened in "$IMAPOperation->( 'select', $IMAPFolder, )" so I tough it was an issue with folder selection, and tried various configs without success. Only by getting the error message printed I understood, in my case, that it was a mailbox authorization issue.
https://metacpan.org/pod/Mail::IMAPClient#LastError describes some differences between $@ and LastError, but I did not go into details - I just tried with it and got the correct error message.
Thanks Mirko
Environment
Expected behaviour
Issues in IMAP connections should give meaningful error messages, especially since they are quite difficult to debug with OAUTH2 connections involved.
Actual behaviour
IMAP(S) fetch with OAuth (and probably also with legacy login) gives an empty error message when having issues with IMAP Folder selection (often simply related to a missing OAuth authorization for that mailbox): "Could not select: "
Happens in /Kernel/System/MailAccount/IMAP.pm line #331: $IMAPOperation->( 'select', $IMAPFolder, ) || die "Could not select: $@\n";
Solution: starting from line 287, IMAPOperation should return "LastError" instead of $@ (whose use is deprecated for the IMAP library used) if something goes wrong. You do this already in other places in the code, e.g. line 127.
Current dirty workaround to get the error message:
however, this would need some refactoring.
How to reproduce
Steps to reproduce the behavior:
Additional information
Screenshots