Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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>
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:

502 5.5.1 Unrecognized command qwertyzxcv.1 -gsmtp
share|improve this question
Please post the solution as an actual answer instead of an update to your question. Be detailed and specific. –  Ramhound Apr 19 '13 at 12:09
@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 Apr 19 '13 at 23:18
add comment

1 Answer

up vote 0 down vote accepted

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.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.