SMTP relay გამავალი ფოსტისთვის: smarthost-ები ახსნილი

SMTP relay - რომელსაც smarthost-საც უწოდებენ - არის ფოსტის სერვერი, რომელიც შენს გამავალ ფოსტას შენს ნაცვლად აწვდის. იმის ნაცვლად, რომ შენმა სერვერმა თითოეული მიმღების MX მოძებნოს და მას პორტ 25-ზე დაუკავშირდეს, ის ყოველ გამავალ წერილს ერთ ფიქსირებულ ჰოსტს გადასცემს პორტ 587-ზე ან 465-ზე, შედის მომხმარებლის სახელითა და პაროლით და მიწოდებას ამ ჰოსტს ანდობს, რომელიც მისამართებიდან აგზავნის, რომლებსაც უკვე აქვთ რეპუტაცია. ის გჭირდება, როცა შენი ქსელი გამავალ პორტ 25-ს ბლოკავს, როცა შენი სერვერის IP-ს გამოსადეგი reverse DNS არ აქვს, ან როცა ახალი IP სხვა შემთხვევაში კვირებს spam-ის საქაღალდეებში გაატარებდა. ფოსტას კვლავ პირდაპირ იღებ, კვლავ საკუთარ საფოსტო ყუთებს ინახავ და კვლავ საკუთარი DKIM გასაღებით აწერ ხელს. relay მხოლოდ ბოლო ნაბიჯია.

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

რას ცვლის relay და რას არა#

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

relay-ით მიმღები ხედავს, რომ relay-ის IP უკავშირდება. blocklist-ის შემოწმებები, reverse DNS და კავშირის დონის რეპუტაცია ახლა relay-ს ეკუთვნის. ყველაფერი წერილის შიგნით - შენი From: მისამართი, შენი DKIM ხელმოწერა, შენი შიგთავსი - კვლავ შენია, და დომენის რეპუტაცია კვლავ შენს დომენს ებმის.

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

როდის გჭირდება ის#

• გამავალი პორტი 25 დაბლოკილია. ყველაზე გავრცელებული მიზეზი, დიდი სხვაობით. შენი სერვერი ვერავის პორტ 25-ს ვერ უკავშირდება, მაგრამ relay-ს 587-ზე ან 465-ზე უკავშირდება. პორტი 25 და გამავალი ფოსტის ბლოკირება ხსნის, რატომ არსებობს ეს ბლოკირება და როგორ დაადასტურო ის.
• reverse DNS-ს ვერ აყენებ. დიდი მიმღებები ელიან, რომ გამგზავნ IP-ს ჰქონდეს PTR ჩანაწერი, რომელიც forward DNS-ს ემთხვევა. თუ შენს პროვაიდერს შენი მისამართისთვის მისი დაყენება არ შეუძლია, relay-ის IP-ებს ის უკვე აქვთ. Reverse DNS და PTR ფოსტის სერვერებისთვის დეტალებს შეიცავს.
• შენი IP ახალია, საერთოა ან შელახულია. ახალ IP-ს რეპუტაცია არ აქვს; გადამუშავებულს შეიძლება სხვისი რეპუტაცია მოჰყვებოდეს. relay აგზავნის IP-ებიდან, რომლებსაც ისტორია აქვთ.
• აპლიკაციის ფოსტას დიდი მოცულობით აგზავნი - პაროლის აღდგენები, ქვითრები, შეტყობინებები. სპეციალური ტრანზაქციული სერვისები bounce-ებს, suppression სიებსა და თითოეული წერილის ლოგებს ზოგად ფოსტის სერვერზე უკეთ ამუშავებენ.
• გინდა ერთი ადგილი მიწოდებაზე თვალყურის სადევნებლად. relay-ის დაფები აჩვენებს თითოეული წერილის მიწოდებას, bounce-ებსა და საჩივრებს, რასაც საკუთარი სერვერის რიგი არ აჩვენებს.

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

relay-ის არჩევა#

relay-ები სამ ფართო ტიპად იყოფა.

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

რა შეამოწმო რეგისტრაციამდე:

