Older e-mail client can't send through stunnel and Gmail SMTP server
I'm using an older e-mail client (Edit: Eudora 7.1.0.9 on Windows) which seems unable to send e-mail through Gmail's SMTP server, even after lowering the security per this article.
So I tried adding stunnel between the e-mail client and Gmail, but it still fails with the same error message telling me to read the article at the following URL:
Here's the stunnel.conf file:
output = stunnel.log
debug = debug
engine = capi
cert = stunnel.pem
options = NO_SSLv2
[gmail-smtp]
client = yes
accept = 127.0.0.1:25
connect = smtp.gmail.com:465Here's the log from stunnel:
2014.09.12 13:29:09 LOG7[6896]: Service [gmail-smtp] accepted (FD=440) from 127.0.0.1:56142
2014.09.12 13:29:09 LOG7[6896]: Creating a new thread
2014.09.12 13:29:09 LOG7[6896]: New thread created
2014.09.12 13:29:09 LOG7[6516]: Service [gmail-smtp] started
2014.09.12 13:29:09 LOG5[6516]: Service [gmail-smtp] accepted connection from 127.0.0.1:56142
2014.09.12 13:29:09 LOG6[6516]: s_connect: connecting 173.194.66.109:465
2014.09.12 13:29:09 LOG7[6516]: s_connect: s_poll_wait 173.194.66.109:465: waiting 10 seconds
2014.09.12 13:29:09 LOG5[6516]: s_connect: connected 173.194.66.109:465
2014.09.12 13:29:09 LOG5[6516]: Service [gmail-smtp] connected remote server from 192.168.0.12:56143
2014.09.12 13:29:09 LOG7[6516]: Remote socket (FD=524) initialized
2014.09.12 13:29:09 LOG6[6516]: SNI: sending servername: smtp.gmail.com
2014.09.12 13:29:09 LOG7[6516]: SSL state (connect): before/connect initialization
2014.09.12 13:29:09 LOG7[6516]: SSL state (connect): SSLv3 write client hello A
2014.09.12 13:29:09 LOG7[6516]: SSL state (connect): SSLv3 read server hello A
2014.09.12 13:29:09 LOG7[6516]: SSL state (connect): SSLv3 read finished A
2014.09.12 13:29:09 LOG7[6516]: SSL state (connect): SSLv3 write change cipher spec A
2014.09.12 13:29:09 LOG7[6516]: SSL state (connect): SSLv3 write finished A
2014.09.12 13:29:09 LOG7[6516]: SSL state (connect): SSLv3 flush data
2014.09.12 13:29:09 LOG7[6516]: 1 items in the session cache
2014.09.12 13:29:09 LOG7[6516]: 4 client connects (SSL_connect())
2014.09.12 13:29:09 LOG7[6516]: 4 client connects that finished
2014.09.12 13:29:09 LOG7[6516]: 0 client renegotiations requested
2014.09.12 13:29:09 LOG7[6516]: 0 server connects (SSL_accept())
2014.09.12 13:29:09 LOG7[6516]: 0 server connects that finished
2014.09.12 13:29:09 LOG7[6516]: 0 server renegotiations requested
2014.09.12 13:29:09 LOG7[6516]: 3 session cache hits
2014.09.12 13:29:09 LOG7[6516]: 0 external session cache hits
2014.09.12 13:29:09 LOG7[6516]: 0 session cache misses
2014.09.12 13:29:09 LOG7[6516]: 0 session cache timeouts
2014.09.12 13:29:09 LOG6[6516]: SSL connected: previous session reused
2014.09.12 13:29:13 LOG6[6516]: SSL socket closed (SSL_read)
2014.09.12 13:29:13 LOG7[6516]: Sent socket write shutdown
2014.09.12 13:29:13 LOG5[6516]: Connection closed: 100 byte(s) sent to SSL, 702 byte(s) sent to socket
2014.09.12 13:29:13 LOG7[6516]: Remote socket (FD=524) closed
2014.09.12 13:29:13 LOG7[6516]: Local socket (FD=440) closed
2014.09.12 13:29:13 LOG7[6516]: Service [gmail-smtp] finished (0 left)
2014.09.12 13:29:13 LOG7[6516]: str_stats: 3 block(s), 4294963962 data byte(s), 150 control byte(s)
2014.09.12 13:29:13 LOG7[6516]: str_stats: 20 byte(s) at ..\src\network.c:413
2014.09.12 13:29:13 LOG7[6516]: str_stats: 20 byte(s) at ..\src\network.c:412
2014.09.12 13:29:13 LOG7[6516]: str_stats: 20 byte(s) at ..\src\network.c:411Any hint from stunnel or SSL experts?
Thank you.
51 Answer
I use a nearly identical stunnel configuration to send email from an older email client to Gmail. It works, but I had to change my email address from to <> because my old email client wasn't sending the address in a format that Gmail accepted. Perhaps you're encountering something similar.
One way to get a packet dump is to use Microsoft Network Monitor.
Using that (or similar packet capture tool), you should be able to compare what Eudora sends to what another (successful) email client sends, then tweak Eudora to send what the other client sends. That's how I solved my similar problem.
