Net::SMTP 3.16 не має конструктора з попередньо підключеним SOCKS

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.