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

AUTH PLAIN for SMTP is not working on all servers #4080

Closed
paresy opened this issue Jun 26, 2019 · 7 comments
Closed

AUTH PLAIN for SMTP is not working on all servers #4080

paresy opened this issue Jun 26, 2019 · 7 comments

Comments

@paresy
Copy link

@paresy paresy commented Jun 26, 2019

I did this

curl smtp://smtp.world4you.com --user "username:password" -v --login-options
 AUTH=PLAIN

Output:

* Rebuilt URL to: smtp://smtp.world4you.com/
*   Trying 81.19.149.200...
* TCP_NODELAY set
* Connected to smtp.world4you.com (81.19.149.200) port 25 (#0)
< 220 mx01lb.world4you.com ESMTP Exim 4.92 Wed, 26 Jun 2019 13:42:29 +0200
> EHLO DESKTOP-E0U2VS3
< 250-mx01lb.world4you.com Hello DESKTOP-E0U2VS3 [212.72.166.112]
< 250-SIZE 157286400
< 250-8BITMIME
< 250-PIPELINING
< 250-AUTH PLAIN LOGIN
< 250-CHUNKING
< 250-STARTTLS
< 250 HELP
> AUTH PLAIN
< 535 Incorrect authentication data
* Closing connection 0
curl: (67) Login denied

I expected the following

> AUTH PLAIN ***base64encoded username/password here***
< 235 Authentication succeeded

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:

> AUTH PLAIN
< 334
> xxxxxxxxxxxxxxxxxxxxxxxx

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

curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

I also tried on the curl 7.64.1 which has the same issue.

Thank you for reading!

@bagder
Copy link
Member

@bagder bagder commented Jun 26, 2019

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:

$ curl smtp://[server] --user foo:bar -v --login-options AUTH=PLAIN
...
< 250-STARTTLS
< 250-DELIVERBY
< 250 HELP
> AUTH PLAIN
< 334 
> AGZvbwBiYXI=

@bagder
Copy link
Member

@bagder bagder commented Dec 15, 2019

Seems nobody wants or can work on this issue. It will be added as a known issue and closed within soon unless something changes.

@captain-caveman2k
Copy link
Member

@captain-caveman2k captain-caveman2k commented Feb 1, 2020

Apologies for the very late response but have you tried using the --sasl-ir option?

@UnknownSourceCode
Copy link

@UnknownSourceCode UnknownSourceCode commented May 5, 2020

Use AUTH LOGIN , AUTH PLAIN ,.AUTH CRM MD5
there Are Many AUTHs For SMTP
https://www.samlogic.net/articles/smtp-commands-reference-auth.htm

@emilengler
Copy link
Contributor

@emilengler emilengler commented May 5, 2020

@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

@jcaron23
Copy link

@jcaron23 jcaron23 commented Jan 14, 2021

It's not a curl bug. Per SMTP AUTH specifications, the server should reply with a 334 if the base64-encoded auth data is not provided directly in the AUTH PLAIN command. But the --sasl-ir option does indeed allow sending the data as an "initial response" direction in the AUTH PLAIN command.

@allgood
Copy link

@allgood allgood commented Dec 13, 2021

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

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

No branches or pull requests

7 participants