Ghost ფოსტას ორი დამოუკიდებელი გზით აგზავნის და ისინი ცალ-ცალკე მოიწყობა. ერთადერთ ადამიანზე გათვლილი წერილები - წევრების შესვლის ბმულები, თანამშრომლების მოსაწვევები, პაროლის აღდგენა - გადის კონფიგურაციის mail ბლოკით, ჩვეულებრივ SMTP-ით, და ამისთვის ნებისმიერი SMTP რელე გამოდგება. მასობრივი გაგზავნა Mailgun-ით ხდება, რომელიც Ghost Admin-ში ან bulkEmail ბლოკშია მოწყობილი, და Ghost მას SMTP-ით საერთოდ არ აგზავნის. რომელი გზითაც არ უნდა წავიდეს წერილი, შემოსულებამდე მხოლოდ მაშინ მიაღწევს, თუ გამგზავნი დომენი აქვეყნებს SPF-ისა და DKIM-ის ჩანაწერებს იმ სერვისისთვის, რომელიც წერილს აგზავნის. „Ghost-ის ფოსტა გაფუჭებულია“ ტიპის ჩივილების უმეტესობა ამ სამიდან ერთის არარსებობაზე მიდის.
ეს გზამკვლევი ფოსტაში უფრო ღრმად შედის, ვიდრე ზოგადი Ghost-ის ჰოსტინგის გზამკვლევი: ზუსტი გასაღებები, რელეს მუშა მაგალითი, Mailgun-ის მხარე, DNS ჩანაწერები, შემოწმება და შეცდომების მნიშვნელობა.
ორი სახის ფოსტა, ორი გზა#
გამოდგება, თუ ტერმინებს მკაცრად გავარჩევთ.
ტრანზაქციული ფოსტა წარმოიშობა მაშინ, როცა ერთი ადამიანი რაღაცას აკეთებს, და სწორედ მას ეგზავნება. Ghost-ში ეს არის:
- ჯადოსნური ბმული, რომლითაც წევრი შედის ან გამოწერას ადასტურებს. Ghost-ის წევრებს პაროლი არ აქვთ, ამიტომ ეს ბმული მთავარი შესასვლელია.
- თანამშრომლების მოსაწვევები და პაროლის აღდგენა ადმინისტრატორის გვერდზე.
- შეტყობინებები თანამშრომლებისთვის, მაგალითად ახალი წევრის შესახებ, თუ ისინი ჩართულია.
მასობრივი ფოსტა არის ნიუსლეტერი: ერთი პოსტი, რომელიც სიაში ყველა გამომწერს ეგზავნება, ხშირად რამდენიმე წუთში ათასობით წერილი.
მათი მოთხოვნები განსხვავებულია. ტრანზაქციული ფოსტა ცოტაა, მაგრამ გადაუდებელი: შესვლის ბმული, რომელიც ათ წუთში მოვიდა, მკითხველს უკვე დაკარგავს, ამიტომ საჭიროა საიმედო გამგზავნი სერვერი და კარგი რეპუტაცია. მასობრივ ფოსტას სჭირდება სერვისი, რომელიც გაგზავნისთვისაა შექმნილი: პაკეტებად დაყოფა, თითოეული ადრესატის აღრიცხვა, გამოწერის გაუქმება და დაბრუნებულ წერილებზე რეაგირება. ამ საქმეს Ghost Mailgun-ს გადასცემს.
გზები ერთმანეთისგან დამოუკიდებელია, ამიტომ ერთი შეიძლება მუშაობდეს, მეორე კი გატეხილი იყოს. საიტმა შეიძლება შესანიშნავად გააგზავნოს ნიუსლეტერები და შესვლის ბმული არასოდეს მიაწოდოს, ან პირიქით. შეამოწმე ორივე.
რატომ სჭირდება Ghost-ს რელე ტრანზაქციული ფოსტისთვის#
თუ mail ბლოკს არ მოაწყობ, Ghost ცდილობს, პირდაპირ თვითონ სერვერიდან მიაწოდოს წერილი. ანუ ყოველი ადრესატის საფოსტო სერვერს უკავშირდება 25 პორტზე შენი სერვერის IP მისამართიდან. ჩვეულებრივ ჰოსტინგის ქსელში ეს ორმაგად ვერ მუშაობს. ბევრი ქსელი გამავალ 25 პორტს სპამის შესაჩერებლად ბლოკავს, ხოლო სადაც ის ღიაა, ახალი IP უკუ DNS ჩანაწერისა და გაგზავნის ისტორიის გარეშე დიდ საფოსტო პროვაიდერებში ეჭვს იწვევს. წერილი ან არ გადის, ან სპამში ხვდება.
SMTP რელე ორივეს წყვეტს. Ghost რელეს უკავშირდება მიღების პორტზე (587 ან 465), შედის ანგარიშით და წერილს გადასცემს. რელე მას ისეთი მისამართიდან აწვდის, რომელსაც უკვე აქვს რეპუტაცია, და შენი დომენისთვის აფორმებს ან ადასტურებს. SMTP რელე გამავალი ფოსტისთვის იდეას ზოგადად საფოსტო სერვერის მხრიდან განმარტავს; Ghost-ისთვის ის უბრალოდ „ის, რაზეც mail ბლოკი მიუთითებს“.
საიდან აიღებ რელეს, შენი არჩევანია:
- ტრანზაქციული ფოსტის პროვაიდერი. აპლიკაციის ფოსტისთვის შექმნილი სერვისები გაძლევს SMTP ჰოსტს, მომხმარებლის სახელსა და გასაღებს, ასევე პანელს, სადაც ჩანს რა მიაწვდინა და რა დაბრუნდა. ეს ჩვეულებრივი პასუხია. ტრანზაქციული ფოსტა შენი აპლიკაციიდან ადარებს, რას უნდა მიაქციო ყურადღება.
- არსებული საფოსტო ყუთის გამავალი სერვერი. პატარა მოცულობის პირადი ბლოგისთვის გამოდგება. შეამოწმე დღიური გაგზავნის ლიმიტი და გაითვალისწინე, რომ ზოგი პროვაიდერი
Fromმისამართს ცვლის ან ზღუდავს. - საკუთარი საფოსტო სერვერი. RE:NODE-ს აქვს Mail Server ხაზი Stalwart-ზე, SMTP-ით, IMAP-ითა და JMAP-ით და ვებ ადმინით დომენების, საფოსტო ყუთებისა და DKIM-ისთვის. Ghost მას ნებისმიერი სხვა რელეს მსგავსად შეუძლია მიმართოს. Stalwart-ის საფოსტო სერვერის მოწყობა სერვერს აღწერს, ხოლო საკუთარი საფოსტო სერვერის გზამკვლევი გულახდილად ამბობს, რას მოითხოვს ასეთი სერვერის გაძღოლა.
- Mailgun-ის SMTP წერტილი. რადგან Mailgun-ის ანგარიში ნიუსლეტერებისთვისაც გჭირდება, მისი SMTP მონაცემები ტრანზაქციული ფოსტისთვისაც შეგიძლია გამოიყენო. ყველაფერი ერთ პანელში იქნება, ოღონდ ერთ მომწოდებელზე.
Ghost ყოველთვის მხოლოდ გარეთ უკავშირდება მიღების პორტს. 25 პორტი მას არ სჭირდება და ფოსტას არასოდეს იღებს.
mail ბლოკი, გასაღები გასაღებზე#
Ghost კონფიგურაციას ინსტალაციის საქაღალდეში არსებული config.production.json-იდან კითხულობს. ტიპური რელეს mail ბლოკი ასე გამოიყურება:
{ "mail": { "from": "'Example Blog' <noreply@example.com>", "transport": "SMTP", "options": { "host": "smtp.relay.example", "port": 587, "secure": false, "auth": { "user": "smtp-username", "pass": "smtp-password" } } }}| გასაღები | მაგალითი | მნიშვნელობა |
|---|---|---|
mail.transport | SMTP | პირდაპირი მიწოდების ნაცვლად SMTP სერვერის გამოყენება |
mail.from | 'Name' <noreply@example.com> | გამგზავნის ნაგულისხმევი მისამართი |
mail.options.host | smtp.relay.example | რელეს ჰოსტის სახელი |
mail.options.port | 587 ან 465 | მიღების პორტი |
mail.options.secure | false ან true | true მხოლოდ 465 პორტისთვის |
mail.options.auth.user | ლოგინი | SMTP მომხმარებელი |
mail.options.auth.pass | პაროლი ან გასაღები | SMTP პაროლი |
უმეტეს პრობლემას რამდენიმე წვრილმანი იწვევს.
პორტი და `secure` ერთად მიდის. 465 პორტი TLS-ს პირველივე ბაიტიდან იყენებს, ამიტომ მას სჭირდება "secure": true. 587 პორტი ღია ტექსტით იწყება და STARTTLS ბრძანებით გადადის დაშიფვრაზე, ამიტომ მას უნდა "secure": false - გადასვლა მაინც ხდება, დროშა მხოლოდ პირველ ბაიტს აღწერს. თუ ისინი ავურიე, მიიღებ ვადის ამოწურვას ან TLS ხელის ჩამორთმევის შეცდომას და არა გასაგებ შეტყობინებას.
`from` მისამართი დაპირებაა. რელე ჩვეულებრივ მხოლოდ იმ მისამართებიდან ან დომენებიდან აგზავნის, რომლებიც მასთან დაადასტურე, ხოლო ადრესატები ამ მისამართს შენს SPF და DKIM ჩანაწერებს ადარებენ. გამოიყენე მისამართი დომენზე, რომელსაც აკონტროლებ და რელესთან მოაწყე. noreply@ ტრანზაქციული ფოსტისთვის კარგია, მაგრამ რეალური, კითხვადი მისამართი უფრო თავაზიანია მკითხველის მიმართ, რომელიც შესვლის ბმულიან წერილს უპასუხებს.
სახელი ბრჭყალებში. JSON სტრიქონში from-ის შიგნით ერთმაგი ბრჭყალები განზრახაა: "'Example Blog' <noreply@example.com>" სახელსა და მისამართს ერთად ინახავს. შიშველი Example Blog <noreply@example.com> უმეტეს ვერსიაში ასევე მუშაობს, მაგრამ Ghost-ის საკუთარი დოკუმენტაცია ბრჭყალებიან ფორმას აჩვენებს.
ზოგ პროვაიდერს დასახელებული სერვისი აქვს. ქვემდებარე საფოსტო ბიბლიოთეკა ჰოსტისა და პორტის ნაცვლად იღებს options.service-ს ცნობილი პროვაიდერის სახელით, და Ghost-ის დოკუმენტაცია ამას Mailgun-ისთვის აჩვენებს. თუ შენი პროვაიდერი სერვისის სახელს აღნიშნავს, ჰოსტის აკრეფას გადაურჩები. თუ დარწმუნებული არ ხარ, ცალსახად მიუთითე host, port და secure, ეს ყოველთვის მუშაობს.
მოწყობა ფაილის შეუცვლელად
მანქანაზე, რომელსაც Ghost-CLI-თი მართავ, გასაღების დაყენება შეგიძლია ბრძანების სტრიქონიდან, და Ghost-CLI მას კონფიგურაციის ფაილში თვითონ ჩაწერს:
$ ghost config mail.transport SMTP$ ghost config mail.options.host smtp.relay.example$ ghost config mail.options.port 587$ ghost restartGhost გარემოს ცვლადებსაც კითხულობს, სადაც ორმაგი ქვედატირე ჩადგმის თითოეულ დონეს ცვლის, ამიტომ mail__transport აყენებს mail.transport-ს:
mail__transport=SMTPmail__from='Example Blog' <noreply@example.com>mail__options__host=smtp.relay.examplemail__options__port=587mail__options__secure=falsemail__options__auth__user=smtp-usernamemail__options__auth__pass=smtp-passwordგარემოს ცვლადები ფაილზე წინ დგას. აქ ეს კონკრეტული მიზეზით გამოდგება: SMTP პაროლი საიდუმლოა, და მისი გარემოს ცვლადში შენახვა, ფაილში კი არა, რომელიც შეიძლება ფორუმზე ჩასვა ან Git-ში დააკომიტო, კარგი ჩვევაა. გარემოს ცვლადები და საიდუმლოები ამ ჩვევას ზოგადად განიხილავს. თუ ფაილის შეცვლა თითქოს არაფერს ცვლის, შეამოწმე, ხომ არ აჭარბებს მას გარემოს ცვლადი, და გახსოვდეს, რომ Ghost კონფიგურაციას მხოლოდ გაშვებისას კითხულობს.
RE:NODE-ზე Ghost სერვერზე კონფიგურაციის ფაილი ჩვეულებრივი ფაილია ფაილების მენეჯერში და SFTP-ით, ხოლო Startup ჩანართზე გარემოს ცვლადებია. ნებისმიერი გზა გამოდგება; აირჩიე ის, რომელსაც დაიმახსოვრებ. ნებისმიერი ცვლილების შემდეგ სერვერი გადატვირთე.
ნიუსლეტერები და Mailgun#
ნიუსლეტერის გაგზავნა სხვა მექანიზმია. Ghost გამოქვეყნებულ პოსტს იღებს, წერილად აქცევს, გამომწერების სიას პაკეტებად ყოფს და ამ პაკეტებს Mailgun-ის API-ში აგზავნის. ყუთებში რეალურ მიწოდებას Mailgun ასრულებს, ის ასევე Ghost-ს უბრუნებს ინფორმაციას დაბრუნებული წერილებისა და საჩივრების შესახებ, და Ghost ამის მიხედვით მისამართებს მიუწვდომლად ნიშნავს.
მისი მოწყობა ორი გზით შეიძლება.
Ghost Admin-ში. ნიუსლეტერის წერილის პარამეტრებში შეგაქვს Mailgun-ის რეგიონი, გასაგზავნი დომენი და Mailgun-ის პირადი API გასაღები. ეს ჩვეულებრივი გზაა და სწორედ მას აღწერს Ghost-ის დოკუმენტაცია თვითონ განთავსებული საიტებისთვის.
კონფიგურაციის ფაილში. bulkEmail ბლოკი იმავე სამ მნიშვნელობას ინახავს, და Ghost-ის დოკუმენტაცია მას Mailgun-ის კონფიგურაციიდან დაყენების გზად ასახელებს:
{ "bulkEmail": { "mailgun": { "baseUrl": "https://api.mailgun.net/v3", "apiKey": "your-mailgun-private-key", "domain": "mg.example.com" } }}| გასაღები | მაგალითი | მნიშვნელობა |
|---|---|---|
bulkEmail.mailgun.baseUrl | https://api.mailgun.net/v3 | შენი რეგიონის Mailgun API |
bulkEmail.mailgun.apiKey | პირადი გასაღები | Ghost-ს გაგზავნის უფლებას აძლევს |
bulkEmail.mailgun.domain | mg.example.com | Mailgun-ში რეგისტრირებული გასაგზავნი დომენი |
Mailgun-ს აქვს აშშ-ისა და ევროკავშირის რეგიონები, და ანგარიში ერთ-ერთში არსებობს. ევროკავშირის რეგიონში შექმნილ დომენს ბაზურ მისამართად სჭირდება https://api.eu.mailgun.net/v3; ევროპული დომენისთვის ამერიკულის გამოყენება იძლევა ავტორიზაციის შეცდომას, რომელიც არასწორ გასაღებს ჰგავს, სინამდვილეში კი არასწორი რეგიონია. თუ ორივეა მითითებული, კონფიგურაციის ფაილი უფრო მნიშვნელოვანია, ვიდრე ადმინში შენახული, და ეს ბუნდოვანია, როცა ვინმე ერთს ცვლის და მეორეს არა.
გასაგზავნი დომენი ჩვეულებრივ ქვედომენია, მაგალითად mg.example.com ან news.example.com, და არა მთავარი დომენი. ამით Mailgun-ის მოთხოვნილი DNS ჩანაწერები შენი ჩვეულებრივი ფოსტისგან განცალკევებული რჩება, ხოლო ნიუსლეტერების მიწოდების პრობლემა იმ მისამართს არ აზიანებს, საიდანაც საქმიან ფოსტას წერ. მისამართი, საიდანაც ნიუსლეტერი გამოგზავნილად ჩანს, მაინც შეიძლება მთავარ დომენზე იყოს; Ghost საშუალებას გაძლევს თითოეული ნიუსლეტერისთვის გამგზავნის სახელი და მისამართი დააყენო, იმის ფარგლებში, რასაც Mailgun ამ დომენისთვის დაუშვებს.
სანამ მას დაეყრდნობი, გააგზავნე ტესტი. Ghost-ის ნიუსლეტერის რედაქტორს შეუძლია წინასწარ ხედის გაგზავნა შენს მისამართზე, ეს ადასტურებს, რომ გასაღები, რეგიონი და დომენი ერთმანეთს ეთანხმება. შემდეგ გააგზავნე რეალური პოსტი მცირე სეგმენტზე, მაგალითად წევრებზე იმ ლეიბლით, რომელიც რამდენიმე მეგობარს მიანიჭე, და მხოლოდ ამის შემდეგ - პირველი სრული გაგზავნა.
მართლა გჭირდება Mailgun?
მხოლოდ მაშინ, თუ პოსტების ელფოსტით გაგზავნა გინდა. საიტს, რომელიც ვებში აქვეყნებს, წევრებს უშვებს და ნიუსლეტერს არასოდეს აგზავნის, მხოლოდ mail ბლოკი სჭირდება. თუ Mailgun-ის მოწყობისთვის მზად არ ხარ, გამომწერების შეგროვება მაინც შეგიძლია, ნიუსლეტერი კი მოგვიანებით გააგზავნო. რისი გაკეთებაც არ შეიძლება, არის Mailgun-ის შენი SMTP რელეთი ჩანაცვლება მასობრივი გაგზავნისთვის: mail ბლოკის რელეზე მიმართვა ნიუსლეტერის მიწოდებას არ ჩართავს, რამდენადაც ხელგაშლილიც არ უნდა იყოს რელეს ლიმიტები.
SPF და DKIM Ghost-ის დომენისთვის#
შენი დომენიდან გამოგზავნილ ფოსტას მიმღები სერვერი ამოწმებს DNS ჩანაწერებით, რომლებსაც შენ აქვეყნებ. Ghost-ისთვის ორი მათგანია მთავარი, მესამე კი მათ აერთიანებს.
SPF არის TXT ჩანაწერი დომენზე, სადაც ჩამოთვლილია სერვერები, რომლებსაც ამ დომენის სახელით ფოსტის გაგზავნა შეუძლიათ. მიმღები უყურებს კონვერტის გამგზავნს, იღებს მისი დომენის SPF ჩანაწერს და მასთან ადარებს იმ IP-ს, საიდანაც კავშირი დამყარდა.
DKIM არის კრიპტოგრაფიული ხელმოწერა. გამგზავნი სერვისი ყოველ წერილს პირადი გასაღებით აწერს ხელს; შესაბამის საჯარო გასაღებს აქვეყნებ TXT ჩანაწერში მისამართზე selector._domainkey.yourdomain. მიმღები გასაღებს იღებს და ხელმოწერას ამოწმებს, რაც ადასტურებს, რომ წერილი არ შეცვლილა და გაგზავნა ის, ვისაც გასაღები აქვს.
DMARC ამბობს, რა ვქნათ, როცა შემოწმებები ვერ გაივლის, და მოითხოვს, რომ დომენი, რომელმაც SPF ან DKIM გაიარა, ხილულ From დომენს ემთხვეოდეს. ამას გასწორება (alignment) ჰქვია, და სწორედ ამიტომ არ არის „SPF გავიდა“ ყოველთვის საკმარისი. SPF, DKIM და DMARC განმარტებით სამივეს თანმიმდევრობით განიხილავს.
რადგან Ghost ორ სერვისს იყენებს, ჩვეულებრივ ორივესთვის ჩანაწერები გჭირდება:
| სახელი | ტიპი | დანიშნულება |
|---|---|---|
example.com | TXT | SPF ტრანზაქციული რელესთვის |
selector._domainkey.example.com | TXT | DKIM გასაღები რელესთვის |
mg.example.com | TXT | SPF Mailgun-ისთვის |
krs._domainkey.mg.example.com | TXT | DKIM გასაღები Mailgun-ისთვის |
_dmarc.example.com | TXT | პოლიტიკა და ანგარიშების მისამართი |
სელექტორების ზუსტი სახელები და გასაღებების მნიშვნელობები თითოეული პროვაიდერის პანელიდან მოდის; ნუ გამოიცნობ. ზემოთ მოცემული krs მხოლოდ ფორმის მაგალითია, გადაიწერე ის, რასაც Mailgun გაჩვენებს.
SPF-ის მინიმალური ჩანაწერი, რომელიც ერთ რელეს ანიჭებს უფლებას, ასე გამოიყურება:
v=spf1 include:_spf.relay.example ~allწესები, რომლებიც უნდა იცოდე:
- ერთი SPF ჩანაწერი თითო სახელზე. თუ უკვე გაქვს, ახალი
include:მასში დაამატე. ერთსა და იმავე სახელზე ორი SPF ჩანაწერი შემოწმების მუდმივ შეცდომას იწვევს. - მაქსიმუმ ათი DNS მოთხოვნა. ყოველი
include:ერთს მაინც ჯდება, ჩადგმულები - მეტს. სერვისები რომ დააგროვო, ლიმიტს გადააჭარბებ და SPF ყველაფერზე ჩავარდება. - `~all` თუ `-all`.
~allნიშნავს „რბილ უარყოფას ყველასთვის, ვინც სიაში არ არის“ და უსაფრთხო დასაწყისია.-all-ზე გადადი, როცა დარწმუნდები, რომ ყველა გამგზავნია ჩამოთვლილი. - ცალკე გასაგზავნ დომენს საკუთარი SPF აქვს. თუ Mailgun
mg.example.com-იდან აგზავნის, SPF ჩანაწერი, რომელსაც Mailgun ითხოვს,mg.example.com-ზე დგას და არა ძირეულზე.
DMARC ჩანაწერი დაკვირვების რეჟიმით იწყება:
v=DMARC1; p=none; rua=mailto:dmarc@example.comp=none მიწოდებას არაფერს უცვლის; ის მხოლოდ მიმღებებს სთხოვს შემაჯამებელი ანგარიშების გამოგზავნას, რათა დაინახო, ვინ აგზავნის შენი დომენის სახელით და გადის თუ არა შემოწმებებს. წაიკითხე ეს ანგარიშები რამდენიმე კვირა, გაასწორე ყველაფერი ლეგიტიმური, რაც ვერ გადის, და შემდეგ პოლიტიკა გააძლიერე. DMARC ანგარიშები და პოლიტიკის დანერგვა ამ თანმიმდევრობას გაგატარებს, ხოლო DKIM გასაღებები და როტაცია გასაღებების ზომებსა და მოგვიანებით შეცვლას მოიცავს.
დაამატე ჩანაწერები შენს DNS პროვაიდერთან, დაელოდე გავრცელებას და გამოიყენე შემოწმების ღილაკი რელესა და Mailgun-ის პანელებში. ორივე უარს იტყვის დომენის დადასტურებულად მიჩნევაზე, სანამ ჩანაწერები არ გადაიჭრება. DNS ჩანაწერები განმარტებით შესავალია იმ შემთხვევისთვის, თუ TXT, CNAME და TTL შენთვის უცნობია. ზოგი პროვაიდერი DKIM-ისთვის TXT-ის ნაცვლად CNAME ჩანაწერებს ითხოვს; ეს მათ გასაღებზე დელეგირებაა და მისაღებია, თუ სახელსა და მიზანს ზუსტად გადაწერ. ბევრი DNS პანელი შენს დომენს თავად ამატებს, ამიტომ მთლიანად ჩასმული სახელი შეიძლება გადაიქცეს selector._domainkey.example.com.example.com-ად. შენახულ ჩანაწერს უყურე და არა იმას, რაც აკრიფე.
შემოწმება და წარუმატებლობის წაკითხვა#
შეამოწმე ამ თანმიმდევრობით, რადგან ყოველი ნაბიჯი წინაზეა დამოკიდებული.
- გადატვირთე Ghost, რათა ახალი კონფიგურაცია წაიკითხოს.
- გამოიწვიე რეალური ტრანზაქციული წერილი. ბრაუზერის პირად ფანჯარაში დარეგისტრირდი წევრად მისამართით, რომლის წაკითხვაც შეგიძლია. შესვლის ან დადასტურების ბმული რამდენიმე წამში უნდა მოვიდეს. ასევე შეგიძლია თანამშრომელი მოიწვიო შენს მისამართზე.
- ნახე წერილის ნედლი სათაურები საფოსტო კლიენტში („ორიგინალის ჩვენება“).
Authentication-Resultsსათაურში უნდა ჩანდესspf=pass,dkim=passდაdmarc=pass. SPF გავიდა, DMARC კი არა - ჩვეულებრივ გასწორების პრობლემაა: რელემ SPF თავისი დომენისთვის გაიარა და არა შენთვის, შენი დომენისთვის კი DKIM ხელმოწერა არ არსებობს. - გააგზავნე ნიუსლეტერის წინასწარი ხედი და იგივე სათაურები შეამოწმე. Mailgun-ის მხარეს საკუთარი დომენი აქვს, ამიტომ შედეგი მე-3 ნაბიჯისგან შეიძლება განსხვავდებოდეს.
- გააგზავნე რამდენიმე პროვაიდერზე. დიდი პროვაიდერისა და პატარა ჰოსტერის ყუთი საკმარისად ხშირად არ ეთანხმება ერთმანეთს, რომ ერთი დამატებითი წუთი ღირდეს.
Ghost-ის ლოგი პირველი ადგილია, სადაც უნდა ნახო, როცა არაფერი მოდის. ფოსტის ფენის შეცდომები შეიცავს რელეს SMTP პასუხს, რომელიც ბევრად უფრო კონკრეტულია, ვიდრე ბრაუზერში ხილული ნებისმიერი რამ. სანამ პარამეტრებს შეცვლი, წაიკითხე ლოგის სტრიქონი.
გავრცელებული შეცდომები და მათი მნიშვნელობა#
არაფერი მოდის და ლოგში შეცდომა არ არის. Ghost ჯერ კიდევ პირდაპირ მიწოდებაზეა ან mail ბლოკი არ წაიკითხა. შეამოწმე, რომ mail.transport არის SMTP, რომ მას გარემოს ცვლადი არ აჭარბებს, და გადატვირთე.
კავშირის ვადის ამოწურვა. რელეს ჰოსტი ან პორტი არასწორია, ან ქსელი პორტს ბლოკავს. თუ ქსელი გამავალ 25 პორტს ბლოკავს, ეს მიზეზია, რომ რელეზე 587 ან 465 გამოიყენო და არა Ghost-ის პრობლემა. 25-ე პორტი და გამავალი ფოსტის ბლოკირება პორტებს შორის სხვაობას განმარტავს.
TLS-ის ან „wrong version number“ შეცდომები. პორტი და secure არ ეთანხმება ერთმანეთს. 465-ს სჭირდება true; 587-ს სჭირდება false.
ავტორიზაცია ვერ შესრულდა. მომხმარებლის სახელი ან პაროლი არასწორია, ან რელეს ანგარიშის პაროლის ნაცვლად აპლიკაციის გასაღები სჭირდება. ზოგი პროვაიდერი მომხმარებლის სახელად სიტყვა apikey-ს, პაროლად კი გასაღებს იყენებს. წაიკითხე რელეს SMTP გვერდი და ნუ ივარაუდებ.
გამგზავნის მისამართი უარყოფილია. from მისამართი ან მისი დომენი რელესთან დადასტურებული არ არის. დაადასტურე დომენი იქ და გამოიყენე მასზე არსებული მისამართი.
წერილი მოდის, მაგრამ სპამში ხვდება. ჩანაწერები აკლია ან გასწორებული არ არის. შეამოწმე სათაურები, როგორც ზემოთ წერია. ასევე შეამოწმე, რომ დომენს ორი SPF ჩანაწერი არ აქვს და რომ DKIM რელეშიცაა ჩართული და არა მხოლოდ DNS-შია გამოქვეყნებული.
ნიუსლეტერის ვარიანტი ნაცრისფერია ან Mailgun გაგზავნისას შეცდომას აბრუნებს. API გასაღები, რეგიონი ან დომენი არასწორია ან დაუყენებელია. ჯერ baseUrl-ში რეგიონი შეამოწმე; შეუსაბამობა არასწორ გასაღებს ჰგავს.
ნიუსლეტერი იგზავნება, მაგრამ წევრები არაფერს იღებენ. Mailgun-მა პაკეტი მიიღო; შემდეგ მიწოდება ჩაიშალა ან ფილტრმა დაიჭირა. ნახე Mailgun-ის ლოგები ადრესატის მიხედვით, სადაც ჩანს, წერილი მიწოდებულია, დაბრუნებულია თუ სპამად მონიშნული.
შესვლის ბმულები ზოგ მისამართზე მუშაობს და ზოგზე - არა. ხშირად მიზეზი მიმღებია, რომელიც SPF-ის ან DKIM-ის ჩავარდნისას ფოსტას უარყოფს, სხვები კი უფრო შემწყნარებლები არიან. ჩანაწერები გაასწორე და ადრესატის პროვაიდერს ნუ დაადანაშაულებ.
Ghost RE:NODE-ის აპლიკაციის სერვერზე#
Ghost ერთი დაწკაპუნებით ინსტალაციის ხაზებიდან ერთ-ერთია. სერვერი Ghost-ს პირველ გაშვებაზე აყენებს და აგებს, მონაცემებს კი სერვერზე SQLite-ში ინახავს, ამიტომ მთავარი, რაც მოსაწყობი რჩება, ფოსტაა. config.production.json-ს ფაილების მენეჯერში ან SFTP-ით ცვლი, ან Startup ჩანართზე აყენებ გარემოს ცვლადებს და კონსოლიდან გადატვირთავ. აპლიკაციები ერთი დაწკაპუნებით: WordPress, Ghost და Strapi აღწერს, რას აკეთებს ინსტალატორი.
რელესთვის სამი გულწრფელი ვარიანტი გაქვს: ტრანზაქციული ფოსტის პროვაიდერი, Mailgun-ის საკუთარი SMTP, ან Stalwart Mail Server ხაზი, თუ ფოსტის თვითონ გაძღოლა გინდა. Mail Server ხაზს აქვს დოკუმენტირებული გზა იმ შემთხვევისთვის, როცა ქსელი გამავალ 25 პორტს ბლოკავს: რელე მის ვებ ადმინში ეთითება. MX, SPF, DKIM და DMARC ჩანაწერებს ორივე შემთხვევაში თვითონ ამატებ. ინტერნეტიდან ფოსტის მისაღებად ასეთ სერვერზე მხარდაჭერამ 25 პორტი უნდა გადაამისამართოს, მაგრამ Ghost-ს მიღება არ სჭირდება - ის მხოლოდ აგზავნის.
FAQ#
შეიძლება თუ არა Ghost-ის ნიუსლეტერების გაგზავნა SMTP-ით Mailgun-ის ნაცვლად?
არა. Ghost-ში მასობრივი ფოსტის გზა Mailgun API-ზეა აგებული. SMTP პარამეტრები მხოლოდ ტრანზაქციულ ფოსტას ატარებს, ამიტომ რელე შესვლის ბმულებს მიაწვდის, მაგრამ პოსტის ელფოსტით გაგზავნის შესაძლებლობას არ ჩართავს.
რომელი პორტი გამოვიყენო Ghost-ის SMTP-ისთვის, 465 თუ 587?
ნებისმიერი, თუ secure შეესაბამება: 465 "secure": true-ით ან 587 "secure": false-ით. გამოიყენე ის, რასაც შენი რელე გირჩევს. 25 პორტს მოერიდე; ის სერვერებს შორის მიწოდებისთვისაა და ხშირად დაბლოკილია.
რატომ ხვდება შესვლის ბმული სპამში, თუ SPF გავიდა?
იმიტომ, რომ DMARC ამოწმებს გასწორებას და არა მხოლოდ გავლას. თუ SPF თვით რელეს დომენისთვის გავიდა, შენი დომენისთვის კი DKIM-ით არაფერია ხელმოწერილი, From დომენი არ ემთხვევა. რელეში ჩართე DKIM შენი დომენისთვის და გამოაქვეყნე გასაღები, რომელსაც გაძლევს.
მჭირდება თუ არა ცალკე დომენი ნიუსლეტერებისთვის?
არა, მაგრამ ქვედომენი, როგორიცაა mg.example.com, ჩვეულებრივი სქემაა. ის Mailgun-ის DNS ჩანაწერებს შენი ჩვეულებრივი ფოსტისგან განცალკევებულად ინახავს და მთავარი დომენის რეპუტაციას იცავს, თუ გაგზავნა ცუდად წავიდა.
სად უნდა ინახებოდეს SMTP პაროლი?
გარემოს ცვლადში, მაგალითად mail__options__auth__pass, და არა ფაილში, რომელსაც შეიძლება გააზიარო. ნებისმიერ შემთხვევაში ის გაშვებისას იკითხება, ამიტომ ცვლილების შემდეგ Ghost გადატვირთე. შეცვალე, თუ ის ოდესმე ლოგში ან ეკრანის სურათზე გამოჩნდა.
ღირს თუ არა საკუთარი საფოსტო სერვერის გაძღოლა მხოლოდ Ghost-ისთვის?
ჩვეულებრივ არა. Ghost ტრანზაქციულ ფოსტას ცოტას აგზავნის, ხოლო კარგი რელე გაძლევს რეპუტაციასა და მიწოდების პანელს, რასაც ახალი სერვერი კვირებით იმსახურებს. საკუთარი ფოსტა მაშინ გაიძღვარე, როცა შენს კონტროლქვეშ საფოსტო ყუთები გინდა და არა რამდენიმე შესვლის ბმულის გამო.
