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 најавата.

Поврзани статии