პორტი 25 დაბლოკილია: გამავალი ფოსტა, 587 თუ 465 და relay-ები

პორტი 25 სახლის კავშირების უმეტესობაზე და ბევრ სერვერზე დაბლოკილია, რადგან სწორედ ამ პორტით მიეწოდება spam, და მისი დახურვა ქსელისთვის ყველაზე იაფი გზაა, რომ თავისი კლიენტების დაინფიცირებულ მანქანებსა და ნაქირავებ სერვერებს spam-ის გაგზავნა შეუწყვიტოს. ბლოკირება თითქმის ყოველთვის ეხება გამავალ კავშირებს სხვა სერვერების პორტ 25-ზე. ის ხელს არ უშლის შენს მომხმარებლებს, ფოსტა საკუთარი ფოსტის სერვერით გააგზავნონ, რადგან ამისთვის პორტი 587 ან 465 გამოიყენება, რომლებიც იშვიათად იბლოკება. და ის ხელს არ გიშლის ფოსტის სერვერის გაშვებაში: იღებ 25-ზე, თუ ის შემომავლისთვის ღიაა, და აგზავნი relay-ით 587-ზე, თუ გამავლისთვის ღია არ არის.

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

სამი პორტი, სამი საქმე#

SMTP სამ პორტზე მუშაობს, და ისინი ურთიერთჩანაცვლებადი არ არის.

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

პორტი 587 RFC 6409-ით არის განსაზღვრული წერილის submission-ისთვის: მომხმარებლის კლიენტი წერილს საკუთარ პროვაიდერს გადასცემს, ავთენტიფიკაციის შემდეგ. სერვერი მას შემდგომ გადაგზავნის, რადგან იცის, ვინ ხარ. კავშირი ღია ტექსტით იწყება და STARTTLS-ით უმჯობესდება; სწორად დაკონფიგურირებული სერვერი შესვლას არ მიიღებს, სანამ TLS არ ამოქმედდება.

პორტ 465-ს არეული ისტორია აქვს. ის 1990-იანებში SMTP over SSL-ისთვის გამოიყო, შემდეგ რეგისტრაციიდან მოიხსნა, მსოფლიოს ნახევარი მაინც იყენებდა, და შემდეგ RFC 8314-მა 2018 წელს ოფიციალურად ხელახლა გამოყო როგორც "submissions" - submission implicit TLS-ით. RFC 8314 სინამდვილეში მას 587-ზე STARTTLS-ით უფრო ამჯობინებს, რადგან ღია ტექსტის ფაზა არ არსებობს, რომელშიც თავდამსხმელი ჩაერევა. პრაქტიკაში ორივე კარგია; აირჩიე ის, რომელსაც შენი სერვერი და კლიენტი უჭერს მხარს, და კლიენტში შესაბამისი უსაფრთხოების პარამეტრი დააყენე.

ზოგიერთი relay სერვისი პორტ 2525-ზეც უსმენს. ეს სტანდარტული პორტი არ არის, უბრალოდ ალტერნატიული submission პორტია ქსელებისთვის, რომლებიც 587-საც ბლოკავს. ის 587-ის მსგავსად იქცევა.

რატომ ბლოკავენ ქსელები პორტ 25-ს#

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

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

• Google Cloud Compute Engine-იდან პორტ 25-ზე გამავალ კავშირებს საერთოდ არ უშვებს და მომხმარებლებს relay სერვისებისკენ მიუთითებს.
• AWS EC2-ზე გამავალ 25-ს ნაგულისხმევად ზღუდავს და მოთხოვნისამებრ, ფორმის მეშვეობით ხსნის.
• Microsoft Azure გამავალ 25-ს გამოწერის ტიპების უმეტესობისთვის ბლოკავს.
• ბევრი VPS პროვაიდერი მას ახალი ანგარიშებისთვის ბლოკავს და ხსნის მას შემდეგ, რაც ანგარიშს გარკვეული ისტორია დაუგროვდება, ან მოთხოვნით, რომელშიც გამოყენებას ხსნი.

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

