Açıkça ortaya çıktığı gibi, spamı durdurmanın en etkin yollarından biri SMTP diyaloğu sırasında aktarıma gecikmeler koymaktır. Bu ilkel bir katran çukuru (teergrubing) türüdür (bkz. http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html).

Virüs taşıyan epostaların hemen hepsi ve çoğu spam çok kısa sürede büyük miktarda postayı göndermek üzere eniyilenerek amaca uygun hale getirilmiş bir SMTP istemci yazılımı yoluyla sunucunuza doğrudan doğruya teslim edilir. Böyle istemciler genel olarak Kalleş Yazılım olarak bilinir.

Kalleş yazılım yazarları bu işlemi yerine getirmek için RFC 2821 belirtimindekinden birazcık farklı birkaç kısayol kullanırlar. Kalleş yazılımların asıl hedefleri, sabırsızlıklarıyla ve özellikle yavaş yanıt vermeleriyle nam salmış posta sunucularıdır. Sunucu daha SMTP aktarımına hazır olduğunu belirtmeden sunucuya bir HELO veya EHLO komutu gönderirler ve/veya sunucunun PIPELINING yetisini ilan etmesini beklemeksizin çeşitli SMTP komutlarıyla boru hattı oluşturmayı denerler.

Bellibaşlı posta aktarımcıları (Exim gibi) özdevinimli olarak SMTP protokolünün bu şekilde hiçe sayılmasını eşzamanlama hataları olarak ele alır ve gelen bağlantıyı hemen keser. Eğer böyle bir posta aktarımcısı kullanıyorsanız, günlük kayıt dosyalarında bu tür bir bağlantı reddine rastlamışsınızdır. Aslında, sunucunuza SMTP aktarımının hemen başında aktarıma hazır olduğunu belirtmeden önce, zaman kaybına sebep olan bazı sınamalar yaptırıyorsanız (DNS Sınamaları gibi) böyle hatalar sıkça olur ve kalleş yazılımlar sunucunuzun canlanabilmek için biraz zamana ihtiyacı olabileceğini dikkate almadıklarından (spamcılar böyle düşünür) bir şansınız olur.

Ek gecikmeler koyarak da bunun oluşmasına yardımcı olabiliriz. Örneğin biraz bekleme kararı verebiliriz:

Nereden çıktı bu 20 saniye diyebilirsiniz. Neden bir dakika değil? Ya da birkaç dakika değil? Herşeyden önce, RFC 2821 gönderici konağın (istemcinin) her SMTP yanıtı için birkaç dakika beklemesini zorunlu kılar. Bazı alıcı konaklar, bilhassa Exim kullananlar, gelen posta teslimat bağlantılarına yanıt olarak Gönderici Varlık Sınaması uygularlar. Siz veya kullanıcılarınızdan biri böyle bir konağa posta gönderdiğinde, bu konak sizin alanınız için yetkilendirdiğiniz Posta Alıcısına bağlanıp gönderici adresinin doğrulanmasını sağlamak üzere bir SMTP diyaloğu başlatacaktır. Böyle bir Gönderici Varlık Sınaması için öntanımlı zamanaşımı 30 saniyedir. Eğer koyduğunuz gecikme bu sürenin aşılmasına sebep oluyorsa, istemcideki Gönderici Varlık Sınaması başarısız olacağından sizin ya da kullanıcınızın istediği posta teslimatı reddedilebilecektir (genellikle, posta teslimatının geri iade edilmeden önce 5 gün boyunca gerçekleştirilmeye çalışılacağını belirten bir geçici başarısızlık olarak).

Başka bir deyişle, meşru posta teslimatı ile ilgili girişimin başlamasını geciktirebileceğiniz en uzun süre 20 saniyedir.

Her SMTP aktarımına böyle gecikmeler uygulamak istemiyorsanız (çok meşgul bir siteniz vardır ve makinenizin kaynakları kıt kanaat yetiyordur), bu gecikmeleri “seçimlik” kullanabilirsiniz. Böyle durumlar:

Aslında seçimlik aktarım gecikmeleri, bundan sonraki bölümlerde açıklayacağımız sınamalardan daha az kesin sınamalarla birlikte kullanıldığında iyi bir yöntem olabilir. Siz, büyük ihtimalle SPEWS gibi karalistelerden kaynaklı olarak posta reddini tercih etmezsiniz, ama bu listeleri gecikmenin uygulanmasında sorunun belirleyicisi olarak kullanabilirsiniz. Tüm bunlardan sonra, aşağılayıcı bir gecikmeye konu olanlar dışında kalan meşru postaların teslimatları bundan etkilenmeyecektir.

Diğer taraftan, spam yapıldığının kesin kanıtını bulursanız (örn. SMTP Sınamaları yoluyla) ve sunucunuzun gücü yetiyorsa, teslimatı reddetmeden önce 15 dakikalık veya buna yakın uzunca bir gecikme uygulayabilirsiniz^[31]. Bunun spamcının yavaşlatılmasından başka bir yararı yoktur. Ama ne var ki, bunlar DNS karalistelerine ve bunlarla işbirliği yapanlara yakalanmadan önce daha az kişiye ulaşmalarını sağlamış olursunuz ve fedakarlığınızla başbaşa kalırsınız. :-)

Benim durumumda, gelen teslimat bağlantılarından reddedilenlerin %50'si, seçimlik aktarım gecikmeleri ve SMTP eşzamanlama hatalarının sonucu reddediliyor. Kabaca bir yaklaşımla, gelen döküntü postanın yaklaşık %50'si tek başına SMTP aktarım gecikmelerinin sonucu olarak durdurulmaktadır, diyebiliriz.

Ayrıca Soru: 5.1.'e de bakınız.