Benim kendim için de denemekte olduğum bir başka farklı yaklaşım, giden postanın
Zarf Göndericisi adresinin yerel kısmına bir dizgecik eklemek ve
teslimat durum bildirimlerini kabul etmeden önce
Zarf Alıcısı adresinde bu dizgeciğin varlığına bakmaktır. Örnek olarak, böyle bir gönderici adresinin biçimi şöyle olabilir:
yerelkısım=dizgecik@alanadı
Normal ileti yanıtları bundan etkilenmez. Çünkü bu yanıtlar, bu işlem sırasında içeriğine dokunulmayan From: veya Reply-To: başlıklarındaki adreslerle yapılır.
Söylemesi kolay, değil mi? Maalesef, bu amaca uygun bir imleme biraz karmaşık bir işlem. Hesaba katılması gereken bir takım olumsuz durumlar mevcut:
Bu yöntemin yararlı olabilmesi için, imli gönderici adresini spamcıların kullanamaması lazım. İm olarak bir zaman damgası kullanıp bir süre sonra kullanışsız hale gelecek bir adres oluşturulabilir:
gönderen=zamandamgası=dizgecik@alanadı
Postanızın
Grilisteleme yapan bir siteye de gidebileceğini gözönüne alırsak, zarf gönderici adresinizin belli bir alıcı için değişmez olması gerekir, aksi halde sürekli grilistede kalırsınız.
gönderen=alıcı=alıcının.alanadı=dizgecik@alanadı
Bu adres zamanaşımına uğramayacağından, bu adresle ilgili döküntü postalar görmeye başlarsanız, en azından kaçağın kaynağını öğrenmiş olursunuz. Bununla birlikte, aynı alıcıdan size gelen normal teslimatları etkilemeksizin, imli adresinize bu alıcıdan gelen postaları kolayca reddebilirsiniz.
Posta listelerinin sunucuları ile ilgili iki durum vardır. Genellikle, sunuculara yapılan isteklerde (“subscribe”/“unsubscribe” gibi), yanıtlar zarf gönderici adresi boş bırakılarak gönderilir.
İlk durum, sunucunun istek postasının
Zarf Göndericisi adresine gönderdiği yanıt ile ilgilidir. Posta listesi sunucusu ile ilgili sorun, komutların (
subscribe veya
unsubscribe gibi) genellikle farklı adreslere (
<discuss (at) en.tldp.org> listesi için
<discuss-subscribe (at) en.tldp.org> ve
<discuss-unsubscribe (at) en.tldp.org> gibi) gönderilmesidir. Böyle bir durumda, üyelik adresi ile listeye gönderilecek iletinin gönderici adresi farklı olacaktır -- ve bu örnekte, ayrıca, üyelikten çıkma isteğinde kullanılan adresten de farklı olacaktır. Sonuçta, ne listeye posta göndermek ne de üyelikten çıkmak mümkün olacaktır.
Bu durumda uzlaşma ancak gönderici adresinde imleme için sadece alıcının alan adının bulunmasıyla sağlanabilir. Yani, gönderici adresi şöyle üretilebilir:
üyeismi=en.tldp.org=dizgecik@üyelik.alanadı
İkinci durum, yanıtların, istek postasının (<spam-l-request (at) peach.ease.lsoft.com> gibi bir adrese istek yapılması gibi) ileti başlığındaki yanıtlama adresine gönderilmesi ile ilgilidir. Bu adres imli olmayacağından, liste sunucusundan gelen yanıt sunucunuz tarafından reddedilecektir.
Postayı imsiz alıcı adresine yollayan bu tür sunucuları “aklisteye” almaktan başka yapabileceğiniz pek birşey yoktur.
Bu noktada bu yaklaşım kenarından köşesinden kırılmaya başlar. Bununla birlikte, özgün postası sizin sunucunuzdan gönderilmemiş meşru teslimat durum bildirimleri de reddedilir. Bu durumda, postalarını sadece sizin denetiminizde olan sunucular üzerinden gönderen kullanıcılarınız için bunu yapmayı düşünebilirsiniz.
Sonuç olarak, yukarıda bahsedilen durumların hiçbirinin mevcut olmadığı durumlarda, bu yöntem dolaylı spamı engelleme imkanı vermekten başka, bunları üreten site sahiplerini eğitme imkanı da verir. Bunun yanında, yararlı bir yan etki olarak,
Gönderici Varlık Sınaması yapan siteler, özgün postanın sadece sizin sunucunuzdan gitmiş olması durumunda bir olumlu yanıt alacaklardır. Özünde, spamcılar tarafından gönderici adreslerin taklit edilmesine maruz kalma şansını düşürürsünüz.
Kullanıcılarınızın giden postalarında imli adresler belirtmek isteyip istemediklerine bağlı olarak, adreslerinin imsiz türlerine dönen postalara izin verecek konakları belirleyebilirsiniz. Örneğin, bu kullanıcılar posta sunucunuzun aynı zamanda sisteme kayıtlı kullanıcıları iseler, onların ev dizinlerindeki belli bir dosyanın içeriğine bakarak bunu yapabilirsiniz.