Няма причина да не можете да го напишете на PHP, въпреки че аз не направете го част от уеб заявка / HTTP процес. Успешно внедрих 500 000 абонати за даване или вземане на поща (в зависимост от наличните местни данни, тъй като това беше проект за специфично местоположение). Това беше вътрешен проект, така че за съжаление няма код/пакет за вас, но някои насоки, на които попаднах:
Настройване на доставка
- Започна със самия phpmailer, за да се грижи за форматирането, кодирането на съдържанието и заглавките, добавянето на прикачени файлове и т.н. Тази част от него работи добре и не бих искал да пиша това от нулата.
- Самото „изпращане“ на имейл е просто задаване на някакъв флаг в база данни дали / как / какво трябва да бъде изпратено на (част от) абонатите.
- След като този флаг бъде зададен, той автоматично ще бъде взет от cronjob, без повече участие на уеб сървър.
- Започнах със силно замърсена база данни с милиони имейл адреси, от които много бяха очевидно невалидни, така че първото нещо беше да потвърдите всички имейл адреси за формат, след това за хост:
filter_var($email, FILTER_VALIDATE_EMAIL);над абонатите (и очевидно съхраняването на резултата) се отърва от първите няколкостотин хиляди невалидни имейли.- Разделяне на хоста (и съхранение името на хоста) от имейлите и потвърждаване на това (има ли MX или поне A запис в DNS, но имайте предвид:можете да изпращате имейл до IP адрес
[email protected][255.255.255.255], така че ги запазете валидни)) се отървах от една добра порция повече. Имейл адресите тук не постоянно деактивирани, но с флаг за състояние, който показва, че са деактивирани поради името на домейна / ip. - Скриптовете бяха променени на изискване валидни имейл адреси при абонамент / преди вмъкването, тази глупост „няма да получите ex sqldat.com ' абонамент-замърсяването в базата данни беше просто нелепо.
- Сега получих списък с имейл адреси, които имаха потенциала да бъдат валидни. По същество има 3 начина за откриване на невалидни адреси (имайте предвид, че всички може да бъде временно):
- Те се отказват незабавно от сървъра.
- По-рано определеният сървър просто не слуша трафика.
- Те са отхвърлени дълго след като сте помислили, че сте ги доставили.
- Странно нещо, отклоненията, които изглежда всеки имейл сървър има друг формат и първоначално бяха адски за анализиране, всъщност се оказаха доста лесни за заснемане с помощта на VERP
. Вместо това да анализирате цели имейли, специален имейл адрес (нека го наречем ex.amplecoms"> a> ) беше конфигуриран да доставя по-скоро до пощенската кутия, да го изпраща чрез команда и ако изпратихме имейл до [email protected]
,
Return-Pathбеше зададен за[email protected]. Лесно се анализира при получаването и след колко отпадания (пощенска кутия не може да съществува, пощенската кутия може да е пълна (да, все още!) и т.н.) Вие декларирате имейл адрес за неизползваем. - Сега, директният отказ от сървъра. Вероятно бихме могли да отидем с правилното конфигуриране на някои MTA и/или писане на плъгини за тях, но тъй като имейлите бяха чувствителни към времето и трябваше да имаме абсолютен конфигурируем контрол за изпращане по пощата върху последното използваемо време за доставка (след което имейлът не беше по-дълъг от интерес за потребителя), дроселиране на получаващ сървър и като цяло всичко, ще отнеме приблизително същото време написването на mailer на PHP, който познаваме по-добре, който използва SMTP протокола директно към сокет 25 на получаващите сървъри. С минимално усилие е вградена възможността за друг транспорт след това по подразбиране в PHPMailer. SMTP протоколът всъщност е доста прост, но има някои предупреждения:
- Много от получаващите сървъри прилагат сив списък:повечето спам ботове всъщност няма да се интересуват дали пристигне конкретна поща, те просто ги изхвърлят. Така че, ако неизвестен/все още не доверен подател изпрати имейл, той ще бъде временно отхвърлен. Хванете това (обикновено код 451) и поставете имейла в опашката за по-късен опит.
- Пощенски сървър, особено на по-големите интернет доставчици и безплатни услуги (gmail, hotmail/msn/live и т.н.) няма да издържат на торент от поща, без да се борят:след първите няколкостотин / хиляди те започват да отхвърлят Вие. Повече за това по-късно.
Получаване на скорост
- Сега имахме система за доставка, която работеше, но трябваше да е бърза . Изпращането на 10 000 имейла за час е добре, ако имате само 10 000 адреса за изпращане, но минимумът, който изисквахме, беше около 200 000 на час. Началото му беше специален сървър (който всъщност може да бъде доста ниско захранван, независимо какво правите, повечето време, необходимо за доставка на имейли, е в мрежата, а не на вашия сървър).
- Кеширане на IP адреси:помните ли всички онези IP, които поискахме от имена на хостове в имейл адреси? Очевидно ги съхранихме и търсенето на техните IP адреси отново и отново води до значително забавяне. Въпреки това IP адресите могат да се променят:DNS запис там, друг MX на друго място... данните бързо се застояват. През повечето време сървърът всъщност не изпраща нищо (очевидно бюлетините за абонамент идват в серии), cronjob с нисък приоритет се изпълнява, проверявайки всички имена на хостове със застоял IP (избрахме по-стар от 1 ден като остарял) за IP адрес , включително тези, които преди не са имали такива (новите домейни се регистрират през цялото време, така че защо домейнът да не стане достъпен в деня, след като някой вече ентусиазирано се абонира с чисто новия си имейл адрес? Или проблемите със сървъра с някакъв домейн са решени и т.н.). Всъщност изпращането на имейлите вече не изисква повече търсене на домейни.
- Повторно използване на SMTP връзката:настройката на връзка със сървър отнема сравнително голяма част от времето за доставяне на имейл, когато говорите директно на порт 25. Не е нужно да настройвате нова връзка за всеки имейл, можете просто да изпратите следващия през същата връзка. Малко проследяване и грешка доведе до настройката по подразбиране тук на около 50 имейла на връзка (ако приемем, че имате толкова много или повече за домейна). Въпреки това, при неуспех на имейл адрес затварянето и повторното отваряне на връзката за повторен опит понякога помагаше. Като цяло, това наистина помогна за ускоряване на нещата.
- Някой очевиден, толкова очевиден, че почти забравих да го спомена:би било загуба да се налага да създавате тялото на имейла на място:ако е обикновена поща, имайте готово тялото (промених PHPMailer донякъде, за да да можете да използвате кеширан имейл), вероятно дни преди това (ако знаете ще изпратите имейл в петък, а сървърът ви не работи, защо не ги подготвите вече в сряда? Ако е персонализиран, все пак можете да го подготвите предварително, като имате достатъчно време, ако не, поне неперсонализираните порции да чакат да си тръгнат.
- Множество процеси. Споменах ли, че голяма част от времето, необходимо за доставка на имейл, е прекарване в мрежата? Един процес на изпращане по пощата почти не извлича максимума от вашия имейл сървър, едва забележимо натоварване и писмата се стичат. Поиграйте си с редица процеси, изпращащи по пощата различни части от опашката, за да видите какво е подходящо за вашия сървър/връзка, но запомнете 2 много важни неща:
- Различните процеси ви правят много уязвими към условията на състезанието:бъдете абсолютно сигурни имате напълно защитена система, която никога изпращайте една и съща поща два пъти (три пъти, дори повече). Това не само сериозно дразни потребителите, но и рейтингът ви за спам се повишава с една степен.
- Дръжте домейните заедно, където е възможно:избирайки произволно от опашката, ще загубите предимството да поддържате отворена връзка със сървъра, който получава имейл за домейна.
Избягване на отказ
- Ще изпратите много имейли. Точно това правят спамърите. Въпреки това, не искате да бъдете разглеждани като разпространител на спам (все пак не сте, нали)? Съществуват редица механизми, които напълно ще увеличат надеждността ви към получаващите сървъри:
- Имайте правилен обратен DNS:процеси, проверяващи DNS, принадлежащ на IP, който изпраща имейла като много много, ако домейните от второ ниво съвпадат:изпращате ли поща от името на example.com ? Уверете се, че обратният DNS на вашия сървър е нещо като somename.example.com .
- Публикувайте SPF записи за вашия домейн:изрично посочете, че машината, използвана за изпращане на вашите групови имейли, е разрешена и се очаква да изпраща поща с тези заглавки From/Return-Path.
- запомнете отказа :сървърите не обичат да ви казват отново и отново, че различни имейл адреси не съществуват. Или автоматизирани механизми, и дори човешки администратори, блокираха нашия сървър, докато работихме през всички невалидирани имейл адреси, които (вече) не съществуваха. Не използвахме двойно избиране до по-късно, така че базата данни беше замърсена с печатни грешки, хора, които сменяха IP адреси и по този начин имейл адрес, имейл адреси за шеги и т.н. Уверете се, че сте уловили тези невалидни и като имате достатъчно или прекъснете достатъчно грешки, отпишете ги . Те не ви вършат никаква полза, те черпят ресурси и ако наистина искат да ви изпратите поща и пощенската кутия стане достъпна по-късно, просто ще трябва да се абонират отново.
- DKIM е друг механизъм, който може да повиши вашата надеждност, но тъй като не сме го внедрили (все още), не мога да ви кажа много за това.
- MX записи:някои сървъри все още харесват, ако вашият изпращащ сървър е и получаващият сървър за домейна. Както беше по онова време, имахме само 1 MX и тъй като пощенският сървър все още не беше толкова зает, ние го нарекохме резервен MX сървър за домейна. Нормалният MX сървър не сървърът, изпращащ абонаментите, тъй като е много дразнещо да бъдете временно блокирани от сървър, на който се опитвате да изпратите важен имейл (клиенти и т.н.), защото вече сте изпратили много по-малко важна поща. Той има най-голямото предпочитание като получаване на MX, но в случай, че не успее, имахме хубавия бонус, че нашият сървър за изпращане на абонамент все пак ще бъде резервен за доставка, така че в криза все още можем да стигнем до него, предотвратявайки неудобни отскачания към клиенти, които се опитват за да стигнете до нас.
- Разкажете им за вас. Сериозно. Много големи играчи в безплатни имейл адреси като live.com ви предлагат възможност да се регистрирате по някакъв начин или да имате някаква точка за контакт, към която да отидете за помощ и поддръжка, ако имейлите ви бъдат отхвърлени. Ако имате основателна причина да изпращате толкова много имейли и е вероятно, че имате толкова много абонати, има вероятност те сериозно да увеличат броя на имейлите, които можете да изпращате до сървъра им на час. Оскъдната 1000 може да стане някъде от десет хиляди или дори повече, ако сте достатъчно убедителни и честни. Може да има договори, изисквания, които трябва да изпълните, и обещания, които трябва да дадете (и да спазвате), за да ви бъде позволено това. Доставчиците на интернет услуги са различна марка и всеки друг играч е различен. Не си правете труда да им се обаждате обикновено, защото в 99% от времето единствените номера, които можете да намерите, ще имат само хора, които желаят да отстранят проблеми с вашата интернет връзка, които разбират (или им е позволено) малко друго.
[email protected]имейл адресът е добро място за начало, но вижте дали можете да намерите по-точен имейл адрес отнякъде. Бъдете точни, честни и пълни:приблизително колко абонати от вас имат имейл адрес с този интернет доставчик, колко често се опитвате да им изпращате по пощата, какви са грешките или отказите, които получавате, как протича процесът на абонамент и отписване и какво е услугата, която всъщност предоставяте на техните клиенти. Също така, бъдете любезни:колко жизненоважно може да бъде изпращането на тези писма за вашия бизнес, паниката за това и твърдението за ужасни загуби не ги засяга. Вежливо изложение на факти и желания и питане дали те могат да помогнат, а не изискването за решение е много дълъг път. - Ограничаване:колкото и да сте опитвали, някой сървър ще приема само определено количество поща на час и/или ден от вас. Научете тези числа (все пак регистрираме успехи и неуспехи), задайте ги на разумна стойност по подразбиране за нормалните домейни, задайте ги на договорени ограничения за по-големите играчи.
Избягване да бъдете маркирани като спам
- Първо правило:не изпращайте спам!
- Второ правило:винаги! Не „еднократно“, не „те не са се абонирали, но това може да е сделка за цял живот за тях“, не с най-добри намерения, хората трябваше да поискат имейлите ви.
- Очевидно настройте правилен механизъм за двойно включване.
- PHPMailer сам задава правилни заглавки,
- Настройте лесен механизъм за отписване от мрежата (включете връзка към него във всяко поща), вероятно също имейл и обслужване на клиенти, ако го имате. Уверете се, че обслужването на клиенти може отпишете директно хора.
- Както беше казано по-рано:прекратяване на абонамента (прекомерно) е неуспешно и отпада.
- Избягвайте спам думите „сделка за цял живот“.
- Използвайте пестеливо URL адресите в имейлите си.
- Избягвайте да добавяте връзки към домейни извън вашия контрол, освен ако не сте напълно сигурни, че можете да се доверите на тем да не спам, ако дори и тогава...
- Предоставете стойност на потребителя:да бъдете маркирани като спам чрез потребителско взаимодействие в клиентите за уеб поща google/yahoo/live сериозно вреди на бъдещите успехи (в забележка на сайта:ако се регистрирате за него, live/msn/hotmail ще препрати всички имейл до вас, изпратен от вашия домейн, който е маркиран като спам от потребителите. Научете се да го обичате и както винаги:отпишете се от тях, те явно не искат вашия мол и вредят на рейтинга ви за спам).
- Наблюдавайте черните списъци за вашия IP. Ако се появите на едно от тях, това е чао, така че незабавно действайте както за изчистване на името си и изисква се определяне на случая.
Измерване на процента на успех
- С целия процес под ваш контрол, сте сигурни, че имейлът е свършил някъде (въпреки че това може да е bitbucket на MX или папка за спам), или сте регистрирали грешка и причината за това. Това се грижи за „действително доставените“ номера.
- Някои хора ще се опитат да ви убедят да добавите връзки към онлайн изображения към имейлите си (или истински, или известния прозрачен gif 1x1), за да измерят колко хора действително четат имейла ви. Тъй като висок процент блокира тези изображения, тези числа в най-добрия случай са нестабилни и ние вярваме, че просто не трябва да се занимаваме с тях, техните числа са напълно ненадеждни.
- Вашият най-добър залог за измерване на действителния процент на успех е много по-лесен, ако искате потребителите да направят нещо. Добавете параметри към връзките в пощата, за да можете да измерите колко потребители пристигат на сайта, който сте свързали, дали са извършили желаните действия (гледали видео, оставили коментар, закупили стоки).
Като цяло, с цялото регистриране, потребителски интерфейс, конфигурируеми настройки за домейн/имейл/потребител и т.н. Отне ни около 1,5 човекомесеца, за да изградим и изгладим странностите. Това може да е доста инвестиция в сравнение с аутсорсинг на имейли, може и да не е, всичко зависи от обема и самия бизнес.
Сега, нека започне пламналото, че бях глупак да напиша MTA на PHP, на мен наистина ми хареса (което е една от причините да напиша това огромно количество текст) и изключително гъвкавите възможности за регистриране и настройки за всеки хост сигналите, базирани на процента на неуспехи и т.н., правят на живо толкова лесно;)
