IMAP, POP3 თუ JMAP: ფოსტაზე წვდომის პროტოკოლების შედარება

გამოიყენე IMAP. ის ფოსტას სერვერზე ინახავს და ყველა მოწყობილობაზე სინქრონიზებულს ტოვებს, მას ყველა საფოსტო კლიენტი უჭერს მხარს, და 993 პორტზე ის პირველივე ბაიტიდან დაშიფრულია. JMAP თანამედროვე შემცვლელია - JSON HTTPS-ზე, ეფექტური სინქრონიზაცია, ნამდვილი push - და ის შესანიშნავია იქ, სადაც კლიენტი მას უჭერს მხარს, მაგრამ ძირითადი კლიენტების უმეტესობა ჯერ კიდევ არ უჭერს. POP3 ფოსტას ერთ მოწყობილობაზე ჩამოტვირთავს და მისი ჩართვა მხოლოდ კონკრეტული ძველი მოწყობილობისთვის ღირს, რომელიც სხვას ვერაფერს ახერხებს. შენს საკუთარ სერვერზე ეს ნიშნავს: ჩართე IMAPS 993-ზე და submission პორტი გასაგზავნად, დაამატე JMAP HTTPS-ზე, თუ გაქვს კლიენტები, რომლებიც მას იყენებენ, ხოლო POP3 და დაუშიფრავი პორტები გამორთული დატოვე.

ამ პროტოკოლებიდან არცერთი ფოსტას არ აგზავნის. გაგზავნა ყოველთვის SMTP submission-ია 587 ან 465 პორტზე - გარდა JMAP-ისა, რომელიც გაგზავნას იმავე API-ში აერთიანებს. ეს განსხვავება ხალხს კლიენტების მორგებისას აბნევს, ამიტომ ქვემოთ კიდევ შევეხებით.

სამი პროტოკოლი ერთი შეხედვით#

POP3: ჩამოტვირთვა და (ჩვეულებრივ) წაშლა#

POP3 - Post Office Protocol version 3 - სერვერს დროებით საცავად ეპყრობა. კლიენტი უკავშირდება, ჩამოთვლის მომლოდინე წერილებს, ჩამოტვირთავს მათ და ნაგულისხმევად სერვერიდან შლის. ამის შემდეგ ფოსტა ამ ერთ მოწყობილობაზე ცხოვრობს.

+OK POP3 readyUSER anna@example.com+OKPASS ********+OK 3 messagesRETR 1+OK message follows...DELE 1+OKQUIT

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

კლიენტები გთავაზობენ "ასლის სერვერზე დატოვებას", რაც ცოტას შველის. ისინი UIDL-ით (უნიკალური ID-ები) აკონტროლებენ, რომელი წერილები უკვე ჩამოტვირთეს, ასე რომ ორ მოწყობილობას ორივეს შეუძლია ყველაფრის ჩამოტვირთვა. მაგრამ წაკითხვის სტატუსი, წაშლები და საქაღალდეები მაინც არ სინქრონიზდება, ხოლო სერვერზე საფოსტო ყუთები უსასრულოდ იზრდება, თუ ერთ-ერთი კლიენტი გარკვეული დღეების შემდეგ წაშლაზე არ არის დაყენებული.

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

IMAP: სიმართლე სერვერზეა#

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

რა ამუშავებს IMAP-ს პრაქტიკაში:

• საქაღალდეები და დროშები სერვერზე. წაკითხული, პასუხგაცემული, მონიშნული, წაშლილი და საკუთარი საკვანძო სიტყვები - ყველაფერი თითოეული წერილისთვის ინახება.
• ნაწილობრივი წამოღება. კლიენტს შეუძლია ჯერ header-ები და სტრუქტურა ჩამოტვირთოს, ხოლო body ან ცალკეული მიმაგრებული ფაილი - მხოლოდ გახსნისას. სწორედ ეს ხდის დიდ საფოსტო ყუთებს ტელეფონზე გამოსაყენებელს.
• ძებნა სერვერის მხარეს. SEARCH სერვერზე სრულდება, ასე რომ კლიენტს შეუძლია 10 GB-იან საფოსტო ყუთში წერილი იპოვოს მისი ჩამოტვირთვის გარეშე.
• IDLE (RFC 2177). კლიენტი სერვერს ეუბნება "ცვლილებების შესახებ შემატყობინე" და კავშირს ღიად ტოვებს; ახალი ფოსტა წამებში ჩნდება. სირთულე ის არის, რომ IDLE თითო კავშირზე ერთ საქაღალდეს უყურებს, ასე რომ კლიენტს, რომელსაც ხუთ საქაღალდეზე მყისიერი განახლებები უნდა, ხუთი კავშირი სჭირდება.
• ეფექტური ხელახალი სინქრონიზაცია CONDSTORE და QRESYNC გაფართოებებით (RFC 7162). ხელახლა დაკავშირებულ კლიენტს შეუძლია იკითხოს "რა შეიცვალა N ცვლილების მიმდევრობის შემდეგ", ნაცვლად იმისა, რომ ყველა წერილი თავიდან ჩამოთვალოს. მათ გარეშე დიდი საქაღალდის გახსნა ერთდღიანი ოფლაინის შემდეგ ნიშნავს ყველა წერილის დროშების ხელახლა შემოწმებას.

IMAP-ის სისუსტე ის არის, რომ ეს ლაყბობის მოყვარული, მდგომარეობის მქონე ტექსტური პროტოკოლია, 1980-იან წლებში შექმნილი და მას შემდეგ მუდმივად გაფართოებული. თითოეულმა კლიენტმა ყოველ საქაღალდეზე, რომელსაც უყურებს, ხანგრძლივი კავშირი უნდა შეინარჩუნოს, რთული გრამატიკა უნდა გაარჩიოს და არასავალდებულო გაფართოებების გრძელ სიას უნდა გაუმკლავდეს, რომლებსაც სერვერები არათანაბრად უჭერენ მხარს. ტელეფონზე ღია კავშირების შენარჩუნება ბატარეას ხარჯავს, და ამიტომ მობილური კლიენტები ხშირად IDLE-ის ნაცვლად პერიოდულად ამოწმებენ. მაგალითად, Apple-ის Mail აპი iPhone-ზე ზოგიერთი ტიპის ანგარიშისთვის push-ს გთავაზობს, IMAP ანგარიშებს კი გრაფიკით ამოწმებს.

გამოიყენე 993 პორტი (implicit TLS). 143 პორტი STARTTLS-ით მისაღებია მხოლოდ მაშინ, თუ სერვერი უარს ამბობს ავტორიზაციის მიღებაზე TLS-ის შეთანხმებამდე; RFC 8314 implicit TLS-ს სწორედ იმ მიზეზით გირჩევს, რომ შეტევისთვის დაუშიფრავი ფაზა საერთოდ არ არსებობს.

JMAP: ფოსტა როგორც თანამედროვე API#

JMAP - JSON Meta Application Protocol - Fastmail-ში შეიქმნა და IETF-მა 2019 წელს სტანდარტად აქცია, რომ IMAP-ის პრობლემები თანამედროვე დიზაინით ჩაენაცვლებინა. ეს არის JSON მოთხოვნები HTTPS-ზე:

{  "using": ["urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail"],  "methodCalls": [    ["Email/query", {      "accountId": "a1",      "filter": { "inMailbox": "inbox-id" },      "sort": [{ "property": "receivedAt", "isAscending": false }],      "limit": 10    }, "q"],    ["Email/get", {      "accountId": "a1",      "#ids": { "resultOf": "q", "name": "Email/query", "path": "/ids" },      "properties": ["subject", "from", "receivedAt", "preview"]    }, "g"]  ]}

