The new method is OAuth2.0, which is not supported by the email node yet. I'd like to make this a feature request / pull request.
I assume many flows make use of the email node, and a decent portion of them will use Office365. Eventually SMTP will be under the hammer too, so updating this node to accommodate all of these protocols seems like a logical step.
The updated nodes would allow OAuth/XOauth2 tokens as a form of authentication for IMAP, POP and SMTP. Looking purely at the documentation for the likes of IMAP, OAuth tokens can already be passed as arguments in the constructor, but this functionality isn't exposed in the email node just yet. So I believe this would require minimal changes.
The process of acquiring tokens would be done by nodes upstream (such as node-red-contrib-oauth2).
For full disclosure I am not a full time developer, but rather focus on integration of services within my industry. So while I can create a branch and update some UI elements, my abilities are sorely lacking beyond that. But I'm happy to try!
So far have IMAP to MS Exchange working using XOauth2 by pulling the access token from "node-red-contrib-oauth2". Working on POP and SMTP soon after clearing some error messages.
I'm also doing the formatting and base64 encoding internally, but this format only works for the likes of Exchange and GMail. I'll add an option to pass the SASL token instead allowing users to do their own formatting if they want to.
Since basic authentication for SMTP is still supported for now, I had this further down the list - but this is awesome! Most clients I use won't end up supporting modern authentication for a long time, so this is absolutely perfect for me.
My goal is still to update the email node to use continue using these old protocols in a modern way (for however long they stick around for). Ideally flows could be created doing exactly what you've done, but hopefully with far less work
But perhaps you're right, maybe these standards will disappear and we'll all just be using APIs for emails in future. If we're still using emails at all.
PR is here. But I do have some problems, and I would welcome the criticism of those more experienced than I to resolve them.
The changes that I have made have been tested against Microsoft Exchange using XOAUTH2 for IMAP and POP. I have also tested against Gmail using passwords for IMAP, POP and SMTP. But I have not been able to try out XOAUTH2 on Gmail, or on SMTP at all. This is mainly because I haven't been able to use the OAuth2 node with Gmail at this stage, since it doesn't support the "Client Credentials" grant type. Perhaps someone else has had some experience with this using "Authorization code"?
I found that the unit tests for email out began failing after I added additional error messages if the username and password were not present. However the tests conducted did specify credentials - but still produced "nouserid" messages. The reason is that the testCredentials parameter (when passed as a function) is turned into Call Back function - so credentials are assigned after the flow is loaded, at which point the node has already thrown errors indicating a lack-therof. The original tests now pass because it looks for its expected error further down the list. Not my favorite solution.
If there are additional steps I need to take to make this work for everyone, I'm still happy to try. I encourage all opinions on operation and usability.
)