Net::SMTP 3.16 non documenta ningún parámetro de construtor SOCKS nin de socket preconectado. Envolver un descritor de ficheiro co new_from_fd herdado non executa o seu construtor SMTP. Unha conexión SOCKS correcta fornece un fluxo, non unha sesión de correo inicializada.

Para SMTP simple, incluída unha actualización STARTTLS posterior, o servidor fala primeiro:

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 ...

Isto é esquemático; as extensións anunciadas varían. O saúdo pode abranguer varias liñas: un código de resposta seguido dun guión continúa a resposta, mentres que a súa liña final a remata. Consome todo o saúdo antes de EHLO. Se non, o cliente pode ler un 220 antigo cando espera o 250 de EHLO e perder o compás nunha conexión san.

O TLS implícito ten outra orde: conexión SOCKS, aperta de mans TLS e despois saúdo SMTP dentro de TLS. STARTTLS comeza co saúdo lexible e EHLO, actualiza o fluxo e obtén de novo as capacidades despois.

O construtor público normalmente xestiona a configuración do socket, os parámetros de conexión gardados e a información do saúdo, a resposta inicial e EHLO con retroceso a HELO cando cómpre:

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;

Este exemplo público usa STARTTLS e non configura SOCKS. O nome do servidor selecciona o destino do correo; Hello fornece a identidade SMTP do cliente. Para TLS implícito, use a opción de construtor SSL documentada e o porto do servizo.

SendHello => 0 suprime o EHLO/HELO automático, non a lectura do saúdo nin a construción do transporte. Chamar un lector de liñas e despois hello() tampouco é un substituto documentado da inicialización: Net::Cmd clasifica os seus lectores de resposta de baixo nivel como métodos protexidos de subclase.

Se SOCKS é obrigatorio, elixa un cliente cunha interface SOCKS admitida ou manteña unha integración contra a versión concreta de Net::SMTP. Use a secuencia anterior como o seu contrato en lugar de copiar campos privados. Un adaptador TCP separado tamén necesita un tratamento deliberado da identidade TLS: o certificado debe identificar o servizo de correo real, e as credenciais do proxy permanecen separadas do inicio de sesión SMTP.

Artigos relacionados