Veilige manier om e-mail via PHP naar veel gebruikers te sturen

Er is geen reden waarom je het niet in PHP zou kunnen schrijven, hoewel ik het niet zou doen maak het onderdeel van een webverzoek / HTTP-proces. Ik heb met succes 500.000 abonnees per mailing geïmplementeerd voor geven of nemen (afhankelijk van de beschikbare lokale gegevens, aangezien dit een locatiespecifiek project was). Het was een intern project, dus helaas geen code/pakket voor jullie, maar enkele tips die ik tegenkwam:

Bezorging instellen

• Begon met phpmailer zelf, om te zorgen voor opmaak, codering van inhoud en kopteksten, het toevoegen van bijlagen enz. Dat gedeelte ervan werkt goed, en ik zou dat niet helemaal opnieuw willen schrijven.
• Het 'verzenden' van een e-mail zelf is gewoon het instellen van een vlag in een database of / hoe / wat er naar (een deel van) de abonnees moet worden verzonden.
• Nadat deze vlag is ingesteld, wordt deze automatisch opgepikt door een cronjob, er is geen webserver meer bij betrokken.
• Ik begon met een zwaar vervuilde database met miljoenen e-mailadressen, waarvan veel waren duidelijk niet geldig, dus eerst moesten alle e-mailadressen worden gevalideerd voor formaat en vervolgens voor host:
  • filter_var($email, FILTER_VALIDATE_EMAIL); over de abonnees (en het opslaan van het resultaat uiteraard) de eerste paar honderdduizend ongeldige e-mails verwijderd.
  • De host uitsplitsen (en opslaan de hostnaam) uit de e-mails, en dat valideren (heeft het een MX of op zijn minst een A-record in DNS, maar onthoud:je kunt een e-mail sturen naar een IP-adres [email protected][255.255.255.255] , dus houd die geldig)) een flink deel meer kwijt. De e-mailadressen hier zijn niet permanent uitgeschakeld, maar met een statusvlag die aangeeft dat ze zijn uitgeschakeld vanwege de domeinnaam / ip.
  • Scripts zijn gewijzigd in require geldige e-mailadressen bij inschrijving / vóór invoeging, deze onzin van 'u krijgt geen voorbeeld@ sqldat.com ' abonnement-vervuiling in de database was gewoon belachelijk.
• Nu kreeg ik een lijst met e-mailadressen die mogelijk geldig waren. Er zijn in wezen 3 manieren om ongeldige adressen te detecteren (houd er rekening mee dat de alle kan tijdelijk zijn):
  • Ze worden onmiddellijk geweigerd door de server.
  • De eerder vastgestelde server luistert gewoon niet naar verkeer.
  • Ze worden teruggestuurd lang nadat je dacht dat je ze bezorgd had.
• Vreemd, de bounces, waarvoor elke e-mailserver een ander formaat lijkt te hebben en in het begin een hel waren om te analyseren, waren uiteindelijk vrij eenvoudig vast te leggen met VERP . In plaats van hele e-mails te ontleden, gebruikt u een speciaal e-mailadres (laten we het [email protected] ) is geconfigureerd om eerder dan af te leveren aan mailbox, om het via een commando te pipen, en als we een e-mail sturen naar [email protected] , het Return-Path is ingesteld voor [email protected] . Gemakkelijk te ontleden bij ontvangst, en na hoeveel bounces (mailbox kon niet bestaan, mailbox is misschien vol (ja, nog steeds!), etc.) dat je een e-mailadres onbruikbaar verklaart, is aan jou.
• Nu, de directe weigering door de server. Waarschijnlijk hadden we daarvoor een aantal MTA- en/of schrijfplug-ins goed kunnen configureren, maar omdat de e-mails tijdgevoelig waren en we per mailing absoluut configureerbare controle moesten hebben over de laatste bruikbare bezorgtijd (waarna de e-mail niet langer interessant voor de gebruiker), beperking per ontvangende server, en in het algemeen alles, het zou ongeveer dezelfde tijd kosten om een ​​mailer in PHP te schrijven die we beter kenden, die het SMTP-protocol rechtstreeks naar socket 25 op ontvangende servers gebruikte. Met een minimale inspanning werd de mogelijkheid van een ander transport dan de standaard keuzes in PHPMailer ingebouwd. Het SMTP-protocol is eigenlijk vrij eenvoudig, maar er zijn enkele kanttekeningen:
  • Veel ontvangende servers passen een grijze lijst toe:de meeste spambots zullen het niet erg vinden als een specifieke e-mail binnenkomt, ze verspreiden ze gewoon. Dus als een onbekende/nog niet vertrouwde afzender mail verstuurt, wordt deze tijdelijk geweigerd. Vang dat op (meestal code 451) en plaats de e-mail in de wachtrij om het later opnieuw te proberen.
  • Een mailserver, vooral van de grotere ISP's en gratis diensten (gmail, hotmail/msn/live, etc.) zal niet staan ​​voor een stortvloed van mail zonder terug te vechten:na de eerste paar honderd/duizend beginnen ze te weigeren jij. Daarover later meer.

