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
AUTH PLAIN for SMTP is not working on all servers #4080
Comments
It appears that when issuing that command line, "AUTH PLAIN" is followed by a CRLF and then the base64 encoded blurb comes... @captain-caveman2k might have some clues here? I tried a similar command line against an SMTP server of mine (using curl from git master) and it did this:
|
Seems nobody wants or can work on this issue. It will be added as a known issue and closed within soon unless something changes. |
Apologies for the very late response but have you tried using the --sasl-ir option? |
Use AUTH LOGIN , AUTH PLAIN ,.AUTH CRM MD5 |
@UnknownSourceCode Thanks for your help but your feedback is not helpful. Ignoring a problem doesn't solve it and there are most likely still many users and servers who use AUTH PLAIN so we should not ignore it |
It's not a curl bug. Per SMTP AUTH specifications, the server should reply with a |
Had to deal with this problem today, after investigation had the conclusion that Exim configuration on the mail server was the problem, it is needed to have the line "server_prompts = :" in the definition of AUTH PLAIN authenticator, as suggests the official exim documentation |
I did this
Output:
I expected the following
Further information
AUTH LOGIN works fine.
AUTH PLAIN with GMail works fine aswell.
If you need credentials for the mentioned mail server i can provide some.
Using Telnet and manually sending the commands with AUTH PLAIN works as intended.
Using GMail the following happens:
There seems to be an additional 334 response which the world4you server does not send. Is this allowed behavior by the SMTP specs? Should libcurl be able to handle this scenario?
curl/libcurl version
I also tried on the curl 7.64.1 which has the same issue.
Thank you for reading!
The text was updated successfully, but these errors were encountered: