Open RubberChickenParadise opened 2 years ago
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
Author: | RubberChickenParadise |
---|---|
Assignees: | - |
Labels: | `area-System.Net` |
Milestone: | - |
unlikely @RubberChickenParadise. 7.0 is mostly done and I don't think this would qualify for servicing.
@filipnavara any thoughts here?
Triage: We might consider it in future, if there is higher demand (please upvote the top post). As mentioned above, System.Net.Mail is deprecated and other implementations are recommended instead.
@filipnavara any thoughts here?
Honestly, move to MailKit. This would require changing the API surface to express passing the OAuth2 token. If you already need to change a code base to add OAuth2 support and get the access/refresh tokens done right then migrating to MailKit is a small change in comparison.
To further elaborate, neither the Office 365 policy nor the deprecation of System.Net.Mail are new things. The policy about Basic authentication was announced years ago and only delayed due to the COVID pandemy. Similarly, SmtpClient
was deprecated in 2017. So this is nothing new, both of these were known for over 3 years.
I would only consider adding the support if there was some API enhancement to support System.Net.ICredentials/NetworkCredential
for OAuth2 Bearer tokens across the board, including on the non-deprecated System.Net.Http APIs. The classes are not sealed and we previously used to implement it in our app through custom handler registered in System.Net.AuthenticationManager
(on the old HttpWebRequest
APIs). I am not aware on any issue with similar API request though.
We talk about HTTP in the past and I think if we can improve OAuth2
integration we should do it cross the board.
While one can do it with existing primitives it seems very common. Same for any Azure bearers ... if that is any different.
I would probably open separate issue to track the generic effort.
So the question here is why the classes have not been marked with an Obsolete
attribute or add xml documentation to the classes themselves? That might be the right direction for this request then.
So the question here is why the classes have not been marked with an
Obsolete
attribute or add xml documentation to the classes themselves? That might be the right direction for this request then.
It is in the documentation for SmtpClient:
Additionally, platform compatibility analyzer (now folded into analyzer that's running by default) gives the DE0005 warning.
I don't remember the historical reason why Obsolete
attribute was not used. The XML documentation in .NET runtime is added only for newly introduced types. It was not added retro-actively for old code.
There is another ask for Bearer authentication #91867. It may be worth of looking into the credentials @filipnavara
As Microsoft has announced the upcoming change to turn off Basic Authentication for all tenants, are there plans to add OAUTH2 support to System.Net.Mail? (Announcement: https://www.microsoft.com/en-us/microsoft-365/blog/2022/09/01/microsoft-retires-basic-authentication-in-exchange-online/)
While there are work arounds, such as enabling SMTP AUTH and setting a policy to AllowBasicAuthSmtp, not having the framework SMTP client support OAUTH2 presents a large issue to organizations that want to avoid user specific policies, even if they are service accounts. (Disable Basic Auth and SMTP AUTH)
Are there plans to release a patch for .net 6 or include the new functionality to support OAUTH2 in .net 7?