mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 09:46:00 +03:00
[GH-ISSUE #1127] email cannot get sent: unrecognized challenge #795
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#795
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @joergmschulz on GitHub (Sep 2, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1127
Subject of the issue
I try to setup / send email.
The server seems to be reached, but the log returns:
Your environment
image: bitwardenrs/server-postgresql:latestSteps to reproduce
Expected behaviour
email should be sent
Actual behaviour
error 400
@BlackDex commented on GitHub (Sep 3, 2020):
Could you give some more details on your config without password and username?
So what are the settings you have for email?
@joergmschulz commented on GitHub (Sep 3, 2020):
Things that didn't change the situation:
@BlackDex commented on GitHub (Sep 7, 2020):
@joergmschulz I think you need to change the "smtp_auth_mechanism" to be "Plain" instead of "login", if you really need the "login" mechanism, then i think i also need to have an uppercase L, so "Login".
Please try if that solves your issue.
@joergmschulz commented on GitHub (Sep 7, 2020):
yes, this has been among the things I have tested. Plain, login, Login, plain. But neither worked.
@BlackDex commented on GitHub (Sep 16, 2020):
I made some changes so it now supports multiple authentication mechanisms. You could try to add both plain and login comma separated. It now also have a bit update mail library which could help a bit.
@joergmschulz commented on GitHub (Sep 17, 2020):
Has this change found its way into the docker image or should I build from master?
@BlackDex commented on GitHub (Sep 17, 2020):
@joergmschulz this is in the latest version when using the testing tag
@joergmschulz commented on GitHub (Sep 17, 2020):
have now built from master; the format of the error message improved, but the content is left unchanged.

@BlackDex commented on GitHub (Sep 19, 2020):
@joergmschulz i have checked the code and this error only happens during the following.
So what happens during the LOGIN auth method is the following.
ehlocommand250-XX)250-AUTHfeatures and if a match, it will continue.AUTH LOGIN334 VXNlcm5hbWU6And there is where it goes wrong.
The value right after 334 here is a base64 encoded string which contains
Username:in this case.For some reason the server you connect to responds with something the mail-library doesn't understand.
You could try to do this manually and see what the server returns.
The
334responses are where the library is tripping on and returning the the error you see.To try it your self do the following.
This will start a console where you can type and press enter to send that command.
Enter the following commands right after each other.
And now wait what will return.
It could also be that the Password part is giving the issue, that normally follows after you have entered your username.
Also, checkout one of these two sites for example to help you test it manually:
https://www.ndchost.com/wiki/mail/test-smtp-auth-telnet
http://www.xglobe.com/knowledgebase/mail/test-smtp-authentication-with-telnet/
@joergmschulz commented on GitHub (Sep 19, 2020):
hmmm
doing it manually, it works correctly:
the smtp server can't be the reason as other smtp servers don't work as well.
Do I need to escape special characters in username or password (like @ or ! )?
@BlackDex commented on GitHub (Sep 19, 2020):
Well, the issue is that the first
334parameter starts with an ” and the last one ends with an “.“Username:Password:”Those signs looking like a " are the issue here. They apparently are causing the match to fail.
Maybe it is something you can configure on the mail server?
@joergmschulz commented on GitHub (Sep 19, 2020):
definitely yes, this is configurable on the mail server. In case of exim, it is the stanza
server_prompts = Username:: : Password::that has contained the quote signes for some years now. Always working with all clients. But leaving away the qutes works as well.Thank you very much for the pain to debug this one!
@BlackDex commented on GitHub (Sep 19, 2020):
@joergmschulz your welcome glad it works now :)