Աշխատող վեբ պրոքսին ինքնաշխատ չի կարգավորում IMAP-ը

Զննարկիչն աշխատում է PAC ֆայլի միջոցով։ Փոստային հաճախորդը սակայն չի կարողանում միանալ IMAP-ին։ Հակասություն չկա. զննարկիչն ու փոստային հաճախորդը տարբեր ծառայություններ են խնդրում տարբեր կարգավորման ինտերֆեյսների միջոցով։

IMAP-ը սովորական HTTP հարցում չէ։ Հաճախորդին անհրաժեշտ է ուղի, որը կարող է տեղափոխել նրա փոստային արձանագրությունը, օրինակ՝ աջակցվող HTTP CONNECT թունել կամ SOCKS կապ։ Պրոքսին նույնպես պետք է թույլատրի նպատակակետն ու պորտը։

Ստուգեք փոստային գրադարանի իրական աջակցությունը

Ընթացիկ Angus Mail-ի IMAP մատակարարը փաստագրում է HTTP պրոքսի հոսթը, պորտը և հաշվի հատկությունները, ինչպես նաև SOCKS-ի հետ կապված կարգավորումները։ Օգտագործեք տեղադրված մատակարարի և արձանագրության փաստաթղթերը։ Այն հին խորհուրդը, թե JavaMail-ը երբեք չի կարող օգտագործել HTTP պրոքսի, նկարագրում է հնարավորությունների այլ սահման։

Հավաստի թվացող հատկության անունը բավարար չէ։ Անվտանգ IMAP արձանագրությունը կարող է պահանջել համապատասխան հատկության նախածանցը, իսկ մեկ այլ Java հաճախորդի կողմից օգտագործվող կամայական HTTP պրոքսի հատկություն փոստային մատակարարը պարտադիր չէ, որ կարդա։

PAC հայտնաբերումը այլ գործառույթ է

Զննարկիչի PAC URL-ը կարգավորման տվյալ է, ոչ թե IMAP սերվերի կամ փոխանցող պրոքսի հասցե։ Որոշեք փոստային նպատակակետի աջակցվող պրոքսի ուղին՝ այդ URL-ը փոստային հոսթով փոխարինելու փոխարեն։

Այնուհետև առանձնացրեք հաշիվները։ Պրոքսի հավատարմագրերը լիազորում են միջնորդին, իսկ փոստային հաշիվը լիազորում է մուտքը փոստարկղ։ Վավեր փոստարկղի գաղտնաբառը չի կարող շտկել մերժված CONNECT հարցումը։

Պահեք փոստի TLS ստուգումը միացված աջակցվող թունելի միջոցով։ Եթե լիազորված պրոքսին չի թույլատրում պահանջվող փոստային պորտը, դիմեք հաստատված մուտքի կարգավորման համար։ Պորտի պիտակի կամ պրոքսի սխեմայի փոփոխությունը չի կարող անհամատեղելի կամ մերժված կապը դարձնել թույլատրված։