Kun yhteydenottolomake sanoo ”Kiitos”, mutta viestiä ei tule

Kuvittele pieni fysioterapiavastaanotto. Sen verkkosivustolla on yhteydenottolomake, ja lomake toimii – tai ainakin näyttää toimivan. Kävijät täyttävät sen, napsauttavat ”Lähetä” ja näkevät ystävällisen viestin ”Kiitos, otamme sinuun pian yhteyttä”. Mitä kukaan ei näe: viestit lakkasivat saapumasta vastaanoton postilaatikkoon jo jokin aika sitten. Virhettä ei ole, palautusviestiä ei näy kenenkään postilaatikossa, punaista valoa ei pala missään. Lomake pettää hiljaa.

Miksi kukaan ei huomaa

Lomakkeen ”Kiitos”-sivu tarkoittaa yleensä vain yhtä asiaa: verkkosivusto on välittänyt viestin eteenpäin. Se, hyväksyykö postipalvelin viestin, luokitteleeko se sen roskapostiksi vai hylkääkö se sen matkalla, tapahtuu myöhemmin, lomakkeen näkökentän ulkopuolella. Esimerkiksi PHP:n mail()-funktio ilmoittaa onnistumisesta heti, kun paikallinen järjestelmä hyväksyy viestin toimitettavaksi – ei silloin, kun se tavoittaa jonkun. Kävijä saa siis vahvistuksen ja jatkaa matkaansa. Omistaja puolestaan näkee tyhjän postilaatikon ja olettaa, että kuukausi on vain hiljainen. Yhteydenottojen väheneminen on harvoin itsessään hälyttävää: lomat, sää, taloustilanne – aina löytyy selitys, joka kuulostaa uskottavammalta kuin ”lomake on rikki”.

Tavalliset syyt

• SMTP-salasana tai sähköpostipalvelun tarjoaja on vaihtunut. Lomake kirjautuu edelleen vanhoilla tunnuksilla, ja postipalvelin kieltäytyy – kävijän näkökulmasta äänettömästi.
• PHP:n mail() ilman todennusta. Verkkopalvelin lähettää postin suoraan kirjautumatta varsinaiselle postipalvelimelle. Monet vastaanottavat palvelimet pitävät tällaista postia epäilyttävänä: se päätyy roskapostiin tai hylätään suoralta kädeltä.
• SPF, DKIM ja DMARC eivät täsmää. Monet lomakkeet laittavat kävijän osoitteen From-kenttään. Viesti väittää silloin tulevansa esimerkiksi gmail.com-osoitteesta, mutta sen lähettää verkkopalvelimesi – juuri sitä, mitä DMARC on suunniteltu estämään.
• Lisäosapäivitys tai teeman vaihto rikkoo lomakkeen tai sen CAPTCHAn. Muuttunut sivupohja pudottaa kentän, skripti ei enää lataudu tai CAPTCHA-widget näkyy ilman skriptiään – ja jokainen lähetys epäonnistuu validoinnissa.
• Vastaanottava postilaatikko on täynnä. Postipalvelin kieltäytyy vastaanottamasta uusia viestejä, ja palautusviesti menee osoitteeseen, jota kukaan ei lue.
• Evästebanneri estää lomakkeen skriptin. Jos suostumustyökalu luokittelee CAPTCHAn tai lomakkeen skriptin ”markkinoinniksi”, evästeistä kieltäytyvät kävijät voivat saada lomakkeen, jota ei voi lähettää tai jonka lähetykset hylätään puuttuvan tunnisteen vuoksi.
• Vanhentunut TLS-varmenne tai verkkotunnus. Kävijät näkevät selaimen varoituksen ja poistuvat, tai postipalvelimeen ei enää saada turvallista yhteyttä. Jos vastaanottavan postilaatikon verkkotunnus vanhenee, sinne lähetetty posti yksinkertaisesti lakkaa kulkemasta.
• Välimuistikerros tarjoaa vanhentuneita sivuja. Koko sivun välimuisti voi toimittaa lomakkeen, jonka turvatunniste (nonce tai CSRF-tunniste) on vanhentunut. Palvelin hylkää lähetyksen, eikä kävijä toteutuksesta riippuen näe selkeää virhettä.

