Nastavení e-mailu v Ghostu: SMTP, Mailgun a ověření domény

Ghost posílá e-maily dvěma samostatnými cestami a nastavují se zvlášť. Zprávy „jeden člověku“ - přihlašovací odkazy členů, pozvánky pro redaktory, obnovení hesla - odcházejí přes blok mail v konfiguraci, obvykle přes SMTP, a stačí k tomu jakýkoli SMTP relay. Hromadné newslettery jdou přes Mailgun, který se nastavuje v Ghost Admin nebo v bloku bulkEmail, a přes SMTP je Ghost neposílá vůbec. Ať zpráva jde kteroukoli cestou, do schránky dorazí jen tehdy, když odesílající doména zveřejňuje záznamy SPF a DKIM, které pokrývají službu, jež zprávu odesílá. Většina stížností typu „e-maily v Ghostu nefungují“ končí u toho, že chybí jedna z těchto tří věcí.

Tento návod jde do pošty hlouběji než obecný návod k hostingu Ghostu: přesné klíče, funkční příklad s relayem, stranu Mailgunu, záznamy DNS, testování a význam chyb.

Dva druhy pošty, dvě cesty#

Vyplatí se být důsledný s pojmy.

Transakční pošta vzniká tím, že jeden člověk něco udělá, a jde právě jemu. V Ghostu to je:

• Magický odkaz, kterým se člen přihlásí nebo potvrdí odběr. Členové Ghostu nemají heslo, takže tento odkaz jsou přední dveře.
• Pozvánky pro redaktory a obnovení hesla do administrace.
• Oznámení pro redaktory, třeba o novém členovi, pokud jsou zapnutá.

Hromadná pošta je newsletter: jeden příspěvek odeslaný všem odběratelům na seznamu, často tisíce zpráv během několika minut.

Mají různé nároky. Transakčních zpráv je málo, ale jsou nespornně časově kritické - přihlašovací odkaz, který dorazí po deseti minutách, už čtenáře ztratil - takže potřebují spolehlivý odesílací server a dobrou pověst. Hromadná pošta potřebuje službu stavěnou na rozesílání: dělení do dávek, sledování každého příjemce, odhlašování a zpracování nedoručených zpráv. Tuhle práci Ghost předává Mailgunu.

Cesty jsou nezávislé, takže jedna může fungovat, zatímco druhá je rozbitá. Web může perfektně rozesílat newslettery a přitom nikdy nedoručit přihlašovací odkaz, a naopak. Zkoušej obě.

Proč Ghost potřebuje relay pro transakční poštu#

Pokud blok mail nenastavíš, Ghost se pokusí doručovat přímo ze samotného serveru. To znamená připojit se k poštovnímu serveru každého příjemce na portu 25 z IP adresy tvého serveru. V běžné hostingové síti to selže hned dvakrát. Mnoho sítí odchozí port 25 blokuje, aby zabránily spamu, a i tam, kde je otevřený, vzbuzuje nová IP bez reverzního DNS a bez historie odesílání u velkých poskytovatelů schránek podezření. Zpráva buď neodejde, nebo skončí ve spamu.

SMTP relay řeší obojí. Ghost se připojí k relayi na submission port (587 nebo 465), přihlásí se a předá zprávu. Relay ji doručí z adresy, která už má pověst, a podepíše ji nebo ověří pro tvou doménu. SMTP relay pro odchozí poštu vysvětluje myšlenku obecně ze strany poštovního serveru; pro Ghost je to prostě „to, na co ukazuje blok mail“.

Odkud relay vezmeš, je na tobě:

• Poskytovatel transakčních e-mailů. Služby určené pro poštu aplikací ti dají SMTP hostitele, uživatelské jméno a klíč a přehled, co bylo doručeno a co se vrátilo. To je obvyklá odpověď. Transakční e-maily z tvé aplikace porovnává, na co se při výběru dívat.
• Odchozí server existující schránky. Funguje pro osobní blog s malým objemem. Zkontroluj denní limit odesílání a pamatuj, že někteří poskytovatelé adresu From přepisují nebo omezují.
• Vlastní poštovní server. RE:NODE prodává řadu Mail Server běžící na Stalwartu, se SMTP, IMAP a JMAP a webovou administrací pro domény, schránky a DKIM. Ghost na něj může odesílat jako na jakýkoli jiný relay. Nastavení poštovního serveru Stalwart popisuje server a návod k vlastnímu poštovnímu serveru otevřeně říká, co provoz takového serveru obnáší.
• SMTP endpoint Mailgunu. Když si účet u Mailgunu stejně zakládáš kvůli newsletterům, můžeš jeho SMTP údaje použít i pro transakční poštu. Všechno pak máš v jednom přehledu, za cenu jednoho dodavatele na všechno.

