Funkcianta reta prokura servilo ne aŭtomate agordas IMAP
IMAP bezonas kongruan retpoŝtan klienton, subtenatan tunelon aŭ SOCKS-vojon, kaj prokuran politikon, kiu permesas la retpoŝtan finan punkton.
La retumilo funkcias per PAC-dosiero. La retpoŝta kliento tamen ne povas konektiĝi al IMAP. Ne estas kontraŭdiro: la retumilo kaj la retpoŝta kliento petas malsamajn servojn per malsamaj agordaj interfacoj.
IMAP ne estas ordinara HTTP-peto. La kliento bezonas vojon kapablan transporti ĝian retpoŝtan protokolon, ekzemple subtenatan HTTP CONNECT-tunelon aŭ SOCKS-konekton. La prokura servilo ankaŭ devas permesi la celon kaj la pordon.
Kontrolu la realan subtenon de la retpoŝta biblioteko
La IMAP-provizanto de la nuna Angus Mail dokumentas gastiganton, pordon kaj kontajn ecojn de la HTTP-prokuro, kune kun SOCKS-rilataj agordoj. Uzu la dokumentaron por la instalita provizanto kaj protokolo. La malnova konsilo, ke JavaMail neniam povas uzi HTTP-prokuron, priskribas alian kapablan limon.
Kredebla nomo de eco ne sufiĉas. La sekura IMAP-protokolo povas postuli la respondan ecan prefikson, kaj arbitran HTTP-prokuran econ uzatan de alia Java-kliento ne nepre legas la retpoŝta provizanto.
PAC-malkovro estas alia funkcio
La PAC-URL de retumilo estas agordaj datumoj, ne la adreso de IMAP-servilo aŭ plusenda prokuro. Determinu la subtenatan prokuran vojon por la retpoŝta celo anstataŭ anstataŭigi la retpoŝtan gastiganton per tiu URL.
Poste apartigu la kontojn. Prokuraj legitimiloj rajtigas la peranton; la retpoŝta konto rajtigas aliron al la poŝtkesto. Valida poŝtkesta pasvorto ne povas ripari rifuzitan CONNECT-peton.
Tenadu la TLS-kontrolon por retpoŝto ŝaltita tra la subtenata tunelo. Se la rajtigita prokuro ne permesas la postulatan retpoŝtan pordon, petu la aprobitan aliraranĝon. Ŝanĝi la pordan etikedon aŭ la prokuran skemon ne povas igi malkongruan aŭ rifuzitan konekton permesita.