Net::SMTP 3.16 não documenta nenhum parâmetro de construtor SOCKS ou de socket pré-conectado. Envolver um descritor de arquivo com o new_from_fd herdado não executa seu construtor SMTP. Uma conexão SOCKS bem-sucedida fornece um fluxo, não uma sessão de correio inicializada.

Para SMTP simples, incluindo uma atualização 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 extensões anunciadas variam. A saudação pode abranger várias linhas: um código de resposta seguido de hífen continua a resposta, enquanto sua linha final a encerra. Consuma a saudação inteira antes do EHLO. Caso contrário, o cliente pode ler um 220 antigo quando espera o 250 do EHLO e perder o compasso numa conexão saudável.

O TLS implícito tem outra ordem: conexão SOCKS, handshake TLS e depois saudação SMTP dentro do TLS. O STARTTLS começa com a saudação legível e o EHLO, atualiza o fluxo e obtém as capacidades novamente depois.

O construtor público normalmente trata da configuração do socket, dos parâmetros de conexão guardados e das informações de saudação, da resposta inicial e do EHLO com recuo para HELO quando apropriado:

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 não configura SOCKS. O nome do servidor seleciona o destino do correio; Hello fornece a identidade SMTP do cliente. Para TLS implícito, use a opção de construtor SSL documentada e a porta do serviço.

SendHello => 0 suprime o EHLO/HELO automático, não a leitura da saudação nem a construção do transporte. Chamar um leitor de linhas e depois hello() também não é um substituto documentado da inicialização: o Net::Cmd classifica seus leitores de resposta de baixo nível como métodos protegidos de subclasse.

Se SOCKS for obrigatório, escolha um cliente com interface SOCKS suportada ou mantenha uma integração para a versão específica do Net::SMTP. Use a sequência acima como contrato em vez de copiar campos privados. Um adaptador TCP separado também exige tratamento deliberado da identidade TLS: o certificado deve identificar o serviço de correio real, e as credenciais do proxy permanecem separadas do login SMTP.

Artigos relacionados