Donu al la SMTP-konekto de Indy prokuran IOHandler

Konektu SOCKS aŭ HTTP CONNECT al TIdSMTP per la IOHandler-ecoj de la ĝusta Indy-versio, kun apartaj poŝtaj kaj prokuraj agordoj.

En Indy, alkroĉu la prokuron al la IOHandler uzata de TIdSMTP. Tenu TIdSMTP.Host kaj Port direktitaj al la poŝta servo. La prokura komponanto de la IOHandler liveras la adreson de la peranto kaj plenumas la prokuran manpremon sur tiu sama konekto.

La eco, kiun vi uzas, dependas de la Indy-versio: Indy 9 montras SocksInfo; Indy 10 uzas TransparentProxy. Kontrolu la komponentan bibliotekon en la aplikaĵo anstataŭ elekti ekzemplon nur laŭ la nomo de la Delphi-eldono.

Indy 10 kun SOCKS5

Supozu, ke la formularo jam posedas ĉi tiujn komponentojn:

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

Konektu kaj agordu ilin antaŭ ol malfermi la SMTP-konekton:

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;

La pordaj valoroj estas ekzemploj. La SMTP-pordo devas kongrui kun la servo kaj TLS-reĝimo, kiun vi intencas uzi. La SOCKS-pordo apartenas al la prokuro.

Por permesata publika SMTP-testo, kie publika peranto estas permesata, la SOCKS5-prokura listo proponas kandidatajn adresojn. Konfirmu, ke la kandidato permesas la realan poŝtan gastiganton kaj pordon, kaj uzu la branĉon sen prokura aŭtentigo sen reteni legitimilojn de antaŭa prokuro.

TIdSocksInfo komenciĝas per svNoSocks, do simple agordi prokuran gastigantnomon ne aktivigas ĝin. Elektu la taŭgan SOCKS-version. Se la prokuro postulas SOCKS5-uzantnoman/pasvortan aŭtentigon, agordu kaj la aŭtentigan metodon kaj la legitimilojn:

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

ProxyUser kaj ProxyPassword reprezentas valorojn liveritajn de la aplikaĵo. Tiuj ecoj aŭtentigas al la prokuro. Agordu la SMTP-konton kaj ĝian aŭtentigan metodon aparte en la poŝta kliento.

Konservi ekzistantan TLS-IOHandler

Poŝta kliento uzanta STARTTLS aŭ implicitan TLS bezonas sian SSL-kapablan IOHandler. Ne anstataŭigu tiun komponenton per ordinara TIdIOHandlerStack nur por aldoni la prokuron.

En Indy 10 la SSL-IOHandler-bazo devenas de TIdIOHandlerStack kaj heredas ĝian prokuran subtenon. Por ekzistanta kongrua SSL-IOHandler nomata MailTLS, la konekto fariĝas:

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

La agordo UseTLS de la SMTP-komponento ankoraŭ elektas la TLS-reĝimon de la poŝta servo. Agordu atestilan fidadon kaj gastigantnoman validigon en la TLS-integriĝo por smtp.example.net, ne por la prokura gastigantnomo. Aldoni tunelon mem ne starigas atestilan validigon.

Uzi HTTP CONNECT-prokuron anstataŭe

Por Indy 10, uzu komponenton TIdConnectThroughHttpProxy, disponeblan el IdConnectThroughHttpProxy. Supozante ekzistantan formular-posedatan instancon nomatan HttpTunnel:

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

Se SMTP uzas MailTLS, atribuu HttpTunnel al la TransparentProxy de tiu traktilo anstataŭe. La poŝta celo restas sur Smtp.

Ĉi tiu komponento starigas HTTP CONNECT-tunelon kaj realigas bazan prokuran aŭtentigon per siaj ecoj Username kaj Password. Prokuro postulanta alian aŭtentigan mekanismon bezonas kongruan realigon; ne supozu, ke ĉi tiuj du ecoj provizas ĉiujn HTTP-aŭtentigajn skemojn.

La prokuro ankaŭ devas permesi CONNECT al la reala pordo de la poŝta servilo. Permeso tuneli al retserviloj ĉe 443 ne implicas permeson atingi sendoservon ĉe 587 aŭ SMTP-servilon ĉe 25.

La Indy 9-konekto

Indy 9 uzas TIdIOHandlerSocket kaj ĝian econ SocksInfo. Kun formular-posedataj komponentoj nomataj Socket9 kaj Socks9, la ekvivalenta dratado estas:

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

Ĝia SOCKS-realigo subtenas versiojn 4, 4a kaj 5. La aranĝo de TransparentProxy kaj HTTP CONNECT-komponento de Indy 10 ne povas simple esti algluita en ĉi tiun pli malnovan interfacon.

Ne ekzistas aparta prepara prokura ensaluto farota per alia TCP-kliento. Prokura aŭtentigo, tunela starigo kaj SMTP-interŝanĝo devas aparteni al la konekto, kiun la SMTP-komponento efektive uzas. Kiam tiu dratado estas ĝusta, fiasko povas esti lokalizita ĉe prokura intertraktado, la SMTP-saluto, TLS aŭ poŝta aŭtentigo, anstataŭ trakti ĉiun rifuzon kiel malbonan poŝtan pasvorton.

Rilataj artikoloj