Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(transport-smtp): Support to SASL draft login challenge #911

Merged
merged 3 commits into from Feb 14, 2024

Conversation

dungmuht
Copy link
Contributor

@dungmuht dungmuht commented Oct 25, 2023

In https://www.ietf.org/archive/id/draft-murchison-sasl-login-00.txt,

base64 encoded "User Name" is "VXNlciBOYW1lAA==",
and "Password" is "UGFzc3dvcmQA".

But using the base64 crate (or any other base64 converter),
"User Name" is "VXNlciBOYW1l",
and "Password" is "UGFzc3dvcmQ=".

This means "VXNlciBOYW1lAA==" and "UGFzc3dvcmQA" is not accepted by lettre-based programs.
I think something is wrong with the sasl draft document, but many programs already follow this standard.
So I added the code to accept these Strings.

Edited:
Currently, the lettre library does not support "User Name\0" and "Password\0" as described in the ietf draft, and this can cause compatibility issues with projects like stalwart mail that follow the ietf draft. Therefore, I would like to address the compatibility issue with this request.

@amousset amousset self-requested a review February 14, 2024 20:05
Hodu Mayo added 3 commits February 14, 2024 21:07
In https://www.ietf.org/archive/id/draft-murchison-sasl-login-00.txt, base64 encoded "User Name" is "VXNlciBOYW1lAA==", and "Password" is "UGFzc3dvcmQA".
But using the base64 crate (or any other base64 converter), "User Name" is "VXNlciBOYW1l" and "Password" is "UGFzc3dvcmQ=".
This means VXNlciBOYW1lAA== and UGFzc3dvcmQA is not accepted by lettre-based programs.
So I added the source to accept these Strings.
@amousset
Copy link
Member

We should actually totally ignore the challenge content and just rely on challenge order:

The client expects the server to issue a challenge. The client then
responds with the authorization identity. The client then expects
the server to issue a second challenge. The client then responds
with the authorization authenticator. The contents of both
challenges SHOULD be ignored.

But it requires architecture changes, let's merge this already.

@amousset amousset merged commit 1196e33 into lettre:master Feb 14, 2024
6 checks passed
@amousset
Copy link
Member

Thanks @hodumayo, and sorry for the late review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants