ელფოსტის გადატანა საკუთარ სერვერზე ფოსტის დაკარგვის გარეშე

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

ეს პოსტი მთელ გადასვლას მიჰყვება: რა გადადის და რა არა, imapsync-ის ბრძანებები, Gmail-ისა და Microsoft 365-ის თავისებურებები, DNS-ის გადართვა და ძველი არქივის შენახვა.

რა გადადის IMAP-ით და რა არა#

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

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

დაწყებამდე: ინვენტარიზაცია და ზომები#

შეაგროვე ყველა საფოსტო ყუთისთვის: მისამართი, ყველა ალიასი, რომელიც მასში აწვდის, მისი ზომა და ვინ იყენებს მას რომელ მოწყობილობებზე. საერთო საფოსტო ყუთებსა და დაგზავნის სიებს იგივე მოპყრობა სჭირდება. პროვაიდერების უმეტესობა საფოსტო ყუთების ზომებს ადმინ-კონსოლში აჩვენებს; თუ არა, imapsync --justfoldersizes ძველ სერვერზე მათ დაბეჭდავს.

შემდეგ ახალ მხარეს სამი რამ შეამოწმე:

• საცავი. შეკრიბე საფოსტო ყუთების ზომები და დატოვე ადგილი ზრდისა და სერვერის საკუთარი ინდექსებისთვის. დომენი 18 GB ფოსტით 10 GB გეგმაში ვერ ეტევა, და ამის აღმოჩენა კოპირების შუაში უსიამოვნოა.
• ანგარიშები. კოპირებამდე ახალ სერვერზე შექმენი ყველა საფოსტო ყუთი და ალიასი. imapsync ანგარიშებში აკოპირებს; ის მათ არ ქმნის.
• DNS-ზე წვდომა. დომენის MX, SPF, DKIM და DMARC ჩანაწერების რედაქტირება დაგჭირდება. გაარკვიე, სადაა დომენის DNS სინამდვილეში დაჰოსტილი - nameserver-ები და DNS ჩანაწერები ხსნის, როგორ გაიგო - და MX ჩანაწერის TTL გადართვამდე სულ მცირე ერთი დღით ადრე 300 წამამდე შეამცირე, რომ ცვლილება საათების ნაცვლად წუთებში გავრცელდეს.

საფოსტო ყუთების კოპირება imapsync-ით#

imapsync IMAP-იდან IMAP-ზე კოპირების სტანდარტული ინსტრუმენტია. ის ორივე სერვერზე შედის, ყველა საქაღალდეს გაივლის და აკოპირებს წერილებს, რომლებიც დანიშნულების ადგილას ჯერ არ არის, მათი ნიშნებითა და თარიღებით. მეორედ გაშვებისას ის მხოლოდ ახალს აკოპირებს, და სწორედ ეს ამუშავებს ორეტაპიან გადართვას. ეს Perl სკრიპტია, რომელსაც მისი ავტორი, Gilles Lamiral, აქვეყნებს; Perl მოდულების დაყენების გარეშე მისი გაშვების უმარტივესი გზა ოფიციალური Docker image-ია, gilleslamiral/imapsync.

გაუშვი ის მანქანიდან, რომელსაც ორივე სერვერთან კარგი კავშირი აქვს - შენი კომპიუტერიდან, ან დიდი მიგრაციისთვის პატარა VDS-იდან - და არა თავად ფოსტის სერვერიდან.

პირველი, უვნებელი გაშვება, რომელიც მხოლოდ იმას გეუბნება, რა მოხდებოდა:

$ imapsync \    --host1 imap.oldprovider.example --user1 anna@example.com \    --passfile1 ./old-anna.txt --ssl1 \    --host2 mail.example.com --user2 anna@example.com \    --passfile2 ./new-anna.txt --ssl2 \    --automap --dry

შემდეგ ნამდვილი: იგივე ბრძანება --dry-ის გარეშე. ოფციები, რომლებიც მნიშვნელოვანია:

--passfile1-ისა და --passfile2-ის გამოყენება --password1-ისა და --password2-ის ნაცვლად პაროლებს შენი shell-ის ისტორიიდან და საზიარო მანქანაზე პროცესების სიიდან შორს ინახავს. შემდეგ ფაილები წაშალე.

რამდენიმეზე მეტი მომხმარებლისთვის login-ები ფაილში ჩაწერე და ციკლი გამოიყენე:

#!/bin/sh# users.csv: old login;old password file;new login;new password filewhile IFS=';' read -r u1 p1 u2 p2; do  imapsync --host1 imap.oldprovider.example --user1 "$u1" --passfile1 "$p1" --ssl1 \           --host2 mail.example.com --user2 "$u2" --passfile2 "$p2" --ssl2 \           --automapdone < users.csv

დიდ საფოსტო ყუთს საათები სჭირდება. ვიწრო ადგილი თითქმის ყოველთვის წყარო პროვაიდერის სიჩქარის ლიმიტებია და არა გამტარუნარიანობა, ხოლო imapsync შეწყვეტის შემდეგ სუფთად აგრძელებს - უბრალოდ თავიდან გაუშვი.

Gmail, Google Workspace და Microsoft 365#

დიდ პროვაიდერებს თითოეულს თითო თავისებურება აქვს, რომელზეც ხალხი ებმევა.

Gmail-სა და Google Workspace-ს საქაღალდეები არ აქვს; მათ ლეიბლები აქვთ, რომლებიც IMAP-ით საქაღალდეებად არის წარმოდგენილი. წერილი სამი ლეიბლით სამ საქაღალდეში ჩნდება, და ყველა წერილი ასევე [Gmail]/All Mail-შიც ჩნდება. გულუბრყვილო კოპირებისას 5 GB საფოსტო ყუთი 15 GB დუბლიკატად იქცევა. imapsync-ს ამისთვის preset აქვს, --gmail1, რომელიც სწორ ჰოსტს აყენებს და ვირტუალურ საქაღალდეებს გამორიცხავს, როგორიცაა All Mail და Important; წაიკითხე მისი დოკუმენტაცია, რომ ზუსტად იცოდე, რას გამორიცხავს, და გადაწყვიტე, გინდა თუ არა, რომ წერილები, რომლებიც მხოლოდ All Mail-შია (ლეიბლის გარეშე დაარქივებული), საარქივო საქაღალდეში დაკოპირდეს. Google ასევე ზღუდავს IMAP ჩამოტვირთვებს ანგარიშზე დღეში - Workspace-ის გამოქვეყნებული ლიმიტი დაახლოებით 2,500 MB-ია - ამიტომ დიდ ანგარიშს რამდენიმე დღე სჭირდება და კოპირება გადართვამდე კარგა ხნით ადრე უნდა დაიწყოს. IMAP წვდომა დაშვებული უნდა იყოს, და ჩართული ორეტაპიანი დადასტურების შემთხვევაში login-ს ჩვეულებრივის ნაცვლად აპლიკაციის პაროლი სჭირდება.

Microsoft 365 / Exchange Online tenant-ების უმეტესობისთვის IMAP-ით ჩვეულებრივ პაროლით შესვლას აღარ იღებს; basic authentication გაუქმდა. imapsync ამისთვის OAuth2 access token-ებს უჭერს მხარს (--oauthaccesstoken1), და არსებობს --office1 preset-იც, მაგრამ token-ის მისაღებად tenant-ში აპლიკაციის რეგისტრაციაა საჭირო. თუ ეს იმაზე მეტია, რისი აღებაც გინდა, სარეზერვო გზაა თითოეული საფოსტო ყუთის Outlook-იდან .pst ფაილში ექსპორტი და მისი იმპორტი კლიენტიდან, რომელიც ორივე ანგარიშს უკავშირდება - ეს უფრო ნელია და იმაზე ნაკლებს კარგავს, ვიდრე ხალხი ელის.

სხვა ჰოსტები და cPanel-ის სტილის პროვაიდერები ჩვეულებრივ 993-ზე ჩვეულებრივ IMAP login-ებს იღებენ და განსაკუთრებულს არაფერს საჭიროებენ. შეამოწმე, ინახავს თუ არა ძველი ჰოსტი ფოსტას INBOX. namespace-ში (საქაღალდეები სახელებით INBOX.Sent, INBOX.Archive); imapsync გამყოფებსა და პრეფიქსებს უმეტეს შემთხვევაში ავტომატურად თარგმნის, ხოლო --dry საქაღალდეების შესაბამისობას რამის დაკოპირებამდე გაჩვენებს.

DNS-ის გადართვა#

როცა ყველა საფოსტო ყუთმა სრული პირველი გავლა გაიარა, გადართე ფოსტის მიწოდება. თანმიმდევრობას მნიშვნელობა აქვს.

