Net::SMTP 3.16 не документира параметър на конструктора за SOCKS или предварително свързан сокет. Обвиването на файлов дескриптор с наследения new_from_fd не стартира неговия SMTP конструктор. Успешна SOCKS връзка дава поток, а не инициализирана пощенска сесия.

За обикновен SMTP, включително по-късно надграждане със STARTTLS, сървърът говори пръв:

SOCKS: connection to smtp.example.net:587 succeeds

server: 220 smtp.example.net ready
client: EHLO client.example.net
server: 250-smtp.example.net
server: 250-STARTTLS
server: 250 AUTH ...

Това е схематично; обявените разширения варират. Поздравът сам може да обхваща няколко реда: код за отговор, последван от тире, продължава отговора, а последният му ред го завършва. Изчерпайте целия поздрав преди EHLO. Иначе клиентът може да прочете стар 220, когато очаква 250 от EHLO, и да излезе от синхрон при здрава връзка.

При имплицитния TLS редът е друг: SOCKS връзка, TLS ръкостискане, после SMTP поздрав в TLS. STARTTLS започва с четимия поздрав и EHLO, надгражда потока и след това отново получава възможности.

Публичният конструктор обикновено се грижи за конфигурацията на сокета, запазените параметри на връзката и информацията за поздрава, първоначалния отговор и EHLO с резервен HELO, където е уместно:

use Net::SMTP;

my $smtp = Net::SMTP->new(
    'smtp.example.net',
    Port    => 587,
    Hello   => 'client.example.net',
    Timeout => 30,
) or die "SMTP connection failed: $@";

$smtp->starttls()
    or die "STARTTLS failed: " . $smtp->message;

Този публичен пример използва STARTTLS и не конфигурира SOCKS. Името на сървъра избира пощенската дестинация; Hello дава SMTP идентичността на клиента. За имплицитен TLS използвайте документираната опция на конструктора SSL и порта на услугата.

SendHello => 0 потиска автоматичния EHLO/HELO, а не четенето на поздрава или изграждането на транспорта. Извикването на четец на редове и след това hello() също не е документирана замяна на инициализацията: Net::Cmd класифицира своите низкоравнищеви четеци на отговори като защитени методи на подклас.

Ако SOCKS е задължителен, изберете клиент с поддържан SOCKS интерфейс или поддържайте интеграция за конкретната версия на Net::SMTP. Използвайте последователността по-горе като неин договор, вместо да копирате частни полета. Отделен TCP адаптер също се нуждае от съзнателно управление на TLS идентичността: сертификатът трябва да идентифицира истинската пощенска услуга, а прокси данните за достъп остават отделни от SMTP входа.

Подобни статии