1. დომენის დადასტურება და DKIM შენი დომენით - რომ DMARC-მა DKIM-ზე შესაბამისობა შეძლოს.
2. საკუთარი return path ან MAIL FROM დომენი - რომ SPF-იც შესაბამისი იყოს.
3. bounce-ებისა და საჩივრების დამუშავება - იმ მისამართების ჩახშობა, რომლებიც hard-bounce-ს იძლევა, და feedback loop-ები მიმღებებისგან.
4. Submission 587-სა და 465-ზე, და იდეალურად 2525-ზეც, ქსელებისთვის, რომლებიც სტანდარტულ პორტებს ბლოკავს.
5. შიგთავსის წესები. ტრანზაქციული სერვისების უმეტესობა ნაყიდ სიებს კრძალავს, ზოგი კი მარკეტინგულ ფოსტას ტრანზაქციულ გეგმებზე. წაიკითხე acceptable use policy; მისი დარღვევისთვის ანგარიშებს აჩერებენ.

ავთენტიფიკაცია relay-ზე#

კავშირი შენი სერვერიდან relay-მდე ჩვეულებრივი SMTP submission-ია:

1. შენი სერვერი relay-ის ჰოსტს პორტ 587-ზე უკავშირდება და გასცემს EHLO-ს, შემდეგ STARTTLS-ს კავშირის გასაუმჯობესებლად - ან უკავშირდება 465-ზე და TLS-ს მაშინვე იწყებს.
2. დაშიფრული კავშირით ის ავთენტიფიკაციას გადის AUTH PLAIN-ით ან AUTH LOGIN-ით, relay-ის მიერ გაცემული მომხმარებლის სახელითა და პაროლით. ტრანზაქციული სერვისები ჩვეულებრივ ამას SMTP credentials-ს უწოდებენ და ანგარიშში შესვლის მონაცემებისგან ცალკე ინახავენ; ზოგი იყენებს სიტყვასიტყვით მომხმარებლის სახელს, მაგალითად apikey-ს, API გასაღებით პაროლად.
3. ის წერილს აგზავნის MAIL FROM-ით, RCPT TO-თი და DATA-თი, ზუსტად ისე, როგორც ნებისმიერ სერვერზე გააგზავნიდა.

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

Stalwart-ში relay ვებ ადმინისტრირების პანელის გამავალის პარამეტრებში კონფიგურირდება. ბოლო ვერსიები მას აღწერს როგორც Relay ტიპის მარშრუტს მისამართით, პორტით, იმით, TLS implicit-ია თუ არა (true 465-ისთვის, false 587-ისთვის STARTTLS-ით), და მომხმარებლის სახელითა და საიდუმლოთი ავთენტიფიკაციისთვის; გამავალი სტრატეგია შემდეგ ამ მარშრუტს დისტანციური მიმღებებისთვის ირჩევს, ლოკალური ფოსტა კი ლოკალურად მიეწოდება. სხვა სერვერები იგივეს სხვაგვარად გამოხატავენ. შედარებისთვის, Postfix:

relayhost = [smtp.relay.example]:587smtp_sasl_auth_enable = yessmtp_sasl_password_maps = hash:/etc/postfix/sasl_passwdsmtp_sasl_security_options = noanonymoussmtp_tls_security_level = encrypt

კვადრატული ფრჩხილები ჰოსტის სახელის გარშემო Postfix-ს ეუბნება, რომ მისთვის MX ჩანაწერები არ მოძებნოს - პირდაპირ ამ ჰოსტს დაუკავშირდეს. იგივე იდეა ყველგან მოქმედებს: relay ფიქსირებული დანიშნულების ადგილია და არა MX-ის ძებნა.

SPF, DKIM და alignment relay-ის გავლით#

სწორედ აქ ფუჭდება relay-ები. DMARC გადის, როცა SPF ან DKIM გადის ხილულ `From:` სათაურში მოცემული დომენისთვის. relay ცვლის, რომელი IP აგზავნის, და შეიძლება envelope sender-იც შეცვალოს, ამიტომ თითოეული შემოწმება კარგად უნდა გაიაზრო. ფონი მოცემულია სტატიაში SPF, DKIM და DMARC ახსნილი.