შემომავალი 25 ცალკე საკითხია. საცხოვრებელი კავშირები ხშირად მასაც ბლოკავს (ასე რომ, სახლში სერვერს ვერ გაუშვებ), ხოლო კონტეინერულ ჰოსტინგზე ერთი სერვერი საერთო მისამართზე პორტ 25-ს უბრალოდ ვერ დაისაკუთრებს - ქსელმა ის შენამდე უნდა მიმართოს.

რომელი მიმართულებაა დაბლოკილი: შემოწმება#

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

# 1. გამავალი 25 სერვერიდან: მიაღწევს თუ არა დიდ მიმღებამდე?$ nc -vz -w 5 gmail-smtp-in.l.google.com 25# 2. შემომავალი 25 სერვერზე: გაუშვი ეს სხვა ქსელიდან$ nc -vz -w 5 mail.example.com 25# 3. Submission: მიაღწევენ თუ არა კლიენტები შენს სერვერამდე 587-სა და 465-ზე?$ nc -vz -w 5 mail.example.com 587$ openssl s_client -connect mail.example.com:465 -quiet

nc ბეჭდავს succeeded-ს ან open-ს, როცა TCP კავშირი სრულდება, და დრო ეწურება, როცა პაკეტებს რაღაც აგდებს. დროის ამოწურვა პირველ ტესტზე გამავალი ბლოკირებაა; დროის ამოწურვა მეორე ტესტზე შემომავალი პრობლემაა (firewall, პორტი გადამისამართებული არ არის, ან სერვერი არ უსმენს). Connection refused დროის ამოწურვისგან განსხვავდება: ის ნიშნავს, რომ პაკეტები მივიდა და ამ პორტზე არაფერი უსმენს, რაც ფოსტის სერვერზე მიუთითებს და არა ქსელზე.

უფრო დიალოგური ტესტისთვის openssl s_client -starttls smtp -connect host:25 -crlf უკავშირდება, TLS-ზე გადადის და საშუალებას გაძლევს აკრიფო EHLO test.example.com, რომ სერვერის შესაძლებლობები ნახო. swaks ("SMTP-ის შვეიცარიული დანა") მთელ სატესტო ტრანზაქციებს ავტომატიზებს და ღირს მისი დაყენება ნებისმიერ მანქანაზე, საიდანაც ფოსტის პრობლემებს იკვლევ.

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

შეცდომები, რომლებიც პორტის ბლოკირებას ჰგავს, მაგრამ არ არის

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

• `554` ან `550` blocklist-ის URL-ით ტექსტში - კავშირი იმუშავა; მიმღებმა უარი გითხრა, რადგან შენი IP სიაშია. მოძებნე მისამართი წერილში დასახელებულ სიაში და მიჰყევი მისი სიიდან ამოღების პროცესს.
• `550 5.7.1`, რომელშიც reverse DNS ან PTR არის ნახსენები - მიმღებმა შენი IP-ის reverse DNS შეამოწმა და არ მოეწონა. ეს კონფიგურაციის საკითხია მისთვის, ვინც მისამართს ფლობს; იხილე reverse DNS და PTR ფოსტის სერვერებისთვის.
• `421` "try again later" ან გადავადებები, რომლებშიც rate limit-ებია ნახსენები - მიმღები უცნობ გამგზავნს ზღუდავს. ნორმალურია ახალი IP-ისთვის; რიგი ხელახლა ცდის და მიწოდება ჩვეულებრივ საათებში ხერხდება.
• `530 5.7.0` must issue STARTTLS first - submission პორტს დაუკავშირდი და შესვლა სცადე TLS-ზე გადასვლამდე. კლიენტის პარამეტრია და არა ქსელის პრობლემა.
• `535` authentication failed - არასწორი მომხმარებლის სახელი ან პაროლი submission ან relay პორტზე. ქსელი წესრიგშია.

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

შენი არჩევანი, როცა გამავალი 25 დაბლოკილია#

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

