İletişim formunuz neden en büyük spam sorumluluğunuz

Sorun sandığınızdan daha eski

İletişim formları 2000'lerin başından beri bir spam vektörü oldu, ancak e-posta sağlayıcıları kimlik doğrulama gereksinimlerini sıkılaştırdıkça sorun daha da büyüdü. Çoğu iletişim formu hâlâ aynı şekilde oluşturuluyor: kullanıcı bir form doldurur, sunucunuz From başlığında kullanıcının adresini kullanarak bir e-posta gönderir ve siz yanıtları beklersiniz.

Bu, ders kitabı niteliğinde bir e-posta sahteciliği açığıdır. Spam gönderenler, formunuzu kullanarak istedikleri herhangi bir adresten geliyor gibi görünen ve sunucunuzun IP'si üzerinden yönlendirilen e-postalar gönderebilir. Bu yolla yeterince spam çıkarsa alan adınız işaretlenir ve meşru işlemsel e-postalarınız gelen kutularına ulaşmamaya başlar.

Çözüm basittir, ancak çoğu eğitim hâlâ bunu yanlış anlatıyor.

İletişim formlarını bu kadar istismar edilebilir yapan şey

Tipik bir iletişim formu üç alan kabul eder: ad, e-posta ve mesaj. Sunucu tarafındaki işleyici bu e-posta adresini alır ve doğrudan giden bir SMTP iletisinin From başlığına yerleştirir. Bu, yanıtlar için kullanışlıdır—gelen kutunuzda sadece "reply" tuşuna basabilirsiniz—ama aynı zamanda spam gönderenler için de bir hediyedir.

Bir spam göndericisi formunuzu bulduğunda olan şudur:

1. Formu, "from" alanına bir kurbanın e-posta adresini yazarak gönderir
2. Sunucunuz usulca From başlığında o kurbanın adresi olan bir e-posta gönderir
3. Kurbanın posta sunucusu, kendi alan adından geldiğini iddia eden ancak sizin IP'nizden kaynaklanan bir e-posta görür
4. Alan adınızda doğru SPF/DKIM/DMARC kayıtları yoksa (hatta varsa bile), birçok sunucu iletişim formu trafiğine karşı esnek davrandığı için e-posta yine de geçebilir
5. Kurban, kendi adresinden geliyormuş gibi görünen spam alır veya alan adınız sahtecilik nedeniyle işaretlenir

Bu teorik bir saldırı değildir. Sürekli olur. Bir iletişim formu çalıştırıyorsanız ve posta sunucusu günlüklerinizi hiç kontrol etmediyseniz, muhtemelen zaten bu şekilde kullanılıyorsunuzdur.

İletişim formu e-postası göndermenin doğru yolu

Çözüm, kullanıcı girdisini asla From başlığına koymamaktır. Bunun yerine:

• From: [email protected] (veya kontrol ettiğiniz herhangi bir adres)
• Reply-To: Kullanıcının gönderdiği e-posta adresi
• Subject: İsterseniz kullanıcının adını ekleyin, ancak e-postasını asla eklemeyin
• Body: Tüm form verilerini açık etiketlerle ekleyin

Bu şekilde sunucunuz yalnızca size ait ve doğru şekilde kimliği doğrulanmış adreslerden e-posta gönderir. Gelen kutunuzda "reply" tuşuna bastığınızda yanıt yine kullanıcıya gider—Reply-To tam olarak bunu yapar. Ancak spam gönderenler formunuzu rastgele adreslerin kimliğine bürünmek için kullanamaz.

Çoğu e-posta kütüphanesi bunu kutudan çıktığı hâliyle destekler. PHP'nin PHPMailer'ında:

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

Python'ın smtplib kütüphanesinde email.mime ile:

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

Node.js'te Nodemailer ile:

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

İletişim formunuz şu anda kullanıcı girdisini From başlığına koyuyorsa, bu tek satırlık bir düzeltmedir. Bugün yapın.

Rate limiting isteğe bağlı değildir

Doğru başlık hijyeniyle bile, korunmayan bir iletişim formu hâlâ bir spam vektörüdür. Spam gönderenler formunuzu farklı mesaj gövdeleriyle yüzlerce kez gönderir ve gelen kutunuz çöp ile dolar.

Birden fazla düzeyde rate limiting gerekir:

• IP başına: Aynı IP'den saatte en fazla 5 gönderim
• E-posta başına: Aynı e-posta adresinden günde en fazla 3 gönderim
• Global: Tüm kullanıcılar genelinde saatte en fazla 50 gönderim (trafiğinize göre ayarlayın)

