25 Aralık 2008

İstenmeyen e-postalarla(Spam) mücadele

"Spam" olarak da bilinen "İstenmeyen e-postalar" ile mücadelede çeşitli yöntemler var. Eğer gmail, yahoo, msn gibi web tabanlı e-posta sağlayıcılarını kullanıyorsanız bu sağlayıcının sunduğu olanaklar dışında bir şey kullanamıyorsunuz. Eğer kendi e-posta sunucunuz varsa veya kurumunuzun e-posta sunucusunu kullanıyorsanız [[ ya da kurumunuzun sunucusunu yönetiyorsanız ;) ]], büyük olasılıkla SpamAssassin kullanıyorsunuzdur.

Spamassasin çeşitli kuralları uygulayıp, karalisteleri denetleyip her e-postaya ona göre bir "spam puanı" veriyor. Bir e-postanın spam puanı belirli bir değerin üstüne çıktığında ise istenmeyen e-posta olarak sınıflandırılıyor, ya işaretleniyor ya da posta kutunuza teslim edilmiyor.

Bir süredir bana gelen her istenmeyen postayı kara listelere bildiriyorum. Sizlere de aynısını yapmanızı tavsiye ederim. Ne kadar çok istenmeyen posta şikayet edilirse kara listelerin etkinliği o derece artar. Ayrıca, Türkiye'den bu listelere bildirim -tahminimce- az olduğu için Türkçe gönderilen spamlar hak ettikleri muameleyi görmüyorlar :) Bunun üstesinden birlikte gelebiliriz.

İstenmeyen posta bildiriminin en kolay olduğu iki kara liste uribl ve spamcop. Uribl, e-postaların içinde reklamı yapılan web sayfa adreslerini listeliyor. Spamcop ise, en az iki farklı kişiden şikayet gelmesi durumunda istenmeyen e-postanın kaynaklandığı ip adresini kara listesine ekliyor, bunun yanında bu IP adresinin ve -varsa- reklamı yapılan web sayfasının yer aldığı ağın yöneticisini haberdar ediyor.

spamcop'u kullanmak için özel bir şeye ihtiyacınız yok, üye olup giriş yaptıktan sonra, size gelen istenmeyen e-posta iletisini "Tüm başlık bilgileriyle birlikte" sayfadaki kutuya yapıştırıp, "Process spam" düğmesine basıp bekliyorsunuz. Daha sonra karşınıza bir analiz geliyor, burada e-postanın geldiği ip adresini, bulunduğu ağı ve o ağın yöneticilerinin e-posta adreslerini görüyorsunuz. Reklamı yapılan web sayfası adresleri için de benzer bilgiler görünüyor. "Send Spam Reports Now" düğmesine bastığınızda da ilgilere e-posta gönderiliyor. Daha önce belirttiğim gibi, e-posta göndermenin yanı sıra, yeterli sayıda şikayet geldiğinde spamcop'un kendi kara listesine bu IP adresleri ekleniyor. Detayları spamcop web sayfasında bulabilirsiniz.

uribl sadece spam ile reklamı yapılan web adreslerini listelediği için çalışması biraz farklı. Üye olduktan sonra önce "lookup" sayfasına web adresini yazıp listede yer alıp almadığına bakıyorsunuz "NOT Listed on URIBL" cevabı alırsanız sağ tarafta "request listing" bağlantısına tıklayarak listeleme isteyebilirsiniz. Karşınıza gelecek ekranda "List (required)" kutusunun içinden liste seçmeniz lazım. URIBL'nin farklı listeleme seviyeleri var ancak tüm şikayetlerin "black" listesi üzerine yapılmasını istiyorlar. Bu istenmeyen posta ve web sayfası ile ilgili kısa bir açıklama yapıp aşağıya postayı yapıştırın, ancak yine "tüm başlık bilgileriyle beraber" yapacaksınız unutmayın.

