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

1 Answer 1

up vote 1 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
    
+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 Nov 22 at 11:58
    
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 Nov 22 at 12:14

Your Answer

 
discard

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.