I've setup ispconfig3 on my debian six server, and here is a little smtp over ssl:

The server is postfix

235 2.7.0 Authentication successful

MAIL FROM: [email protected]
250 2.1.0 Ok
RCPT TO: [email protected]
depth=0 /C=AU/ST=NSW/L=Sydney/O=Self-Signed Key! Procees with caution!/OU=Web Hosting/[email protected]
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=AU/ST=NSW/L=Sydney/O=Self-Signed Key! Procees with caution!/OU=Web Hosting/[email protected]
verify return:1
554 5.5.1 Error: no valid recipients

but, the thing is, if I just do a vanilla telnet over port 25 I can authenticate and send mail like a madman... hopefully this is enough information! (as opposed to 'mail.app can't handle ssl!')

  • Not by a long shot. Provide the output from postconf -n and the relevant part of your mail log (the part containing the entire transaction from beginning to end).
    – adaptr
    Dec 1, 2011 at 12:58
  • Have you tried another RCPT TO: [email protected]?
    – Andy Smith
    Dec 1, 2011 at 12:58
  • possible duplicate of Exim TLS and Secure SMTP
    – jj33
    Dec 1, 2011 at 14:53
  • Ooh, I like the automatic comments when you flag as a dupe, nice touch. It's not super obvious that the questions are duplicates since they're using different MTAs and @lol didn't say that he was using s_client to test, but he is, and they are =)
    – jj33
    Dec 1, 2011 at 14:55
  • really, you're beautiful people. you can have a doctorate in methods in computing but if you simply are not well versed in using programs you still need community help! I <3 stack overflow. In terms of the actual duplicate post - what should I do? (since the tags and the title in no way reflect what is actually going on in the tty) ...?
    – lol
    Dec 1, 2011 at 15:04

2 Answers 2


Pressing "R" in an s_client session causes openssl to renegotiate. Try entering "rcpt to:" instead of "RCPT TO".

You might also try tools that are more suited to SMTP-specific testing, such as Tony Finch's smtpc or swaks.

  • 14
    To be clear, s_client is just wrong here. You were correct in principle for using "RCPT TO". It's completely braindead that a plain text "R", in a tool that's made for typing text into, causes a renegotiate. The fact that you can get around it by using "rcpt to" is just a way to work around the bug/poor implementation decision in s_client.
    – jj33
    Dec 1, 2011 at 15:11
  • 16
    Oh my goodness. OpenSSL, what did you smoke? :'(
    – bot47
    Dec 30, 2014 at 22:36
  • 2
    It’s behavior that could be useful, but on by default? When I saw the message I assumed the renegotiation was caused by the server and there was a bug there. (Sorry for this “me too!” post)
    – binki
    Nov 5, 2015 at 21:50
  • 17
    Another workaround is to use openssl s_client -quiet, which suppresses the interactive interpretation of R and Q characters. Nov 13, 2016 at 5:03
  • 3
    o-m-g saved my day
    – Marki
    Dec 26, 2017 at 14:55

It's a design flaw in openssl. As @jj33 alludes, the R at the beginning of a line causes openssl to renegotiate.

Start openssl s_client with the -quiet option. I use:

openssl s_client -starttls smtp -quiet -connect $HOST:$PORT

Granted, you will not see as much debugging output for the certificate. If it fails to verify the cert, you may need to add that option.

Hat tips:

  • 200_success
  • jj33


I didn't mean to steal your answer, but I thought it better if there is an actual answer which fully explains the work-around, rather than for people to fish in comments.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .