Cliente de e-mail mais antigo não pode enviar stunnel e servidor SMTP do Gmail

Question

Estou usando um cliente de e-mail antigo (Edit: Eudora 7.1.0.9 no Windows) que parece incapaz de enviar e-mail através do servidor SMTP do Gmail, mesmo depois de diminuir a segurança por este artigo .

Então, tentei adicionar stunnel entre o cliente de e-mail e o Gmail, mas ainda falha com a mesma mensagem de erro que me diz para ler o artigo no seguinte URL: link

Aqui está o arquivo stunnel.conf:

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

Aqui está o log do 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:411

Alguma dica de stunnel ou especialistas em SSL?

Obrigado.

    

Answer 1

Eu uso uma configuração stunnel quase idêntica para enviar e-mails de um cliente de e-mail mais antigo para o Gmail. Funciona, mas tive que alterar meu endereço de e-mail de [email protected] para <[email protected]> porque meu antigo cliente de e-mail não estava enviando o endereço em um formato aceito pelo Gmail. Talvez você esteja encontrando algo semelhante.

Uma maneira de obter um dump de pacote é usar Microsoft Network Monitor .

Usando essa (ou ferramenta de captura de pacote semelhante), você deve ser capaz de comparar o que o Eudora envia a outro cliente de email (bem-sucedido) e, em seguida, ajustar o Eudora para enviar o que o outro cliente envia. Foi assim que resolvi meu problema semelhante.