Answers.Body: <p>I think the best approach would be to file an issue at <a href="https://github.com/zetacomponents/Mail/issues" rel="nofollow noreferrer">https://github.com/zetacomponents/Mail/issues</a>. 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.</p>
  
  <p>CiviCRM does support patching the library and <a href="https://github.com/civicrm/civicrm-core/blob/5.21.2/tools/scripts/composer/patches/civicrm-custom-patches-zetacompoents-mail.patch" rel="nofollow noreferrer">does currently do that</a> for something else, so it could be done on the CiviCRM side, but this one seems more appropriate to do in the library itself.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-05T22:25:33.927Z
Answers.LastActivityDate: 2020-02-05T22:25:33.927Z
Answers.UserDisplayName: Demerit
Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Tags: <civimail><joomla>
Title: IMAP authentication error with Smartermail
ThreadText: # IMAP authentication error with Smartermail
  
  (Asked by: username_0 on 2020-02-05)
  
  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.
  
  **Tags:** civimail, joomla
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-02-05. Score: 1 | Accepted answer
  
  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](https://github.com/civicrm/civicrm-core/blob/5.21.2/tools/scripts/composer/patches/civicrm-custom-patches-zetacompoents-mail.patch) for something else, so it could be done on the CiviCRM side, but this one seems more appropriate to do in the library itself.
  
  
  ---
  
  