Старый почтовый клиент не может отправлять сообщения через stunnel и GTP SMTP-сервер

Question

Я использую старый почтовый клиент (Edit: Eudora 7.1.0.9 в Windows), который, похоже, не может отправлять электронную почту через SMTP-сервер Gmail, даже после снижения уровня безопасности в соответствии с этой статьей.

Поэтому я попытался добавить stunnel между почтовым клиентом и Gmail, но все равно не получается с тем же сообщением об ошибке, в котором предлагается прочитать статью по следующему адресу:https://support.google.com/mail/answer/14257.

Вот файл 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

Вот лог от 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

Любой намек от экспертов Stunnel или SSL?

Спасибо.

Answer 1

Я использую почти идентичную конфигурацию Stunnel для отправки электронной почты из старого почтового клиента в Gmail. Это работает, но мне пришлось изменить свой адрес электронной почты с foo@domain.com на <foo@domain.com> потому что мой старый почтовый клиент не отправлял адрес в формате, принятом Gmail. Возможно, вы сталкиваетесь с чем-то похожим.

Один из способов получить дамп пакета - использовать Microsoft Network Monitor.

Используя это (или аналогичное средство захвата пакетов), вы сможете сравнить то, что отправляет Eudora, с тем, что отправляет другой (успешный) почтовый клиент, а затем настроить Eudora, чтобы отправить то, что отправляет другой клиент. Вот так я решил свою похожую проблему.