Робочий веб-проксі не налаштовує IMAP автоматично
IMAP потребує сумісного поштового клієнта, підтримуваного тунелю або маршруту SOCKS і політики проксі, яка дозволяє поштову кінцеву точку.
Браузер працює через PAC-файл. Поштовий клієнт натомість не може підключитися до IMAP. Тут немає суперечності: браузер і поштовий клієнт запитують різні служби через різні інтерфейси налаштування.
IMAP — це не звичайний HTTP-запит. Клієнту потрібен маршрут, здатний передавати його поштовий протокол, наприклад підтримуваний тунель HTTP CONNECT або з'єднання SOCKS. Проксі також має дозволяти призначення і порт.
Перевірте фактичну підтримку поштової бібліотеки
Поштовий провайдер IMAP у поточному Angus Mail документує хост, порт і властивості облікового запису HTTP-проксі, а також параметри, пов'язані з SOCKS. Використовуйте документацію для встановленого провайдера й протоколу. Стара порада, що JavaMail ніколи не може використовувати HTTP-проксі, описує іншу межу можливостей.
Правдоподібна назва властивості не є достатньою. Захищений протокол IMAP може вимагати відповідного префікса властивості, а довільну властивість HTTP-проксі, яку використовує інший клієнт Java, поштовий провайдер не обов'язково читає.
Виявлення PAC — інша функція
PAC URL браузера — це дані конфігурації, а не адреса сервера IMAP чи пересилального проксі. Визначте підтримуваний маршрут проксі для поштового призначення замість того, щоб підставляти цей URL замість поштового хоста.
Потім розділіть облікові записи. Облікові дані проксі уповноважують посередника; поштовий обліковий запис уповноважує доступ до поштової скриньки. Правильний пароль скриньки не може виправити відхилений запит CONNECT.
Тримайте перевірку TLS для пошти ввімкненою через підтримуваний тунель. Якщо дозволений проксі не пропускає потрібний поштовий порт, запросіть погоджений порядок доступу. Зміна позначки порту або схеми проксі не може перетворити несумісне чи відхилене з'єднання на дозволене.