1. დარწმუნდი, რომ ახალ სერვერს მიღება შეუძლია. პორტი 25 მას აღწევს, დომენი და ყველა მისამართი არსებობს, და სატესტო წერილი, რომელიც პირდაპირ ახალ სერვერზე გაიგზავნა, მოდის.
2. დაამატე ახალი სერვერი SPF-ში ძველი პროვაიდერის გვერდით, მაგალითად v=spf1 include:_spf.oldprovider.example ip4:203.0.113.25 ~all. გარკვეული დროით ორივე აგზავნის.
3. გამოაქვეყნე ახალი სერვერის DKIM გასაღები მისივე selector-ით. ძველი პროვაიდერის selector ადგილზე რჩება; ისინი ერთმანეთს არ ეწინააღმდეგება. DKIM გასაღებები და მათი როტაცია selector-ებს აღწერს.
4. შეცვალე `MX` ჩანაწერი ახალ სერვერზე.
5. დაელოდე ძველი TTL-ის ამოწურვას, პლუს მარაგი. ზოგი გამგზავნი იმაზე დიდხანს ქეშირებს, ვიდრე უნდა.

შენი DMARC ჩანაწერი არ იცვლება, თუ გადაფარვის პერიოდში ძველი და ახალი გამგზავნები ორივე SPF-ს ან DKIM-ს გასწორებულად გადიან. MX ჩანაწერები ახსნილი აღწერს, როგორ შეამოწმო, რას ხედავს სამყარო, dig MX example.com +short-ით, და როგორ მიმართო ავტორიტეტულ სერვერს ქეშების გვერდის ავლით.

მეორე გავლა და გადაფარვის პერიოდი#

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

შემდეგ რამდენიმე დღეში კიდევ ერთხელ გაიმეორე, და ძველი ანგარიშები ორიდან ოთხ კვირამდე ღიად შეინახე. ეს ფანჯარა ბოლო დაგვიანებულებს იჭერს და სარეზერვო ვარიანტს გაძლევს, თუ ახალ სერვერზე რამე არასწორი აღმოჩნდება. როცა ძველი პროვაიდერის inbox-ები ერთი კვირა ცარიელი დარჩება, წაშალე მისი ჩანაწერი SPF-იდან, წაშალე მისი DKIM selector, როგორც კი დარწმუნდები, რომ მისით აღარაფერი იგზავნება, და დახურე ანგარიშები.

ფოსტის კლიენტების გადაყვანა

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

• დესკტოპის კლიენტები (Thunderbird, კლასიკური Outlook): დაამატე ახალი ანგარიში ძველის გვერდით, ნაცვლად იმისა, რომ ძველი ანგარიშის სერვერის პარამეტრები დაარედაქტირო. კლიენტი ახალი სერვერიდან ახალ ლოკალურ ქეშს აშენებს, ხოლო ძველი ანგარიში წაკითხვადი რჩება, სანამ არ წაშლი. სერვერის ველის ადგილზე რედაქტირება ხშირად ლოკალურ ქეშს აბნევს და ის დუბლიკატებს ან ცარიელ საქაღალდეებს აჩვენებს.
• ტელეფონები: წაშალე ძველი ანგარიში და დაამატე ახალი. ტელეფონები ლოკალურად ცოტას ინახავს, ამიტომ დასაკარგი არაფერია.
• კონტაქტები და კალენდრები: .vcf და .ics ექსპორტები იქ დააიმპორტე, სადაც ისინი ახლა ცხოვრობენ.
• ხელმოწერები და წესები: კლიენტის მხარის წესები ხელახლა უნდა შეიქმნას; სერვერის მხარის წესები ახალ სერვერზე Sieve წესებად იქცევა.

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

ძველი არქივის შენახვა#

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

1. დააკოპირე ყველაფერი. თუ საცავი იძლევა საშუალებას, ყველაფერი ახალ სერვერზე ცხოვრობს და ძიება ისე მუშაობს, როგორც ადრე.
2. საარქივო ანგარიში. ძველი წლები ცალკე საფოსტო ყუთში დააკოპირე, რომლის გახსნაც რამდენიმე ადამიანს შეუძლია, რომ ყოველდღიური საფოსტო ყუთები პატარა იყოს და ტელეფონებთან სწრაფად სინქრონდებოდეს.
3. ოფლაინ ექსპორტი. imapsync-ს ნებისმიერ IMAP სერვერზე კოპირება შეუძლია, მაგრამ ცივი არქივისთვის ცალკე საცავზე შენახული mbox ან Maildir ექსპორტი უფრო მარტივია. შეინახე ორჯერ, ორ ადგილას; ერთ ასლად შენახული არქივი არქივი არ არის.

