So, I've spent the last few days running this issue down, and I actually have a solution (or a workaround?), but I just wanted to ask if it's really the best way to handle the situation.

I'm running CiviCRM 5.21.0 on Joomla 3.9.15 and was looking at bounce processing and the Fuzion Transactional Email extension. I was setting up an IMAP account to handle the bounces, but every time I ran the fetch_bounces scheduled job, it would come back with "The IMAP server did not accept the username and/or password". Well, I know the username and password are correct.

Long story short(er), my mail server (I host in-house), Smartermail 14.7, does the same thing that GMail does - instead of an immediate "OK LOGIN completed" response, it gives the "* CAPABILITY" line first.

I couldn't find anywhere in the code where it might dynamically figure out that the server is a gmail server, so I just changed the $serverType on line 331 of /administrator/components/com_civicrm/vendor/zetacomponents/mail/src/transports/imap/imap_transport.php from null to self::SERVER_GIMAP, and now the authentication error is gone.

Is this the best way to do this, or is there a better way? I'm guessing that any time I update CiviCRM, I'm going to have to re-do this change.

1 Answer 1


I think the best approach would be to file an issue at https://github.com/zetacomponents/Mail/issues. It should be addressed in the mail library. There's a comment in the code near that line you changed where they have foreseen that there's this possible todo for other servers.

CiviCRM does support patching the library and does currently do that for something else, so it could be done on the CiviCRM side, but this one seems more appropriate to do in the library itself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.