1. გაგზავნე relay-ით. დააკონფიგურირე შენი ფოსტის სერვერი ისე, რომ მთელი გამავალი ფოსტა smarthost-ს გადასცეს პორტ 587-ზე ან 465-ზე, მომხმარებლის სახელითა და პაროლით ავთენტიფიცირებული. relay შენი სახელით აწვდის IP მისამართებიდან, რომლებსაც უკვე აქვთ რეპუტაცია და reverse DNS. შენი სერვერი კვლავ პირდაპირ იღებს და კვლავ ინახავს საფოსტო ყუთებს. ეს სტანდარტული გადაწყვეტაა და დეტალურად აღწერილია სტატიაში SMTP relay გამავალი ფოსტისთვის.
2. სთხოვე ბლოკირების მოხსნა. ზოგი პროვაიდერი ამას გააკეთებს, მას შემდეგ რაც გამოყენებას აუხსნი, დაადასტურებ, რომ reverse DNS დაყენებულია, და აჩვენებ, რომ abuse-ის მოქმედი კონტაქტი გაქვს. შემდეგ პირდაპირ აგზავნი - მაგრამ IP რეპუტაციის ნულიდან აშენებასაც იღებ თავზე, რასაც კვირები სჭირდება. იხილე რატომ მიდის ელფოსტა spam-ში, რომ ნახო, რას მოიცავს ეს.
3. გამოიყენე პროვაიდერის საფოსტო სერვისი გასაგზავნად, ხოლო მიიღე საკუთარ სერვერზე. შესაძლებელია, მაგრამ ეს გაყოფა SPF-სა და DKIM-ს უფრო არეულს ხდის, და relay-ზე მარტივი იშვიათად არის.
4. გადაიტანე სერვერი ქსელში, რომელიც გამავალ 25-ს უშვებს. გონივრული არჩევანია, თუ მნიშვნელოვანი მოცულობების პირდაპირ გაგზავნას გეგმავ და რეპუტაციის მართვისთვის მზად ხარ; პატარა ორგანიზაციისთვის ზედმეტია.

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

რა არ მუშაობს#

რამდენიმე იდეა ყოველ ჯერზე ჩნდება და არ შველის.

• SMTP-ის სხვა პორტზე გაშვება. სხვა ფოსტის სერვერები მხოლოდ პორტ 25-ზე აწვდიან. Gmail-ს ვერ ეტყვი, რომ შენს პორტ 2525-ზე მოიტანოს ფოსტა; ამისთვის DNS ჩანაწერი არ არსებობს. MX ჩანაწერებს პორტის ველი არ აქვს. არასტანდარტული პორტები მხოლოდ submission-ისთვის მუშაობს, სადაც კლიენტს შენ აკონტროლებ.
• გამავალი 25-ის VPN-ით გატარება. ეს პრობლემას VPN-ის მისამართებზე გადაიტანს, რომლებიც ჩვეულებრივ უკვე blocklist-ებზეა და შენი დომენისთვის reverse DNS არ აქვს. ფოსტა პირდაპირ spam-ში მიდის ან უარყოფილია.
• გაგზავნა თავად ვებ სერვერის `sendmail`-იდან. ჰოსტზე, რომელიც 25-ს ბლოკავს, ლოკალური საფოსტო პროგრამა წერილს რიგში აყენებს და ჩუმად ჩავარდება. აპლიკაციებმა წერილები ნამდვილ ფოსტის სერვერს ან relay-ს უნდა მიაწოდონ 587-ზე, მონაცემებით. ტრანზაქციული ელფოსტა შენი აპლიკაციიდან შეიცავს დეტალებს აპლიკაციის კოდისთვის.
• პორტ 25-ის გახსნა საკუთარ firewall-ში. თუ ბლოკირება ზემოთ, პროვაიდერთანაა, შენი firewall-ის წესები არაფერს ცვლის. Firewall-ის წესები, რომლებსაც მნიშვნელობა აქვს ხსნის, სად დგას სხვადასხვა შრე.