Rate limiting yalnızca web sunucusu yapılandırmanızda değil, uygulama kodunuzda yer almalıdır. Nginx ve Apache rate limiting yardımcı olabilir, ancak istek düzeyinde çalışırlar ve e-posta adresleri ya da forma özgü kötüye kullanım kalıpları hakkında bilgi sahibi değildirler.

Bir framework kullanıyorsanız, muhtemelen ekleyebileceğiniz bir rate-limiting middleware vardır. Sıfırdan geliştiriyorsanız, süresi dolan anahtarlarla basit bir Redis sayacı yeterlidir:

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")

Bu kurşun geçirmez değildir—spam gönderenler IP'leri döndürebilir—ancak kötüye kullanım maliyetini önemli ölçüde artırır.

CAPTCHA'lar bir takastır, çözüm değil

Google'ın reCAPTCHA v3'ü görünmezdir ve kullanıcıları davranışlarına göre puanlar; bu kulağa ideal gelir. Pratikte ise meşru kullanıcıları beklediğinizden daha sık engeller, özellikle VPN, Tor veya paylaşımlı kurumsal ağ kullananları.

reCAPTCHA v2 ("I'm not a robot" onay kutusu) daha güvenilirdir ancak sürtünme ekler. Honeypot alanları—insanların doldurmayacağı ancak botların dolduracağı gizli form girdileri—kullanıcıya hiçbir etkisi olmadan basit botları yakalar, ancak ciddi bir spam göndericisi için aşılması çok kolaydır.

En iyi yaklaşım katmanlıdır:

1. Doğru e-posta başlıkları (pazarlık konusu değil)
2. Rate limiting (pazarlık konusu değil)
3. Honeypot alanı (kolay kazanç, dezavantaj yok)
4. CAPTCHA yalnızca yukarıdakilerden sonra hâlâ ciddi spam alıyorsanız

CAPTCHA ekliyorsanız, düşük bir eşikle (0.5 veya daha düşük) reCAPTCHA v3 kullanın ve düşük puan alan kullanıcılar için v2'ye geri dönüş sağlayın. Bu, çoğu kullanıcı için sürtünmeyi düşük tutarken botları engellemeye devam eder.

Üçüncü taraf form hizmeti ne zaman kullanılmalı

Küçük bir site işletiyorsanız ve form altyapısını sürdürmek istemiyorsanız, Formspree, Tally veya Netlify Forms gibi üçüncü taraf hizmetler tüm bunları sizin için yönetir. Rate-limit uygular, doğrulama yapar ve e-postaları kendi alan adlarından gönderirler; böylece itibarınız temiz kalır.

Takası, kullanıcı verilerini üçüncü bir tarafa göndermenizdir; bu da gizlilik politikanızla veya GDPR yükümlülüklerinizle çelişebilir. Verileri istemci tarafında işlemek, gizlilik konusunda hassas ekipler için büyüyen bir eğilimdir; ancak iletişim formları doğası gereği sunucu tarafı işleme gerektirir—kimlik bilgilerini açığa çıkarmadan tarayıcıdan e-posta gönderemezsiniz.

Hassas başvurularla ilgileniyorsanız (hukuki, tıbbi, finansal), muhtemelen kendi form altyapınızı çalıştırmanız gerekir. Diğer her şey için üçüncü taraf bir hizmet makul bir seçimdir.

DMARC sorunu

İletişim formu başlıklarınızı düzeltmiş olsanız bile, alan adınızda bir DMARC politikası yoksa güvende değilsiniz. DMARC, SPF veya DKIM kontrollerinden geçemeyen e-postalarla ne yapılacağını alıcı posta sunucularına söyler. Onsuz, spam gönderenler sunucularınızı kullanmasalar bile alan adınızdan geliyormuş gibi görünen e-postalar göndermeye devam edebilir.

DMARC kurulumu bu makalenin kapsamı dışındadır, ancak e-posta itibarı konusunda ciddiyseniz pazarlık konusu değildir. Yalnızca izleme amaçlı bir politikayla (p=none) başlayın ve meşru e-postalarınızın doğru şekilde kimlik doğrulamasından geçtiğini doğruladıkça kademeli olarak p=quarantine veya p=reject değerlerine geçin.

Çerez onayı ve form takibi ne olacak?

