Copy link to clipboard
Copied
Hello community, We use the CFIMAP tag to connect to a Microsoft Exchange server to retrieve emails. It has been working properly for a couple of years until yesterday when at about 8:40 AM EST we started to get this error from our CFTRY/CATCH block: Logon failure: unknown user name or bad password.
Nothing has been changed from our side. I can still login to the webmail for the account being used and I see all the emails.
We also tried a different account to discard that the account was the issue without success.
After looking online, I believe the issue could be related to something wrong in the handshake. Quoting Charlie Arehart: "TLS (and SSL) is a two-way handshake between the origin and the destination, where each reports what versions it supports and they negotiate to pick one that works for both ends of the conversation."
That's where my troubleshooting takes me but I could be wrong.
Anyone has experienced this before?
Thank you very much!
I'll bet the issue is on Microsoft's side of things - especially if you are using Exchange Online. See here for some details:
Additionally, we have been having to change all of our IMAP calls to using Microsoft Graph API as all basic auth for POP, IMAP, etc. is being deprecated and completely shut off in October of this year. Figuring out oauth2 for IMAP looked to be
...Copy link to clipboard
Copied
Dani, others may have more to say, and more specific suggestions, but first since "nothing changed", do you mean even that cf did not restart today? If it did, something about cf COULD have changed since the previous restart. The cf server.log tracks each startup, as do others (usually with lots more other info).
Note that while cf may not itself have been changed (code or admin config), perhaps the jvm that Cf uses was changed. Look at your cf admin "settings summary" page. What jvm version does it show cd using? There may be more to suggest depending on that.
Copy link to clipboard
Copied
Hello Charlie and thanbk you very much for jumping in.
Since we started with this issue, the server has been restarted a couple of times. However, it hasn't been restarted when this problem started to occur. The email started to act up after 8:40 AM as it was the last email retrieved. No restart happens during the day.
As for the JVM version, the Settings Summary show 11.0.1+13-LTS
Would it be possible that the exchange server provider could've changed something from their end?
Thank you once again Charlie.
Copy link to clipboard
Copied
Yes, they could have. And that's why I was asking first for your jvm version. 11.0.1, is about 4 yrs old. The latest (from this week, in fact, is 11.0.16). Even cf's update feature fails to be able to find and download new updates with such an old jvm.
So yes, the exchange server could have changed any of supported tls algorithms, bit length of certs, and more. Rather than try to discern that, just try updating the jvm that Cf uses. I have a blog post with more on each of the above (which both also point to resources on updating the Java that Cf uses, which is a 5-minute job if done right).
https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/
https://www.carehart.org/blog/2022/7/19/java_updates_Jul_2022
As both note, I can also help ensure it's done, with 15-min minimum remote consulting session, including leaving things so that the jvm switch can be reverted with only second of work.
Let us know if doing that jvm update solves it or not, or if you feel you can't or won't.
Copy link to clipboard
Copied
Thank you very much once again Charlie, I have forwarded your reply to the team in charge of the updates.
Let me get back to you on this.
Copy link to clipboard
Copied
I'll bet the issue is on Microsoft's side of things - especially if you are using Exchange Online. See here for some details:
Additionally, we have been having to change all of our IMAP calls to using Microsoft Graph API as all basic auth for POP, IMAP, etc. is being deprecated and completely shut off in October of this year. Figuring out oauth2 for IMAP looked to be more work than just switching over to their recommended Graph API, so that's what we've been doing.
Copy link to clipboard
Copied
Yep, that's a very real possibility.
Copy link to clipboard
Copied
Yes, I think @Andrew Kretzer's response is the most likely cause of your problem. I was too lazy to write it myself yesterday, but authentication processes change in Exchange Online fairly often. You might also find that IMAP has been disabled entirely, too!
Dave Watts, Eidolon LLC
Copy link to clipboard
Copied
Thank you Dave and Charlie. Working on the changes.
I appreciate all your input. I will update the ticket as soon as we change the configuration for out connection.
Copy link to clipboard
Copied
Andrew thank you very much for this.
I believe it fits perfectly to what is happening.
I'll work on the changes.
Copy link to clipboard
Copied
Andrew, do you have a sample of what you have done when you say "Additionally, we have been having to change all of our IMAP calls to using Microsoft Graph API"?
It would be a huge help.
Thank you in advance!
Copy link to clipboard
Copied
Well, it depends upon what you're doing with it. But here is a pretty straight forward, albeit older, article that should get you started:
https://www.linkedin.com/pulse/reading-o365-emails-from-daemon-process-using-graph-bhattacharya/
Basically, you need to enable the correct permissions on Exchange, then grab an auth token (a straightforward cfhttp call) and then once you have the token, make other cfhttp calls using Microsoft's (very robust) Graph API.
Copy link to clipboard
Copied
Thank you very much once again Andrew.
What we were doing before we couldn't do it anymore was basically retrieving emails for a specific account, reading the email's subject, then retrieving the email's attachments and based on the Subject, deciding where to place them. It was a very straighforward process. We need to replicate this. I've noticed the API has a fileAttachment resource. There's a lot to learn from this API to see if we can actually mimic what we were doing before.
Thanks a lot for your time!
Copy link to clipboard
Copied
We do the same (usually Excel workbooks that then need to be imported into our db). I haven't gotten to fully implmenting the attachement part yet, so hoping it goes well. Hpwever, I do find the overall performance to be much, MUCH snappier than imap.
I'm also seeing that some things (e.g. moving emails from one folder to another) seem to need to be done individually rather than in bulk. There is a "batch" feature, but I saw some documentation that for email, you cannot batch more than 4 emails at a time? So it appears I have my work cut out for me as well!
Copy link to clipboard
Copied
Thank you very much Andrew.
We also move email after the attachment has been retrieved, so yes, we do the same thing.
I'll let you know how the process goes and share my findings!
Copy link to clipboard
Copied
Andrew, I am finding information about retrieving byte data from the attachment, but can't find anything regarding how to download the attachment. Have you found anything about this?
Copy link to clipboard
Copied
I'm not following real closely, but from what I've seen--the reference above to cfhttp, if that's how you're getting the file, do note it has a getasbinary attribute/argument.
That may not be helpful. Again, just offering if it may be.
Copy link to clipboard
Copied
Thank you Charlie!
And I apologize for not getting back sooner, even though I have setup "email me when someone replies", I am not getting anything.
Copy link to clipboard
Copied
Hello Andrew, have you been able to download the Attachments using the Graph API by any chance?