I Indy knyter du proxyen til IOHandleren som TIdSMTP brukar. Hald TIdSMTP.Host og Port retta mot e-posttenesta. Proxykomponenten i IOHandleren leverer adressa til mellomleddet og gjer proxy-handtrykket på same tilkopling.

Eigenskapen du brukar, er avhengig av Indy-versjonen: Indy 9 eksponerer SocksInfo; Indy 10 brukar TransparentProxy. Kontroller komponentbiblioteket i programmet i staden for å velje eit døme berre ut frå namnet på Delphi-utgåva.

Indy 10 med SOCKS5

Føreset at skjemaet allereie eig desse komponentane:

  • Smtp: TIdSMTP
  • MailSocket: TIdIOHandlerStack
  • Socks: TIdSocksInfo

Kople dei til og konfigurer dei før du opnar SMTP-tilkoplinga:

Smtp.Host := 'smtp.example.net';
Smtp.Port := 587;
Smtp.IOHandler := MailSocket;

Socks.Host := 'proxy.example.net';
Socks.Port := 1080;
Socks.Version := svSocks5;
MailSocket.TransparentProxy := Socks;

Portverdiane er døme. SMTP-porten må samsvare med tenesta og TLS-modusen du planlegg å bruke. SOCKS-porten høyrer til proxyen.

For ein tillaten offentleg SMTP-test der eit offentleg mellomledd er tillate, tilbyr SOCKS5-proxylista kandidatadresser. Stadfest at kandidaten tillèt den faktiske e-postverten og porten, og bruk greina utan proxyautentisering utan å halde på legitimasjon frå ein tidlegare proxy.

TIdSocksInfo startar med svNoSocks, så det å setje berre eit proxy-vertsnamn aktiverer det ikkje. Vel rett SOCKS-versjon. Viss proxyen krev SOCKS5-brukarnamn/passord-autentisering, konfigurer både autentiseringsmetoden og legitimasjonen:

Socks.Authentication := saUsernamePassword;
Socks.Username := ProxyUser;
Socks.Password := ProxyPassword;

ProxyUser og ProxyPassword representerer verdiar som programmet leverer. Desse eigenskapane autentiserer mot proxyen. Konfigurer SMTP-kontoen og autentiseringsmetoden hans separat i e-postklienten.

Å halde på ein eksisterande TLS-IOHandler

Ein e-postklient som brukar STARTTLS eller implisitt TLS treng SSL-kapabel IOHandler. Ikkje byt ut den komponenten med ein vanleg TIdIOHandlerStack berre for å leggje til proxyen.

I Indy 10 stammar SSL-IOHandler-grunnlaget frå TIdIOHandlerStack og arvar proxy-støtta. For ein eksisterande kompatibel SSL-IOHandler kalla MailTLS blir tilkoplinga:

Smtp.IOHandler := MailTLS;
MailTLS.TransparentProxy := Socks;

Innstillinga UseTLS på SMTP-komponenten vel framleis TLS-modusen til e-posttenesta. Konfigurer sertifikattillit og vertsnamnvalidering i TLS-integreringa for smtp.example.net, ikkje for vertsnamnet til proxyen. Å leggje til ein tunnel etablerer ikkje sertifikatvalidering av seg sjølv.

Bruke ein HTTP CONNECT-proxy i staden

For Indy 10 brukar du ein TIdConnectThroughHttpProxy-komponent, tilgjengeleg frå IdConnectThroughHttpProxy. Føreset at det finst ein eksisterande skjema-eigd instans kalla HttpTunnel:

HttpTunnel.Host := 'proxy.example.net';
HttpTunnel.Port := 8080;
HttpTunnel.Enabled := True;
MailSocket.TransparentProxy := HttpTunnel;

Viss SMTP brukar MailTLS, tildel HttpTunnel til TransparentProxy til den handteraren i staden. E-postmålet blir verande på Smtp.

Denne komponenten etablerer ein HTTP CONNECT-tunnel og implementerer Basic proxyautentisering gjennom eigenskapane Username og Password. Ein proxy som krev ein annan autentiseringsmekanisme, treng ei kompatibel implementering; ikkje gå ut frå at desse to eigenskapane gir alle HTTP-autentiseringsskjema.

Proxyen må også tillate CONNECT til den faktiske porten til e-posttenaren. Løyve til å tunnelere til nettenarar på 443 tyder ikkje løyve til å nå ein innsendarteneste på 587 eller ein SMTP-tenar på 25.

Indy 9-tilkoplinga

Indy 9 brukar ein TIdIOHandlerSocket og eigenskapen SocksInfo. Med skjema-eigde komponentar kalla Socket9 og Socks9 er den tilsvarande kopinga:

Smtp.IOHandler := Socket9;
Socket9.SocksInfo := Socks9;
Socks9.Host := 'proxy.example.net';
Socks9.Port := 1080;
Socks9.Version := svSocks5;

SOCKS-implementeringa hans støttar versjon 4, 4a og 5. Indy 10-oppsettet med TransparentProxy og HTTP CONNECT-komponenten kan ikkje berre limast inn i dette eldre grensesnittet.

Det finst inga separat innleiande proxypålogging å utføre med ein annan TCP-klient. Proxyautentisering, tunneloppsett og SMTP-utveksling må høyre til tilkoplinga som SMTP-komponenten faktisk brukar. Når den kopinga er rett, kan ein feil lokaliserast ved proxyforhandling, SMTP-helsinga, TLS eller e-postautentisering i staden for å handsame kvar avvising som eit dårleg e-postpassord.

Relaterte artiklar