Ghost se vždy jen připojuje ven na submission port. Port 25 nepotřebuje a poštu nikdy nepřijímá.

Blok mail, klíč po klíči#

Ghost čte konfiguraci ze souboru config.production.json v instalační složce. Blok mail pro typický relay vypadá takto:

{  "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"      }    }  }}

Většinu potíží způsobuje pár detailů.

Port a `secure` patří k sobě. Port 465 používá TLS od prvního bajtu, takže potřebuje "secure": true. Port 587 začíná nešifrovaně a přechází na šifrování příkazem STARTTLS, takže chce "secure": false - přechod stejně proběhne, příznak popisuje jen úplně první bajt. Když je zaměníš, dostaneš timeout nebo chybu TLS handshaku, ne užitečnou zprávu.

Adresa `from` je příslib. Relay obvykle odesílá jen z adres nebo domén, které jsi u něj ověřil, a příjemci tuto adresu porovnávají s tvými záznamy SPF a DKIM. Použij adresu na doméně, kterou ovládáš a kterou máš u relaye nastavenou. noreply@ je pro transakční poštu v pořádku, ale skutečná, sledovaná adresa je laskavější ke čtenáři, který na zprávu s přihlašovacím odkazem odpoví.

Jméno v uvozovkách. Jednoduché uvozovky uvnitř řetězce JSON v from jsou záměrné: "'Example Blog' <noreply@example.com>" drží jméno a adresu pohromadě. Holé Example Blog <noreply@example.com> ve většině verzí také funguje, ale tvar s uvozovkami ukazuje dokumentace samotného Ghostu.

Někteří poskytovatelé mají pojmenovanou službu. Poštovní knihovna pod kapotou přijímá options.service se známým názvem poskytovatele místo hostitele a portu a dokumentace Ghostu to ukazuje u Mailgunu. Pokud tvůj poskytovatel uvádí název služby, ušetříš si psaní hostitele. Když si nejsi jistý, vypiš host, port a secure explicitně, to funguje vždy.

Nastavení bez úpravy souboru

Na stroji, který spravuješ přes Ghost-CLI, můžeš klíč nastavit z příkazové řádky a Ghost-CLI ho zapíše do konfiguračního souboru za tebe:

$ ghost config mail.transport SMTP$ ghost config mail.options.host smtp.relay.example$ ghost config mail.options.port 587$ ghost restart

Ghost čte také proměnné prostředí, kde dvojité podtržítko nahrazuje každou úroveň zanoření, takže mail__transport nastaví 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

Proměnné prostředí mají přednost před souborem. Tady je to užitečné z konkrétního důvodu: heslo k SMTP je tajemství a držet ho v proměnné prostředí, a ne v souboru, který bys mohl vložit na fórum nebo commitnout do Gitu, je dobrý zvyk. Proměnné prostředí a tajemství tento zvyk rozebírá obecně. Pokud úprava souboru jako by nic nedělala, zkontroluj, jestli ji nepřebíjí proměnná prostředí, a pamatuj, že Ghost čte konfiguraci jen při startu.

Na serveru Ghost u RE:NODE je konfigurační soubor obyčejný soubor ve správci souborů a přes SFTP a na záložce Startup jsou proměnné prostředí. Funguje kterákoli cesta; použij tu, kterou si zapamatuješ. Po každé změně server restartuj.

Newslettery a Mailgun#

Odesílání newsletterů je jiný mechanismus. Ghost vezme publikovaný příspěvek, vykreslí z něj e-mail, rozdělí seznam odběratelů do dávek a odešle je do API Mailgunu. Vlastní doručení do schránek obstará Mailgun, hlásí Ghostu nedoručené zprávy a stížnosti a Ghost podle toho označuje adresy jako nedoručitelné.

Nastavit to jde dvěma způsoby.

V Ghost Admin. V nastavení e-mailu newsletteru zadáš region Mailgunu, odesílací doménu a soukromý API klíč Mailgunu. To je běžná cesta a přesně to popisuje dokumentace Ghostu pro weby, které si provozuješ sám.

