sql >> Databáze >  >> RDS >> Mysql

Bezpečný způsob odesílání pošty přes PHP mnoha uživatelům

Není důvod, proč byste to nemohli napsat v PHP, i když já bych ne učinit z něj součást webového požadavku / procesu HTTP. Úspěšně jsem implementoval 500 000 odběratelů na e-mail (v závislosti na dostupných místních datech, protože se jednalo o projekt specifický pro dané místo). Byl to interní projekt, takže pro vás bohužel žádný kód/balíček, ale narazil jsem na několik ukazatelů:

Nastavení doručování

  • Začal jsem se samotným phpmailerem, který se stará o formátování, kódování obsahu a hlaviček, přidávání příloh atd. Tato část funguje dobře a nechtěl bych to psát od začátku.
  • Samotné „odeslání“ e-mailu je pouze nastavením příznaku v databázi, zda/jak/co má být zasláno (části) odběratelům.
  • Po nastavení tohoto příznaku jej automaticky vyzvedne cronjob, žádný další webový server.
  • Začal jsem se silně znečištěnou databází s miliony e-mailových adres, z nichž hodně byly zjevně neplatné, takže první věcí bylo ověřit u všech e-mailových adres formát a poté hostitel:
    • filter_var($email, FILTER_VALIDATE_EMAIL); přes odběratele (a samozřejmě uložení výsledku) zbavili prvních několik set tisíc neplatných e-mailů.
    • Rozdělení hostitele (a uložení název hostitele) z e-mailů a ověření toho (má záznam MX nebo alespoň A v DNS, ale mějte na paměti:e-mail můžete odeslat na IP adresu [email protected][255.255.255.255] , tak si je ponechte v platnosti)) se zbavili o pořádnou porci víc. Zde uvedené e-mailové adresy nejsou trvale zakázáno, ale se stavovým příznakem, který označuje, že jsou zakázány kvůli názvu domény / ip.
    • Skripty byly změněny na vyžadovat platné e-mailové adresy při odběru / před vložením, tento nesmysl 'nedostanete example@ sqldat.com ' Subscription-pollution v databázi bylo prostě směšné.
  • Nyní jsem skončil se seznamem e-mailových adres, které mohly být platné. V podstatě existují 3 způsoby, jak zjistit neplatné adresy (mějte na paměti, vše může být dočasné):
    • Server je okamžitě zamítne.
    • Dříve určený server prostě nenaslouchá provozu.
    • Jsou vráceny dlouho poté, co jste si mysleli, že jste je doručili.
  • Zvláštní věc, bounces, o kterých se zdá, že každý e-mailový server má jiný formát a zpočátku je bylo možné pekelně analyzovat, nakonec bylo docela snadné zachytit pomocí VERP . Spíše než analýzu celých e-mailů, vyhrazenou e-mailovou adresu (říkejme jí exdatle@datqcom a> ) byl nakonfigurován tak, aby spíše než doručoval do poštovní schránky, prováděl jej prostřednictvím příkazu, a pokud jsme odeslali e-mail na [email protected] , Return-Path byla nastavena pro [email protected] . Snadno se analyzuje při přijetí a po kolika vrácených zprávách (schránka nemůže existovat, schránka může být plná (ano, stále!) atd.) prohlásíte e-mailovou adresu za nepoužitelnou, záleží jen na vás.
  • Nyní přímé odmítnutí ze strany serveru. Pravděpodobně jsme mohli jít s řádnou konfigurací některých MTA a / nebo psaní pluginů pro ně, ale protože e-maily byly časově citlivé a museli jsme mít absolutní konfigurovatelnou kontrolu pro každou zásilku nad poslední použitelnou dobou doručení (po níž e-mail nebyl delší uživatele), omezení na přijímající server a obecně vše, přibližně stejně dlouho by trvalo napsat mailer v PHP, které jsme znali lépe a který používal protokol SMTP přímo do soketu 25 na přijímacích serverech. S minimálním úsilím byla vestavěna možnost jiného přenosu než výchozí volby v PHPMailer. Protokol SMTP je ve skutečnosti docela jednoduchý, ale existují některá upozornění:
    • Mnoho přijímajících serverů používá šedý výpis:většině spambotů bude opravdu jedno, jestli přijde konkrétní e-mail, prostě je chrlí. Pokud tedy neznámý / dosud nedůvěryhodný odesílatel odešle e-mail, bude dočasně odmítnut. Zachyťte to (obvykle kód 451) a umístěte e-mail do fronty pro pozdější opakování.
    • Poštovní server, zejména větších poskytovatelů internetových služeb a bezplatné služby (gmail, hotmail/msn/live atd.), nevydrží příval pošty, aniž by se bránil:po prvních několika stovkách/tisících začnou odmítat vy. Více o tom později.

