Zašto je vaš kontaktni obrazac vaš najveći rizik za spam

Problem je stariji nego što mislite

Kontaktni obrasci vektor su spama još od ranih 2000-ih, ali se problem pogoršao kako su pružatelji usluga e-pošte postrožili zahtjeve za autentikaciju. Većina kontaktnih obrazaca i dalje je izrađena na isti način: korisnik ispuni obrazac, vaš poslužitelj pošalje e-poštu koristeći korisnikovu adresu u zaglavlju From, a vi čekate odgovore.

To je školski primjer ranjivosti za lažiranje e-pošte. Spameri mogu upotrijebiti vaš obrazac za slanje e-pošte koja izgleda kao da dolazi s bilo koje adrese koju žele, usmjerene preko IP adrese vašeg poslužitelja. Ako se na taj način pošalje dovoljno spama, vaša domena biva označena, a vaša legitimna transakcijska e-pošta prestaje stizati u ulazne sandučiće.

Rješenje je jednostavno, ali većina uputa i dalje ga pogrešno prikazuje.

Zašto su kontaktni obrasci toliko laki za zloupotrebu

Tipični kontaktni obrazac prihvaća tri polja: ime, e-poštu i poruku. Poslužiteljski obrađivač uzme tu adresu e-pošte i izravno je ubaci u zaglavlje From odlazne SMTP poruke. To je praktično za odgovore — možete samo kliknuti "odgovori" u svojem ulaznom sandučiću — ali je ujedno i poklon spamerima.

Evo što se događa kada spamer pronađe vaš obrazac:

1. Pošalje obrazac s adresom e-pošte žrtve u polju "from"
2. Vaš poslužitelj poslušno pošalje e-poštu s adresom te žrtve u zaglavlju From
3. Poslužitelj e-pošte žrtve vidi e-poštu koja tvrdi da dolazi s njihove domene, ali potječe s vaše IP adrese
4. Ako vaša domena nema ispravne SPF/DKIM/DMARC zapise (ili čak i ako ih ima), e-pošta ipak može proći jer su mnogi poslužitelji popustljivi prema prometu iz kontaktnih obrazaca
5. Žrtva primi spam koji izgleda kao da dolazi s njezine vlastite adrese, ili vaša domena bude označena zbog lažiranja

Ovo nije teorijski napad. Događa se stalno. Ako imate kontaktni obrazac i nikada niste provjerili zapisnike svojeg poslužitelja e-pošte, vjerojatno se već koristite na ovaj način.

Ispravan način slanja e-pošte iz kontaktnog obrasca

Rješenje je da se korisnički unos nikada ne stavlja u zaglavlje From. Umjesto toga:

• From: [email protected] (ili bilo koja adresa koju kontrolirate)
• Reply-To: Adresa e-pošte koju je korisnik poslao
• Subject: Uključite korisnikovo ime ako želite, ali nikada njegovu e-poštu
• Body: Uključite sve podatke iz obrasca, jasno označene

Na taj način vaš poslužitelj šalje e-poštu samo s adresa koje posjedujete i koje ste pravilno autentificirali. Kada kliknete "odgovori" u svojem ulaznom sandučiću, poruka i dalje ide korisniku — tome služi Reply-To. Ali spameri ne mogu upotrijebiti vaš obrazac za predstavljanje kao proizvoljne adrese.

Većina biblioteka za e-poštu podržava ovo odmah. U PHP-ovom PHPMaileru:

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

U Pythonovom smtplib s email.mime:

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

U Node.js s Nodemailerom:

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

Ako vaš kontaktni obrazac trenutačno stavlja korisnički unos u zaglavlje From, ovo je ispravak u jednom retku. Učinite to danas.

Ograničavanje učestalosti nije opcionalno

Čak i uz uredna zaglavlja, nezaštićeni kontaktni obrazac i dalje je vektor spama. Spameri će slati vaš obrazac stotine puta s različitim tekstovima poruke, a vaš ulazni sandučić napunit će se smećem.

Potrebno vam je ograničavanje učestalosti na više razina:

• Po IP adresi: Ne više od 5 slanja po satu s iste IP adrese
• Po e-pošti: Ne više od 3 slanja dnevno s iste adrese e-pošte
• Globalno: Ne više od 50 slanja po satu za sve korisnike (prilagodite prema svojem prometu)

Ograničavanje učestalosti pripada u kôd vaše aplikacije, ne samo u konfiguraciju web-poslužitelja. Ograničavanje učestalosti u Nginxu i Apacheu može pomoći, ali djeluje na razini zahtjeva i ne zna ništa o adresama e-pošte ni o obrascima zloupotrebe specifičnima za obrazac.

Ako koristite framework, vjerojatno postoji middleware za ograničavanje učestalosti koji možete dodati. Ako gradite od nule, jednostavan Redis brojač s ključevima koji istječu sasvim je dovoljan:

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

Ovo nije neprobojno — spameri mogu rotirati IP adrese — ali značajno povećava cijenu zloupotrebe.

CAPTCHA-e su kompromis, ne rješenje

Googleov reCAPTCHA v3 nevidljiv je i ocjenjuje korisnike na temelju ponašanja, što zvuči idealno. U praksi blokira legitimne korisnike češće nego što biste očekivali, osobito korisnike na VPN-ovima, Toru ili zajedničkim korporativnim mrežama.

reCAPTCHA v2 (potvrdni okvir "I'm not a robot") pouzdaniji je, ali dodaje trenje. Honeypot polja — skriveni unosi u obrazac koje ljudi neće ispuniti, ali botovi hoće — hvataju nesofisticirane botove bez ikakvog utjecaja na korisnika, ali ih svaki ozbiljan spamer trivijalno zaobilazi.

Najbolji pristup je slojevit:

1. Ispravna zaglavlja e-pošte (nepregovarivo)
2. Ograničavanje učestalosti (nepregovarivo)
3. Honeypot polje (laka pobjeda, bez nedostataka)
4. CAPTCHA samo ako i nakon navedenog i dalje dobivate značajan spam

Ako dodate CAPTCHA-u, koristite reCAPTCHA v3 s niskim pragom (0,5 ili niže) i rezervnim prijelazom na v2 za korisnike koji dobiju lošu ocjenu. Time se trenje održava niskim za većinu korisnika, a botovi se i dalje blokiraju.

Kada koristiti uslugu obrasca treće strane

Ako vodite malo web-mjesto i ne želite održavati infrastrukturu za obrasce, usluge trećih strana poput Formspree, Tally ili Netlify Forms sve to rješavaju umjesto vas. Ograničavaju učestalost, validiraju i šalju e-poštu sa svojih domena, pa vaša reputacija ostaje čista.

Kompromis je u tome što korisničke podatke šaljete trećoj strani, što može biti u sukobu s vašom politikom privatnosti ili obvezama prema GDPR-u. Obrada podataka na strani klijenta rastući je trend među timovima koji paze na privatnost, ali kontaktni obrasci po prirodi zahtijevaju obradu na strani poslužitelja — ne možete slati e-poštu iz preglednika bez izlaganja vjerodajnica.

Ako obrađujete osjetljive upite (pravne, medicinske, financijske), vjerojatno trebate vlastitu infrastrukturu za obrasce. Za sve ostalo, usluga treće strane razuman je izbor.

Problem s DMARC-om

Čak i ako popravite zaglavlja svojeg kontaktnog obrasca, niste sigurni ako vaša domena nema DMARC politiku. DMARC govori poslužiteljima primatelja što učiniti s e-poštom koja ne prođe SPF ili DKIM provjere. Bez toga spameri i dalje mogu slati e-poštu koja izgleda kao da dolazi s vaše domene, čak i ako ne koriste vaše poslužitelje.

Postavljanje DMARC-a izvan je opsega ovog članka, ali ako vam je reputacija e-pošte važna, ono je nepregovarivo. Počnite s politikom samo za nadzor (p=none) i postupno prijeđite na p=quarantine ili p=reject kada potvrdite da je vaša legitimna e-pošta pravilno autentificirana.

Što je s pristankom za kolačiće i praćenjem obrazaca?