URIBL ile ilgili bir gözlemim; bir web sayfasının kara listeye girmesi için bir insanın onayından geçmesi gerekiyor. Her kabul edilen gönderiniz size "itibar puanı" kazandırıyor. Eğer üye olunca hemen Türkçe spamları raporlarsanız içeriği anlamadıkları için ve puanınız düşük olduğu için listelemeyebiliyorlar. Önceleri sadece İngilizce spamları raporlayıp bir miktar puan aldıktan sonra Türkçeleri de göndermenizi öneririm.

Bir e-postanın tüm başlıklarını(header) nasıl alacağınızı bilmiyorsanız, örneğin Thunderbird'de postanın üzerine tıkladıktan sonra "ctrl+u" klavye kısayolunu veya "Görünüm->Mesaj Kaynağı" menüsünü kullanabilirsiniz.

El ele verip spam ile mücadele edelim. Tabii en büyük mücadele arkadaşlarınızı ve ailenizi, virüs yuvası olup spam göndermekten sürüm sürüm sürünen windows makinalarından kurtarıp onları Linux ile tanıştırmakla olur, belirtmeden geçmeyelim :)

17 Aralık 2008

NFS ve Xen sorunu, çözüm UDP

Saç baş yolduran bir sorunla karşılaşan olursa yaşadıklarımızı yaşamasın diye günlüğe yazma ihtiyacı duydum.

Xen sanal makina altyapısını kullanan sanal makinalarımız var, ve bunlar NFS(Network File System: Ağ Dosya Sistemi) ile bir başka sunucudan kullanıcı ev dizinlerine erişiyorlar.

Bugün ilginç bir şekilde NFS işlemleri yavaşladı, dosyalara erişim ve IMAP sunucusu için elzem olan kilitleme işlemleri çooook uzun sürüyordu. IMAP sunucunun tepki vermediğini düşünen IMAP istemcisi ise (Thunderbird) tekrar tekrar bağlantı açıp sunucunun işini daha da zorlaştırıyordu.

İki koldan yaptığımız internet aramalarından çıkan çözüm önerilerinin tamamını tükettikten sonra (4 saat kadar sürdü bu) bir de IRC'ye sormak istedim. Daha önce de çözümsüz gibi görünen sorunları yaşamış birilerine IRC'de denk geldiğim olmuştu çünkü. Ancak "faydalı cevap/toplam soru" oranı düşük olduğu için yine son çare olarak gördüm. Freenode'da #solaris kanalına sorduk (NFS sunucu solaris, #nfs kanalında 10 kişi vardı ve cevap veren olmadı)

"UDP ile bağlan"

Dedi birisi, ve sorun çözüldü. Ben varsayılan olarak NFS'in UDP üzerinden çalıştığını düşünüyordum, ancak protokol belirtmediğinizde Deban Etch sürümü TCP bağlantısı kuruyormuş. NFS bağlama seçenekleri arasına "proto=udp" ekleyince sorunlar kuş oldu uçtu. Bunu komut satırından yapmak için

mount -t nfs -o proto=udp sunucu:/dizin /hedef
ve autofs kullanıyorsanız /etc/auto.master dosyasında, mevcut seçeneklerin yanına "proto=udp" ayarını aşağıdaki gibi eklemelisiniz.
/dizin map --ghost,intr,proto=udp

Bu meselenin sadece Xen altında çalışan sanal makinalarda ortaya çıktığını tekrar hatırlatayım.


ENGLISH VERSION

Today we had a problem with Xen virtual machines. Their NFS mounts started working very slow. Access to files and file locking were problematic and the IMAP server was crawling.

Web searches did not lead us to a solution, so we asked on #solaris IRC channel on Freenode.

It seems there is a problem with Xen guests, NFS and TCP. Switching to NFS mount over UDP did the trick. Use "-o proto=udp" as an option to mount command, or put "proto=udp" at the end of the map line in /etc/auto.master if you are using autofs. I tought that NFS used UDP by default but Debian Etch does not seem to agree.