Säkert sätt att skicka e-post via PHP till många användare

Det finns ingen anledning till varför du inte kunde skriva det i PHP, även om jag inte skulle göra det gör det till en del av en webrequest/HTTP-process. Jag har framgångsrikt implementerat för ge eller ta 500 000 prenumeranter per utskick (beroende på lokal information tillgänglig, eftersom detta var ett platsspecifikt projekt). Det var ett internt projekt, så tyvärr ingen kod/paket för dig, men några tips jag stötte på:

Ställa in leverans

Började med phpmailer själv, för att ta hand om formatering, kodning av innehåll och rubriker, lägga till bilagor etc. Den delen av det fungerar bra, och jag skulle inte vilja skriva det från början.
Sändningen av ett e-postmeddelande i sig ställer bara in en flagga i en databas om / hur / vad som ska skickas till (en del av) prenumeranterna.
När denna flagga har ställts in kommer den automatiskt att hämtas av en cronjob, ingen mer webbserver inblandad.
Jag började med en kraftigt förorenad databas med miljontals e-postadresser, varav mycket var uppenbart ogiltiga, så det första var att validera alla e-postadresser för format, sedan för värd:
- filter_var($email, FILTER_VALIDATE_EMAIL); över prenumeranterna (och att lagra resultatet så klart) blev av med de första hundra tusen ogiltiga e-postmeddelandena.
- Dela upp värden (och lagring värdnamnet) från e-postmeddelandena, och validera det (har det en MX- eller åtminstone en A-post i DNS, men kom ihåg:du kan skicka e-post till en IP-adress [email protected][255.255.255.255] , så håll de giltiga)) blev av med en bra del till. E-postadresserna här är inte permanent inaktiverade, men med en statusflagga som indikerar att de är inaktiverade på grund av domännamnet/ip.
- Skript ändrades till kräver giltiga e-postadresser vid prenumeration / före införandet, detta nonsens av 'du kommer inte få exempel sqldat.com ' prenumerationsföroreningar i databasen var bara löjliga.
Nu fick jag en lista över e-postadresser som hade potential att vara giltiga. Det finns i huvudsak tre sätt att upptäcka ogiltiga adresser (tänk på att alla kan vara tillfälligt):
- De nekas omedelbart av servern.
- Den tidigare bestämda servern lyssnar helt enkelt inte på trafik.
- De studsar långt efter att du trodde att du levererade dem.
Konstigt, studsarna, som varje e-postserver verkar ha ett annat format för och var ett helvete att analysera först, slutade faktiskt ganska lätt att fånga med VERP . Istället för att analysera hela e-postmeddelanden, en dedikerad e-postadress (låt oss kalla den lexample@sq">lexample.com a> ) konfigurerades för att istället leverera till postlådan, för att skicka det genom ett kommando, och om vi skickade e-post till [email protected] , Return-Path var inställd för [email protected] . Lätt att analysera vid mottagandet, och efter hur många avvisningar (brevlådan kunde inte existera, postlådan kan vara full (ja, fortfarande!), etc.) du förklarar att en e-postadress är obrukbar är upp till dig.
Nu, direkt förnekande av servern. Förmodligen kunde vi ha gått med att korrekt konfigurera vissa MTA och/eller skriva plugins för dessa, men eftersom e-postmeddelandena var tidskänsliga, och vi var tvungna att ha absolut konfigurerbar kontroll per utskick över den senaste användbara leveranstiden (efter vilken e-postmeddelandet inte var längre av intresse för användaren), strypning per mottagande server och i allmänhet allt, det skulle ta ungefär samma tid att skriva en mailer i PHP som vi visste bättre, som använde SMTP-protokollet direkt till socket 25 på mottagande servrar. Med en minimal ansträngning var möjligheten till en annan transport då standardvalen i PHPMailer inbyggda. SMTP-protokollet är faktiskt ganska enkelt, men det finns några varningar:
- Många mottagande servrar tillämpar grå listning:de flesta spambots bryr sig inte riktigt om en specifik e-post kommer, de bara tar bort dem. Så om en okänd / ännu inte betrodd avsändare skickar e-post, kommer den att avvisas tillfälligt. Fånga det (vanligtvis kod 451) och placera e-postmeddelandet i kön för att senare försöka igen.
- En e-postserver, särskilt av de större ISP:erna och gratistjänsterna (gmail, hotmail/msn/live, etc.) kommer inte att stå för en ström av e-post utan att slå tillbaka:efter de första hundra/tusen börjar de avvisa du. Mer om det senare.

Få fart

Nu hade vi ett leveranssystem som fungerade, men det behövde vara snabbt . Att skicka 10 000 e-postmeddelanden på en timme är okej om du bara har 10 000 adresser att skicka till, men det lägsta vi krävde var cirka 200 000 per timme. Början av det var en dedikerad server (som faktiskt kan ha ganska låg effekt, oavsett vad du gör, det mesta av tiden för leverans av e-post är i nätverket, inte på din server).
Cachning av IP:er:kommer du ihåg alla de IP:er som vi begärde från värdnamn i e-postadresser? Vi lagrade dem uppenbarligen, och att leta upp deras IP-adresser om och om igen orsakar avsevärd fördröjning. Däremot kan IP-adresser ändras:en DNS-post där, en annan MX på ett annat ställe... data blir snabbt inaktuella. För det mesta som servern faktiskt inte skickar någonting (prenumerationsnyhetsbrev kommer uppenbarligen i skur), ett lågprioriterat cronjob körs och kontrollerar alla värdnamn med en inaktuell IP (vi valde äldre än 1 dag som inaktuell) för en IP-adress , inklusive de som tidigare inte hade några (nya domäner registreras hela tiden, så varför skulle inte en domän bli tillgänglig dagen efter att någon redan entusiastiskt prenumererat med hans/hennes helt nya e-postadress? Eller serverproblem med någon domän är löst, etc.). Att skicka e-postmeddelanden krävde faktiskt inga fler domänsökningar.
Återanvändning av SMTP-anslutningen:att upprätta en anslutning till en server tar relativt stor del av tiden att leverera ett e-postmeddelande när du pratar direkt till port 25. Du behöver inte konfigurera en ny anslutning för varje e-post, kan du bara skicka nästa via samma anslutning. Lite trail-and-error har resulterat i att ställa in standarden här till cirka 50 e-postmeddelanden per anslutning (förutsatt att du har så många eller fler för domänen). Men när en e-postadress misslyckades, hjälpte det ibland att stänga och öppna anslutningen för ett nytt försök. Allt som allt, detta verkligen hjälpte till att påskynda saker och ting.
Något uppenbart, så uppenbart att jag nästan glömde att nämna det:det skulle vara ett slöseri att behöva skapa e-postmeddelandet på plats:om det är ett allmänt e-postmeddelande, ha brödtexten redo (jag ändrade PHPMailer något till kunna använda en cachad e-post), möjligen dagar innan (om du vet). du ska skicka ett mail på fredag och din server går på tomgång, varför inte förbereda dem redan på onsdag? Om det är personligt kan du fortfarande förbereda det i förväg med tillräckligt med tid, om inte, åtminstone ha de icke-personliga portionerna som väntar på att gå.
Flera processer. Nämnde jag att mycket av den tid det tar att leverera e-post spenderas på nätverket? En e-postprocess får inte nästan ut det mesta av din e-postserver, knappt märkbar belastning och e-postmeddelandena sipprar ut. Lek med ett antal processer som skickar olika delar av kön för att se vad som är rätt för din server/anslutning, men kom ihåg två mycket viktiga saker:
- Olika processer gör dig mycket sårbar för tävlingsförhållanden:var alldeles säker du har ett heltäckande system som aldrig kommer att göra skicka samma mail två gånger (tre gånger, av ännu mer). Det irriterar inte bara användarna allvarligt, din spamrating ökar ett snäpp.
- Håll domäner tillsammans där det är möjligt:genom att slumpmässigt välja från kön förlorar du fördelen av att ha en öppen anslutning till servern som tar emot e-post för domänen.

Undvika avslag

Du kommer att skicka mycket e-post. Det är precis vad spammare gör. Men du vill inte bli sedd som en spammare (det är du trots allt inte, eller hur)? Det finns ett antal mekanismer på plats som grundligt kommer att öka din trovärdighet för mottagande servrar:
Ha en ordentlig omvänd DNS:processer som kontrollerar DNS som tillhör IP:n som skickar e-postmeddelandet som det mycket mycket om domänerna på andra nivån matchar:skickar du e-post på uppdrag av example.com ? Se till att din servers omvända DNS är något i stil med något namn.exempel.com .
Publicera SPF-poster för din domän:ange uttryckligen att maskinen som används för att skicka din mass-e-post är tillåten och förväntas skicka e-post med dessa Från / Return-Path-rubriker.
kom ihåg avslag :servrar gillar inte att berätta om och om igen att olika e-postadresser inte existerar. Antingen automatiserade mekanismer, och till och med mänskliga administratörer, blockerade vår server medan vi arbetade igenom alla icke-validerade e-postadresser som existerade (inte längre). Vi använde inte en dubbel opt-in förrän senare, så databasen var nedsmutsad av stavfel, människor som bytte IP-adresser och därmed e-postadresser, busiga e-postadresser och så vidare. Var noga med att fånga de ogiltiga, och med tanke på tillräckligt många eller ta bort tillräckligt många misslyckanden, avsluta prenumerationen . De gör ingen nytta för dig, de tär på resurser, och om de verkligen vill ha dig e-post och brevlådan blir tillgänglig senare, måste de bara prenumerera på nytt.
DKIM är en annan mekanism som kan öka din trovärdighet, men eftersom vi inte har implementerat det (ännu) kan jag inte berätta så mycket om det.
MX-poster:vissa servrar gillar det fortfarande om din sändande server också är den mottagande servern för domänen. Som det var vid den tiden hade vi bara 1 MX, och eftersom e-postservern fortfarande inte var så upptagen, kallade vi den till reserv-MX-servern för domänen. Den normala MX-servern var inte servern som skickar prenumerationerna, eftersom det är väldigt irriterande att tillfälligt blockeras av en server som du försöker skicka ett viktigt e-postmeddelande till (klienter etc.) eftersom du redan har skickat en mängd mindre viktig e-post. Den har visserligen den högsta preferensen som att ta emot MX, men om den skulle misslyckas hade vi den fina bonusen att vår prenumerationssändande server fortfarande skulle vara reserv för leverans, så i kris kunde vi fortfarande komma till den, vilket förhindrade obekväma studsar till kunder som försöker för att nå oss.
Berätta om dig för dem. Allvarligt. Många stora aktörer inom gratis e-postadresser som live.com erbjuder dig möjligheten att registrera dig på något sätt, eller ha någon kontaktpunkt att gå till för hjälp och support om dina e-postmeddelanden avvisas. Om du har en legitim anledning att skicka så många e-postmeddelanden, och det är troligt att du har så många prenumeranter, är chansen stor att de på allvar ökar antalet e-postmeddelanden du kan skicka till deras server per timme. En knapp 1 000 kan bli någonstans i tiotusental eller till och med högre om du är övertygande och ärlig nog. Det kan finnas kontrakt, krav du måste uppfylla och löften du måste göra (och hålla) för att tillåtas detta. ISP:er är ett varumärke för sig, och alla andra spelare är olika. Bry dig inte om att ringa dem vanligtvis, för 99% av tiden kommer de enda numren du kan hitta bara ha personer som är villiga att felsöka din internetanslutning, som förstår (eller är tillåtna) lite annat. En [email protected] e-postadress är ett bra ställe att börja, men se om du kan gräva upp en mer konkret e-postadress från någonstans. Var exakt, ärlig och fullständig:ungefär hur många prenumeranter av dig som har en e-postadress hos den internetleverantören, hur ofta försöker du skicka dem via e-post, vad är det för fel eller avslag du får, hur ser prenumerations- och avregistreringsprocessen ut och vad är tjänsten du faktiskt tillhandahåller sina kunder. Var också snäll:hur viktigt det kan vara att skicka dessa e-postmeddelanden för ditt företag, att få panik över det och hävda fruktansvärda förluster berör dem inte. Ett artigt uttalande av fakta och önskemål, och fråga om de kan hjälpa till istället för att kräva en lösning räcker väldigt långt.
Strypning:så mycket som du försökte, kommer en viss server bara att acceptera en viss mängd e-post per timme och/eller dag från dig. Lär dig dessa siffror (vi loggar framgångar och misslyckanden i alla fall), ställ in dem till en rimlig standard för de vanliga domänerna, ställ in dem på överenskomna gränser för större spelare.

Undvika att bli taggad som skräppost

Första regeln:spamma inte!
Andra regel:någonsin! Inte ett "en gång till", inte ett "de har inte prenumererat men det här kan vara livets affär för dem", inte med de bästa avsikterna, folk har varit tvungna att be om dina e-postmeddelanden.
Sätt upp en korrekt dubbel-opt-in-prenumerationsmekanism.
PHPMailer ställer in korrekta rubriker på egen hand,
Sätt upp en enkel avregistreringsmekanism via webben (inkludera en länk till den i varje mail), eventuellt även mail och kundtjänst om du har det. Se till att kundtjänsten kan avregistrera personer direkt.
Som tidigare nämnt:avsluta prenumerationen (överdrivet många) misslyckanden och studsar.
Undvik skräppostformuleringar av "en livstidsaffär".
Använd url:er i dina e-postmeddelanden sparsamt.
Undvik att lägga till länkar till domäner utanför din kontroll, såvida du inte är helt säker på att du kan lita på dem inte spam, om även då...
Ge användaren värde:att bli taggad som skräppost genom användarinteraktion i google/yahoo/live webbmailklienter skadar allvarligt framtida framgångar (notera på en webbplats:om du registrerar dig för det kommer live/msn/hotmail att vidarebefordra alla e-post till dig skickas av din domän som är taggad som spam av användare. Lär dig att älska det, och som alltid:avsluta prenumerationen på dem, de vill uppenbarligen inte ha ditt köpcentrum och skadar ditt spambetyg).
Övervaka svartlistor för din IP. Om du dyker upp på en av dessa är det hejdå, så agera omedelbart genom att både rensa ditt namn och att avgöra ärendet krävs.

Mäta framgångsfrekvens

Med hela processen under din kontroll är du ganska säker på att e-postmeddelandet hamnade någonstans (även om det kan vara MX:s bitbucket eller en skräppostmapp), eller så har du loggat ett fel och anledningen till det. Det tar hand om de "faktiskt levererade" siffrorna.
Vissa människor kommer att försöka övertyga dig om att lägga till länkar till onlinebilder i dina e-postmeddelanden (antingen riktiga eller den berömda 1x1 transparenta gif-filen) för att mäta hur många som faktiskt läser din e-post. Eftersom en hög procentandel blockerar dessa bilder är dessa siffror i bästa fall skakiga, och vår uppfattning är att vi helt enkelt inte ska bry oss om dem, deras siffror är helt opålitliga.
Din bästa insats för att mäta den faktiska framgångsfrekvensen är mycket enklare om du vill att användarna ska göra något. Lägg till parametrar till länkar i e-postmeddelandet så att du kan mäta hur många användare som kommer till webbplatsen du länkade, om de utförde önskade åtgärder (tittade på en video, lämnade en kommentar, köpte varor).

Allt som allt, med all loggning, användargränssnittet, konfigurerbara inställningar per domän/e-post/användare etc. Det tog oss cirka 1,5 man-månad att bygga och lösa egenheter. Det kan vara en investering jämfört med att lägga ut e-postmeddelanden på entreprenad, det kanske inte är det, allt beror på volymen och verksamheten i sig.

Låt nu det flammande börja att jag var en idiot att skriva en MTA i PHP, jag njöt verkligen av det (vilket är en anledning till att jag skrev den här enorma mängden text) och de extremt mångsidiga loggnings- och inställningarna, per värd varningar baserade på felprocent etc. gör live oh så enkelt;)