V konfiguračním souboru. Blok bulkEmail drží stejné tři hodnoty a dokumentace Ghostu ho uvádí jako způsob, jak nastavit Mailgun z konfigurace:

{  "bulkEmail": {    "mailgun": {      "baseUrl": "https://api.mailgun.net/v3",      "apiKey": "your-mailgun-private-key",      "domain": "mg.example.com"    }  }}

Mailgun má region USA a EU a účet žije v jednom z nich. Doména vytvořená v regionu EU potřebuje jako základní adresu https://api.eu.mailgun.net/v3; když pro evropskou doménu použiješ americkou adresu, dostaneš chybu autorizace, která vypadá jako špatný klíč, ale ve skutečnosti je to špatný region. Pokud jsou nastavené obě varianty, konfigurační soubor má přednost před tím, co je uloženo v administraci, což může mást, když někdo změní jedno a druhé ne.

Odesílací doména je obvykle subdoména jako mg.example.com nebo news.example.com, ne hlavní doména. Záznamy DNS, které Mailgun chce, tak zůstanou oddělené od tvé běžné pošty a problém s doručitelností newsletterů nestáhne dolů adresu, ze které píšeš firemní poštu. Adresa, od které newsletter vypadá odeslaný, může být stále na hlavní doméně; Ghost umožňuje nastavit jméno a adresu odesílatele pro každý newsletter, v rozsahu toho, co Mailgun pro danou doménu dovolí.

Než se na to spolehneš, pošli test. Editor newsletteru v Ghostu umí poslat náhled na tvou adresu, což ověří, že klíč, region a doména si odpovídají. Potom pošli skutečný příspěvek malému segmentu, třeba členům se štítkem, který jsi dal několika přátelským lidem, a teprve potom první úplné odeslání.

Opravdu potřebuješ Mailgun?

Jen pokud chceš příspěvky rozesílat e-mailem. Web, který publikuje na webu, pouští členy a nikdy nerozesílá newsletter, potřebuje jen blok mail. Pokud ještě nejsi připravený Mailgun nastavit, odběratele můžeš sbírat a newsletter poslat později. Co nejde, je nahradit Mailgun svým SMTP relayem pro hromadné odesílání: nasměrování bloku mail na relay doručování newsletterů nezapne, ať jsou limity relaye jakkoli štědré.

SPF a DKIM pro doménu Ghostu#

Příchozí server kontroluje poštu z tvé domény podle záznamů DNS, které zveřejníš. Pro Ghost jsou nejdůležitější dva a třetí je spojuje.

SPF je záznam TXT na doméně, který uvádí, které servery smějí za doménu posílat poštu. Příjemce se podívá na obálkového odesílatele, načte SPF záznam jeho domény a porovná s ním IP adresu, ze které spojení přišlo.

DKIM je kryptografický podpis. Odesílající služba podepíše každou zprávu soukromým klíčem; odpovídající veřejný klíč zveřejníš v záznamu TXT na adrese selector._domainkey.yourdomain. Příjemce si klíč načte a ověří podpis, což dokazuje, že zpráva nebyla změněna a poslal ji někdo, kdo klíč má.

DMARC říká, co dělat, když kontroly selžou, a vyžaduje, aby doména, která prošla SPF nebo DKIM, odpovídala viditelné doméně From. Tomu se říká zarovnání (alignment) a je to důvod, proč „SPF prošlo“ nemusí stačit. SPF, DKIM a DMARC vysvětleně probírá všechny tři popořadě.

Protože Ghost používá dvě služby, obvykle skončíš se záznamy pro obě:

Přesné názvy selektorů a hodnoty klíčů přijdou z přehledu každého poskytovatele; nehádej je. Název krs výše je jen ukázka tvaru, opiš to, co ti ukáže Mailgun.

Minimální záznam SPF, který opravňuje jeden relay, vypadá takto:

v=spf1 include:_spf.relay.example ~all

Pravidla, která stojí za to znát:

1. Jeden záznam SPF na jméno. Pokud už jeden máš, přidej nový include: do něj. Dva záznamy SPF na stejném jménu způsobí trvalou chybu kontroly.
2. Nejvýše deset dotazů DNS. Každý include: stojí aspoň jeden, vnořené víc. Když nahromadíš služby, limit překročíš a SPF pak selže pro všechno.
3. `~all` nebo `-all`. ~all znamená „měkké odmítnutí všeho, co není na seznamu“ a je bezpečným začátkem. Na -all přejdi, až budeš jistý, že jsou vypsaní všichni odesílatelé.
4. Samostatná odesílací doména má vlastní SPF. Pokud Mailgun odesílá z mg.example.com, záznam SPF, který Mailgun chce, patří na mg.example.com, ne na kořen.

Záznam DMARC začíná v režimu sledování:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none na doručování nic nemění; jen žádá příjemce, aby posílali souhrnné reporty, abys viděl, kdo posílá jménem tvé domény a zda prochází kontrolami. Čti tyto reporty pár týdnů, oprav všechno legitimní, co neprochází, a pak politiku zpřísni. Reporty DMARC a postupné zavádění politiky tímto postupem provede a klíče DKIM a jejich rotace pokrývají velikosti klíčů a pozdější výměnu klíče.

Přidej záznamy u svého poskytovatele DNS, počkej na propagaci a použij tlačítko ověření v přehledu relaye i Mailgunu. Oba odmítnou označit doménu za ověřenou, dokud se záznamy nepřeloží. Záznamy DNS vysvětleně je úvod pro případ, že ti TXT, CNAME a TTL nic neříkají. Někteří poskytovatelé chtějí pro DKIM záznamy CNAME místo TXT; je to delegace na jejich klíč a je to v pořádku, pokud název i cíl opíšeš přesně. Mnoho panelů DNS doplňuje tvou doménu automaticky, takže název vložený celý se může změnit na selector._domainkey.example.com.example.com. Dívej se na uložený záznam, ne na to, co jsi napsal.

Testování a čtení chyby#

Testuj v tomto pořadí, protože každý krok závisí na předchozím.

1. Restartuj Ghost, aby načetl novou konfiguraci.
2. Vyvolej skutečnou transakční zprávu. V anonymním okně prohlížeče se zaregistruj jako člen s adresou, kterou si můžeš přečíst. Přihlašovací nebo potvrzovací odkaz by měl dorazit během několika sekund. Případně pozvi redaktora na svou adresu.
3. Podívej se na surové hlavičky zprávy v poštovním klientu („zobrazit originál“). V hlavičce Authentication-Results chceš vidět spf=pass, dkim=pass a dmarc=pass. Prošlé SPF při neprošlém DMARC většinou znamená zarovnání: relay prošel SPF pro svou vlastní doménu, ne pro tvou, a pro tu tvou chybí podpis DKIM.
4. Pošli náhled newsletteru a zkontroluj stejné hlavičky. Strana Mailgunu má vlastní doménu, takže výsledek se může od kroku 3 lišit.
5. Pošli zprávy více poskytovatelům. Schránka u velkého poskytovatele a u malého hostingu se rozcházejí dost často na to, aby se jedna minuta navíc vyplatila.

Log Ghostu je první místo, kam se dívat, když nic nedorazí. Chyby poštovní vrstvy obsahují odpověď SMTP od relaye, která je mnohem konkrétnější než cokoli, co uvidíš v prohlížeči. Přečti si řádek v logu dřív, než začneš měnit nastavení.

Časté chyby a co znamenají#

Nic nedorazí a v logu není chyba. Ghost je pořád na přímém doručování nebo se blok mail nenačetl. Zkontroluj, že mail.transport je SMTP, že ho nepřebíjí proměnná prostředí, a restartuj.

Timeout spojení. Hostitel nebo port relaye je špatně, nebo síť port blokuje. Pokud síť blokuje odchozí port 25, je to důvod použít 587 nebo 465 na relay, ne něco, co by se týkalo Ghostu. Port 25 a blokace odchozí pošty vysvětluje rozdíl mezi porty.

Chyby TLS nebo „wrong version number“. Port a secure si neodpovídají. Pro 465 je potřeba true; pro 587 je potřeba false.

Selhalo ověření. Uživatelské jméno nebo heslo je špatně, nebo relay potřebuje klíč aplikace místo hesla k účtu. Někteří poskytovatelé používají jako uživatelské jméno doslova slovo apikey a jako heslo klíč. Přečti si stránku SMTP u relaye, nepředpokládej.

