Sikker måde at sende mail via PHP til mange brugere

Der er ingen grund til, hvorfor du ikke kunne skrive det i PHP, selvom jeg ikke ville gøre det til en del af en webrequest/HTTP-proces. Jeg har med succes implementeret for give or take 500.000 abonnenter pr. mailing (afhængigt af lokale tilgængelige data, da dette var et stedsspecifikt projekt). Det var et internt projekt, så desværre ingen kode/pakke til dig, men nogle tips jeg stødte på:

Opsætning af levering

• Begyndte med selve phpmailer for at tage sig af formatering, kodning af indhold og overskrifter, tilføjelse af vedhæftede filer osv. Den del af det fungerer godt, og jeg vil ikke skrive det fra bunden.
• Afsendelsen af ​​en e-mail i sig selv er blot at sætte et eller andet flag i en database, om / hvordan / hvad skal sendes til (en del af) abonnenterne.
• Når dette flag er indstillet, vil det automatisk blive opfanget af en cronjob, der er ikke mere involveret webserver.
• Jeg startede med en stærkt forurenet database med millioner af e-mailadresser, heraf en masse var åbenlyst ikke gyldige, så den første ting var at validere alle e-mailadresser for format, derefter for vært:
  • filter_var($email, FILTER_VALIDATE_EMAIL); over abonnenter (og lagring af resultatet naturligvis) slap af med de første par hundrede tusinde ugyldige e-mails.
  • Opdeling af værten (og lagring værtsnavnet) fra e-mails og validere det (har det en MX- ​​eller i det mindste en A-record i DNS, men husk:du kan sende e-mail til en IP-adresse [email protected][255.255.255.255] , så hold dem gyldige)) slap af med en god portion mere. E-mailadresserne her er ikke permanent deaktiveret, men med et statusflag, der angiver, at de er deaktiveret på grund af domænenavnet/ip.
  • Scripts blev ændret til kræver gyldige e-mailadresser på abonnement / før indsættelse, dette nonsens med 'du får ikke eksempel sqldat.com ' abonnementsforurening i databasen var bare latterligt.
• Nu endte jeg med en liste over e-mail-adresser, der havde potentialet til at være gyldige. Der er i det væsentlige 3 måder at opdage ugyldige adresser på (husk på, at alle kan være midlertidig):
  • De afvises øjeblikkeligt af serveren.
  • Den tidligere bestemte server lytter bare ikke til trafik.
  • De afvises længe efter, du troede, du havde leveret dem.