როგორ მუშაობს პორტი 25 RE:NODE-ის Mail Server-ზე#

ორი მიმართულება, ორი პასუხი.

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

გამავალი: თუ გზაზე მყოფი ქსელი შენს გამავალ პორტ 25-ს უარყოფს, გაგზავნე Stalwart-ის ვებ ადმინისტრირების პანელში დაყენებული relay-ით, რომელიც 587-ზე ან 465-ზე გადის relay-ის მონაცემებით. შენს მომხმარებლებსა და აპლიკაციებს ეს ორივე შემთხვევაში არ ეხება: ისინი წერილებს შენს Stalwart სერვერს მის submission პორტზე აწვდიან, იმ პორტის ნომრით, რომელსაც პანელი შენი სერვერისთვის ჩამოთვლის, და Stalwart წყვეტს, როგორ გავა წერილი. გეგმებს ხუთი პორტი აქვს submission-ისთვის, IMAP-ისთვის, HTTPS-ისთვის და ყველაფრისთვის, რისი გახსნაც გადაწყვიტე. Stalwart ფოსტის სერვერის დაყენება დანარჩენს ნაბიჯ-ნაბიჯ გადის, ხოლო საკუთარი ფოსტის სერვერის გზამკვლევი განიხილავს, საერთოდ სწორია თუ არა შენთვის საკუთარის გაშვება.

მაგალითი: გაჭედილი რიგის დიაგნოზი#

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

კლიენტები მართლები არიან: მათ 587-ზე მიაწოდეს, ავთენტიფიკაცია გაიარეს და სერვერმა წერილი მიიღო. პრობლემა შემდეგ ნაბიჯზეა. სერვერის რიგში ყველა გარე წერილი ელოდება, და თითოეულზე ბოლო შეცდომა დაახლოებით ასე იკითხება: "connection timed out" მიმღებების MX ჰოსტებთან.

1. სერვერის კონსოლიდან nc -vz -w 5 gmail-smtp-in.l.google.com 25-ს დრო ეწურება. გამავალი 25 დაბლოკილია.
2. nc -vz -w 5 smtp.relayprovider.example 587 წარმატებით სრულდება. Submission relay-ზე ღიაა.
3. ისინი relay-ზე ანგარიშს ქმნიან, მის include:-ს დომენის SPF ჩანაწერში ამატებენ, ფოსტის სერვერში relay-ს მის მიერ გაცემული მონაცემებით აკონფიგურირებენ და დისტანციურ ფოსტას მის გავლით უშვებენ.
4. ისინი რიგს ხელახლა ცდიან. წერილები ერთ წუთში გადის. Authentication-Results მიმღებთან აჩვენებს spf=pass-ს relay-ის include-ის მეშვეობით, dkim=pass-ს კომპანიის საკუთარი სელექტორით და dmarc=pass-ს.

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

FAQ#

უნდა გამოიყენოს ჩემმა ფოსტის კლიენტმა პორტი 25?

არა. კლიენტები წერილებს აწვდიან 587-ზე STARTTLS-ით ან 465-ზე implicit TLS-ით, შესვლის შემდეგ. პორტი 25 სერვერიდან სერვერზე მიწოდებისთვისაა და სამომხმარებლო ქსელების უმეტესობაზე ისედაც დაბლოკილია.

მოძველებულია პორტი 465?

აღარ არის. ის წლების განმავლობაში რეგისტრაციიდან მოხსნილი იყო, მაგრამ RFC 8314-მა 2018 წელს ხელახლა გამოყო submission-ისთვის implicit TLS-ით და მას გვირჩევს. 465-იც და 587-იც აქტუალურია და მათი გამოყენება ნორმალურია.

შემიძლია ფოსტის მიღება 25-ის გარდა სხვა პორტზე?

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

relay ჩემს ფოსტას ისე წარმოაჩენს, თითქოს სხვისგან მოდის?

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

ჩემმა პროვაიდერმა ბლოკირება მოხსნა. მაინც მჭირდება relay?

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