ფოსტის კლიენტის დაყენება: IMAP და SMTP პარამეტრები, რომლებიც მუშაობს

ფოსტის ყველა კლიენტს ერთი და იგივე ექვსი ფაქტი სჭირდება: შემომავალი სერვერის სახელი, მისი პორტი, მისი დაშიფვრის რეჟიმი, გამავალი სერვერის სახელი, მისი პორტი და დაშიფვრის რეჟიმი, და მომხმარებლის სახელი და პაროლი. თანამედროვე სერვერისთვის ეს ნიშნავს IMAP-ს 993-ზე, TLS-ით პირველივე ბაიტიდან, და SMTP submission-ს 465-ზე (TLS პირველივე ბაიტიდან) ან 587-ზე (ღია კავშირი, რომელიც STARTTLS-ით უმჯობესდება), შესვლით საფოსტო ყუთის login სახელით. ეს ექვსი სწორად დააყენე და Thunderbird, Outlook, Apple Mail და Android-ის ყველა კლიენტი იმუშავებს. პორტისთვის დაშიფვრის რეჟიმი შეგეშალოს - ეს ყველაზე გავრცელებული შეცდომაა - და კლიენტი ან გაიჭედება, ან სერტიფიკატის ან პროტოკოლის შეცდომას გამოიტანს, რომელიც სასარგებლოს არაფერს გეუბნება.

ეს პოსტი მოიცავს პარამეტრებს, ოთხ კლიენტს, რომელსაც ხალხის უმეტესობა იყენებს, იმას, თუ როგორ აიძულო კლიენტები, პარამეტრები თავად იპოვონ autoconfig-ითა და autodiscover-ით, და შეცდომებს, რომლებსაც გზაში შეხვდები.

პარამეტრები, რომლებსაც ყველა კლიენტი გთხოვს#

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

ორი ტერმინი ხალხს აბნევს, რადგან კლიენტები მათ არათანმიმდევრულად ასახელებენ. Implicit TLS ნიშნავს, რომ დაშიფრული სესია დაკავშირებისთანავე იწყება; კლიენტები მას "SSL/TLS"-ს, "SSL"-ს ან უბრალოდ "TLS"-ს უწოდებენ. STARTTLS ნიშნავს, რომ კავშირი ღია ტექსტით იწყება და პაროლის გაგზავნამდე უმჯობესდება; კლიენტები მას "STARTTLS"-ს ან, დამაბნევლად, ასევე "TLS"-ს უწოდებენ. პორტები 993 და 465 implicit-ია. პორტები 143 და 587 - STARTTLS. 587-ზე "SSL/TLS" აირჩიე და კლიენტი TLS handshake-ს დაელოდება, რომელსაც სერვერი არასოდეს დაიწყებს; 465-ზე STARTTLS აირჩიე და სერვერი დაელოდება TLS handshake-ს, რომელსაც კლიენტი არასოდეს გაგზავნის. ორივე timeout-ს ჰგავს.

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

დარჩენილი ველები:

• მომხმარებლის სახელი. ის, რასაც სერვერი login სახელად იყენებს. თვითონ დაჰოსტილი სერვერების უმეტესობაზე ეს სრული მისამართია (anna@example.com), მაგრამ შეიძლება მარტო ანგარიშის სახელიც იყოს. გამოიყენე ის, რითაც საფოსტო ყუთი შეიქმნა.
• პაროლი. საფოსტო ყუთის პაროლი. თუ ანგარიშს ორფაქტორიანი ავთენტიფიკაცია აქვს, IMAP-სა და SMTP-ისთვის ჩვეულებრივ აპლიკაციის სპეციალური პაროლია საჭირო, რადგან არცერთ პროტოკოლს არ შეუძლია კოდის მოთხოვნა.
• ავთენტიფიკაციის მეთოდი. "Normal password" (Thunderbird) ან "Password" (Outlook) TLS-ზე სწორია - პაროლს დაშიფრული კავშირი იცავს. "Encrypted password" ვარიანტები ძველი challenge-response სქემებია, რომლებსაც ბევრი სერვერი არ სთავაზობს, და ისეთის არჩევა, რომელსაც სერვერი არ უჭერს მხარს, ავთენტიფიკაციის შეცდომას იძლევა სწორი პაროლის დროსაც.
• გამავალი ავთენტიფიკაცია. ყოველთვის ჩართული, იმავე მონაცემებით. Submission სერვერი, რომელიც ავთენტიფიკაციის გარეშე იღებს ფოსტას, open relay-ია, ხოლო სწორად დაყენებული სერვერი უარს "relay access denied"-ით გეტყვის.