• Mærkeligt, afvisningerne, som hver e-mailserver ser ud til at have et andet format for og var et helvede at analysere i starten, endte faktisk ret nemme at fange ved hjælp af VERP . I stedet for at analysere hele e-mails, en dedikeret e-mailadresse (lad os kalde det lexample@sq">lexample.com a> ) blev konfigureret til i stedet for at levere til postkassen, at sende den gennem en kommando, og hvis vi sendte e-mail til [email protected] , Return-Path blev indstillet til [email protected] . Let at analysere ved modtagelse, og efter hvor mange afvisninger (postkasse kunne ikke eksistere, postkasse kan være fuld (ja, stadig!) osv.) du erklærer en e-mailadresse ubrugelig, er op til dig.
• Nu, den direkte afvisning fra serveren. Sandsynligvis kunne vi have gået med at konfigurere nogle MTA korrekt og/eller skrive plugins til dem, men da e-mails var tidsfølsomme, og vi var nødt til at have absolut konfigurerbar kontrol per mail over sidste brugbare leveringstid (hvorefter e-mailen ikke var længere af interesse for brugeren), drosling pr. modtagende server, og generelt alt, ville det tage omtrent samme tid at skrive en mailer i PHP, som vi vidste bedre, der brugte SMTP-protokollen direkte til socket 25 på modtagende servere. Med et minimum af indsats var muligheden for en anden transport så standardvalgene i PHPMailer indbygget. SMTP-protokollen er faktisk ret simpel, men der er nogle forbehold:
  • Mange modtagende servere anvender grå liste:de fleste spambots er ligeglade med, om der kommer en specifik e-mail, de fjerner dem bare. Så hvis en ukendt / endnu ikke betroet afsender sender mail, vil den blive midlertidigt afvist. Fang det (normalt kode 451), og placer e-mailen i køen for senere at prøve igen.
  • En mailserver, især af de større internetudbydere og gratis tjenester (gmail, hotmail/msn/live, osv.) vil ikke stå for en strøm af mail uden at slå tilbage:efter de første par hundrede / tusinde begynder de at afvise du. Mere om det senere.

Få hastighed

• Nu havde vi et leveringssystem, der fungerede, men det skulle være hurtigt . At sende 10.000 e-mails på en time er helt fint, hvis du kun har 10.000 adresser at sende til, men det minimum, vi krævede, var omkring 200.000 i timen. Starten på det var en dedikeret server (som faktisk kan være ret lavt strømførende, uanset hvad du gør, det meste af tiden, det tager at levere e-mail er på netværket, ikke på din server).
• Caching af IP'er:kan du huske alle de IP'er, vi anmodede om fra værtsnavne i e-mail-adresser? Vi har naturligvis gemt dem, og at finde deres IP'er igen og igen forårsager betydelig forsinkelse. Dog kan IP'er ændre sig:en DNS-post der, en anden MX et andet sted... dataene bliver hurtigt forældede. Det meste af tiden sender serveren faktisk ikke noget (abonnementsnyhedsbreve kommer naturligvis i serier), en lavprioritet cronjob kører og tjekker alle værtsnavne med en forældet IP (vi valgte ældre end 1 dag som forældet) for en IP-adresse , inklusive dem, der tidligere ikke havde nogen (nye domæner bliver registreret hele tiden, så hvorfor skulle et domæne ikke blive tilgængeligt dagen efter, at nogen allerede begejstret abonnerer med hans/hendes helt nye e-mailadresse? Eller serverproblemer med et domæne er løst osv.). At sende e-mails nu krævede faktisk ikke flere domæneopslag.
• Genbrug af SMTP-forbindelsen:Opsætning af en forbindelse til en server tager relativt en stor del af tiden at levere en e-mail, når du taler direkte til port 25. Du behøver ikke at oprette en ny forbindelse for hver e-mail, kan du bare sende den næste over samme forbindelse. En smule trail-and-error har resulteret i at indstille standarden her til omkring 50 e-mails pr. forbindelse (forudsat at du har så mange eller flere for domænet). Men ved en fejl i en e-mailadresse hjalp det nogle gange at lukke og genåbne forbindelsen for at prøve igen. Alt i alt, dette virkelig hjalp med at fremskynde tingene.
• Noget indlysende, så indlysende, at jeg næsten glemte at nævne det:det ville være spild at skulle oprette e-mailens brødtekst på stedet:hvis det er en generel e-mail, så hav brødteksten klar (jeg har ændret PHPMailer noget til være i stand til at bruge en cachelagret e-mail), muligvis dage før (hvis du ved det). du vil sende en mail på fredag, og din server er i tomgang, hvorfor ikke forberede dem allerede på onsdag? Hvis det er personligt, kan du stadig forberede det på forhånd, hvis der er tid nok, hvis ikke, så i det mindste have de ikke-personlige portioner, der venter på at gå.
• Flere processer. Fik jeg nævnt, at meget af den tid, det tager at levere e-mail, bruger på netværket? Én mailing-proces er ikke nær at få mest muligt ud af din e-mailserver, knap nok mærkbar belastning og mails siver ud. Leg med en række processer, der sender forskellige dele af køen for at se, hvad der er rigtigt for din server/forbindelse, men husk 2 meget vigtige ting:
  • Forskellige processer gør dig meget sårbar over for racerforhold:vær helt sikker du har et fuldsikkert system, der aldrig vil sende den samme mail to gange (tre gange, eller endnu mere). Ikke alene irriterer det brugerne alvorligt, din spamrating stiger et trin.
  • Hold domæner sammen, hvor det er muligt:​​Ved at vælge tilfældigt fra køen mister du fordelen ved at holde en åben forbindelse til serveren, der modtager e-mail for domænet.

Undgå afvisninger

• Du kommer til at sende en masse mails. Det er præcis, hvad spammere gør. Men du ønsker ikke at blive set som en spammer (det er du trods alt ikke, vel)? Der er en række mekanismer på plads, som grundigt vil øge din troværdighed over for modtagende servere:
• Har en ordentlig omvendt DNS:processer, der kontrollerer den DNS, der tilhører IP-adressen, der sender e-mailen som den meget meget hvis domænerne på andet niveau matcher:sender du mail på vegne af example.com ? Sørg for, at din servers omvendte DNS er noget i stil med somename.example.com .
• Udgiv SPF-registreringer for dit domæne:Angiv udtrykkeligt, at den maskine, der bruges til at sende din bulk-e-mail, er tilladt og forventes at sende e-mail med disse Fra-/Retursti-headere.
• husk afvisninger :servere kan ikke lide det at fortælle dig igen og igen, at forskellige e-mailadresser ikke eksisterer. Enten automatiserede mekanismer, og endda menneskelige administratorer, blokerede vores server, mens vi arbejdede gennem alle ikke-validerede e-mail-adresser, der eksisterede (ikke længere). Vi brugte ikke en dobbelt opt-in før senere, så databasen blev forurenet med tastefejl, folk skiftede IP'er og dermed e-mailadresse, prank e-mailadresser og så videre. Sørg for at fange disse ugyldige, og givet nok eller afbryde nok fejl, afmeld dem . De gør ikke noget for dig, de tærer på ressourcer, og hvis de virkelig vil have dig mail, og postkassen bliver tilgængelig senere, skal de bare abonnere igen.
• DKIM er en anden mekanisme, der kan øge din troværdighed, men da vi ikke har implementeret den (endnu), kan jeg ikke fortælle dig meget om det.
• MX-registreringer:Nogle servere kan stadig lide det, hvis din afsendende server også er den modtagende server for domænet. Som det var på det tidspunkt, havde vi kun 1 MX, og da mailing-serveren stadig ikke var så travl, døbte vi den til fallback MX-serveren for domænet. Den normale MX-server var ikke serveren, der sender abonnementerne, da det er meget irriterende at blive midlertidigt blokeret af en server, du forsøger at sende en vigtig e-mail til (klienter osv.), fordi du allerede har sendt en masse mindre vigtige e-mails. Den har den højeste præference som at modtage MX, men i tilfælde af at den ville mislykkes, havde vi den gode bonus, at vores server til afsendelse af abonnementer stadig ville være reserve til levering, så i krise kunne vi stadig nå det, hvilket forhindrede akavede afvisninger til kunder, der forsøgte for at nå os.
• Fortæl dem om dig. Helt seriøst. Mange store spillere inden for gratis e-mail-adresser som live.com tilbyder dig muligheden for at tilmelde dig på en eller anden måde eller have et kontaktpunkt at gå til for at få hjælp og support, hvis dine e-mails bliver afvist. Hvis du har en legitim grund til at sende så mange e-mails, og det er troværdigt, at du har så mange abonnenter, er chancerne for, at de seriøst øger antallet af e-mails, du kan sende til deres server i timen. En sølle 1.000 kan blive et sted i titusindvis eller endnu højere, hvis du er overbevisende og ærlig nok. Der kan være kontrakter, krav du skal opfylde, og løfter du skal give (og holde) for at få lov til dette. ISP'er er et mærke adskilt, og hver anden spiller er anderledes. Lad være med at ringe til dem normalt, for 99% af tiden vil de eneste numre, du kan finde, kun have folk, der er villige til at fejlfinde din internetforbindelse, som forstår (eller er tilladt) lidt andet. Et [email protected] e-mailadresse er et godt sted at starte, men se om du kan dykke op en mere konkret e-mail-adresse et eller andet sted fra. Vær præcis, ærlig og fuldstændig:hvor mange abonnenter af dig har en e-mail-adresse hos den internetudbyder, hvor ofte prøver du at sende dem, hvad er de fejl eller afvisninger, du modtager, hvordan er tilmeldings- og afmeldingsprocessen, og hvad er den service du rent faktisk leverer til deres kunder. Vær også sød:Hvor vigtigt det kan være at sende disse mails for din virksomhed, at gå i panik over det og hævde frygtelige tab, vedrører dem ikke. En høflig redegørelse for fakta og ønsker, og spørger om de kan hjælpe i stedet for at kræve en løsning, rækker meget langt.
• Trøvning:Så meget som du har prøvet, vil nogle servere kun acceptere en vis mængde mail fra dig i timen og/eller dagen. Lær disse tal (vi logger alligevel succeser og fiaskoer), indstil dem til en rimelig standard for de normale domæner, indstil dem til aftalte grænser for større spillere.

Undgå at blive tagget som spam

• Første regel:Spam ikke!
• Anden regel:nogensinde! Ikke et "engangstidspunkt", ikke et "de har ikke abonneret, men dette kan være deres livs aftale", ikke med de bedste hensigter, folk har været nødt til at bede om dine e-mails.
• Selvfølgelig opsætte en korrekt dobbelt tilmeldings-abonnementsmekanisme.
• PHPMailer sætter de rigtige overskrifter alene,
• Opsæt en nem afmeldingsmekanisme via internettet (medtag et link til den i hver mail), eventuelt også mail og kundeservice, hvis du har det. Sørg for, at kundeservice kan afmeld personer direkte.
• Som tidligere nævnt:afmeld (overdreven) fejl og afvisninger.
• Undgå spam-udtryk af "en livstidsaftale".
• Brug url'er i dine e-mails sparsomt.
• Undgå at tilføje links til domæner uden for din kontrol, medmindre du er helt sikker på, at du kan stole på dem ikke at spam, hvis selv da...
• Giv værdi for brugeren:At blive tagget som spam ved brugerinteraktion i google/yahoo/live webmail-klienter skader alvorligt fremtidige succeser (note på et websted:hvis du tilmelder dig det, vil live/msn/hotmail videresende alle e-mail til dig sendes af dit domæne, som er tagget som spam af brugere. Lær at elske det, og som altid:afmeld dem, de vil tydeligvis ikke have dit indkøbscenter og skader din spamvurdering).
• Overvåg sortlister for din IP. Hvis du optræder på en af ​​dem, er det farvel, så omgående handling ved både at rydde dit navn og det er nødvendigt at afgøre sagen.

Måling af succesrate

• Med hele processen under din kontrol, er du rimelig sikker på, at e-mailen er endt et sted (selvom det kan være MX'ens bitbucket eller en spam-mappe), eller du har logget en fejl og årsagen til det. Det tager sig af de 'faktisk leverede' tal.
• Nogle mennesker vil forsøge at overbevise dig om at tilføje links til onlinebilleder til dine e-mails (enten ægte eller den berømte 1x1 gennemsigtige gif) for at måle, hvor mange mennesker der rent faktisk læser din e-mail. Da en høj procentdel blokerer for disse billeder, er disse tal i bedste fald rystede, og vores overbevisning er, at vi bare ikke skal bekymre os om dem, deres tal er fuldstændig upålidelige.
• Dit bedste bud på at måle den faktiske succesrate er meget nemmere, hvis du ønsker, at brugerne skal gøre noget. Tilføj parametre til links i mailen, så du kan måle, hvor mange brugere der ankommer til det websted, du linkede til, om de udførte de ønskede handlinger (set en video, efterladt en kommentar, købte varer).

Alt i alt, med al logningen, brugergrænsefladen, konfigurerbare indstillinger pr. domæne/e-mail/bruger osv. Det tog os omkring 1,5 mand-måned at opbygge og udjævne særheder. Det kan være noget af en investering sammenlignet med at outsource e-mails, det er det måske ikke, det hele afhænger af mængden og selve forretningen.

Lad nu flammen begynde, at jeg var et fjols til at skrive en MTA i PHP, jeg nød det grundigt (hvilket er en af ​​grundene til, at jeg skrev denne enorme mængde tekst), og de ekstremt alsidige lognings- og indstillingsmuligheder, pr. vært alarmer baseret på fejlprocent osv. gør live åh så nemt;)