Дайце SMTP-злучэнню Indy проксі IOHandler
Падключыце SOCKS або HTTP CONNECT да TIdSMTP праз уласцівасці IOHandler патрэбнай версіі Indy, з асобнымі наладамі пошты і проксі.
У Indy далучайце проксі да IOHandler, які выкарыстоўвае TIdSMTP. Трымайце TIdSMTP.Host і Port накіраванымі на паштовы сэрвіс. Кампанент проксі ў IOHandler падае адрас пасярэдніка і выконвае рукапоціск проксі на тым самым злучэнні.
Уласцівасць залежыць ад версіі Indy: Indy 9 прапануе SocksInfo; Indy 10 выкарыстоўвае TransparentProxy. Правярайце бібліятэку кампанентаў у праграме, а не выбірайце прыклад толькі па назве выпуску Delphi.
Indy 10 з SOCKS5
Выкажам здагадку, што форма ўжо мае гэтыя кампаненты:
Smtp: TIdSMTPMailSocket: TIdIOHandlerStackSocks: TIdSocksInfo
Злучыце і наладзьце іх перад адкрыццём злучэння SMTP:
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;
Значэнні партоў — прыклады. Порт SMTP мусіць адпавядаць сэрвісу і рэжыму TLS, які вы плануеце. Порт SOCKS належыць проксі.
Для дазволенага публічнага тэсту SMTP, дзе дапускаецца публічны пасярэднік, спіс проксі SOCKS5 прапануе адрасы-кандыдаты. Пераканайцеся, што кандыдат дазваляе фактычны паштовы хост і порт, і выкарыстоўвайце галіну без аўтэнтыфікацыі проксі, не захоўваючы ўліковыя даныя ад папярэдняга проксі.
TIdSocksInfo пачынаецца з svNoSocks, таму адно задзенне імені хоста проксі яго не ўключае. Выберыце адпаведную версію SOCKS. Калі проксі патрабуе аўтэнтыфікацыі SOCKS5 па імені/паролі, наладзьце і метад аўтэнтыфікацыі, і ўліковыя даныя:
Socks.Authentication := saUsernamePassword;
Socks.Username := ProxyUser;
Socks.Password := ProxyPassword;
ProxyUser і ProxyPassword — гэта значэнні, якія падае праграма. Гэтыя ўласцівасці аўтэнтыфікуюцца на проксі. Наладзьце ўліковы запіс SMTP і яго метад аўтэнтыфікацыі асобна ў паштовым кліенце.
Захаванне існуючага TLS IOHandler
Паштоваму кліенту з STARTTLS або непаяўным TLS патрэбны IOHandler з падтрымкай SSL. Не замяняйце гэты кампанент звычайным TIdIOHandlerStack толькі дзеля дадання проксі.
У Indy 10 база SSL IOHandler паходзіць ад TIdIOHandlerStack і ўспадкоўвае яго падтрымку проксі. Для існуючага сумяшчальнага SSL IOHandler з іменем MailTLS злучэнне выглядае так:
Smtp.IOHandler := MailTLS;
MailTLS.TransparentProxy := Socks;
Налада UseTLS кампанента SMTP па-ранейшаму выбірае рэжым TLS паштовага сэрвісу. Давер да сертыфіката і праверку імені хоста наладзьце ў інтэграцыі TLS для smtp.example.net, а не для імені хоста проксі. Даданне тунеля само па сабе не ўстанаўлівае праверку сертыфіката.
Выкарыстанне проксі HTTP CONNECT
Для Indy 10 выкарыстоўвайце кампанент TIdConnectThroughHttpProxy, даступны з IdConnectThroughHttpProxy. Мяркуючы, што ў форме ўжо ёсць экзэмпляр з іменем HttpTunnel:
HttpTunnel.Host := 'proxy.example.net';
HttpTunnel.Port := 8080;
HttpTunnel.Enabled := True;
MailSocket.TransparentProxy := HttpTunnel;
Калі SMTP выкарыстоўвае MailTLS, прызначце HttpTunnel уласцівасці TransparentProxy гэтага апрацоўніка. Мэта пошты застаецца на Smtp.
Гэты кампанент устанаўлівае тунель HTTP CONNECT і рэалізуе базовую аўтэнтыфікацыю проксі праз уласцівасці Username і Password. Проксі, якому патрэбны іншы механізм аўтэнтыфікацыі, патрабуе сумяшчальнай рэалізацыі; не лічыце, што гэтыя дзве ўласцівасці даюць усе схемы аўтэнтыфікацыі HTTP.
Проксі таксама мусіць дазваляць CONNECT на фактычны порт паштовага сервера. Дазвол тунеля да вэб-сервераў на 443 не азначае дазволу да сэрвісу адпраўкі на 587 або SMTP-сервера на 25.
Злучэнне Indy 9
Indy 9 выкарыстоўвае TIdIOHandlerSocket і яго ўласцівасць SocksInfo. З кампанентамі формы з іменамі Socket9 і Socks9 эквівалентнае злучэнне такое:
Smtp.IOHandler := Socket9;
Socket9.SocksInfo := Socks9;
Socks9.Host := 'proxy.example.net';
Socks9.Port := 1080;
Socks9.Version := svSocks5;
Яго рэалізацыя SOCKS падтрымлівае версіі 4, 4a і 5. Схему TransparentProxy і кампанента HTTP CONNECT з Indy 10 нельга проста ўставіць у гэты старэйшы інтэрфейс.
Асобнага папярэдняга ўваходу ў проксі праз іншы TCP-кліент няма. Аўтэнтыфікацыя проксі, усталяванне тунеля і абмен SMTP мусіць належаць злучэнню, якое фактычна выкарыстоўвае кампанент SMTP. Калі гэтае злучэнне слушнае, збой можна лакалізаваць на перамовах проксі, прывітанні SMTP, TLS або аўтэнтыфікацыі пошты, замест таго каб кожную адмову лічыць дрэнным паролем пошты.