İletişim formunuz gönderimleri izlemek için analytics veya pazarlama pikselleri kullanıyorsa, muhtemelen GDPR ve ePrivacy kurallarına tabisinizdir. Çoğu iletişim formunun izlemeye ihtiyacı yoktur—e-postayı aldığınız için birinin formu gönderdiğini zaten bilirsiniz—ancak Facebook Pixel veya Google Analytics events gibi bir şey kullanıyorsanız, bu script'ler yüklenmeden önce açık rıza almanız gerekir.

En basit yaklaşım, iletişim formu gönderimlerini hiç izlememektir. Bunları izlemeniz gerekiyorsa, izleme script'lerini yalnızca kullanıcı onay verdikten sonra yükleyin ve onay banner'ınızın uyumlu olduğundan emin olun.

Temel çıkarımlar

• Kullanıcı tarafından gönderilen e-posta adreslerini asla From başlığına koymayın. Bunun yerine Reply-To kullanın.
• Rate limiting zorunludur. Bunu yalnızca web sunucusunda değil, uygulama düzeyinde uygulayın.
• Honeypot alanları ücretsiz bir kazanımdır. CAPTCHA'lar son çare olmalıdır.
• Üçüncü taraf form hizmetleri küçük siteler için makul bir seçimdir, ancak gizlilik takasları getirir.
• Alan adınızdan herhangi bir e-posta gönderiyorsanız, bir DMARC politikasına ihtiyacınız vardır.

FAQ

Q: İletişim formunu devre dışı bırakıp bunun yerine bir mailto bağlantısı kullanabilir miyim?

A: Kullanabilirsiniz, ancak mailto bağlantıları e-posta adresinizi scraper'lara açar ve yapılandırılmış veri toplama yeteneğinizi kaybedersiniz. Spam bunaltıcıysa, bir mailto bağlantısı bozuk bir iletişim formundan iyidir; ancak formu düzeltmek ikisinden de iyidir.

Q: Meşru nedenlerle kullanıcının adresinden e-posta göndermem gerekirse ne olur?

A: Neredeyse kesinlikle gerekmez. Gerektiğini düşünüyorsanız, muhtemelen Reply-To'nun zaten çözdüğü bir iş akışı sorununu (yanıt yönlendirme gibi) çözmeye çalışıyorsunuzdur. Gerçekten rastgele adreslerden e-posta göndermeniz gerekiyorsa, bir iletişim formuna değil, doğru kimlik doğrulamaya sahip özel bir e-posta hizmetine ihtiyacınız vardır.

Q: İletişim formumun zaten kötüye kullanılıp kullanılmadığını nasıl anlarım?

A: Giden SMTP bağlantıları için posta sunucusu günlüklerinizi kontrol edin. Tanımadığınız adreslere yüksek hacimde giden e-posta görüyorsanız veya alan adınız Spamhaus gibi spam veritabanları tarafından işaretlendiyse, muhtemelen relay olarak kullanılıyorsunuzdur. MXToolbox gibi araçlar alan adınızın itibarını kontrol edebilir.

Q: Ücretsiz bir CAPTCHA hizmeti kullanmak güvenli mi?

A: Google'ın reCAPTCHA'sı ücretsizdir ve yaygın olarak kullanılır, ancak kullanıcı verilerini Google'a gönderir; bu da gizlilik politikanızla çelişebilir. hCaptcha, kullanıcılarınız üzerinde AI modelleri eğitmeyen, gizlilik odaklı bir alternatiftir. Cloudflare Turnstile, geleneksel CAPTCHA'lara göre daha az müdahaleci olan başka bir seçenektir.

Q: SPF, DKIM ve DMARC arasındaki fark nedir?

A: SPF, alan adınızdan e-posta göndermesine izin verilen posta sunucularını listeler. DKIM, alıcıların e-postanın değiştirilmediğini doğrulayabilmesi için giden e-postayı kriptografik olarak imzalar. DMARC bunları birbirine bağlar ve bir e-posta SPF veya DKIM kontrollerinden geçemezse alıcılara ne yapmaları gerektiğini söyler. Doğru e-posta kimlik doğrulaması için üçünün de olması gerekir.

Kaynaklar

• OWASP: Email Header Injection — İletişim formlarının e-posta sahteciliği için nasıl istismar edilebileceğine dair ayrıntılı açıklama.
• RFC 5322: Internet Message Format — From ve Reply-To dahil e-posta başlıklarını tanımlayan teknik standart.
• DMARC.org: Overview — DMARC politikalarını anlamak ve uygulamak için resmi kaynak.
• Spamhaus: Domain Blocklists — Alan adınızın spam nedeniyle işaretlenip işaretlenmediğini kontrol edin ve blocklist'lerin nasıl çalıştığını anlayın.