Le navigateur fonctionne via un fichier PAC. Le client de messagerie, lui, ne peut pas se connecter à IMAP. Il n'y a pas de contradiction : le navigateur et le client de messagerie demandent des services différents par des interfaces de configuration différentes.

IMAP n'est pas une simple requête HTTP. Le client a besoin d'une route capable de transporter son protocole de messagerie, par exemple un tunnel HTTP CONNECT pris en charge ou une connexion SOCKS. Le proxy doit aussi autoriser la destination et le port.

Vérifier le support réel de la bibliothèque de messagerie

Le fournisseur IMAP de l'Angus Mail actuel documente l'hôte, le port et les propriétés de compte du proxy HTTP, ainsi que les réglages liés à SOCKS. Utilisez la documentation du fournisseur et du protocole installés. L'ancien conseil selon lequel JavaMail ne peut jamais utiliser de proxy HTTP décrit une autre limite de capacités.

Un nom de propriété plausible ne suffit pas. Le protocole IMAP sécurisé peut exiger le préfixe de propriété correspondant, et une propriété de proxy HTTP arbitraire utilisée par un autre client Java n'est pas forcément lue par le fournisseur de messagerie.

La découverte PAC est une autre fonction

L'URL PAC du navigateur est une donnée de configuration, pas l'adresse d'un serveur IMAP ni d'un proxy de transfert. Déterminez la route de proxy prise en charge pour la destination de messagerie au lieu de remplacer l'hôte de messagerie par cette URL.

Séparez ensuite les comptes. Les identifiants du proxy autorisent l'intermédiaire ; le compte de messagerie autorise l'accès à la boîte. Un mot de passe de boîte valide ne peut pas réparer une requête CONNECT refusée.

Gardez la vérification TLS de la messagerie activée à travers le tunnel pris en charge. Si le proxy autorisé n'autorise pas le port de messagerie requis, demandez l'arrangement d'accès approuvé. Changer le libellé du port ou le schéma du proxy ne peut pas transformer une connexion incompatible ou refusée en connexion autorisée.

Articles similaires