ტრანზაქციული ელფოსტა შენი აპიდან: SMTP სწორად გაკეთებული

აპლიკაციამ ელფოსტა ისე უნდა გააგზავნოს, როგორც ადამიანის ფოსტის კლიენტი აგზავნის: ავთენტიფიცირებული SMTP submission-ით ნამდვილ ფოსტის სერვერზე, პორტ 587-ზე STARTTLS-ით ან 465-ზე TLS-ით თავიდანვე, ცალკე გამგზავნი ანგარიშით, რომლის მონაცემებიც გარემოს ცვლადებში ცხოვრობს. მან უნდა გააგზავნოს ფონური სამუშაოდან და არა ვებ მოთხოვნის შიგნით, From: ხაზში ჩასვას დომენი, რომელსაც შენ აკონტროლებ, ამ დომენისთვის DKIM ხელმოწერით, და bounce-ებს რამე მოუხერხოს და არ უგულებელყოს. ამაში არაფერია რთული. რომელიმეს გამოტოვება არის ის, რის გამოც პაროლის აღდგენის წერილები სპამში ხვდება, რის გამოც ნელი ფოსტის სერვერი შენს რეგისტრაციის გვერდს timeout-ს აწვევს, და რის გამოც რეპოზიტორიაში ჩაკომიტებული SMTP პაროლი სხვისი სპამ-ოპერაცია ხდება.

ეს პოსტი მოიცავს პროტოკოლის არჩევანს, კოდს Node-ისთვის, Python-ისთვის, Django-სა და PHP-ისთვის, რიგებს, header-ებს, რომელთა დაყენებაც ღირს, და იმას, რას გეუბნება bounce-ები.

ტრანზაქციული ფოსტა მარკეტინგულისგან განსხვავებული საქმეა#

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

ამ განსხვავებას სამი მიზეზით აქვს მნიშვნელობა:

• რეპუტაცია საერთოა. თუ newsletter საჩივრებს იწვევს, მიმღები სერვერები გამგზავნ დომენსა და IP-ს ეჭვით ეპყრობიან, და იმავე ადგილიდან გაგზავნილი პაროლის აღდგენის წერილებიც ზარალდება. დიდი გამგზავნები ამ ორ ნაკადს ყოფენ - სხვადასხვა გამგზავნი მისამართები, ხშირად სხვა ქვედომენიც, მაგალითად mail.example.com მარკეტინგისთვის - რომ ერთმა მეორე ვერ ჩაითრიოს.
• წესები განსხვავდება. Gmail და Yahoo მარკეტინგული ფოსტის მასობრივი გამგზავნებისგან ერთი დაწკაპუნებით გამოწერის გაუქმების შეთავაზებას მოითხოვენ. პაროლის აღდგენას გამოწერის გაუქმების ბმული არ სჭირდება და არც უნდა ჰქონდეს.
• ხელსაწყოები განსხვავდება. ტრანზაქციული ფოსტა კოდის რამდენიმე ხაზი და ფოსტის სერვერია. მასობრივ ფოსტას სჭირდება სიების მართვა, გამოწერის გაუქმების დამუშავება, suppression სიები და სიჩქარის შეზღუდვა, და სწორედ ამიტომ ყიდულობენ მას სერვისად.

ყველაფერი ქვემოთ ტრანზაქციულ სახეს ეხება.

Submission და არა პორტი 25#

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

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

Submission მეორე გზაა. აპლიკაცია საკუთარ ფოსტის სერვერზე ავთენტიფიცირდება - შენსაზე ან პროვაიდერისაზე - და წერილს გადასცემს. ფოსტის სერვერი იღებს რიგებს, თავიდან ცდებს, DKIM ხელმოწერასა და მიწოდებას. 465 და 587 თანაბრად კარგია; ერთადერთი წესი ის არის, რომ შენს კოდში TLS-ის პარამეტრი პორტის რეჟიმს უნდა ემთხვეოდეს, თორემ კავშირი timeout-მდე გაიჭედება.