ჰოსტის სახელები და სერტიფიკატები#

ყველა კლიენტი ამოწმებს, რომ TLS სერტიფიკატი, რომელსაც სერვერი წარადგენს, იმ ჰოსტის სახელზეა გაცემული, რომელიც აკრიფე. აკრიფე 203.0.113.25 ან server42.somehost.net, როცა სერტიფიკატზე mail.example.com წერია, და გაფრთხილებას მიიღებ. მისი გამოტოვება მუშაობს, და ასევე ორგანიზაციის ყველა ადამიანს აჩვევს სერტიფიკატის გაფრთხილებების გამოტოვებას - სწორედ ამ ჩვევაზე აკეთებს გათვლას თავდამსხმელი სასტუმროს wifi-ში.

სუფთა დაყენება არის ერთი სახელი ყველაფრისთვის, ჩვეულებრივ mail.example.com:

1. შექმენი A ჩანაწერი mail.example.com-ისთვის, რომელიც ფოსტის სერვერის მისამართზე მიუთითებს. DNS ჩანაწერები ახსნილი ჩანაწერების ტიპებს აღწერს, თუ ეს ახალია შენთვის.
2. დარწმუნდი, რომ სერვერის სერტიფიკატი ამ სახელს მოიცავს. Stalwart-ს შეუძლია სერტიფიკატების მიღება და განახლება ACME-ით (Let's Encrypt და მსგავსები), ასე რომ ეს კონფიგურაციის საკითხია და არა შესყიდვის.
3. ყველა კლიენტში mail.example.com გამოიყენე როგორც შემომავალ, ისე გამავალ ჰოსტად.

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

Thunderbird#

Thunderbird-ს ყველა კლიენტს შორის საუკეთესო ავტომატური კონფიგურაცია და ყველაზე გამჭვირვალე ხელით რეჟიმი აქვს.

1. გახსენი Account Settings, შემდეგ Account Actions, შემდეგ Add Mail Account.
2. შეიყვანე შენი სახელი, მისამართი და პაროლი, და აირჩიე Continue.
3. Thunderbird პარამეტრებს ეძებს (თანმიმდევრობა ქვემოთ, autoconfig-ის თავშია აღწერილი). თუ იპოვის, აჩვენებს IMAP-სა და SMTP-ს ჰოსტის სახელებითა და პორტებით. შეამოწმე ისინი, შემდეგ აირჩიე Done.
4. თუ ვერაფერს იპოვის ან არასწორად გამოიცნობს, აირჩიე Configure manually და შეავსე ზემოთ მოცემული ცხრილის მიხედვით: IMAP, mail.example.com, 993, SSL/TLS, Normal password; SMTP, mail.example.com, 465, SSL/TLS, Normal password. შენახვამდე დასადასტურებლად გამოიყენე Re-test.

Thunderbird-ის ვარაუდები გონივრულია, მაგრამ ყოველთვის სწორი არა. თუ მან 143-ზე STARTTLS აირჩია, როცა შენი სერვერი 993-საც სთავაზობს, ორივე იმუშავებს, მაგრამ 993-ზე SSL/TLS-ით შეცვლა ერთ მოძრავ ნაწილს აკლებს.

ორი პარამეტრი, რომლის შემოწმებაც შემდეგ ღირს, ანგარიშის Copies and Folders-ში: სად ინახება გაგზავნილი ფოსტა (ეს სერვერის Sent საქაღალდე უნდა იყოს და არა ლოკალური საქაღალდე, რომ გაგზავნილი წერილები ტელეფონზეც გამოჩნდეს) და ინახება თუ არა მონახაზები სერვერზე. Thunderbird for Android, კლიენტი, რომელიც ადრე K-9 Mail-ის სახელით იყო ცნობილი, იმავე დაყენების ლოგიკასა და იმავე autoconfig ძიებებს იყენებს.

Outlook#

Outlook Windows-ზე ორ საკმაოდ განსხვავებულ ვერსიად არსებობს, და ეს სხვაობა კერძო ფოსტის სერვერისთვის მნიშვნელოვანია.

კლასიკური Outlook (Microsoft 365-ის დესკტოპ აპლიკაცია) შენს სერვერს პირდაპირ ესაუბრება. გამოიყენე File, Add Account, შეიყვანე მისამართი, გახსენი Advanced options, მონიშნე "Let me set up my account manually" და აირჩიე IMAP. შეიყვანე შემომავალი და გამავალი სერვერი, პორტი და დაშიფვრის მეთოდი ცხრილიდან. Outlook implicit TLS-ს "SSL/TLS"-ს უწოდებს, ხოლო გაუმჯობესებულ რეჟიმს - "STARTTLS"-ს; ძველი ვერსიები "Auto"-ს სთავაზობდა, რომელსაც ჯობს ერიდო, რადგან მალავს, რა აირჩია.

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

Outlook-ს macOS-ზე, iOS-სა და Android-ზე საკუთარი ანგარიშის დამატების პროცესი აქვს და IMAP ანგარიშებისთვის ისიც Microsoft-ის სინქრონიზაციის სერვისს იყენებდა. თუ შენთვის მნიშვნელოვანია, მიმდინარე ქცევა Microsoft-ის დოკუმენტაციაში გადაამოწმე, რადგან ის ვერსიებს შორის იცვლებოდა.

Outlook-ის გავრცელებული შეცდომები ცხრილს უკავშირდება: "The server does not support the specified connection encryption type" პორტისა და რეჟიმის შეუსაბამობაა, ხოლო პაროლის განმეორებითი მოთხოვნა თითქმის ყოველთვის მომხმარებლის სახელის ფორმატია.

iPhone, iPad და Mac#

Apple Mail Thunderbird-ის სტილის autoconfig-ს არ იყენებს. ის მისამართიდან გამოცნობას ცდილობს, და როცა ვერ ახერხებს, გეკითხება.

iPhone-ზე ან iPad-ზე: გახსენი Settings, გადადი Mail-ზე (iOS 18-სა და უფრო ახალზე Apps-ის ქვეშ), შემდეგ Mail Accounts, Add Account, Other, Add Mail Account. შეიყვანე სახელი, მისამართი, პაროლი და აღწერა, შემდეგ აირჩიე Next. აირჩიე IMAP და Incoming Mail Server-სა და Outgoing Mail Server-ში შეავსე ჰოსტის სახელი, მომხმარებლის სახელი და პაროლი. iOS სტანდარტულ პორტებზე TLS-ს ცდის და წარმატების შემთხვევაში ანგარიშს ინახავს.

თუ შენი სერვერი არასტანდარტულ პორტებს იყენებს, iOS-ის პირველი შემოწმება ჩავარდება. მაინც შეინახე ანგარიში, შემდეგ დაარედაქტირე: შემომავალი პორტი ანგარიშის Advanced პარამეტრებშია, ხოლო გამავალი პორტი - ანგარიშში SMTP სერვერის ჩანაწერის ქვეშ. ჩართე "Use SSL", დააყენე პორტი და ავთენტიფიკაცია Password-ზე.

Mac-ზე პროცესი ასეთია: Mail, Add Account, Other Mail Account, იმავე ველებით. რამდენიმეზე მეტი მოწყობილობისთვის Apple კონფიგურაციის პროფილებს უჭერს მხარს (.mobileconfig ფაილები), რომლებიც ანგარიშის მთელ აღწერას შეიცავს; მათ Apple Configurator ქმნის, მომხმარებლები კი ერთი შეხებით აყენებენ. ეს autoconfig-ის Apple-ისეული ეკვივალენტია და გუნდისთვის სწორი ინსტრუმენტი.

Android: Gmail აპი, Samsung Email, Thunderbird#

Android-ს ერთი ფოსტის კლიენტი არ აქვს. სამი, რომელსაც ყველაზე ხშირად შეხვდები:

• Gmail აპი. Add another account, აირჩიე Other, შეიყვანე მისამართი, აირჩიე Personal (IMAP), შემდეგ პაროლი, შემდეგ შემომავალი და გამავალი სერვერის პარამეტრები. Gmail აპი IMAP ანგარიშებისთვის შენს სერვერს პირდაპირ უკავშირდება.
• Samsung Email. Add account, შეიყვანე მისამართი და პაროლი, აირჩიე Manual setup და IMAP, შემდეგ სერვერის მონაცემები. მისი უსაფრთხოების ტიპის წარწერები ვერსიებს შორის განსხვავდება, ამიტომ შეამოწმე პორტი, რომელსაც ის არჩევანის გვერდით ავსებს, და დარწმუნდი, რომ წყვილი ზემოთ მოცემულ ცხრილს ემთხვევა.
• Thunderbird for Android. იმავე autoconfig ძიებებს იყენებს, რასაც დესკტოპის Thunderbird, ასე რომ დომენი, რომელზეც autoconfig დაყენებულია, თავისით კონფიგურირდება.

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

Autoconfig და autodiscover: კლიენტებს პარამეტრებს თავად აპოვნინე#

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

Autoconfig Mozilla-ს ფორმატია, რომელსაც Thunderbird, Thunderbird for Android და ზოგიერთი სხვა კლიენტი იყენებს. anna@example.com-ის მიღებისას Thunderbird დაახლოებით ამ თანმიმდევრობით ეძებს: კლიენტთან ერთად მოყოლილი კონფიგურაცია, https://autoconfig.example.com/mail/config-v1.1.xml, https://example.com/.well-known/autoconfig/mail/config-v1.1.xml, Mozilla-ს საჯარო ISP მონაცემთა ბაზა, ISP ბაზის ჩანაწერი იმ დომენისთვის, რომელზეც შენი MX მიუთითებს, და ბოლოს გავრცელებული ჰოსტის სახელებისა და პორტების გამოცნობა. ფაილის გამოქვეყნება ნიშნავს, რომ პირველივე სასარგებლო ძიება წარმატებით დასრულდება:

<?xml version="1.0" encoding="UTF-8"?><clientConfig version="1.1">  <emailProvider id="example.com">    <domain>example.com</domain>    <displayName>Example mail</displayName>    <incomingServer type="imap">      <hostname>mail.example.com</hostname>      <port>993</port>      <socketType>SSL</socketType>      <authentication>password-cleartext</authentication>      <username>%EMAILADDRESS%</username>    </incomingServer>    <outgoingServer type="smtp">      <hostname>mail.example.com</hostname>      <port>465</port>      <socketType>SSL</socketType>      <authentication>password-cleartext</authentication>      <username>%EMAILADDRESS%</username>    </outgoingServer>  </emailProvider></clientConfig>

socketType არის SSL implicit TLS-ისთვის და STARTTLS გაუმჯობესებული რეჟიმისთვის. password-cleartext შემაშფოთებლად ჟღერს, მაგრამ ნიშნავს "გაგზავნე პაროლი TLS სესიის შიგნით", რაც სწორია. %EMAILADDRESS% იცვლება იმით, რაც მომხმარებელმა აკრიფა; გამოიყენე %EMAILLOCALPART%, თუ შენი login-ები მარტო ანგარიშის სახელებია.

Autodiscover Microsoft-ის ეკვივალენტია, რომელსაც კლასიკური Outlook იყენებს. კლიენტი მოთხოვნას POST-ით აგზავნის https://autodiscover.example.com/autodiscover/autodiscover.xml-ზე (და რამდენიმე სხვა ადგილას, მათ შორის https://example.com/autodiscover/autodiscover.xml-ზე და SRV ჩანაწერზე _autodiscover._tcp.example.com-ზე) და ელოდება XML პასუხს, რომელიც IMAP და SMTP სერვერებს აღწერს. Autoconfig-ისგან განსხვავებით ეს POST-ია, ამიტომ ჩვეულებრივ ვებ სერვერზე სტატიკური ფაილი მას ვერ უპასუხებს; მოთხოვნას რაღაცამ უნდა უპასუხოს.

Stalwart-ს ორივე სახის მოთხოვნის თავად მომსახურება შეუძლია, იმ პირობით, რომ კლიენტი მას HTTPS-ით ამ სახელებზე მიწვდება. თუ ეს მოუხერხებელია, autoconfig ფაილი სტატიკურია და შეიძლება ნებისმიერ ვებ ჰოსტზე იცხოვროს, რომელსაც ვალიდური სერტიფიკატი აქვს - პატარა საიტი ვებ ჰოსტინგის გეგმაზე, რომლის proxy სლოტი autoconfig.example.com-ზეა მიმართული, ამ საქმეს გააკეთებს.

არსებობს მხოლოდ DNS-ზე დაფუძნებული ვარიანტიც, RFC 6186 SRV ჩანაწერები, რომლებიც IMAP და submission სერვერებს პირდაპირ ასახელებს:

_imaps._tcp.example.com.       3600 IN SRV 0 1 993 mail.example.com._submissions._tcp.example.com. 3600 IN SRV 0 1 465 mail.example.com._submission._tcp.example.com.  3600 IN SRV 0 1 587 mail.example.com.

მათ ცოტა კლიენტი ეყრდნობა, ამიტომ მიიჩნიე ისინი იაფ დამატებად და არა autoconfig-ის შემცვლელად.

ფოსტის სერვერის გამოყენება RE:NODE-ზე#

Mail Server ხაზზე მუშაობს Stalwart, რომელიც SMTP-ს, IMAP-სა და JMAP-ს ლაპარაკობს და აქვს ვებ ადმინი, სადაც დომენებსა და საფოსტო ყუთებს ქმნი. კლიენტები უკავშირდებიან სერვერის მისამართს და გეგმისთვის გამოყოფილ პორტებს - თითოეულ Mail გეგმას ხუთი აქვს - ამიტომ მისამართი და პორტის ნომრები პანელიდან წაიკითხე და ნუ ივარაუდებ ზემოთ ცხრილში მოცემულ სტანდარტულებს. თუ პორტის ნომერი სტანდარტულისგან განსხვავდება, ის ნომერი ჩაწერე კლიენტში და დაშიფვრის ის რეჟიმი დატოვე, რომელიც listener-ს შეესაბამება (implicit TLS ან STARTTLS); autoconfig ფაილიც და SRV ჩანაწერებიც ნებისმიერ პორტს იღებს.

პორტი 25 ცალკე საკითხია. ინტერნეტში სხვა სერვერებიდან ფოსტის მისაღებად ის საჭიროა, კონტეინერს მისი თავად გახსნა არ შეუძლია, და მხარდაჭერა მას მოთხოვნით შენს სერვერზე გადაამისამართებს (ერთი ფოსტის სერვერი თითო მისამართზე). ამას კლიენტებთან კავშირი არ აქვს: ისინი ყოველთვის IMAP-სა და submission-ს იყენებენ, არასოდეს 25-ს. ასევე DNS ჩანაწერები, რომლებიც დომენს გარე სამყაროსთვის ამუშავებს - MX, SPF, DKIM, DMARC - შენ უნდა დაამატო შენს DNS ჰოსტთან. Stalwart-ის დაყენების გზამკვლევი აღწერს დომენის, საფოსტო ყუთებისა და DKIM გასაღების შექმნას ვებ ადმინში, სანამ რომელიმე კლიენტს დააკონფიგურირებ.

კლიენტის კავშირების პრობლემების მოგვარება#

კლიენტს timeout ემართება. არასწორი პორტი, პორტისთვის არასწორი დაშიფვრის რეჟიმი, ან ქსელი, რომელიც პორტს ბლოკავს. შეამოწმე ბრძანების ხაზიდან, რაც კლიენტს საკითხიდან გამორიცხავს:

$ openssl s_client -connect mail.example.com:993 -servername mail.example.com$ openssl s_client -connect mail.example.com:587 -starttls smtp$ openssl s_client -connect mail.example.com:465 -servername mail.example.com

კავშირი, რომელიც სერტიფიკატების ჯაჭვს და შემდეგ სერვერის მისალმებას ბეჭდავს (* OK IMAP-ისთვის, 220 SMTP-ისთვის), ამტკიცებს, რომ პორტი და TLS რეჟიმი მუშაობს. გაჭედვა 993-ზე, როცა 143-ზე -starttls imap მუშაობს, გეუბნება, რომელ რეჟიმს იყენებს listener სინამდვილეში.

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

პაროლი უარყოფილია, პაროლი ნამდვილად სწორია. მომხმარებლის სახელის ფორმატი (სრული მისამართი თუ ანგარიშის სახელი), ავთენტიფიკაციის მეთოდი, რომელსაც სერვერი არ სთავაზობს, ან ორფაქტორიანი ავთენტიფიკაცია, რომელიც აპლიკაციის პაროლს მოითხოვს. განმეორებითმა წარუმატებლობებმა შეიძლება სერვერის საკუთარი brute-force დაცვაც აამოქმედოს, რის შემდეგაც გარკვეული დროით სწორი პაროლიც ვერ გადის.

მიღება მუშაობს, გაგზავნა ვარდება "relay access denied"-ით. კლიენტში გამავალი ავთენტიფიკაცია გამორთულია. ჩართე და გამოიყენე იგივე მონაცემები, რაც შემომავლისთვის.

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

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

FAQ#

გასაგზავნად პორტი 465 გამოვიყენო თუ 587?

ნებისმიერი. 465 TLS-ს პირველივე ბაიტიდან იყენებს და RFC 8314 მას submission-ისთვის გვირჩევს; 587 STARTTLS-ით ისეთივე უსაფრთხოა, როცა კლიენტი გაუმჯობესებას მოითხოვს. აირჩიე ერთი, დაშიფვრის რეჟიმი მას მოარგე და ყველა კლიენტში ერთი და იგივე არჩევანი გამოიყენე, რომ მხარდაჭერის კითხვებს ერთი პასუხი ჰქონდეს.

რატომ იღებს ჩემი ტელეფონი ახალ ფოსტას მხოლოდ მაშინ, როცა აპს ვხსნი?

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

შემიძლია IMAP-ის ნაცვლად POP3 გამოვიყენო?

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

მჭირდება autoconfig, თუ მხოლოდ ხუთი მომხმარებელი მყავს?

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

უსაფრთხოა კომპანიის ფოსტის კითხვა ახალი Outlook-ით?

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