Amikor a kapcsolatfelvételi űrlap azt írja: „Köszönjük”, de levél nem érkezik

Képzeljen el egy kis gyógytornász-rendelőt. A weboldalán van egy kapcsolatfelvételi űrlap, és az űrlap működik – vagy legalábbis úgy tűnik. A látogatók kitöltik, a „Küldés” gombra kattintanak, és egy kedves „Köszönjük, hamarosan jelentkezünk” üzenetet látnak. Amit senki sem lát: az üzenetek egy ideje már nem jutnak el a rendelő postafiókjába. Nincs hiba, nincs visszapattanó levél senki postafiókjában, sehol sem gyullad ki piros lámpa. Az űrlap csendben hibázik.

Miért nem veszi észre senki

Egy űrlap „Köszönjük” oldala általában csak egyetlen dolgot jelent: a weboldal továbbadta az üzenetet. Hogy egy levelezőszerver elfogadja, spamként sorolja be vagy útközben elutasítja, az később, az űrlap látókörén kívül történik. A PHP mail() függvénye például már akkor sikert jelez, amikor a helyi rendszer kézbesítésre átveszi az üzenetet – nem akkor, amikor az bárkihez is eljut. A látogató tehát visszaigazolást kap, és továbblép. A tulajdonos eközben üres postafiókot lát, és azt feltételezi, hogy csak csendes hónap van. A kevesebb megkeresés önmagában ritkán riasztó: szabadságok, az időjárás, a gazdaság – mindig van olyan magyarázat, amely hihetőbbnek hangzik annál, hogy „elromlott az űrlap”.

A szokásos okok

• Megváltozott az SMTP-jelszó vagy a levelezőszolgáltató. Az űrlap továbbra is a régi hitelesítő adatokkal jelentkezik be, a levelezőszerver pedig elutasítja – a látogató számára észrevétlenül.
• PHP mail() hitelesítés nélkül. A webszerver közvetlenül küldi a levelet, anélkül hogy bejelentkezne egy rendes levelezőszerverre. Sok fogadó szerver gyanúsnak tekinti az ilyen leveleket: a spambe kerülnek, vagy azonnal elutasítják őket.
• Az SPF, a DKIM és a DMARC nem illeszkedik egymáshoz. Sok űrlap a látogató címét teszi a From mezőbe. Az üzenet ekkor azt állítja, hogy mondjuk egy gmail.com-os címről érkezik, de az Ön webszervere küldi – pontosan ezt hivatott megakadályozni a DMARC.
• Egy bővítményfrissítés vagy témaváltás elrontja az űrlapot vagy a CAPTCHA-ját. Egy módosított sablonból kimarad egy mező, egy szkript már nem töltődik be, vagy a CAPTCHA-widget a szkriptje nélkül jelenik meg – és minden beküldés elbukik az érvényesítésen.
• Megtelt a fogadó postafiók. A levelezőszerver elutasítja az új üzeneteket, a visszapattanó levél pedig egy olyan címre megy, amelyet senki sem olvas.
• A sütibanner blokkolja az űrlap szkriptjét. Ha a hozzájáruláskezelő eszköz a CAPTCHA-t vagy az űrlap szkriptjét „marketing” kategóriába sorolja, a sütiket elutasító látogatók olyan űrlapot kaphatnak, amely nem küldhető el, vagy amelynek beküldéseit hiányzó token miatt elutasítják.
• Lejárt TLS-tanúsítvány vagy domain. A látogatók böngészőfigyelmeztetést látnak és távoznak, vagy a levelezőszerver már nem érhető el biztonságosan. Ha a fogadó postafiók domainje lejár, a rá küldött levelek egyszerűen nem érkeznek meg többé.
• Egy gyorsítótárazási réteg elavult oldalakat szolgál ki. Egy teljes oldalas gyorsítótár lejárt biztonsági tokennel (nonce-szal vagy CSRF-tokennel) is kiszolgálhatja az űrlapot. A szerver elutasítja a beküldést, és a beállítástól függően a látogató nem lát egyértelmű hibaüzenetet.

A feladócím csapdája

A harmadik ok közelebbi vizsgálatot érdemel, mert sok űrlapbeállításba alapértelmezetten be van építve. A DMARC azt ellenőrzi, hogy a látható From címben szereplő domain megegyezik-e egy olyan domainnel, amelyért az SPF vagy a DKIM kezeskedik. Ha az űrlap a látogató címéről „küldi” az üzenetet, az Ön szervere nem jogosult az adott domain nevében küldeni, így az ellenőrzés sikertelen. A látogató domainjének DMARC-szabályzatától és az Ön levelezőszolgáltatójától függően az üzenet a spambe kerül, vagy elutasítják. A megoldás egyszerű: küldjön a saját domainjén lévő címről, a látogató címét pedig tegye a Reply-To mezőbe. A „Válasz” gombra kattintva így is a látogatóhoz jut el a levél.

Mit tegyen

1. 1Küldjön rendszeresen tesztüzenetet a saját űrlapján keresztül – legalább havonta, és mindig frissítések, témaváltások vagy a levelezési beállítások módosítása után. Jelölje egyértelműen tesztként, hogy senki se válaszoljon rá.
2. 2Ismerje a szokásos ritmust. Ha az űrlap általában heti néhány üzenetet hoz, a kéthetes csend ok az ellenőrzésre, nem csendes hónap.
3. 3Küldjön hitelesített SMTP-n keresztül – a levelezőszolgáltatóján vagy egy erre szakosodott levélküldő szolgáltatáson át –, ahelyett hogy a PHP mail()-re hagyatkozna.
4. 4A From mezőben a saját domainjét, a Reply-To mezőben a látogató címét használja. Ezután állítsa be az SPF-et, a DKIM-et és a DMARC-ot ehhez a domainhez, hogy az üzenetek átmenjenek az ellenőrzéseken.
5. 5Őrizzen meg minden beküldésről másolatot az adatbázisban. Sok űrlapbővítmény kínálja ezt, néha kiegészítőként. Ha a levélküldés meghiúsul, a megkeresések akkor is megmaradnak.
6. 6Ellenőrizze az űrlapot minden bővítményfrissítés után – a CAPTCHA-val együtt, és elutasított sütikkel is.

Az ilyen ellenőrzéseket könnyű elfelejteni, ezért érdemes automatizálni őket. Fiókkal és igazolt domainnel a formexposed egyértelműen megjelölt tesztbeküldést tud küldeni, és ellenőrzi, hogy valóban megérkezik-e (kézbesítés-ellenőrzés, csak külön bekapcsolás esetén). A csendet is észleli – ha egy általában üzeneteket kapó űrlap hirtelen egyet sem kap –, és ellenőrzi az értesítő levelek SPF-, DKIM- és DMARC-beállításait, valamint a TLS-tanúsítvány és a domain lejáratát. Csak akkor kap riasztást, ha valami megváltozik.

Ha csak egy első pillantást szeretne vetni rá: a formexposed.com ingyenes ellenőrzéséhez nem kell fiók, és semmit sem küld be. Többek között megmutatja, hogy van-e jelen CAPTCHA, amely azonban hibás – szkript nélküli widget, nyilvános tesztkulcs, hibák a böngészőben –, ami az űrlapok leállásának egyik csendesebb módja. Hogy az üzenetek valóban megérkeznek-e, azt csak egy valódi tesztüzenet igazolhatja, ezért küldjön egyet még ma.