ცალკე გამგზავნი ანგარიში#

შექმენი საფოსტო ყუთი ან SMTP მონაცემები, რომლებსაც მხოლოდ აპლიკაცია იყენებს, მაგალითად app@example.com ან noreply@example.com. არა ადამიანის საფოსტო ყუთი და არა ადმინისტრატორის ანგარიში.

• მონაცემები გარემოს ცვლადებში მიდის, არასოდეს რეპოზიტორიაში. გაჟონილ SMTP პაროლს საჯარო რეპოზიტორიაში push-იდან რამდენიმე საათში სპამის გასაგზავნად იყენებენ, და ამის შესახებ პირველად მაშინ გაიგებ, როცა შენი დომენი blocklist-ში აღმოჩნდება. გარემოს ცვლადები და საიდუმლოებები აღწერს, სად უნდა ცხოვრობდნენ ისინი.
• `From:` მისამართი ისეთი უნდა იყოს, რომლის გამოყენებაც ანგარიშს შეუძლია. ფოსტის სერვერების უმეტესობა უარს ამბობს, ან უნდა თქვას, ავთენტიფიცირებულ ანგარიშს მისცეს გაგზავნის უფლება მისამართით, რომელიც მას არ ეკუთვნის. თუ აპლიკაცია orders@example.com-ით აგზავნის, ეს მისამართი გამგზავნ ანგარიშს ალიასად მიეცი.
• პასუხებისთვის გამოიყენე `Reply-To:`. noreply@ მისამართი From:-ისთვის მისაღებია, მაგრამ თუ მომხმარებლებმა შეიძლება ქვითარს უპასუხონ, Reply-To: დააყენე მხარდაჭერის მისამართზე, რომელსაც ვინმე ადევნებს თვალს, ნაცვლად იმისა, რომ მათი პასუხები გაქრეს.
• შეცვალე პაროლი, როცა წვდომის მქონე ვინმე წავა, და დაუყოვნებლივ, თუ გაჟონვაზე ეჭვი გაქვს. ცალკე ანგარიში ნიშნავს, რომ მისი შეცვლა მხოლოდ ერთ რამეს აფუჭებს, რომელსაც შენ აკონტროლებ.

გაგზავნა კოდიდან#

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

SMTP_HOST=mail.example.comSMTP_PORT=465SMTP_SECURE=trueSMTP_USER=app@example.comSMTP_PASS=a-long-random-passwordMAIL_FROM="Example <app@example.com>"

SMTP_SECURE ცალკე ცვლადია და არა პორტის ნომრიდან გამოყვანილი, რადგან პორტი, რომელსაც შენი სერვერი უსმენს, შეიძლება სტანდარტული არ იყოს. true ნიშნავს implicit TLS-ს (465-ის რეჟიმი), false ნიშნავს ღია ტექსტით დაკავშირებას და STARTTLS-ით გაუმჯობესებას (587-ის რეჟიმი).

Node.js Nodemailer-ით:

import nodemailer from "nodemailer";const transport = nodemailer.createTransport({  host: process.env.SMTP_HOST,  port: Number(process.env.SMTP_PORT),  secure: process.env.SMTP_SECURE === "true",   // false = STARTTLS  requireTLS: true,                              // refuse to send without TLS  auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },});await transport.sendMail({  from: process.env.MAIL_FROM,  to: user.email,  subject: "Reset your password",  text: `Use this link within an hour: ${link}`,  html: `<p>Use <a href="${link}">this link</a> within an hour.</p>`,});

შექმენი transport ერთხელ, გაშვებისას, და ხელახლა გამოიყენე. transport.verify() ჩატვირთვისას იაფი გზაა, რომ არასწორი პაროლი პირველ მომხმარებელზე ადრე იპოვო.

Python სტანდარტული ბიბლიოთეკით:

import os, smtplib, sslfrom email.message import EmailMessagefrom email.utils import make_msgid, formatdatemsg = EmailMessage()msg["From"] = os.environ["MAIL_FROM"]msg["To"] = to_addressmsg["Subject"] = "Reset your password"msg["Date"] = formatdate(localtime=True)msg["Message-ID"] = make_msgid(domain="example.com")msg.set_content(f"Use this link within an hour: {link}")ctx = ssl.create_default_context()host, port = os.environ["SMTP_HOST"], int(os.environ["SMTP_PORT"])if os.environ.get("SMTP_SECURE") == "true":    server = smtplib.SMTP_SSL(host, port, context=ctx, timeout=15)else:    server = smtplib.SMTP(host, port, timeout=15)    server.starttls(context=ctx)with server:    server.login(os.environ["SMTP_USER"], os.environ["SMTP_PASS"])    server.send_message(msg)

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

EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"EMAIL_HOST = os.environ["SMTP_HOST"]EMAIL_PORT = int(os.environ["SMTP_PORT"])EMAIL_USE_SSL = os.environ.get("SMTP_SECURE") == "true"   # implicit TLSEMAIL_USE_TLS = not EMAIL_USE_SSL                          # STARTTLSEMAIL_HOST_USER = os.environ["SMTP_USER"]EMAIL_HOST_PASSWORD = os.environ["SMTP_PASS"]EMAIL_TIMEOUT = 15DEFAULT_FROM_EMAIL = os.environ["MAIL_FROM"]SERVER_EMAIL = DEFAULT_FROM_EMAIL

EMAIL_USE_SSL და EMAIL_USE_TLS ურთიერთგამომრიცხავია; ორივეს დაყენება შეცდომაა. SERVER_EMAIL არის გამგზავნი შეცდომების ანგარიშებისთვის, რომლებიც ADMINS-ს ეგზავნება, და მისი ნაგულისხმევ root@localhost-ზე დატოვება ხშირი მიზეზია, რის გამოც ეს ანგარიშები არასოდეს მოდის.

PHP Symfony Mailer-ით (რომელსაც Laravel-იც შიგნით იყენებს) DSN-ს იღებს: smtps:// implicit TLS-ისთვის, smtp:// კავშირისთვის, რომელიც STARTTLS-ით უმჯობესდება:

MAILER_DSN=smtps://app%40example.com:a-long-random-password@mail.example.com:465

მომხმარებლის სახელში @ URL-ით არის დაშიფრული როგორც %40, და ასევე უნდა იყოს პაროლის ნებისმიერი სპეციალური სიმბოლოც. Laravel-ში იგივე პარამეტრები ცხოვრობს MAIL_MAILER=smtp-ში, MAIL_HOST-ში, MAIL_PORT-ში, MAIL_USERNAME-ში, MAIL_PASSWORD-სა და MAIL_FROM_ADDRESS-ში; ცვლადის სახელი, რომელიც TLS რეჟიმს ირჩევს, Laravel-ის ვერსიებს შორის შეიცვალა, ამიტომ შეამოწმე config/mail.php შენსავე პროექტში.

გაგზავნე რიგიდან და არა მოთხოვნიდან#

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

მოთხოვნაში წერილი რიგში ჩადე და worker-ს მიეცი გაგზავნის საშუალება. მოთხოვნა მაშინვე ბრუნდება, worker წარუმატებლობისას დაყოვნებით თავიდან ცდის, და ფოსტის სერვერის გათიშვა ფოსტის დაყოვნებად იქცევა და არა შენი აპლიკაციის გათიშვად. Node-ზე ეს BullMQ-ია; Python-ზე Celery ან RQ; Laravel-ში მისი რიგების სისტემა; Django-ში Celery ან მონაცემთა ბაზაზე დაფუძნებული task runner. ფონური სამუშაოები პატარა სერვერზე ვარიანტებს აღწერს, მათ შორის რიგს PostgreSQL-ში, რომელსაც დამატებითი სერვისი არ სჭირდება, ხოლო სამუშაოთა რიგები Valkey-ით Redis-პროტოკოლის რიგებს აღწერს.

worker-ისთვის ორი წესი:

1. თავიდან სცადე დროებითი წარუმატებლობები და არა მუდმივი. SMTP პასუხი, რომელიც 4-ით იწყება (421, 451), ნიშნავს "სცადე მოგვიანებით". 5-ით დაწყებული (550, 553) ნიშნავს "არა", და თავიდან ცდა პასუხს ვერ შეცვლის.
2. გაგზავნა იდემპოტენტური გახადე. თუ worker ავარიულად გაჩერდება მას შემდეგ, რაც სერვერმა წერილი მიიღო, მაგრამ სანამ სამუშაო დასრულებულად მოინიშნებოდა, სამუშაო თავიდან გაეშვება. მოვლენასთან შეინახე "გაგზავნილია" ნიშანი - პაროლის აღდგენის token-ი, შეკვეთის ნომერი - და გაგზავნამდე შეამოწმე.

Header-ები, რომელთა დაყენებაც ღირს#

ფოსტის ბიბლიოთეკები მინიმუმს აყენებს. რამდენიმე დამატებითი header-ი შენს ფოსტას უკეთეს ქცევას აძლევს:

• `Message-ID` და `Date`: პრაქტიკაში სავალდებულოა; მათი არქონა სპამის ქულას ზრდის. ბიბლიოთეკებისა და ფოსტის სერვერების უმეტესობა მათ ამატებს, მაგრამ შეამოწმე.
• `Auto-Submitted: auto-generated` (RFC 3834): მიმღების სერვერს ეუბნება, რომ წერილი პროგრამამ გაგზავნა, რომ შვებულების ავტომოპასუხეებმა მას არ უპასუხონ.
• ღია ტექსტის ნაწილი HTML-ის გვერდით. მხოლოდ HTML-იანი ფოსტა უარეს ქულას იღებს და ნაკლებად ხელმისაწვდომია.
• `List-Unsubscribe` და `List-Unsubscribe-Post: List-Unsubscribe=One-Click`: შეტყობინებების დაიჯესტებისთვის და ყველაფრისთვის, რაც მარკეტინგს ჰგავს, და არა პაროლის აღდგენისთვის.

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

Bounce-ები და კონვერტის გამგზავნი#

ყველა წერილს აქვს კონვერტის გამგზავნი, რომელიც MAIL FROM ბრძანებით დგინდება და Return-Path:-ად იწერება. როცა მიწოდება ჩავარდება მას შემდეგ, რაც შენმა სერვერმა წერილი მიიღო - საფოსტო ყუთი არ არსებობს, მიმღების სერვერმა უარყო - bounce ამ მისამართზე მიდის. თუ ის მიუთითებს noreply@ საფოსტო ყუთზე, რომელსაც არავინ ადევნებს თვალს, ან ისეთზე, რომელიც არ არსებობს, ვერასოდეს გაიგებ, რომ შენი რეგისტრირებულების ნახევარმა საკუთარი მისამართი შეცდომით აკრიფა.

რა უნდა უქნა მათ:

• Hard bounce-ები (5xx: მომხმარებელი უცნობია, დომენი არ არსებობს): შეწყვიტე ამ მისამართზე გაგზავნა. მონიშნე ის მომხმარებლის ჩანაწერში და სთხოვე მომხმარებელს, შემდეგ შესვლისას გაასწოროს. მკვდარ მისამართებზე განმეორებით გაგზავნა იმ გამგზავნის ერთ-ერთი ყველაზე ნათელი ნიშანია, რომელიც თავის სიას არ უვლის.
• Soft bounce-ები (4xx, საფოსტო ყუთი სავსეა, დროებით მიუწვდომელია): შენი ფოსტის სერვერი მათ თავად ცდის თავიდან დღეების განმავლობაში, სანამ ხელს აიღებს. მხოლოდ საბოლოო წარუმატებლობის შემდეგ არის ეს ნამდვილი bounce.
• სად მიდის ისინი: საფოსტო ყუთში, რომელსაც აპლიკაცია კითხულობს (IMAP-ით, worker-იდან), ან ისეთში, რომელსაც ადამიანი ამოწმებს. აპლიკაციები, რომლებიც ბევრს აგზავნის, იყენებენ VERP-ს - კონვერტის გამგზავნს თითო მიმღებზე, მაგალითად bounces+anna=gmail.com@example.com - რომ bounce-მა მისამართი წერილის გარჩევის გარეშე ამოიცნოს, რაც წვალებაა.

შენს ფოსტის სერვერს მიწოდებისას ნდობაც სჭირდება. გამგზავნი დომენისთვის SPF, DKIM და DMARC აღწერილია სტატიაში SPF, DKIM და DMARC ახსნილი; მათ გარეშე ფრთხილად დაწერილი კოდიც სპამში ხვდება.

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

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

RE:NODE-ზე Mail Server ხაზზე მუშაობს Stalwart, და Node, Python ან C# გეგმაზე მყოფ აპლიკაციას მასზე submission ისევე შეუძლია, როგორც ნებისმიერ ფოსტის კლიენტს: პანელში ნაჩვენები სერვერის მისამართი და submission პორტი, Stalwart-ის ვებ ადმინში შექმნილი ცალკე ანგარიში და მონაცემები გარემოს ცვლადებად აპლიკაციის Startup ჩანართზე. დომენისთვის MX, SPF, DKIM და DMARC ჩანაწერებს შენ ამატებ. თუ მიმღების ქსელი შენი სერვერის მისამართიდან პორტ 25-ზე ფოსტას უარყოფს, Stalwart-ს შეუძლია გამავალი ფოსტა მის ვებ ადმინში დაყენებულ relay-ს გადასცეს, და შენი აპლიკაციის კოდი საერთოდ არ იცვლება - SMTP relay-ები გამავალი ფოსტისთვის აღწერს, როდის ღირს ამის გაკეთება.

ტესტირება მომხმარებლებამდე#

swaks - SMTP-ის შვეიცარიული დანა - აგზავნის სატესტო წერილს ზუსტად იმ პარამეტრებით, რომლებსაც შენი აპლიკაცია იყენებს, და მთელ საუბარს ბეჭდავს:

$ swaks --to you@example.net --from app@example.com \    --server mail.example.com:587 --tls \    --auth LOGIN --auth-user app@example.com --auth-password 'secret'

Implicit TLS პორტისთვის --tls-ის ნაცვლად გამოიყენე --tls-on-connect. 235 პასუხი ნიშნავს, რომ ავთენტიფიკაციამ იმუშავა; 250 მონაცემების შემდეგ ნიშნავს, რომ სერვერმა წერილი მიიღო. შემდეგ გახსენი მიწოდებული ასლი და წაიკითხე მისი header-ები: Authentication-Results უნდა აჩვენებდეს, რომ SPF, DKIM და DMARC შენი დომენისთვის ყველა გადის. გაიმეორე ტესტი Gmail-ისა და Outlook-ის მისამართზე, რადგან შენი მომხმარებლების უმეტესობა იქ არის.

FAQ#

შეუძლია ჩემს აპს ელფოსტის გაგზავნა ფოსტის სერვერის გარეშე?

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

რატომ იჭედება გაგზავნა timeout-მდე?

TLS რეჟიმი პორტს არ ემთხვევა. Implicit TLS (secure: true, SMTP_SSL, EMAIL_USE_SSL, smtps://) STARTTLS პორტზე ელოდება handshake-ს, რომელსაც სერვერი არასოდეს დაიწყებს, ხოლო პირიქით შემთხვევაში - მისალმებას, რომელსაც სერვერი არასოდეს გაგზავნის. პარამეტრი listener-ს მოარგე.

პაროლის აღდგენის წერილები noreply მისამართიდან უნდა მოდიოდეს?

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

მჭირდება გამოწერის გაუქმების ბმული ტრანზაქციულ ფოსტაში?

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

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

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