Adresa odesílatele odmítnuta. Adresa from nebo její doména není u relaye ověřená. Ověř tam doménu a pak použij adresu na ní.

Zpráva dorazí, ale skončí ve spamu. Záznamy chybí nebo nejsou zarovnané. Zkontroluj hlavičky, jak je popsáno výše. Zkontroluj také, že doména nemá dva záznamy SPF a že DKIM je zapnutý v relayi, ne jen zveřejněný v DNS.

Volba newsletteru je zašedlá nebo Mailgun při odeslání vrátí chybu. Klíč API, region nebo doména jsou špatně nebo nenastavené. Nejdřív zkontroluj region v baseUrl; nesoulad vypadá jako špatný klíč.

Newsletter se odešle, ale členové nic nedostanou. Mailgun dávku přijal; doručení pak selhalo nebo zprávu zachytil filtr. Podívej se do logů Mailgunu pro daného příjemce, kde je vidět, zda byla zpráva doručena, vrácena, nebo označena jako spam.

Přihlašovací odkazy fungují pro některé adresy a pro jiné ne. Často jde o příjemce, který odmítá poštu při selhání SPF nebo DKIM, zatímco jiní jsou shovívavější. Oprav záznamy, ne vinu příjemcova poskytovatele.

Ghost na aplikačním serveru RE:NODE#

Ghost je jedna z řad s instalací na jedno kliknutí. Server Ghost při prvním startu nainstaluje a sestaví a data drží v SQLite na serveru, takže hlavní věc, kterou zbývá zařídit, je pošta. Soubor config.production.json upravuješ ve správci souborů nebo přes SFTP, případně nastavuješ proměnné prostředí na záložce Startup, a restartuješ z konzole. Aplikace na jedno kliknutí: WordPress, Ghost a Strapi popisují, co instalátor dělá.

Pro relay máš tři poctivé možnosti: poskytovatele transakčních e-mailů, vlastní SMTP Mailgunu, nebo řadu Stalwart Mail Server, pokud chceš poštu provozovat sám. Řada Mail Server má zdokumentovaný postup pro případ, že síť blokuje odchozí port 25: relay se nastaví v její webové administraci. Záznamy MX, SPF, DKIM a DMARC si v obou případech přidáváš sám. Pro příjem pošty z internetu na takovém serveru musí podpora přesměrovat port 25, ale Ghost nic přijímat nepotřebuje - jen odesílá.

FAQ#

Mohu posílat newslettery z Ghostu přes SMTP místo Mailgunu?

Ne. Cesta hromadné pošty v Ghostu je postavená na API Mailgunu. Nastavení SMTP nese jen transakční poštu, takže relay bude doručovat přihlašovací odkazy, ale nezapne možnost rozeslat příspěvek e-mailem.

Který port použít pro SMTP v Ghostu, 465 nebo 587?

Kterýkoli, pokud secure odpovídá: 465 s "secure": true, nebo 587 s "secure": false. Použij ten, který doporučuje tvůj relay. Port 25 nepoužívej; je určený pro doručování mezi servery a často je blokovaný.

Proč se přihlašovací odkaz dostane do spamu, když SPF prošlo?

Protože DMARC kontroluje zarovnání, ne jen prošlo/neprošlo. Pokud SPF projde pro doménu samotného relaye a pro tu tvou není nic podepsáno DKIM, doména From nesedí. Zapni DKIM pro svou doménu v relayi a zveřejni klíč, který ti dá.

Potřebuji pro newslettery samostatnou doménu?

Ne, ale subdoména jako mg.example.com je obvyklý vzor. Drží záznamy DNS Mailgunu odděleně od tvé běžné pošty a chrání pověst hlavní domény, kdyby odeslání dopadlo špatně.

Kde má být uložené heslo k SMTP?

V proměnné prostředí, třeba mail__options__auth__pass, a ne v souboru, který bys mohl sdílet. V obou případech se čte při startu, takže po změně Ghost restartuj. Změň ho, pokud se někdy objeví v logu nebo na snímku obrazovky.

Vyplatí se provozovat vlastní poštovní server jen kvůli Ghostu?

Obvykle ne. Ghost posílá málo transakční pošty a dobrý relay ti dá pověst a přehled doručování, které si nový server vydělává týdny. Vlastní poštu provozuj, pokud chceš schránky pod svou kontrolou, ne kvůli pár přihlašovacím odkazům.