Zrychlení

  • Nyní jsme měli systém doručování, který fungoval, ale musel být rychlý . Odeslání 10 000 e-mailů za hodinu je v pořádku, pokud máte k odeslání pouze 10 000 adres, ale minimum, které jsme požadovali, bylo asi 200 000 za hodinu. Na začátku byl dedikovaný server (který může mít ve skutečnosti docela nízký výkon, bez ohledu na to, co děláte, většina času, který zabere doručení e-mailu, je v síti, ne na vašem serveru).
  • Ukládání IP do mezipaměti:pamatujete si všechny ty IP, které jsme požadovali od názvů hostitelů v e-mailových adresách? Zjevně jsme je uložili a vyhledávání jejich IP znovu a znovu způsobuje značné zpoždění. IP adresy se však mohou změnit:DNS záznam tam, další MX na jiném místě... data rychle zatuchnou. Většinu času server ve skutečnosti nic neposílá (zpravodaje s předplatným očividně přicházejí v dávkách), běží cronjob s nízkou prioritou, který kontroluje IP adresu všech názvů hostitelů se zastaralou IP (vybrali jsme starší než 1 den) , včetně těch, které dříve žádné neměly (nové domény se registrují neustále, tak proč by doména nemohla být dostupná den poté, co se někdo již nadšeně přihlásil se svou zbrusu novou emailovou adresou? Nebo jsou vyřešeny problémy se serverem s nějakou doménou atd.). Odesílání e-mailů nyní nevyžaduje žádné další vyhledávání domén.
  • Opětovné použití připojení SMTP:Nastavování připojení k serveru zabere relativně velkou část času doručení e-mailu, když mluvíte přímo na portu 25. Nemusíte nastavovat nové připojení pro každý e-mail, můžete odeslat další přes stejné připojení. Trocha tras a chyb vedla k nastavení výchozího nastavení na přibližně 50 e-mailů na připojení (za předpokladu, že jich máte pro doménu tolik nebo více). Při selhání e-mailové adresy však někdy pomohlo uzavření a opětovné otevření připojení pro opakování. Celkově vzato, toto opravdu pomohl urychlit věci.
  • Nějaký zřejmý, tak zřejmý, že jsem ho skoro zapomněl zmínit:bylo by zbytečné vytvářet tělo e-mailu na místě:pokud se jedná o obecný mail, mějte tělo připravené (poněkud jsem upravil PHPMailer na být schopen používat e-maily uložené v mezipaměti), možná několik dní předem (pokud chystáte se odeslat e-mail v pátek a váš server je nečinný, proč je nepřipravit již ve středu? Pokud je to personalizované, stále byste si to mohli připravit předem, pokud máte dostatek času, pokud ne, nechte si na odjezd alespoň nepersonalizované porce.
  • Více procesů. Zmínil jsem se, že hodně času, který zabere doručení e-mailu, stráví v síti? Jeden poštovní proces zdaleka nevytěžuje maximum z vašeho e-mailového serveru, sotva znatelné zatížení a e-maily odtékají. Pohrajte si s řadou procesů odesílajících různé části fronty, abyste zjistili, co je pro váš server/připojení správné, ale nezapomeňte na 2 velmi důležité věci:
    • Různé procesy vás činí velmi zranitelnými vůči rasovým podmínkám:buďte si úplně jisti máte plně odolný systém, který nikdy nebude poslat stejnou poštu dvakrát (třikrát nebo ještě více). Nejen, že to vážně obtěžuje uživatele, ale vaše spamování jde o stupeň výš.
    • Pokud je to možné, držte domény pohromadě:náhodným výběrem z fronty ztratíte výhodu zachování otevřeného připojení k serveru, který přijímá e-maily pro doménu.

Předcházení odmítnutí

  • Budete posílat hodně pošty. To je přesně to, co spammeři dělají. Nechcete však být vnímáni jako spammer (koneckonců nejste, že)? Existuje řada mechanismů, které důkladně zvýší vaši důvěryhodnost vůči přijímajícím serverům:
  • Mějte správný reverzní DNS:procesy kontrolující DNS patřící k IP adrese, která odesílá e-mail, velmi hodně, pokud se domény druhé úrovně shodují:posíláte poštu jménem example.com ? Ujistěte se, že reverzní DNS vašeho serveru je něco jako somename.example.com .
  • Publikujte záznamy SPF pro vaši doménu:výslovně uveďte, že stroj používaný k odesílání vašich hromadných e-mailů je povolen a očekává se, že bude odesílat poštu s těmito záhlavími From / Return-Path.
  • pamatujte si odmítnutí :servery nemají rády, když vám znovu a znovu říkají, že různé e-mailové adresy neexistují. Buď automatizované mechanismy, a dokonce i lidští administrátoři, zablokovali náš server, když jsme procházeli všechny neověřené e-mailové adresy, které (již) neexistovaly. Dvojité přihlášení jsme použili až později, takže databáze byla znečištěná překlepy, lidé si přepínali IP adresy a tím i e-mailové adresy, žertovné e-mailové adresy a tak dále. Ujistěte se, že jste tyto neplatné zachytili, a pokud máte dostatek nebo dost vážných selhání, odhlaste je . Nedělají vám dobře, okrádají zdroje, a pokud opravdu chtějí, abyste vám poslali poštu a poštovní schránka byla k dispozici později, budou se muset znovu přihlásit.
  • DKIM je další mechanismus, který může zvýšit vaši důvěryhodnost, ale protože jsme jej (zatím) nezavedli, nemohu vám o tom mnoho říct.
  • Záznamy MX:některým serverům se to stále líbí, pokud je váš odesílající server zároveň přijímajícím serverem pro doménu. V té době jsme měli pouze 1 MX, a protože poštovní server stále nebyl tak vytížený, nazvali jsme jej záložním MX serverem pro doménu. Normální server MX nebyl server odesílající odběry, protože je velmi nepříjemné být dočasně blokován serverem, kterému se pokoušíte poslat důležitý e-mail (klienti atd.), protože jste již odeslali množství méně důležité pošty. Má sice nejvyšší preferenci jako příjem MX, ale v případě, že by selhal, měli jsme ten příjemný bonus v tom, že náš server pro odesílání předplatného by byl stále záložní pro doručování, takže v krizi jsme se k němu mohli stále dostat, čímž jsme zabránili nepříjemným odrazům od zákazníků, kteří se snaží k nám.
  • Řekni jim o sobě. Vážně. Mnoho velkých hráčů na bezplatných e-mailových adresách, jako je live.com, vám nabízí možnost se nějakým způsobem zaregistrovat nebo mít nějaký kontaktní bod, na který můžete zajít pro pomoc a podporu, pokud budou vaše e-maily odmítnuty. Pokud máte legitimní důvod posílat tolik e-mailů, a je uvěřitelné, že máte tolik odběratelů, je pravděpodobné, že vážně zvýší počet e-mailů, které můžete poslat na jejich server za hodinu. Hubená 1000 se může stát někde v desetitisících nebo ještě výš, pokud budete dostatečně přesvědčiví a upřímní. Mohou existovat smlouvy, požadavky, které musíte splnit, a sliby, které musíte učinit (a dodržet), aby vám to bylo dovoleno. ISP jsou jedna značka a každý jiný hráč je jiný. Neobtěžujte se jim obvykle volat, protože 99 % času jediná čísla, která najdete, budou mít pouze lidé ochotní řešit problémy s vaším internetovým připojením, kteří rozumí (nebo jsou povoleni) jen málo jinému. [email protected] e-mailová adresa je dobré místo, kde začít, ale zjistěte, zda odněkud nemůžete získat podrobnější e-mailovou adresu. Buďte přesní, upřímní a kompletní:přibližně kolik z vás má e-mailovou adresu u tohoto ISP, jak často se jim snažíte poslat e-mail, jaké chyby nebo zamítnutí obdržíte, jak vypadá proces přihlášení a odhlášení a co službu, kterou skutečně poskytujete jejich zákazníkům. Buďte také milí:jak životně důležité může být odesílání těchto e-mailů pro vaši firmu, panikaření z toho a tvrzení o hrozných ztrátách se jich netýká. Zdvořilé prohlášení o faktech a přáních a ptání se zda mohou pomoci spíše než požadovat řešení, je velmi dlouhá cesta.
  • Omezování:jakkoli jste se snažili, některý server od vás přijme pouze určité množství pošty za hodinu a/nebo den. Naučte se tato čísla (stejně zaznamenáváme úspěchy a neúspěchy), nastavte je na rozumnou výchozí hodnotu pro normální domény a nastavte je na dohodnuté limity pro větší hráče.

Abyste nebyli označeni jako spam

  • První pravidlo:nerozesílejte spam!
  • Druhé pravidlo:vždy! Nikoli „jednorázové“, ani „nepřihlásili se k odběru, ale může to být pro ně celoživotní záležitost“, ne s nejlepšími úmysly, lidé vás museli žádat o vaše e-maily.
  • Samozřejmě nastavte správný mechanismus dvojitého přihlášení k odběru.
  • PHPMailer nastavuje správná záhlaví sám,
  • Nastavte mechanismus snadného odhlašování prostřednictvím webu (odkaz na něj uveďte v každém mail), případně také e-mail a zákaznický servis, pokud jej máte. Ujistěte se, že zákaznický servis může přímo odhlásit lidi.
  • Jak již bylo řečeno:odhlášení z odběru (nadměrné množství) selhává a vrací zpět.
  • Vyhněte se spamovým formulacím „dohoda na celý život“.
  • Používejte adresy URL ve svých e-mailech střídmě.
  • Nepřidávejte odkazy na domény mimo vaši kontrolu, pokud si nejste absolutně jisti, že jim můžete důvěřovat nespamovat, i když...
  • Poskytujte uživateli hodnotu:označení jako spam uživatelskou interakcí v klientech webové pošty google/yahoo/live vážně poškozuje budoucí úspěchy (poznámka k webu:pokud se k odběru přihlásíte, live/msn/hotmail přepošle všechny e-mail, který vám posílá vaše doména, který je uživateli označen jako spam. Naučte se ho milovat a jako vždy:zrušte jeho odběr, zjevně nechtějí vaše obchodní centrum a poškozují vaše hodnocení spamu).
  • Sledujte seznam zakázaných adres IP. Pokud se objevíte na jednom z nich, je sbohem, takže okamžitě začněte očištěním svého jména a je vyžadováno určení případu.

Měření úspěšnosti

  • Když máte celý proces pod kontrolou, jste si přiměřeně jisti, že e-mail skončil někde (ačkoli to může být bitbucket MX nebo složka se spamem), nebo jste zaznamenali selhání a důvod proč. To se postará o „skutečně doručená“ čísla.
  • Někteří lidé se vás budou snažit přesvědčit, abyste do svých e-mailů přidali odkazy na online obrázky (buď skutečné, nebo slavný průhledný gif 1x1), aby změřili, kolik lidí si váš e-mail skutečně přečte. Vzhledem k tomu, že vysoké procento tyto obrázky blokuje, jsou tato čísla přinejlepším nestálá a věříme, že bychom se jimi neměli obtěžovat, jejich čísla jsou naprosto nespolehlivá.
  • Měření skutečné úspěšnosti je mnohem jednodušší, pokud chcete, aby uživatelé něco udělali. Přidejte parametry k odkazům v e-mailu, abyste mohli měřit, kolik uživatelů přichází na odkazovaný web, zda provedli požadované akce (zhlédli video, zanechali komentář, zakoupili zboží).

Sečteno a podtrženo, se vším logováním, uživatelským rozhraním, konfigurovatelnými nastaveními pro doménu / e-mail / uživatele atd. Trvalo nám asi 1,5 člověkoměsíce, než jsme vytvořili a vyžehlili vtípky. To může být docela investice ve srovnání s outsourcingem e-mailů, nemusí být, vše závisí na objemu a samotném podnikání.

A teď začněte hořet, že jsem byl blázen, když jsem napsal MTA v PHP, já jsem si to užil (což je jeden z důvodů, proč jsem napsal tak obrovské množství textu), a extrémně všestranné možnosti protokolování a nastavení pro každého hostitele výstrahy založené na procentu selhání atd. dělají život tak snadným;)



  1. Dotaz Oracle k načtení názvů sloupců

  2. mysql příkaz min where

  3. Adaptivní server je nedostupný nebo neexistuje chyba při připojování k SQL Serveru z PHP

  4. Poddotaz Oracle nevidí proměnnou z vnějšího bloku o 2 úrovně výše