Ako vaš kontaktni obrazac koristi analitiku ili marketinške piksele za praćenje slanja, vjerojatno podliježete pravilima GDPR-a i ePrivacyja. Većini kontaktnih obrazaca praćenje nije potrebno — već znate da je netko poslao obrazac jer ste primili e-poštu — ali ako koristite nešto poput Facebook Pixela ili događaja u Google Analyticsu, potreban vam je izričit pristanak prije učitavanja tih skripti.

Najjednostavniji pristup je uopće ne pratiti slanja kontaktnih obrazaca. Ako ih morate pratiti, učitavajte skripte za praćenje tek nakon što korisnik pristane i provjerite je li vaš banner za pristanak usklađen s pravilima.

Ključne pouke

• Nikada ne stavljajte adrese e-pošte koje korisnik pošalje u zaglavlje From. Umjesto toga koristite Reply-To.
• Ograničavanje učestalosti je obvezno. Implementirajte ga na razini aplikacije, ne samo na web-poslužitelju.
• Honeypot polja besplatna su pobjeda. CAPTCHA-e trebaju biti krajnja mjera.
• Usluge obrazaca trećih strana razuman su izbor za mala web-mjesta, ali uvode kompromise u pogledu privatnosti.
• Ako šaljete bilo kakvu e-poštu sa svoje domene, potrebna vam je DMARC politika.

FAQ

Q: Mogu li jednostavno onemogućiti kontaktni obrazac i umjesto toga koristiti mailto poveznicu?

A: Možete, ali mailto poveznice izlažu vašu adresu e-pošte scraperima i gubite mogućnost prikupljanja strukturiranih podataka. Ako je spam preplavljujući, mailto poveznica bolja je od neispravnog kontaktnog obrasca, ali popravak obrasca bolji je od oboje.

Q: Što ako iz legitimnih razloga moram slati e-poštu s korisnikove adrese?

A: Gotovo sigurno ne morate. Ako mislite da morate, vjerojatno pokušavate riješiti problem tijeka rada (poput usmjeravanja odgovora) koji Reply-To već rješava. Ako doista trebate slati e-poštu s proizvoljnih adresa, potrebna vam je namjenska usluga e-pošte s pravilnom autentikacijom, a ne kontaktni obrazac.

Q: Kako mogu znati zloupotrebljava li se moj kontaktni obrazac već?

A: Provjerite zapisnike svojeg poslužitelja e-pošte za odlazne SMTP veze. Ako vidite velik volumen odlazne e-pošte prema adresama koje ne prepoznajete, ili ako je vaša domena označena u bazama spama poput Spamhausa, vjerojatno vas se koristi kao relej. Alati poput MXToolboxa mogu provjeriti reputaciju vaše domene.

Q: Je li sigurno koristiti besplatnu CAPTCHA uslugu?

A: Googleov reCAPTCHA besplatan je i široko korišten, ali šalje korisničke podatke Googleu, što može biti u sukobu s vašom politikom privatnosti. hCaptcha je alternativa usmjerena na privatnost koja ne trenira AI modele na vašim korisnicima. Cloudflare Turnstile još je jedna opcija koja je manje nametljiva od tradicionalnih CAPTCHA-a.

Q: Koja je razlika između SPF-a, DKIM-a i DMARC-a?

A: SPF navodi kojim je poslužiteljima e-pošte dopušteno slati e-poštu s vaše domene. DKIM kriptografski potpisuje odlaznu e-poštu kako bi primatelji mogli provjeriti da nije izmijenjena. DMARC ih povezuje i govori primateljima što učiniti ako e-pošta ne prođe SPF ili DKIM provjere. Za pravilnu autentikaciju e-pošte potrebna su vam sva tri.

Izvori

• OWASP: Email Header Injection — Detaljno objašnjenje kako se kontaktni obrasci mogu zloupotrijebiti za lažiranje e-pošte.
• RFC 5322: Internet Message Format — Tehnički standard koji definira zaglavlja e-pošte, uključujući From i Reply-To.
• DMARC.org: Overview — Službeni resurs za razumijevanje i implementaciju DMARC politika.
• Spamhaus: Domain Blocklists — Provjerite je li vaša domena označena zbog spama i shvatite kako funkcioniraju popisi blokiranih domena.