feat(transport-smtp): switch to rsasl for SASL support #813
Conversation
|
I think it could make sense to add a dependency for SASL handling, it is not lettre's core business and being able to share the implementation with other projects would probably be a good thing (both is terms of reliability and mechanism choice). |
This was my original motive when developing rsasl too. Too many crates implement SASL by hand, hitting, having to debug, and finally working around the same annoying edgecases that come with it. All of the API that is immediately relevant to lettre is pretty much set in stone in rsasl, so time spent now designing with the current preview version is not going to go to waste. |
|
maybe sspi = "0.4.0" is better than rsasl， it has no enviroment dependence for building， and supports linux、mac、windows； I have done some work for this， but only support exchange 2007， and the higher version will be authen failed. |
|
Can rsasl be build for any platform？I found it depend on gsasl-sys. If rsasl has no building enviroment dependence， it will be nice. I haven't used rsasl, and not sure for this. Thanks. |
|
Can rsasl be build for any platform？I found it depend on gsasl-sys. If rsasl has no building dependence， it will be nice. Thanks.
All versions of rsasl can be built and have been tested for all major architectures and operating systems. The major version two of rsasl additionally has no obligatory dependencies other than `thiserror`.
|
a1ec14b to
5891a32
Compare
|
So, let's talk code ^^ The first question is of course, how do we want to handle the old methods Right now I simply removed them; IMO ripping the band-aid off and making this a major release (i.e.
|
This way support for additional SASL mechanisms can easily be added without any involvement of the lettre crate itself. Update 2022-09-10: Switched to -rc channel of rsasl, fixed compilation issues and tests/examples not running.
|
Thanks for keeping up with this PR. I'm about to release 0.10.3 so that the master branch can then be used for 0.11 development and we don't have to worry about breaking changes |
What's this?
In short, it removes all SASL handling from lettre itself, instead using rsasl for it.
Wait, Why?
I've been porting rsasl to pure Rust because a work project needs to handle SASL and we want to minimize our C dependencies.
After getting most of the public API of rsasl 2.0.0 figured out I'm now at the stage where I'm testing said API with different use-cases to make sure it's actually usable for its intended purpose. This code is basically the part of the testing I did with lettre.
It's not even close to being mergeable; it changes lettre's public API, this functionality needs the hell documented out of it and rsasl 2.0.0 isn't yet stable because I'm still doing this sort of interop testing. The main reason for this PR to exist at all is to get the discussion started if lettre is interested in this kind of addition, and if so, develop this code further. So this is really more of a feature request issue but with some code attached :P
That being said the code should be pretty faithful to the behaviour of the original code, with the exception of
XOAUTH2support, becauseSASLConfig::with_credentialsdoesn't yet handle it.Why would we want this?
The main benefit of rsasl is downstream users being able add support for any mechanism without having to involve the protocol crates. This completely sidesteps issues like #794 and #719, because adding support for additional SASL mechanisms does not involve the lettre crate itself at all anymore.
Also, rsasl provides SCRAM-SHA-1 and SCRAM-SHA-256 (without -PLUS) so you'd already get those for free ;)
What's the catch?
Well, it does add a dependency.
Buuuut … I specifically designed rsasl to be lean and mean when used by a protocol library so you pay a whopping 2.2 KiB in additional code size, or about 0.4% more. And most of that are the strings of the
fmt::Debugandfmt::Displayimplementations.