From-osoitteen ansa

Kolmas syy ansaitsee tarkemman tarkastelun, koska monissa lomakeasetuksissa se on oletuksena sisäänrakennettu. DMARC tarkistaa, vastaako näkyvän From-osoitteen verkkotunnus verkkotunnusta, jonka SPF tai DKIM takaa. Jos lomake lähettää viestin kävijän osoitteesta ”lähetettynä”, palvelimellasi ei ole oikeutta lähettää kyseisen verkkotunnuksen nimissä, joten tarkistus epäonnistuu. Kävijän verkkotunnuksen DMARC-käytännöstä ja omasta sähköpostipalvelustasi riippuen viesti päätyy roskapostiin tai hylätään. Korjaus on yksinkertainen: lähetä oman verkkotunnuksesi osoitteesta ja laita kävijän osoite Reply-To-kenttään. ”Vastaa”-painikkeella tavoitat edelleen kävijän.

Mitä tehdä

1. 1Lähetä säännöllisesti testiviesti oman lomakkeesi kautta – vähintään kuukausittain ja aina päivitysten, teeman vaihtojen tai sähköpostiasetusten muutosten jälkeen. Merkitse se selvästi testiksi, jottei kukaan vastaa siihen.
2. 2Tunne normaali rytmisi. Jos lomakkeen kautta tulee yleensä muutama viesti viikossa, kahden viikon hiljaisuus on syy tarkistaa asia, ei hiljainen kuukausi.
3. 3Lähetä SMTP:n kautta todennusta käyttäen – sähköpostipalvelusi tai erillisen lähetyspalvelun kautta – sen sijaan, että luottaisit PHP:n mail()-funktioon.
4. 4Käytä From-kentässä omaa verkkotunnustasi ja Reply-To-kentässä kävijän osoitetta. Määritä sitten kyseiselle verkkotunnukselle SPF, DKIM ja DMARC, jotta viestit läpäisevät tarkistukset.
5. 5Säilytä kopio jokaisesta lähetyksestä tietokannassa. Monet lomakelisäosat tarjoavat tämän, joskus lisäosana. Jos sähköposti pettää, yhteydenotot ovat silti tallessa.
6. 6Tarkista lomake jokaisen lisäosapäivityksen jälkeen – myös CAPTCHA ja myös evästeistä kieltäydyttäessä.

Tällaiset tarkistukset unohtuvat helposti, minkä vuoksi ne kannattaa automatisoida. Tilin ja todennetun verkkotunnuksen avulla formexposed voi lähettää selvästi merkityn testilähetyksen ja tarkistaa, saapuuko se todella (toimitustarkistus, vain erikseen käyttöön otettuna). Se havaitsee myös hiljaisuuden – lomakkeen, joka tavallisesti saa viestejä, mutta yhtäkkiä ei saa yhtään – ja tarkistaa ilmoitusviestien SPF:n, DKIM:n ja DMARC:n sekä TLS-varmenteen ja verkkotunnuksen vanhenemisen. Saat hälytyksen vain, kun jokin muuttuu.

Jos haluat vain ensisilmäyksen: maksuton tarkistus osoitteessa formexposed.com ei vaadi tiliä eikä lähetä mitään. Se näyttää muun muassa, onko CAPTCHA olemassa mutta rikki – widget ilman skriptiään, julkinen testiavain, virheitä selaimessa – yksi hiljaisimmista tavoista, joilla lomake lakkaa toimimasta. Sen, saapuvatko viestit todella, voi vahvistaa vain oikealla testiviestillä, joten lähetä sellainen tänään.