İletişim formu “Teşekkürler” diyor ama posta gelmiyorsa

Küçük bir fizyoterapi kliniği düşünün. Web sitesinde iletişim formu vardır ve form çalışır; en azından öyle görünür. Ziyaretçiler doldurur, “Gönder”e tıklar ve nazik bir “Teşekkürler, yakında size döneceğiz” mesajı görür. Kimsenin görmediği şudur: mesajlar bir süre önce kliniğin gelen kutusuna ulaşmayı bırakmıştır. Hata yoktur, kimsenin gelen kutusunda geri dönen posta yoktur, hiçbir yerde kırmızı ışık yanmaz. Form sessizce başarısız olur.

Neden kimse fark etmez?

Formun “Teşekkürler” sayfası genellikle yalnızca tek bir anlama gelir: web sitesi mesajı sonraki aşamaya aktarmıştır. Posta sunucusunun bunu kabul etmesi, spama atması veya yolda reddetmesi daha sonra, formun görüş alanı dışında gerçekleşir. Örneğin PHP'nin mail() işlevi, mesaj birine ulaştığında değil, yerel sistem onu teslim için kabul ettiği anda başarı bildirir. Ziyaretçi onayı alır ve yoluna devam eder. İşletme sahibi ise boş gelen kutusunu görüp yalnızca sakin bir ay olduğunu varsayar. Daha az talep gelmesi tek başına nadiren alarm verir: tatiller, hava, ekonomi; her zaman “form bozuk”tan daha makul görünen bir açıklama vardır.

Yaygın nedenler

• SMTP parolası veya posta sağlayıcısı değişmiştir. Form eski kimlik bilgileriyle oturum açmayı sürdürür ve posta sunucusu reddeder; ziyaretçinin anlayabildiği kadarıyla sessizce.
• Kimlik doğrulamasız PHP mail(). Web sunucusu, uygun bir posta sunucusunda oturum açmadan doğrudan posta gönderir. Birçok alıcı sunucu bu postayı şüpheli sayar: spama düşer veya doğrudan reddedilir.
• SPF, DKIM ve DMARC hizalanmaz. Birçok form ziyaretçinin adresini From alanına koyar. Böylece mesaj, örneğin gmail.com adresinden geldiğini iddia ederken web sunucunuzdan gönderilir; DMARC'ın durdurmak için tasarlandığı şey tam da budur.
• Eklenti güncellemesi veya tema değişikliği formu ya da CAPTCHA'sını bozar. Değişen şablon bir alanı atlar, bir betik artık yüklenmez veya CAPTCHA bileşeni betiği olmadan görünür; her gönderim doğrulamada başarısız olur.
• Alıcı posta kutusu doludur. Posta sunucusu yeni mesajları reddeder ve geri dönen posta kimsenin okumadığı bir adrese gider.
• Çerez bildirimi form betiğini engeller. Rıza aracı CAPTCHA'yı veya form betiğini “pazarlama” olarak sınıflandırırsa çerezleri reddeden ziyaretçiler gönderilemeyen veya token eksik olduğu için gönderimleri reddedilen bir formla karşılaşabilir.
• Süresi dolmuş TLS sertifikası veya alan adı. Ziyaretçiler tarayıcı uyarısı görüp ayrılır veya posta sunucusuna artık güvenli biçimde erişilemez. Alıcı posta kutusunun alan adının süresi dolarsa o adrese posta akışı durur.
• Önbellek katmanı eski sayfalar sunar. Tam sayfa önbelleği, süresi dolmuş güvenlik token'ı (nonce veya CSRF token'ı) içeren bir form sunabilir. Sunucu gönderimi reddeder ve kuruluma bağlı olarak ziyaretçi açık bir hata görmez.

From adresi tuzağı

Üçüncü neden daha yakından bakmayı hak eder; çünkü birçok form kurulumunda varsayılan olarak bulunur. DMARC, görünen From adresindeki alan adının SPF veya DKIM'in doğruladığı bir alan adıyla eşleşip eşleşmediğini kontrol eder. Form, ziyaretçinin adresinden geliyormuş gibi mesaj gönderiyorsa sunucunuz bu alan adı adına gönderime yetkili değildir ve kontrol başarısız olur. Ziyaretçinin alan adının DMARC politikasına ve kendi posta sağlayıcınıza bağlı olarak mesaj spama düşer veya reddedilir. Çözüm basittir: kendi alan adınızdaki bir adresten gönderin ve ziyaretçinin adresini Reply-To alanına koyun. “Yanıtla”ya tıklamak yine ziyaretçiye ulaşır.

Ne yapmalı?

1. 1Kendi formunuz üzerinden düzenli test mesajı gönderin: en az ayda bir, ayrıca güncelleme, tema değişikliği veya posta ayarı değişikliklerinden sonra mutlaka. Kimsenin yanıtlamaması için test olduğunu açıkça işaretleyin.
2. 2Normal ritminizi bilin. Form genellikle haftada birkaç mesaj getiriyorsa iki haftalık sessizlik, sakin bir ay değil kontrol etmek için nedendir.
3. 3PHP mail() işlevine güvenmek yerine posta sağlayıcınız veya özel bir gönderim hizmeti üzerinden kimlik doğrulamalı SMTP kullanın.
4. 4From alanında kendi alan adınızı, Reply-To alanında ziyaretçinin adresini kullanın. Ardından mesajların kontrollerden geçmesi için bu alan adına SPF, DKIM ve DMARC kurun.
5. 5Her gönderimin bir kopyasını veri tabanında tutun. Birçok form eklentisi bunu, bazen ek modül olarak, sunar. Posta başarısız olursa talepler hâlâ oradadır.
6. 6Her eklenti güncellemesinden sonra CAPTCHA dahil formu kontrol edin; çerezler reddedilmişken de.

Böyle kontrolleri unutmak kolaydır; bu nedenle otomatikleştirmek değerlidir. Bir hesap ve doğrulanmış alan adıyla formexposed, açıkça test olarak işaretlenmiş bir gönderim yapabilir ve gerçekten ulaşıp ulaşmadığını kontrol edebilir (gönderim kontrolü, yalnızca isteğe bağlı etkinleştirmeyle). Ayrıca sessizliği, yani normalde mesaj alan bir formun aniden hiç almamasını tespit eder; bildirim e-postalarının SPF, DKIM ve DMARC'ını, TLS sertifikasını ve alan adı süresinin dolmasını da kontrol eder. Yalnızca bir şey değiştiğinde uyarılırsınız.

Yalnızca ilk bakış istiyorsanız: formexposed.com'daki ücretsiz kontrol hesap gerektirmez ve hiçbir şey göndermez. Diğer şeylerin yanı sıra, CAPTCHA mevcutken bozuk olup olmadığını gösterir: betiği olmayan bileşen, herkese açık test anahtarı, tarayıcı hataları. Bunlar formun sessizce çalışmayı bırakmasının yollarındandır. Mesajların gerçekten ulaştığı yalnızca gerçek bir test mesajıyla doğrulanabilir; bugün bir tane gönderin.