Hatékony automatizált levélküldés
Jelenlegi munkaadómnál, a DotRoll Kft-nél feladatom volt garantálni, hogy a kiküldött értesítő levelek megérkezzenek a célszemély postafiókjába. Mivel a munkafolyamatok gyakorlatilag e-mailben zajlanak és az ügyfelek szinte kizárólag így kapják meg az értesítéseket a szolgáltatások elkészültéről, lejáratáról, stb. Egy-egy elveszett e-mail komoly problémát jelentett volna. Ennek tapasztalatait igyekszem most összefoglalni az automatizált levelek küldésén fáradozó webfejlesztő kollégáknak.
Tartalomjegyzék # ↑
IP „hírnév“ # ↑
Ismerkedjünk meg az IP hírnevével, avagy szakmai néven az IP reputation fogalmával. A dolog voltaképpen a kiterjesztése a hagyományos feketelista (blacklist) működésének. Egy-egy IP-ről ezek a rendszerek megjegyzik, mennyi spamet / hamet (a spam ellentéte) kaptak és ez alapján építenek föl egy hírnevet. Fontos megjegyezni, hogy mivel a szolgáltatók fölismerték a spammerek IP ugráló szokásait, egy ismeretlen IP cím csak egy hajszállal jobb a spamelés miatt elhíresült IP címnél. Az utóbbi időben ezen felül a dolog odáig eszkalálódott, hogy néhány masszívan spamelő IP egy teljes tartomány hírnevét el tudja rontani, ezért érdemes körülnézni a szolgáltatónk háza táján.
Sajnos a Google, Yahoo, stb. adataihoz szinte lehetetlen hozzáférni, de jó jelzése lehet egy „hírhedt“ tartománynak, ha a SpamCop.net térképén minimálisnál több spamforgalmat látunk. Jó vészjelző az is, hogy a szerverünknek egy olcsóbb társaságot választottunk, mivel a spammereknek gyakran felmondás áldozatai lesznek és elbukjak a pénzt valamint a szolgáltatónál kevesebb pénz jut a spamproblémák problémák kezelésére. Természetesen előfordulhatnak ettől merőben eltérő tendenciák is, de általánosan elfogadott tény az, hogy a jó IP hírnevet meg kell fizetni.
DKIM aláírás # ↑
A küldő identitását szavatolandó jött létre az Exim tutorialban már említett DKIM (a DomainKeys utódja). A DKIM kétkulcsos titkosítással aláírja a kimenő levelek bizonyos fejléceit és ezzel ellehetetleníti az esetleges hamisítást. A nyilvános kulcsot az aláírásra használt domainbe kell TXT rekordba betenni, ami alapján a fogadó szerver ellenőrzi a levelet. Erről a már nevezett tutorial utolsó részében részletesebben szó esik.
SPF rekord # ↑
Az SPF rekord azt szabályozza, hogy az adott domainről milyen IP-ről lehet levelet küldeni. A DKIM-hez hasonlóan TXT rekordban kell közzétenni.
Az SPF rekordnak van egy árnyoldala is. Mivel rengetegen használnak úgynevezett e-mail átirányítást, az SPF rekord jelentheti azt, hogy egy átirányított fiókra küldött teljesen legitim levél az átirányított e-mail címre nem érkezik meg, mivel az átirányító szerver nincs bent az engedélyezett szerverek listájában. Éppen ezért azt szoktam javasolni, hogy az SPF rekordban engedélyezzünk minden IP címet, de semmiképp ne hagyjuk el, mivel követelmény sok helyen.
Feedback loop # ↑
A legtöbb e-mail szolgáltató tart fönt úgynevezett feedback loop szolgáltatást, amely keretében a kiküldött levelekről spamnek jelöléséről értesítést kaphatunk. Ezzel hatékonyan előzhetjük meg a fekete listára kerülést. Természetesen a panaszos e-mail címét azonnal le kell venni a küldő listáról. Néhány feedback loop:
Ezen felül még rengeteg ilyen található az interneten. Fontos megjegyezni, hogy a legtöbbjük valamilyen bizonyítékot kér arra, hogy valóban jogosultak vagyunk az IP-t használni. Ezt többnyire az IP tartomány RIR bejegyzése szerinti tulajdonostól kérik (avagy az internet szolgáltatótól).
Csak ellenőrzött címek! # ↑
Ha valaki föliratkozik az e-mail listára, nagyon fontos ellenőrizni egy kiküldött levéllel, hogy a címzett valóban kérte-e a feliratkozást. A hibás címekre menő levelek rontják az IP címünk besorolását! Az sem lehetetlen, hogy ellenőrzés nélkül u.n. spamtrap címre küldünk levelet ami néhány levél után azonnali hatállyal feketelistára teszi a küldő IP címet.
Ennek elkerülésére bevett szokás, hogy a felhasználó által megadott e-mail cím ellenőrzésekor a háttérben nyitunk egy SMTP kapcsolatot és az RCPT TO parancsig lefolytatjuk a levélküldés folyamatát. Ez természetesen csak a tényleges ellenőrzéssel együtt ér valamit, hiszen nagyobb a hibák valószínűsége.
Azt gondolom, mondanom sem kell, hogy a mindenkori média és adatvédelmi törvények, valamint netikett értelmébe senkinek eszébe se jusson netről címeket gyűjteni vagy valakitől vásárolni, hiszen ez szinte predesztinálja a közutálatot és adott esetben a hatóságok látogatását.
Bounce kezelés # ↑
Az előzőek fényében a visszapattanó levelekben szereplő címeket mindenképpen érdemes levenni a következő kiküldés előtt, hogy minimalizáljuk a fölösleges szemetet.
Formai követelmények # ↑
Ha minden más technikai akadályt megugrottunk, még hátra vannak a formai követelmények a levéllel szemben:
Leiratkozás link, magyarázat # ↑
Remélhetőleg mondani sem kell, de minden levélben kötelező szerepelnie egy leiratkozás linknek, valamint egy magyarázó szövegnek, hogy miért kapja a címzett a levelet. A leiratkozás linken felül célszerű a levelezési listákra specifikus List-Unsubscribe fejlécet is elhelyezni. Természetesen a leiratkozási kérelmeket haladéktalanul, korrekt válaszlevél mellett teljesíteni kell és nem szabad szükségtelenül elbonyolítani.
HTML levelek # ↑
Amennyiben HTML levelet küldünk ki, az esetleges képeket ágyazzuk be és figyeljünk arra, hogy elegendő szöveg legyen ahhoz, hogy ne nézzék képi spamnek a levelünket. Arra is érdemes figyelni, hogy a HTML valid legyen.
Létezzen az e-mail cím # ↑
Akár tetszik, akár nem, egy rakás szolgáltató nem fog átvenni tőlünk levelet, ha nem létezik az e-mail cím, amiről küldjük a levelet. Ezért is, és a visszapattanó levelek feldolgozása érdekében is tegyünk róla, hogy a küldő cím létezzen.
Reverse DNS, Received fejlécek # ↑
Ez ugyan már a rendszergazda dolga, de fontos megemlíteni, hogy a küldő IP cím reverse DNS-e legyel beállítva és lehetőleg mutasson arra a domainre, amiről küldjük a levelet. Természetesen ennek a domainnek ugyanarra az IP-re kell visszamutatnia.
Ezen felül még arra is figyelni kell, hogy ne legyenek a levél törzsében olyan IP címek, amik ADSL vonalra utalhatna (ha pl a levélküldő szoftvert otthon futtattuk), hiszek ekkor az érzékenyebb szűrők azonnal vágják is a kukába a levelet.
Levélküldő szoftverek # ↑
Ha a kiküldésre kerül a sor, mindenképpen figyelni kell néhány apróságra. Hacsak nem vagyunk SMTP szakértők, semmiképpen nem javaslom elkezdeni nulláról megírni a kiküldő szoftvert hiszen rengeteg e-mail küldő könyvtár létezik (pl SwiftMailer, PHPMailer), de ezen felül a nyílt forrású közösség komplett hírlevél-küldő szoftvereket is előállított (pl. poMMo). Ezek a szoftverek tartalmaznak egy rakat olyan problémára megoldást, amit egyébként még ki kellene tapasztalni. Hogy csak egyet említsek, a levelek kiküldési ütemezése.