DKIM სანდოა. შენი ფოსტის სერვერი თითოეულ წერილს შენი საკუთარი გასაღებით აწერს ხელს (d=example.com), სანამ relay-ს გადასცემს. relay-მა ხელმოწერილი სათაურები ან შიგთავსი არ უნდა შეცვალოს, და სანდო relay-ები არც ცვლიან. ხელმოწერა ხელუხლებლად მიდის, შენი საჯარო გასაღებით მოწმდება და შენს From:-ს ემთხვევა. ბევრი relay საკუთარ ხელმოწერასაც ამატებს თავისი დომენით; ეს უვნებელია - ერთი შესაბამისი გამავალი ხელმოწერა საკმარისია. თუ შენი სერვერი ხელს არ აწერს, relay-ს მოაწერინე ხელი შენი დომენით, იმ DKIM ჩანაწერების გამოყენებით, რომლებსაც ის გაძლევს გამოსაქვეყნებლად.

SPF envelope sender-ზეა დამოკიდებული. ორი შემთხვევა:

• relay შენს envelope sender-ს ინარჩუნებს (MAIL FROM:<anna@example.com>). მიმღებები example.com-ის SPF-ს relay-ის IP-ს მიხედვით ამოწმებენ. relay შენს SPF ჩანაწერს უნდა დაამატო, ჩვეულებრივ იმ include: მნიშვნელობით, რომელსაც relay თავის დოკუმენტაციაში მიუთითებს - მაგალითად include:amazonses.com, include:mailgun.org ან include:sendgrid.net.
• relay envelope sender-ს გადაწერს საკუთარ bounce დომენზე, რომ bounce-ები დაამუშაოს. მაშინ SPF relay-ის დომენის მიხედვით მოწმდება, გადის და შენსას არ ემთხვევა. ეს ნორმალურია, თუ DKIM ემთხვევა. უკეთესი: დააკონფიგურირე საკუთარი MAIL FROM ან return-path დომენი, მაგალითად bounces.example.com, გამოქვეყნებული ისე, როგორც relay გასწავლის, რომ SPF-იც შესაბამისი იყოს.

example.com.  IN  TXT  "v=spf1 mx include:mailgun.org -all"

ერთ სახელზე ერთი SPF ჩანაწერი შეინახე და ათ DNS მოთხოვნას ნუ გადააჭარბებ; ყოველი include: სულ მცირე ერთს ხარჯავს. თუ relay-ის დამატებამდე -all გამოიყენე, ჯერ include დაამატე და სატესტო წერილი გაგზავნე, თორემ ამ დროის განმავლობაში relay-ით გაგზავნილი ყველა წერილი SPF-ს ვერ გაივლის.

Bounce-ები, ლიმიტები და რიგი#

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

• Bounce-ები envelope sender-თან მიდის. თუ relay მას გადაწერს, bounce-ებს relay იღებს და ჩვეულებრივ ამ მისამართებს ავტომატურად ახშობს - ჩახშობილ მისამართზე შემდგომ გაგზავნილ წერილს relay აგდებს და ის მიმღებამდე არასოდეს აღწევს. შეამოწმე მისი suppression სია, როცა ვინმე ამბობს, რომ შენს ფოსტას არასოდეს იღებს.
• გაგზავნის ლიმიტები. relay-ის ახალი ანგარიშები ხშირად იწყება დღიური ზღვრით ან sandbox-ში, რომელიც მხოლოდ დადასტურებულ მისამართებზე აწვდის. სერვერი, რომელიც ზღვარს გადააჭარბებს, relay-ისგან 4xx გადავადებებს იღებს; შენი რიგი ფოსტას ინახავს და ხელახლა ცდის. უფრო მაღალი ლიმიტი დაგეგმილ გაგზავნამდე მოითხოვე და არა მისი მსვლელობისას.
• წერილის ზომა. relay-ებს წერილის მაქსიმალური ზომა აქვთ, ხშირად 10 MB-დან 50 MB-მდე, კოდირების დანამატის ჩათვლით. Base64 მიმაგრებულ ფაილებს თავად ფაილებზე დაახლოებით მესამედით დიდს ხდის.
• შენი რიგი კვლავ პირველი რიგია. თუ relay მიუწვდომელია ან შესვლას უარყოფს, ფოსტა შენი სერვერის რიგში ელოდება. მზარდი რიგი ავთენტიფიკაციის შეცდომებით ნიშნავს არასწორ ან ვადაგასულ მონაცემებს; დროის ამოწურვებით - relay-ის პორტი დაბლოკილია ან relay გათიშულია.