Snelheid krijgen

• We hadden nu een bezorgsysteem dat werkte, maar het moest snel zijn . Het verzenden van 10.000 e-mails in een uur is prima als je maar 10.000 adressen hebt om naar te verzenden, maar het minimum dat we nodig hadden was ongeveer 200.000 per uur. Het begon met een dedicated server (die eigenlijk vrij laag vermogen kan hebben, wat je ook doet, de meeste tijd die nodig is voor het bezorgen van e-mail is in het netwerk, niet op je server).
• Caching van IP's:herinner je je al die IP's die we van hostnamen in e-mailadressen hebben opgevraagd? Die hebben we natuurlijk opgeslagen, en het steeds weer opzoeken van hun IP's zorgt voor een behoorlijke vertraging. IP's kunnen echter veranderen:een DNS-record daar, een andere MX op een andere plaats ... de gegevens worden snel oud. Meestal verzendt de server eigenlijk niets (abonnementsnieuwsbrieven komen uiteraard in bursts), een cronjob met lage prioriteit wordt uitgevoerd om alle hostnamen met een oud IP-adres (we kozen ouder dan 1 dag als oud) te controleren op een IP-adres , inclusief degenen die er voorheen geen hadden (er worden steeds nieuwe domeinen geregistreerd, dus waarom zou een domein niet de dag beschikbaar komen nadat iemand zich al enthousiast heeft aangemeld met zijn/haar gloednieuwe e-mailadres? Of serverproblemen met een domein zijn opgelost, enz.). Het daadwerkelijk verzenden van de e-mails vereist nu geen domeinzoekacties meer.
• Hergebruik van de SMTP-verbinding:het opzetten van een verbinding met een server kost relatief een groot deel van de tijd om een ​​e-mail af te leveren als je rechtstreeks met poort 25 praat. Je hoeft niet voor elke e-mail, kunt u de volgende gewoon via dezelfde verbinding verzenden. Een beetje trail-and-error heeft ertoe geleid dat de standaard hier is ingesteld op ongeveer 50 e-mails per verbinding (ervan uitgaande dat je er zoveel of meer hebt voor het domein). Bij het mislukken van een e-mailadres hielp het echter soms om de verbinding te sluiten en opnieuw te openen voor een nieuwe poging. Al met al is dit echt hielp de zaken te versnellen.
• Een voor de hand liggende, zo voor de hand liggende dat ik het bijna vergat te vermelden:het zou zonde zijn om ter plekke de hoofdtekst van de e-mail te moeten maken:als het een algemene e-mail is, moet u de hoofdtekst gereed hebben (ik heb PHPMailer enigszins gewijzigd om in staat zijn om een ​​e-mail in de cache te gebruiken), mogelijk dagen ervoor (als u weet je gaat vrijdag een mail sturen, en je server staat inactief, waarom zou je ze woensdag niet al voorbereiden? Als het gepersonaliseerd is, kun je het nog steeds van tevoren voorbereiden, als je genoeg tijd hebt, zo niet, laat dan in ieder geval de niet-gepersonaliseerde porties wachten om te gaan.
• Meerdere processen. Had ik al gezegd dat een groot deel van de tijd die nodig is om e-mail te bezorgen, wordt besteed aan het netwerk? Eén mailingproces haalt lang niet het maximale uit je e-mailserver, nauwelijks merkbare belasting en de mails druppelen eruit. Speel met een aantal processen die verschillende delen van de wachtrij mailen om te zien wat goed is voor uw server/verbinding, maar onthoud 2 zeer belangrijke dingen:
  • Verschillende processen maken je erg kwetsbaar voor race-omstandigheden:wees absoluut zeker je hebt een volledig beveiligd systeem dat nooit . zal stuur dezelfde e-mail twee keer (driemaal, of zelfs meer). Niet alleen irriteert het gebruikers, je spamrating gaat een stuk omhoog.
  • Houd domeinen waar mogelijk bij elkaar:als u willekeurig uit de wachtrij kiest, verliest u het voordeel van een open verbinding met de server die e-mail voor het domein ontvangt.

Afwijzingen vermijden

• Je gaat veel post versturen. Dat is precies wat spammers doen. U wilt echter niet als spammer worden gezien (u bent het toch niet)? Er zijn een aantal mechanismen die uw betrouwbaarheid voor het ontvangen van servers aanzienlijk zullen vergroten:
• Zorg voor een goede reverse DNS:processen die de DNS controleren die hoort bij het IP-adres dat de e-mail verzendt, zoals deze zeer veel als de domeinen van het tweede niveau overeenkomen:verzendt u e-mail namens example.com ? Zorg ervoor dat de omgekeerde DNS van uw server zoiets is als eennaam.voorbeeld.com .
• Publiceer SPF-records voor uw domein:geef expliciet aan dat de machine die wordt gebruikt om uw bulk-e-mail te verzenden, e-mail mag verzenden met die Van / Return-Path-headers.
• onthoud afwijzingen :servers houden er niet van om u keer op keer te vertellen dat verschillende e-mailadressen niet bestaan. Ofwel geautomatiseerde mechanismen, en zelfs menselijke beheerders, blokkeerden onze server terwijl we alle niet-gevalideerde e-mailadressen verwerkten die (niet meer) bestonden. We hebben pas later een dubbele opt-in gebruikt, dus de database was vervuild met typefouten, mensen die van IP wisselden en daardoor van e-mailadres, prank-e-mailadressen enzovoort. Zorg ervoor dat u die ongeldige personen vastlegt, en als er genoeg of voldoende fouten zijn, schrijf ze uit . Ze doen je geen goed, ze vreten middelen aan, en als ze je mail echt willen en de mailbox later beschikbaar komt, moeten ze zich gewoon opnieuw abonneren.
• DKIM is een ander mechanisme dat uw betrouwbaarheid kan vergroten, maar aangezien we het (nog) niet hebben geïmplementeerd, kan ik u daar niet veel over vertellen.
• MX-records:sommige servers vinden het nog steeds prettig als uw verzendende server ook de ontvangende server voor het domein is. Zoals het toen was, hadden we maar 1 MX, en omdat de mailingserver nog niet zo druk was, noemden we het de fallback MX-server voor het domein. De normale MX-server was niet de server die de abonnementen verzendt, omdat het erg irritant is om tijdelijk te worden geblokkeerd door een server waarnaar u een belangrijke e-mail probeert te sturen (klanten enz.), omdat u al een lading minder belangrijke e-mail hebt verzonden. Het heeft de hoogste voorkeur voor het ontvangen van MX, maar in het geval dat het zou mislukken, hadden we de leuke bonus dat onze server voor het verzenden van abonnementen nog steeds een terugval zou zijn voor bezorging, dus in een crisis konden we er nog steeds bij komen, waardoor onhandige bounces voor klanten die probeerden om ons te bereiken.
• Vertel ze over jou. Ernstig. Veel grote spelers in gratis e-mailadressen zoals live.com bieden je de mogelijkheid om je op de een of andere manier aan te melden, of een contactpersoon te hebben waar je heen kunt gaan voor hulp en ondersteuning als je e-mails worden afgewezen. Als je een legitieme reden hebt om zoveel e-mails te verzenden, en het is aannemelijk dat je zoveel abonnees hebt, is de kans groot dat ze het aantal e-mails dat je per uur naar hun server kunt sturen serieus verhogen. Een schamele 1.000 kan ergens in de tienduizenden worden of zelfs hoger als je overtuigend en eerlijk genoeg bent. Er kunnen contracten zijn, eisen waaraan u moet voldoen en toezeggingen die u moet doen (en nakomen) om dit te mogen doen. ISP's zijn een apart merk en elke andere speler is anders. Bel ze meestal niet, want 99% van de tijd zijn de enige nummers die u kunt vinden alleen mensen die bereid zijn om problemen met uw internetverbinding op te lossen, die weinig anders begrijpen (of zijn toegestaan). Een [email protected] e-mailadres is een goede plek om te beginnen, maar kijk of je ergens een meer to-the-point e-mailadres kunt vinden. Wees precies, eerlijk en volledig:hoeveel abonnees van jullie hebben ongeveer een e-mailadres bij die ISP, hoe vaak probeer je ze te mailen, wat zijn de fouten of weigeringen die je ontvangt, hoe verloopt het aan- en afmeldproces en wat is de service die u daadwerkelijk aan hun klanten levert. Wees ook aardig:hoe belangrijk het verzenden van die e-mails voor uw bedrijf kan zijn, in paniek raken en enorme verliezen claimen, gaat hen niet aan. Een beleefde verklaring van feiten en wensen, en vragen of ze kunnen helpen in plaats van een oplossing te eisen, gaat heel ver.
• Beperking:hoeveel je ook hebt geprobeerd, sommige servers zullen slechts een bepaalde hoeveelheid e-mail per uur en/of dag van je accepteren. Leer die cijfers (we registreren hoe dan ook successen en mislukkingen), stel ze in op een redelijke standaard voor de normale domeinen, stel ze in op overeengekomen limieten voor grotere spelers.

Voorkomen dat u als spam wordt getagd

• Eerste regel:spam niet!
• Tweede regel:ooit! Geen 'eenmalig', niet een 'ze hebben zich niet geabonneerd, maar dit kan voor hen de deal van hun leven zijn', niet met de beste bedoelingen, mensen hebben om je e-mails moeten vragen.
• Het is duidelijk dat u een correct abonnementsmechanisme voor dubbele aanmelding heeft ingesteld.
• PHPMailer stelt zelf de juiste headers in,
• Stel een eenvoudig afmeldmechanisme in via internet (voeg een link ernaar toe in elke mail), eventueel ook e-mail en klantenservice als je die hebt. Zorg ervoor dat de klantenservice kan mensen direct uitschrijven.
• Zoals eerder gezegd:afmelden (overmatig) mislukt &stuitert.
• Vermijd spamachtige 'deal of a lifetime'-bewoordingen.
• Gebruik url's spaarzaam in uw e-mails.
• Vermijd het toevoegen van links naar domeinen buiten uw controle, tenzij u absoluut zeker weet dat u ze kunt vertrouwen niet spammen, zelfs dan...
• Bied waarde aan de gebruiker:getagd worden als spam door gebruikersinteractie in google/yahoo/live webmailclients schaadt toekomstige successen ernstig e-mail die door uw domein naar u is verzonden en die door gebruikers als spam is gemarkeerd. Leer ervan te houden, en zoals altijd:schrijf ze uit, ze willen uw winkelcentrum duidelijk niet en schaden uw spambeoordeling).
• Bewaak zwarte lijsten voor uw IP. Als je op een van deze verschijnt, is het tot ziens, dus kom onmiddellijk tot actie door zowel je naam te zuiveren en het bepalen van de zaak is vereist.