ორი გამოძახება ერთ მოთხოვნაში: მეორე პირველის შედეგს უკუმითითებით იყენებს (#ids), ასე რომ კლიენტი სიასაც და დეტალებსაც ერთ წრეში იღებს. ეს დაჯგუფება დიდწილად იმის მიზეზია, რომ JMAP ნელ მობილურ კავშირებზე სწრაფია.

დიზაინის დანარჩენი პუნქტები:

• მდგომარეობის სტრიქონები სინქრონიზაციისთვის. ყოველი ობიექტის ტიპს თავისი მდგომარეობა აქვს. კლიენტი კითხულობს "რა შეიცვალა X მდგომარეობის შემდეგ" და ზუსტად შექმნილი, განახლებული და განადგურებული ობიექტების ID-ებს იღებს. არც ხელახალი ჩამოთვლა, არც კავშირები თითო საქაღალდეზე.
• Push ყველაფრისთვის. ერთი კავშირი - EventSource HTTP-ზე, ან WebSocket (RFC 8887) - კლიენტს ყველა საფოსტო ყუთში მომხდარ ცვლილებებს ატყობინებს. ბატარეისთვის დაზოგვითი და მყისიერი.
• ჩაშენებული გაგზავნა. EmailSubmission ფოსტას იმავე API-ით და იმავე ავთენტიკაციით აგზავნის. JMAP კლიენტს ცალკე SMTP პარამეტრები არ სჭირდება.
• აღმოჩენა. კლიენტები API-ს პოულობენ https://<host>/.well-known/jmap-ზე, რომელიც აბრუნებს სესიის ობიექტს endpoint-ებითა და შესაძლებლობებით.
• ჩვეულებრივი ვებ ინფრასტრუქტურა. ეს HTTPS-ია, ამიტომ ის გადის firewall-ებს, proxy-ებსა და load balancer-ებს, რომლებიც ვებ ტრაფიკს უკვე ამუშავებენ, და მისი გამოყენება ადვილია ბრაუზერიდან ან ნებისმიერი პროგრამირების ენიდან.

შეზღუდვა კლიენტებშია. ძირითადი დესკტოპისა და ტელეფონის საფოსტო აპების უმეტესობა - Outlook, Apple Mail, Gmail-ის აპი - JMAP-ზე არ საუბრობს. მას იყენებს Fastmail-ის საკუთარი აპები, ზოგიერთი ახალი და ღია კოდის კლიენტი, ვებ კლიენტები და ბიბლიოთეკები საკუთარი ხელსაწყოების ასაწყობად. სერვერის მხარეს მას Stalwart, Cyrus IMAP და Apache James ახორციელებენ. თუ წერ პროგრამას, რომელიც ფოსტას კითხულობს ან ახარისხებს, JMAP-ზე პროგრამირება IMAP-თან შედარებით გაცილებით სასიამოვნოა; თუ ოფისისთვის ტელეფონებს აწყობ, ისინი მაინც IMAP-ს გამოიყენებენ.

რას ნიშნავს თითოეული შენი მომხმარებლებისთვის#

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

კლიენტის პარამეტრები ტიპური შემთხვევისთვის:

ელფოსტის კლიენტის მორგება IMAP-ისა და SMTP-ისთვის გადის Thunderbird-ს, Outlook-ს, iOS-სა და Android-ს, autoconfig-ის ჩათვლით, რომ მომხმარებლებს ამის აკრეფა არ მოუწიოთ.

რა ჩართო საკუთარ სერვერზე#

ყოველი ღია პორტი ინტერნეტისა და პაროლის გამომცნობი ბოტებისთვის გახსნილი რამაა. ჩართე ის, რასაც იყენებ.

• IMAPS `993`-ზე: კი. ის ყველა კლიენტს სჭირდება.
• Submission `465`-ზე ან `587`-ზე: კი, ერთ-ერთი, გასაგზავნად. ორივე, თუ გაქვს კლიენტები, რომლებიც ერთ-ერთს ჯიუტად ითხოვენ.
• JMAP `443`-ზე: კი, თუ JMAP კლიენტს იყენებ ან საფოსტო ყუთზე ხელსაწყოების აწყობა გინდა; Stalwart-ზე ის HTTPS listener-ს ვებ ადმინკასთან იზიარებს.
• IMAP `143`-ზე: მხოლოდ თუ კლიენტს implicit TLS არ შეუძლია, და მხოლოდ იმ პირობით, რომ ავტორიზაციამდე STARTTLS სავალდებულოა.
• POP3 `995`-ზე: მხოლოდ კონკრეტული მოწყობილობისთვის, რომელსაც ის სჭირდება. 110 TLS-ის გარეშე - არასოდეს.
• ManageSieve `4190`-ზე: მხოლოდ თუ მომხმარებლები ფილტრის წესებს არედაქტირებენ კლიენტიდან, რომელიც მას იყენებს.

RE:NODE-ის Mail Server გეგმაზე გასანაწილებლად ხუთი პორტია, ამიტომ ეს არჩევანი კონკრეტულია: IMAPS, ერთი submission პორტი და HTTPS თითქმის ყველას ფარავს და ერთი-ორი დამატებითისთვის ადგილს ტოვებს. 25 პორტი ინტერნეტიდან ფოსტის მისაღებად ცალკე საკითხია, რომელსაც მხარდაჭერა მოთხოვნისამებრ აწყობს. listener-ების მხარეს ფარავს პოსტი Stalwart საფოსტო სერვერის დაყენება, ხოლო 25-ე პორტი და გამავალი ფოსტის ბლოკები ხსნის, რატომ არის 25 განსხვავებული.

ავტორიზაცია, პაროლები და უსაფრთხოება სხვადასხვა პროტოკოლში#

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

• დაშიფრე ყველა კავშირი. Implicit TLS 993, 995 და 465 პორტებზე, ან დანარჩენებზე ავთენტიკაციამდე სავალდებულო STARTTLS. სერვერი, რომელიც პაროლს 143-ზე ან 110-ზე დაუშიფრავად იღებს, მას ყველას გადასცემს, ვინც გზაზე დგას.
• გამოიყენე აპის პაროლები თითო მოწყობილობაზე, სადაც სერვერი მათ უჭერს მხარს. ტელეფონი, ლეპტოპი და პლანშეტი თითოეული საკუთარ პაროლს იღებს, ასე რომ დაკარგული მოწყობილობა ერთი ავტორიზაციის მონაცემის გაუქმებას ნიშნავს და არა მომხმარებლის მთავარი პაროლის ყველგან შეცვლას.
• გამორთე ის, რასაც არ იყენებ. გამორთულ POP3 listener-ზე brute-force შეუძლებელია. ეს ყველაზე ძლიერი არგუმენტია POP3-ის ნაგულისხმევად გამორთულად დატოვებისთვის.
• თვალი ადევნე ავთენტიკაციის ჩავარდნებს სერვერის ლოგებში. ბევრი მისამართიდან ერთ ანგარიშზე მუდმივი ნაკადი გამოცნობის შეტევაა; დაფიქრდი, საკმარისად ძლიერია თუ არა ამ ანგარიშის პაროლი, რომ ის უგულებელყო.
• OAuth არის ის, როგორც დიდ პროვაიდერებს ახლა ურჩევნიათ, რომ კლიენტები შევიდნენ, და ზოგიერთი საკუთარი სერვერი მას IMAP-ისა და SMTP-ისთვისაც უჭერს მხარს XOAUTH2 და OAUTHBEARER მექანიზმებით. კლიენტების მხარდაჭერა OAuth-ისთვის საკუთარ სერვერთან არათანაბარია, ამიტომ ჩვეულებრივი პაროლები TLS-ზე ტიპურ შემთხვევად რჩება.

JMAP-ს აქ მცირე უპირატესობა აქვს: ის HTTPS-ზე მუშაობს იმავე ავთენტიკაციის ვარიანტებით, როგორც ნებისმიერი ვებ API, ამიტომ ტოკენებისა და rate limiting-ის ხელსაწყოები, რომლებიც ვებ სერვისებს უკვე იცავს, პირდაპირ გამოიყენება.

მომხმარებლების გადაყვანა POP3-დან IMAP-ზე#

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

1. გაარკვიე, სად ცხოვრობს თითოეული მომხმარებლის ფოსტა. თუ მათმა კლიენტმა ჩამოტვირთვის შემდეგ სერვერიდან წაშალა, ერთადერთი ასლი ლოკალურია. თუ ფოსტა სერვერზე დატოვა, სერვერის ასლი შეიძლება სრული იყოს, ნაწილობრივი ან წლების წინანდელი.
2. დაამატე IMAP ანგარიში POP3-ის გვერდით იმავე კლიენტში, რომელიც იმავე საფოსტო ყუთზე მიუთითებს. POP3 ანგარიში ჯერ ნუ წაშლი.
3. ლოკალური საქაღალდეები IMAP ანგარიშში გადაათრიე. კლიენტი მათ სერვერზე ატვირთავს, რასაც დიდი საფოსტო ყუთისთვის შეიძლება საათები დასჭირდეს. ამის შემდეგ სერვერის მხარეს რაოდენობები შეამოწმე.
4. დანარჩენი მოწყობილობები მხოლოდ IMAP-ით მოაწყე.
5. წაშალე POP3 ანგარიში, როცა ატვირთვა დადასტურდება, და ძველი მონაცემების ფაილის ლოკალური backup გარკვეული დროით შეინახე.

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

თითოეულის ტიპური პრობლემები#

• POP3-მა ფოსტა "შეჭამა". ჩამოტვირთვის შემდეგ წაშლაზე დაყენებულმა კლიენტმა სერვერი დააცარიელა; დანარჩენი მოწყობილობები ვერაფერს ხედავენ. ჩართე "სერვერზე დატოვება", ან უკეთესი - IMAP-ზე გადადი.
• IMAP საქაღალდეები ერთ მოწყობილობაზე აკლია. საქაღალდეები არსებობს, მაგრამ ამ კლიენტში გამოწერილი არ არის. მოძებნე "subscribe" ან "manage folders" ოფცია.
• გაგზავნილი ფოსტა ორჯერ ჩანს, ან საერთოდ არ ჩანს. IMAP-ის შემთხვევაში კლიენტი SMTP-ით გაგზავნის შემდეგ ასლს Sent საქაღალდეში ატვირთავს. თუ სერვერიც ინახავს გაგზავნილ ფოსტას, დუბლიკატებს იღებ; თუ კლიენტის Sent საქაღალდის პარამეტრი ლოკალურ საქაღალდეზე მიუთითებს, სერვერი მას ვერასოდეს ხედავს. კლიენტის გაგზავნილების საქაღალდე სერვერის Sent-ზე დააყენე.
• ახალი ფოსტა ტელეფონზე ნელა მოდის. კლიენტი IDLE-ის ნაცვლად პერიოდულად ამოწმებს, ხშირად ბატარეის დასაზოგად. შეამოწმე წამოღების ინტერვალი, ან გამოიყენე კლიენტი push-ით.
• "Cannot connect" 993-ზე, მაგრამ 143 მუშაობს. Firewall-ია, ან პორტი გახსნილი არ არის. სერტიფიკატამდე პორტების მიბმა შეამოწმე.
• სერტიფიკატის გაფრთხილებები. კლიენტი უკავშირდება სახელს, რომელიც სერვერის სერტიფიკატზე არ არის, მაგალითად შიშველ IP-ს. გამოიყენე hostname.

FAQ#

POP3 უფრო კონფიდენციალურია, რადგან ფოსტა სერვერიდან იშლება?

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

შემიძლია IMAP და POP3 ერთსა და იმავე საფოსტო ყუთზე გამოვიყენო?

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

JMAP SMTP-ს ცვლის?

კლიენტებისთვის - კი, JMAP კლიენტები API-ით აგზავნიან. სერვერებს შორის - არა. ფოსტა შენი სერვერიდან სხვა ორგანიზაციებამდე კვლავ SMTP-ით მიდის 25-ე პორტზე.

რატომ არ უჭერს ჩემი ტელეფონი მხარს JMAP-ს?

ტელეფონის საფოსტო აპების უმეტესობა IMAP-ისა და Exchange-ის გარშემო აშენდა და JMAP არ დაუმატებია. ტელეფონებზე IMAP გამოიყენე; JMAP-ის უპირატესობები ყველაზე მეტად ვებ კლიენტებსა და შენ მიერ აწყობილ პროგრამებში ჩანს.

რომელი პორტი გამოვიყენო IMAP-ისთვის?

993 SSL/TLS-ით. 143 გამოიყენე მხოლოდ სავალდებულო STARTTLS-ით, და მხოლოდ თუ კლიენტს implicit TLS-ის გამოყენება არ შეუძლია.