მხოლოდ ფოსტის ნაწილის relay-ით გაგზავნა#

relay-მა ყველაფერი არ უნდა წაიღოს. გავრცელებული დაყოფები:

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

relay-ის ტესტირება#

# მიაღწევს თუ არა სერვერი relay-მდე საერთოდ?$ nc -vz -w 5 smtp.relay.example 587# სრული ავთენტიფიცირებული ტესტი ბრძანების ხაზიდან$ swaks --server smtp.relay.example:587 --tls \    --auth LOGIN --auth-user 'relay-user' --auth-password 'relay-secret' \    --from anna@example.com --to you@gmail.com

შემდეგ შენი ფოსტის სერვერით გაგზავნე ნამდვილი წერილი გარე საფოსტო ყუთზე, რომელსაც აკონტროლებ, და წაიკითხე Authentication-Results. გინდა dkim=pass header.d=example.com-ით (ან header.i=@example.com-ით), dmarc=pass და header.from=example.com. spf=pass ბონუსია, თუ საკუთარი return path დააყენე. Received: სათაურები relay-ის სერვერებს აჩვენებს როგორც ბოლო ნაბიჯს მიმღებამდე - ეს მოსალოდნელია.

როცა ტესტი ჩავარდება, შეცდომა ჩვეულებრივ გეუბნება, რომელი შრეა არასწორი:

• `535 5.7.8` authentication failed - არასწორი მონაცემები, ან მონაცემები სხვა რეგიონისთვის ან ანგარიშისთვის. ტრანზაქციული სერვისები SMTP მონაცემებს ხშირად რეგიონის მიხედვით გასცემენ; ჰოსტის სახელი და მონაცემები ერთმანეთს უნდა ემთხვეოდეს.
• `530` must issue STARTTLS first - სერვერმა 587-ზე შესვლა სცადა გაუმჯობესებამდე. relay-ისთვის STARTTLS ჩართე, ან 465-ზე გადადი implicit TLS-ით.
• TLS handshake-ის შეცდომები 465-ზე - სერვერი STARTTLS-ით ელაპარაკება implicit-TLS პორტს. TLS რეჟიმი შეცვალე.
• `554` sender address not verified ან "domain not verified" - relay მხოლოდ იმ From: დომენებს იღებს, რომლებიც მასთან დაადასტურე. დაასრულე დომენის დადასტურება relay-ის დაფაზე.
• `dkim=fail` relay-ის შემდეგ - გზაზე რაღაცამ წერილი შეცვალა. შეამოწმე, რომ relay არ არის დაყენებული ბმულების გადასაწერად ან footer-ების დასამატებლად, რასაც ზოგი სერვისი click tracking-ისთვის ორივეს აკეთებს.

Relay-ები RE:NODE-ის Mail Server-ზე#

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

FAQ#

relay იგივეა, რაც open relay?

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

დაინახავენ მიმღებები relay-ის სახელს?

მხოლოდ ტექნიკურ Received: სათაურებში. From: მისამართი, საჩვენებელი სახელი და DKIM ხელმოწერა შენია, და ფოსტის კლიენტები შენს დომენს აჩვენებენ. ზოგი relay Gmail-ში პატარა "via" შენიშვნას ამატებს, თუ DKIM შენი საკუთარი დომენით არ არის ხელმოწერილი - შენი დომენით ხელმოწერა მას აქრობს.

ასწორებს relay spam-ში მოხვედრილ ფოსტას?

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

relay-მდე მისაღწევად პორტი 587 გამოვიყენო თუ 465?

ნებისმიერი. 465 TLS-ს თავიდანვე იყენებს; 587 STARTTLS-ით უმჯობესდება. გამოიყენე ის, რომელსაც relay თავის დოკუმენტაციაში მიუთითებს, და შენს სერვერში შესაბამისი TLS რეჟიმი დააყენე. თუ ორივე დაბლოკილია, ბევრი relay 2525-საც იღებს.

შემიძლია ჩემი Gmail ანგარიშის relay-ად გამოყენება?

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