How can I send e-mails via Gmail SMTP via OpenSSL (on Windows)?

0

I know that the SMTP server requires TLS so I'm using OpenSSL (on Windows).

openssl s_client -connect smtp.gmail.com:465 -crlf

Now, I know that I have to encode a string (basically \x00myemail\x00password) that has my account and password using base64. Things work pretty well:

AUTH PLAIN <encodedString>
235 2.7.0 Accepted

The problem is when I try to write my message:

MAIL FROM:<myemail>
250 2.1.0 OK qwertyzxcv.1 - gstmp
RCPT TO:<myemail>
RENEGOTIATING
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
verify error:num=20:unable to get local issuer certificate
verify return:0

The truth is that I don't understand that error message. Do I have to generate some certificate? If so, how do I do it (again, on Windows)?

EDIT[0]: I finally solved the problem. You HAVE to write the command rcpt in lowercase because R makes OpenSSL to renegotiate. But now, I have a new problem. It seems that the SMTP server can't recognize de DATA command:

DATA
502 5.5.1 Unrecognized command qwertyzxcv.1 -gsmtp

user3680

Posted 2013-04-18T21:33:52.930

Reputation: 41

Please post the solution as an actual answer instead of an update to your question. Be detailed and specific. – Ramhound – 2013-04-19T12:09:10.900

@Ramhound I tried to do that but it says that I didn't have enough karma and I had to wait like 8 hours or something like that. – user3680 – 2013-04-19T23:18:49.140

Answers

3

OK, I finally solved my two problems:.

  1. The first problem was about the RENEGOTIATING thing. The solution is to write the commands (or at least the ones that start with R) in lowercase. OpenSSL interprets a uppercase R as a command for renegotiation of the TLS.

  2. The second problem was that the server "didn't recognize the DATA command". This problem is at the very beginning:

    openssl s_client -connect smtp.gmail.com:465 -crlf

All tutorials on the internet say that you should use the -crlf option and it's true, for Linux. If you're using Windows do NOT use that option. That option is, according to the documentation:

this option translated a line feed from the terminal into CR+LF as required by some servers.

I thought that even though Windows uses CR+LF, OpenSSL forced the newline to be LF just to have consistency with the unix implementation. I was wrong. In fact, right now, I don't know what the -crlf option does on Windows. Maybe it translates CR+LF into LF? That would be pretty weird though, given the name of the option.

user3680

Posted 2013-04-18T21:33:52.930

Reputation: 41

+1 Almost spot on.. BUT, re your point 2, what did it for me was doing -crlf and that was on windows. I don't think it makes a difference what your OS is. It'd a question of what the server supports as your quote of documentation suggests. Even in Windows, a command - any command - a unix port of a command e.g. something in gnuwin32 could use just LF, it could produce a file with LF rather than CRLF. No command/program has to use the OS's favorite of CRLF or LF. So my guess is openssl s_client by default uses LF, and can be made to use CRLF. – barlop – 2014-11-22T11:58:08.663

so I think that line means that the -crlf option translates an LF from the openssl s_client program (and that LF will be given whether it's a windows port or *nix port), it translates it into a CRLF. smtp.gmail.com requires CRLF. And i'm on Windows with a cygwin openssl port, connecting to smtp.gmail.com with openssl s_client and it only worked with -crlf. But I got the idea of doing that, from your answer. So now it accepts the DATA command. Spot on with the R too I found that moments before reading your answer, but that's a very important point you make. – barlop – 2014-11-22T12:14:54.293

Asked: 2013-04-18T21:33:52.930

Viewed: 5 294 times

Active: 2018-01-01T06:29:45.523