დაუკავშირდით ოფისის VPN-ს, გახსენით ფოსტის კლიენტი და ნახეთ, როგორ უარყოფს შემოსულების საქაღალდე განახლებას, მაშინ როცა ვებფოსტა ნორმალურად იტვირთება. ჩვეულებრივი დიაგნოზია, რომ VPN ტრაფიკს ატარებს, მაგრამ ფოსტას ბლოკავს, ან რომ ანგარიშის პაროლი შეიცვალა. ორივე ვარაუდი გამოტოვებს იმ სტრუქტურას, რასაც IMAP კლიენტი აკეთებს. ჰოსტამდე მისვლა, TLS-ის დასრულება, ავთენტიფიკაცია და საფოსტო ყუთის არჩევა ოთხი სხვადასხვა მოვლენაა, და VPN მხოლოდ პირველს ფლობს.

მითი: ერთი კავშირი ნიშნავს ერთ შესვლას

რწმენა ისაა, რომ როგორც კი გვირაბი ადგება და ფოსტის სერვერი პასუხობს, საფოსტო ყუთი პრაქტიკულად ღიაა. ასე არ არის. VPN სერვისამდე გზას იძლევა; ის არ გაგიწევთ შესვლას და არ ირჩევს საქაღალდეს. კლიენტი შეიძლება იდგეს ამ ნაბიჯებიდან მეოთხეზე სრულყოფილად მომუშავე გვირაბით და ვალიდური პაროლით.

სწორედ ამ უფსკრულში ცხოვრობს „VPN-ით IMAP არ მუშაობს“ ანგარიშების უმეტესობა.

IMAP-ის სამი მდგომარეობა და სად იჭერიან კლიენტები

IMAP განსაზღვრავს არაავთენტიფიცირებულ მდგომარეობას, ავთენტიფიცირებულ მდგომარეობას და არჩეულ მდგომარეობას, და ბრძანებები ვალიდურია მხოლოდ იმ მდგომარეობაში, რომელიც მათ უშვებს. კავშირი შეიძლება უკვე ავთენტიფიცირებულადაც დაიწყოს, როცა სერვერი წინასწარ ავთენტიფიკაციას გვთავაზობს, ამიტომ პაროლის მოთხოვნის არარსებობა არაფერს ამტკიცებს. საფოსტო ყუთის არჩევა სესიას ავთენტიფიცირებულიდან არჩეულში გადააქვს, და მხოლოდ მაშინ აქვთ შეტყობინებებზე მოქმედ ბრძანებებს სამიზნე.

კლიენტი, რომელიც წარმატებით ავთენტიფიცირდება და შემდეგ ვერ ირჩევს კონფიგურირებულ საქაღალდეს, სინქრონიზაციის ჩავარდნად გამოჩნდება, მაშინ როცა სერვერი სწორად იქცევა. გადარქმეული საქაღალდეები, პროვაიდერი, რომელიც „შემოსულებს“ სხვანაირად ასახავს, ან უკმარისი წვდომის უფლებები ყველა აქ მთავრდება. სერვერის ტეგირებული NO პასუხი მტკიცებულებაა, და ეს არ არის იგივე პასუხი, რაც უარყოფილი პაროლი.

TLS წინ უსწრებს IMAP საუბარს

პორტ 993-ზე იმპლიციტური TLS-ის დროს TLS ხელის ჩამორთმევა სრულდება IMAP ბრძანების გაგზავნამდე, ამიტომ სერტიფიკატის პრობლემა იწვევს შეცდომას, რომელიც ნდობას ახსენებს და არა ფოსტას. ფოსტის ჰოსტის სახელი სერტიფიკატის წინააღმდეგ უნდა დამოწმდეს ისევე, როგორც ვების ჰოსტის სახელი; გვირაბი, რომელიც ტრაფიკს ინახავს, არასწორ სერტიფიკატს სწორად არ აქცევს.

შეცდომის ტექსტი ჰყოფს შემთხვევებს. კავშირის დროის ამოწურვა ნიშნავს, რომ SYN არასოდეს დასრულებულა. TLS შეცდომა ნიშნავს, რომ TCP კავშირი მუშაობდა, ხელის ჩამორთმევა კი არა. IMAP NO ან BAD პასუხი ნიშნავს, რომ ორივე წარმატებული იყო და პროტოკოლის ფენამ რაღაც უარყო. ჩაწერეთ, რომელი ნახეთ, სანამ რომელიმე პარამეტრს შეცვლით.

ქეშირებული ფოსტა არაფრის მტკიცებულება არ არის

ფოსტის კლიენტი აჩვენებს ადრე ჩამოტვირთულ შეტყობინებებს, მიუხედავად იმისა, შეუძლია თუ არა დღეს სერვერთან მისვლა, ამიტომ ნაჩვენები შემოსულების საქაღალდე მხოლოდ იმას გეუბნებათ, რომ ლოკალური საცავი მუშაობს. ნებისმიერი რეალური ტესტი სერვერის ოპერაციას უნდა აიძულოს: განაახლეთ საქაღალდე, ჩამოტვირთეთ შეტყობინება, რომელიც არასოდეს ჩამოტვირთულა, ან გაგზავნეთ ბრძანება, რომელსაც კლიენტი მხოლოდ საფოსტო ყუთის არჩევის შემდეგ გასცემს.

გამოიყენეთ არადესტრუქციული შემოწმება. ერთი საქაღალდის განახლება და ანგარიშის შეცდომების ჟურნალის წაკითხვა ჯობია ანგარიშის წაშლას და ხელახლა დამატებას, რაც ძირითადად ამტკიცებს, რომ კონფიგურაციის ეკრანი ჯერ კიდევ მუშაობს.

გაგზავნა და ვებფოსტა სხვადასხვა პროტოკოლია

ფოსტის გაგზავნა წარდგენაა, არა IMAP. ის იყენებს ცალკე სერვისს და ჩვეულებრივ ცალკე პორტს საკუთარი TLS რეჟიმითა და საკუთარი ავთენტიფიკაციით, ამიტომ მომუშავე გამავალი ყუთი არ ამტკიცებს, რომ IMAP საფოსტო ყუთი არჩეულია, და გატეხილი გამავალი ყუთი IMAP-ს არ ადანაშაულებს.

ვებფოსტა ისევ სხვაა. მას იმავე VPN-ით შეუძლია წარმატება, რადგან ეს ვებ ფრონტენდის მიმართ HTTPS სესიაა, რაც არაფერს ამბობს დესკტოპის კლიენტის IMAP ჰოსტზე, პორტზე ან TLS რეჟიმზე.

გადაცემისთვის ჩაწერეთ ოთხი შედეგი ცალ-ცალკე: VPN გზა, ფოსტის ბოლო წერტილისა და TLS-ის შედეგი, ანგარიშის ავთენტიფიკაციის შედეგი და საფოსტო ყუთის არჩევის შედეგი. შეინახეთ სერტიფიკატები და შეტყობინებების შიგთავსი ჩანაწერის გარეთ. ეს ჩანაწერი შემდეგ ადამიანს ეუბნება, გასწორება ქსელს, სერტიფიკატს, ანგარიშს თუ საქაღალდეების კონფიგურაციას ეკუთვნის, დაცვის არც ერთი ფენის შესუსტების გარეშე.

დაკავშირებული სტატიები