Net::SMTP 3.16 har ingen forhåndstilkoblet SOCKS-konstruktør

Net::SMTP 3.16 dokumenterer ikke en SOCKS- eller forhåndstilkoblet socket-konstruktørparameter. Å pakke en filbeskrivelse inn med den arvede new_from_fd kjører ikke SMTP-konstruktøren dens. En vellykket SOCKS-tilkobling gir en strøm, ikke en initialisert e-postøkt.

For vanlig SMTP, inkludert en senere STARTTLS-oppgradering, snakker serveren først:

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

Dette er skjematisk; annonserte utvidelser varierer. Hilsenen kan selv strekke seg over flere linjer: en svarkode etterfulgt av en bindestrek fortsetter svaret, mens den siste linjen avslutter det. Bruk opp hele hilsenen før EHLO. Ellers kan klienten lese en gammel 220 når den forventer EHLOs 250 og komme ut av takt på en sunn tilkobling.

Implisitt TLS har en annen rekkefølge: SOCKS-tilkobling, TLS-håndtrykk, deretter SMTP-hilsen inne i TLS. STARTTLS begynner med den lesbare hilsenen og EHLO, oppgraderer strømmen og henter deretter funksjoner på nytt.

Den offentlige konstruktøren håndterer vanligvis socket-konfigurasjon, lagrede tilkoblingsparametere og hilseninformasjon, den første responsen og EHLO med HELO-fallback der det passer:

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;

Dette offentlige eksempelet bruker STARTTLS og konfigurerer ikke SOCKS. Servernavnet velger e-postmålet; Hello gir klientens SMTP-identitet. For implisitt TLS, bruk det dokumenterte konstruktørvalget SSL og tjenestens port.

SendHello => 0 undertrykker automatisk EHLO/HELO, ikke lesing av hilsenen eller bygging av transporten. Å kalle en linjeleser og deretter hello() er heller ikke en dokumentert erstatning for initialisering: Net::Cmd klassifiserer sine lavnivå-svarlserne som beskyttede underklassemetoder.

Hvis SOCKS er obligatorisk, velg en klient med et støttet SOCKS-grensesnitt eller vedlikehold en integrasjon mot den spesifikke Net::SMTP-versjonen. Bruk rekkefølgen ovenfor som kontrakten i stedet for å kopiere private felt. En separat TCP-adapter trenger også bevisst håndtering av TLS-identitet: sertifikatet må identifisere den ekte e-posttjenesten, og proxy-påloggingsinformasjon holdes atskilt fra SMTP-pålogging.