Succespercentage meten

• Met het hele proces onder jouw controle, ben je er redelijk zeker van dat de e-mail ergens terecht is gekomen (hoewel het de bitbucket van de MX of een spammap kan zijn), of je hebt een fout geregistreerd en de reden waarom. Dat zorgt voor de 'daadwerkelijk geleverde' nummers.
• Sommige mensen zullen proberen u te overtuigen om links naar online afbeeldingen toe te voegen aan uw e-mails (echte of de beroemde 1x1 transparante gif) om te meten hoeveel mensen uw e-mail daadwerkelijk lezen. Aangezien een hoog percentage die afbeeldingen blokkeert, zijn deze cijfers op zijn best wankel, en we zijn van mening dat we ons er gewoon niet mee moeten bemoeien, hun cijfers zijn volkomen onbetrouwbaar.
• Uw beste gok voor het meten van het werkelijke succespercentage is een stuk eenvoudiger als u wilt dat de gebruikers iets doen. Voeg parameters toe aan links in de e-mail, zodat u kunt meten hoeveel gebruikers op de door u gelinkte site aankomen, of ze de gewenste acties hebben uitgevoerd (een video bekeken, een opmerking achtergelaten, goederen gekocht).

Al met al, met alle logging, de gebruikersinterface, configureerbare instellingen per domein / e-mail / gebruiker enz. Het kostte ons ongeveer 1,5 manmaand om de eigenaardigheden op te bouwen en glad te strijken. Dat kan een behoorlijke investering zijn in vergelijking met het uitbesteden van de e-mails, misschien niet, het hangt allemaal af van het volume en de business zelf.

Nu, laat het vlammende beginnen dat ik een dwaas was om een ​​MTA in PHP te schrijven, ik heb er enorm van genoten (wat een reden is dat ik deze enorme hoeveelheid tekst heb geschreven), en de extreem veelzijdige mogelijkheden voor logging en instellingen, per host alerts op basis van uitvalpercentage etc. maken live oh zo makkelijk;)