Indy-ში მიამაგრეთ პროქსი იმ IOHandler-ს, რომელსაც TIdSMTP იყენებს. TIdSMTP.Host და Port ფოსტის სერვისისკენ დატოვეთ. IOHandler-ის პროქსი კომპონენტი შუამავლის მისამართს აწვდის და პროქსის ხელის ჩამორთმევას იმავე კავშირზე ასრულებს.

გამოსაყენებელი თვისება Indy-ის ვერსიაზეა დამოკიდებული: Indy 9 გვაძლევს SocksInfo-ს; Indy 10 იყენებს TransparentProxy-ს. შეამოწმეთ აპლიკაციის კომპონენტების ბიბლიოთეკა და ნუ აირჩევთ მაგალითს მხოლოდ Delphi-ს გამოშვების სახელის მიხედვით.

Indy 10 SOCKS5-ით

დავუშვათ, ფორმას უკვე აქვს ეს კომპონენტები:

  • Smtp: TIdSMTP
  • MailSocket: TIdIOHandlerStack
  • Socks: 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-ს გამოყენებულ ფოსტის კლიენტს სჭირდება SSL-უნარიანი IOHandler. ნუ ჩაანაცვლებთ ამ კომპონენტს ჩვეულებრივი TIdIOHandlerStack-ით მხოლოდ პროქსის დასამატებლად.

Indy 10-ში SSL IOHandler-ის საფუძველი TIdIOHandlerStack-იდან მომდინარეობს და მის პროქსის მხარდაჭერას მემკვიდრეობით იღებს. MailTLS სახელის არსებული თავსებადი SSL IOHandler-ისთვის კავშირი ასეთი ხდება:

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

SMTP კომპონენტის UseTLS პარამეტრი კვლავ ირჩევს ფოსტის სერვისის TLS რეჟიმს. სერტიფიკატის ნდობა და ჰოსტის სახელის ვალიდაცია დააკონფიგურეთ smtp.example.net-ის TLS ინტეგრაციაში, და არა პროქსის ჰოსტის სახელისთვის. გვირაბის დამატება თავისთავად არ ამყარებს სერტიფიკატის ვალიდაციას.

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-ზე გაგზავნის სერვისთან ან 25-ზე SMTP სერვერთან მისვლის ნებართვას.

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 ვერსიებს. Indy 10-ის TransparentProxy და HTTP CONNECT კომპონენტის განლაგება ამ ძველ ინტერფეისში პირდაპირ ვერ ჩაისმება.

ცალკე წინასწარი პროქსი შესვლა, რომელიც სხვა TCP კლიენტით უნდა შესრულდეს, არ არსებობს. პროქსის ავტორიზაცია, გვირაბის დაყენება და SMTP გაცვლა უნდა ეკუთვნოდეს იმ კავშირს, რომელსაც SMTP კომპონენტი რეალურად იყენებს. როცა ეს შეერთება სწორია, ხარვეზი შეიძლება ლოკალიზდეს პროქსის მოლაპარაკებაში, SMTP მისალმებაში, TLS-ში ან ფოსტის ავტორიზაციაში, და არა ყოველი უარი ცუდ ფოსტის პაროლად ჩაითვალოს.

დაკავშირებული სტატიები