Når kontaktskjemaet sier «Takk», men ingen e-post kommer frem

Tenk deg en liten fysioterapipraksis. Nettstedet har et kontaktskjema, og skjemaet virker – eller ser i det minste slik ut. Besøkende fyller det ut, klikker «Send» og ser et vennlig «Takk, vi tar snart kontakt». Det ingen ser: meldingene sluttet å nå praksisens innboks for en tid siden. Ingen feil, ingen returmelding i noens innboks, intet rødt lys noe sted. Skjemaet svikter stille.

Hvorfor ingen merker det

En «Takk»-side fra et skjema betyr vanligvis bare én ting: nettstedet sendte meldingen videre. Om en e-postserver godtar den, legger den i søppelpost eller avviser den underveis, skjer senere, utenfor skjemaets synsfelt. PHP-funksjonen mail() melder for eksempel suksess så snart det lokale systemet godtar meldingen for levering – ikke når den når noen. Den besøkende får derfor en bekreftelse og går videre. Eieren ser imens en tom innboks og antar at det bare er en stille måned. Færre henvendelser er sjelden alarmerende alene: ferier, været, økonomien – det finnes alltid en forklaring som høres mer sannsynlig ut enn «skjemaet er ødelagt».

De vanlige årsakene

• SMTP-passordet eller e-postleverandøren er endret. Skjemaet fortsetter å logge inn med de gamle opplysningene, og e-postserveren nekter – stille, så langt den besøkende kan se.
• PHP mail() uten autentisering. Webserveren sender e-post direkte uten å logge inn på en ordentlig e-postserver. Mange mottakerservere behandler slik e-post som mistenkelig: den havner i søppelpost eller avvises helt.
• SPF, DKIM og DMARC samsvarer ikke. Mange skjemaer setter den besøkendes adresse i From-feltet. Meldingen hevder da å komme fra for eksempel en gmail.com-adresse, men sendes av webserveren din – nettopp det DMARC er laget for å stoppe.
• En oppdatering av programtillegg eller et temabytte ødelegger skjemaet eller CAPTCHA-en. En endret mal mister et felt, et skript lastes ikke lenger, eller CAPTCHA-widgeten vises uten skriptet – og hver innsending feiler valideringen.
• Mottakerpostkassen er full. E-postserveren nekter nye meldinger, og returmeldingen går til en adresse ingen leser.
• Informasjonskapselbanneret blokkerer skjemaskriptet. Hvis samtykkeverktøyet klassifiserer CAPTCHA-en eller skjemaskriptet som «markedsføring», kan besøkende som avviser informasjonskapsler, få et skjema som ikke kan sendes inn, eller der innsendinger avvises fordi et token mangler.
• Et utløpt TLS-sertifikat eller domene. Besøkende ser en nettleseradvarsel og forlater siden, eller e-postserveren kan ikke lenger nås sikkert. Hvis domenet til mottakerpostkassen utløper, stopper e-post dit ganske enkelt.
• Et mellomlagringslag leverer gamle sider. En fullsidebuffer kan levere et skjema med et utløpt sikkerhetstoken (en nonce eller et CSRF-token). Serveren avviser innsendingen, og avhengig av oppsettet ser den besøkende ingen tydelig feil.

From-adressefellen

Den tredje årsaken fortjener nærmere oppmerksomhet, fordi mange skjemaoppsett har den innebygd som standard. DMARC kontrollerer om domenet i den synlige From-adressen samsvarer med et domene SPF eller DKIM går god for. Hvis skjemaet sender en melding «fra» den besøkendes adresse, er serveren din ikke autorisert til å sende for det domenet, så kontrollen mislykkes. Avhengig av DMARC-policyen til den besøkendes domene og din egen e-postleverandør havner meldingen i søppelpost eller avvises. Løsningen er enkel: send fra en adresse på ditt eget domene og sett den besøkendes adresse i Reply-To. Et klikk på «Svar» når fortsatt den besøkende.

Hva du bør gjøre

1. 1Send en testmelding gjennom ditt eget skjema regelmessig – minst månedlig, og alltid etter oppdateringer, temabytter eller endringer i e-postinnstillingene. Merk den tydelig som test slik at ingen svarer på den.
2. 2Kjenn den vanlige rytmen din. Hvis skjemaet vanligvis gir noen meldinger i uken, er to ukers stillhet grunn til å kontrollere, ikke en stille måned.
3. 3Send via SMTP med autentisering – gjennom e-postleverandøren eller en egen avsendingstjeneste – i stedet for å stole på PHP mail().
4. 4Bruk ditt eget domene i From og den besøkendes adresse i Reply-To. Konfigurer deretter SPF, DKIM og DMARC for domenet slik at meldingene består kontrollene.
5. 5Behold en kopi av hver innsending i databasen. Mange skjemaprogramtillegg tilbyr dette, noen ganger som et tillegg. Hvis e-posten feiler, finnes henvendelsene fortsatt.
6. 6Kontroller skjemaet etter hver oppdatering av programtillegg – inkludert CAPTCHA-en og også med informasjonskapsler avvist.

Slike kontroller er lette å glemme, og derfor er det verdt å automatisere dem. Med konto og bekreftet domene kan formexposed sende en tydelig merket testinnsending og kontrollere om den faktisk kommer frem (leveringskontrollen, bare etter aktivt valg). Tjenesten oppdager også stillhet – et skjema som vanligvis mottar meldinger, får plutselig ingen – og kontrollerer SPF, DKIM og DMARC for varslings-e-postene samt utløp av TLS-sertifikat og domene. Du varsles bare når noe endres.

Hvis du bare vil ta en første titt: en gratis kontroll på formexposed.com krever ingen konto og sender ikke inn noe. Den viser blant annet om en CAPTCHA finnes, men er ødelagt – en widget uten skriptet, en offentlig testnøkkel, feil i nettleseren – en av de stillere måtene et skjema slutter å virke på. Om meldinger faktisk kommer frem, kan bare bekreftes med en ekte testmelding, så send en i dag.