في 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 وطريقة مصادقته بشكل منفصل على عميل البريد.

الإبقاء على IOHandler حالي لـ TLS

يحتاج عميل البريد الذي يستخدم STARTTLS أو TLS الضمني إلى IOHandler القادر على SSL. لا تستبدل ذلك المكوّن بـ TIdIOHandlerStack عادي لمجرد إضافة الوكيل.

في Indy 10، تنحدر قاعدة IOHandler الخاصة بـ SSL من TIdIOHandlerStack وترث دعم الوكيل منها. لـ 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 أو مصادقة البريد بدلاً من اعتبار كل رفض كلمة مرور بريد خاطئة.

مقالات ذات صلة