რასაც არ უნდა ინახავდე, ახალი სერვერი ახლა ორგანიზაციის ფოსტის ერთადერთ ცოცხალ ასლს ინახავს, ამიტომ backup-ები პირველივე დღეს დააყენე. Backup-ები, რომლებიც მართლა აღდგება ხსნის, რატომ არის აღდგენის ტესტი backup-ის განრიგზე მნიშვნელოვანი.

მიგრაციის პრობლემების მოგვარება#

`imapsync` ძველ პროვაიდერზე ვერ შედის. შეიძლება IMAP ანგარიშისთვის ან tenant-ისთვის გათიშულია, პროვაიდერი აპლიკაციის პაროლს მოითხოვს, რადგან ორეტაპიანი დადასტურება ჩართულია, ან პროვაიდერმა პაროლით შესვლა საერთოდ გააუქმა. შედი დესკტოპის კლიენტით იმავე მონაცემებით; თუ ესეც ვერ ხერხდება, პრობლემა ანგარიშშია და არა ინსტრუმენტში.

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

საქაღალდეები უცნაური სახელებით მოდის, მაგალითად `INBOX.INBOX.Sent`. ორ სერვერს შორის namespace-ის ან გამყოფის შეუსაბამობა. გაუშვი --dry --justfolders-ით და წაიკითხე შესაბამისობა, რომელსაც ბეჭდავს; imapsync-ს პრეფიქსებისა და გამყოფების მოსარგებად ოფციები აქვს, ხოლო --automap სპეციალურ საქაღალდეებს უვლის.

გაშვება შუაში ჩერდება timeout-ებით ან "too many connections"-ით. წყარო სიჩქარეს გიზღუდავს. ერთდროულად რამდენიმეს ნაცვლად თითო საფოსტო ყუთი გაუშვი და უბრალოდ ბრძანება თავიდან გაუშვი; ის იქიდან აგრძელებს, სადაც შეჩერდა.

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

ალიასზე გაგზავნილი ფოსტა გადართვის შემდეგ bounce-ით ბრუნდება. ალიასი ახალ სერვერზე არასოდეს შექმნილა. შეადარე ინვენტარიზაციის სია ახალი სერვერის მისამართებს - და შეამოწმე bounce, რომელიც ზუსტ მისამართს ასახელებს.

გადასვლა RE:NODE-ის ფოსტის სერვერზე#

Mail Server ხაზზე მუშაობს Stalwart, SMTP-ით, IMAP-ითა და JMAP-ით და ვებ ადმინით, სადაც პირველ კოპირებამდე დომენს, საფოსტო ყუთებსა და DKIM გასაღებს ქმნი. გეგმები 10 GB საფოსტო საცავით იწყება და 80 GB-მდე ადის, ამიტომ შეკვეთამდე შენი ინვენტარიზაციის ჯამი გეგმას შეადარე. MX-ის შეცვლამდე სთხოვე მხარდაჭერას პორტ 25-ის გადამისამართება - ერთი ფოსტის სერვერი თითო მისამართზე - რადგან სერვერი, რომელსაც მიღება არ შეუძლია, მეოთხე ნაბიჯისთვის მზად არ არის. --host2-ად და --port2-ად გამოიყენე პანელში ნაჩვენები სერვერის მისამართი და IMAP პორტი. Backup სლოტები ყველა Mail გეგმას მოყვება; პირველი სრული კოპირების შემდეგ აიღე ერთი და ერთხელ სადმე აღადგინე, რომ იცოდე, რომ მუშაობს.

FAQ#

შემიძლია ელფოსტის გადატანა ყოველგვარი შეფერხების გარეშე?

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

რამდენი ხანი სჭირდება imapsync-ით მიგრაციას?

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

ელფოსტის გადატანა ჩემს ვებსაიტს გააფუჭებს?

არა, თუ მხოლოდ ფოსტის ჩანაწერებს ცვლი. MX, SPF, DKIM და DMARC ჩანაწერები დამოუკიდებელია A ან CNAME ჩანაწერებისგან, რომლებიც ვებსაიტს ემსახურება. ფოსტის ჩანაწერები ადგილზე დაარედაქტირე და დანარჩენს თავი დაანებე.

რა ემართება ფოსტას, რომელიც DNS-ის გადართვის დროს გაიგზავნა?

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

შემიძლია imapsync თავად ახალ ფოსტის სერვერზე გავუშვა?

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