الوكيل الشبكي العامل لا يضبط IMAP تلقائيًا

يعمل المتصفح عبر ملف PAC. أما عميل البريد فلا يستطيع الاتصال بـ IMAP. لا يوجد تناقض هنا: فالمتصفح وعميل البريد يطلبان خدمتين مختلفتين عبر واجهتي تهيئة مختلفتين.

IMAP ليس طلب HTTP عاديًا. يحتاج العميل إلى مسار قادر على حمل بروتوكول بريده، مثل نفق HTTP CONNECT مدعوم أو اتصال SOCKS. ويجب أن يسمح الوكيل أيضًا بالوجهة والمنفذ.

تحقق من الدعم الفعلي لمكتبة البريد

يوثّق مزوّد IMAP في Angus Mail الحالي مضيف ومنفذ الوكيل HTTP وخصائص الحساب، إضافة إلى إعدادات SOCKS. استخدم وثائق المزوّد والبروتوكول المثبتين. أما النصيحة القديمة بأن JavaMail لا يمكنه أبدًا استخدام وكيل HTTP فتصف حدًا مختلفًا للقدرات.

لا يكفي اسم خاصية يبدو معقولًا. فقد يتطلب بروتوكول IMAP الآمن بادئة الخاصية المقابلة، كما أن خاصية وكيل HTTP عشوائية يستخدمها عميل Java آخر لا يقرأها مزوّد البريد بالضرورة.

اكتشاف PAC ميزة أخرى

عنوان PAC URL الخاص بالمتصفح بيانات تهيئة، وليس عنوان خادم IMAP أو وكيل إعادة توجيه. حدّد مسار الوكيل المدعوم لوجهة البريد بدلًا من استبدال مضيف البريد بذلك العنوان.

ثم افصل بين الحسابين. فبيانات اعتماد الوكيل تصرّح للوسيط، وحساب البريد يصرّح بالوصول إلى صندوق البريد. وكلمة مرور صحيحة لصندوق البريد لا تستطيع إصلاح طلب CONNECT مرفوض.

أبقِ التحقق من TLS للبريد مفعّلًا عبر النفق المدعوم. وإذا لم يسمح الوكيل المصرّح به بمنفذ البريد المطلوب، فاطلب ترتيب الوصول المعتمد. وتغيير وسم المنفذ أو مخطط الوكيل لا يمكن أن يحوّل اتصالًا غير متوافق أو مرفوضًا إلى اتصال مسموح.