Çevrimdışı

RDNS (Reverse Domain Name System) Ters isim kaydı demektir. PTR kaydı diye de adlandırılır.

RDNS tanımlamasını genelde ISP servisleri yapmaktadır yani bir host hizmeti aldığınızda sunucu yada vps kiraladığınızda makinanızdaki yada kontrol panelinizdeki DNS kısmından bu RDNS kaydını giremezsiniz.

Bu kaydın girilebilmesi için hizmet alınan ISP servisine kullandığınız ip adresi için istediğiniz ismi yazdırabilirsiniz.

Örnek olarak : 31.210.116.195 ip adresi için = linux.net.tr
yazdırabilirsiniz. RDNS kaydımız olmazsa ne olur eğer rdns kaydımız olmaz ise bir çok mail servisi veren firmaların mail sunucularına mail gönderemeyebilirsiniz firmaların %90 nı RDNS kaydını kontrol ettirmektedir %70 kısmıda SPF kaydını kontrol ettirmektedir.

Aslında DNS servisi olan tüm sunucularda RDNS girilmesi için kayıt imkanı bulunmaktadır fakat ana ip sağalayıcı kuruluşlar RIPE gibi ip tahsis edildiği zaman ip adresini kiralayan ISP lerin name server adreslerine bu RDNS kayıtlarının girilmesi için kayıt girerler ve bu yüzden sadece ISP ler bu kayıtları girebilmektedir.

Eğer bir C class 255 ip adresi ISP tarafından size tahsis edilmiş ise ISP firmasından size ait ip adreslerinin RDNS kayıtlarını sizin vereceğiniz sunucudaki name server adreslerine yönlendirilmesini sağlayabilir ve kendiniz bu kayıtları girebilirsiniz.

RDNS kaydınızın olup olmadığını aşağıdaki AOL adresinden sorgulayarak öğrenebilirsiniz.

[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]
[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]

-DNS sunucusu kurulumu ve DNS/rDNS/SPF yapılandırması hakkında-

Internete bağlı her "şey"in bir IP adresi vardır. Ancak 7/24 internete bağlı ve web, mail vs. gibi hizmetler veren sunucular Alan Ad'larına (Domain Name) ihtiyaç duyarlar. Alan adı ornek.com.tr şeklinde bir adresten başka bir şey değildir; 12.34.56.78 gibi bir sayılar dizisi yerine bir isim daha kolay hatırlanacağından kullanılırlar. İnternet kullanıcıları ise Domain Name Server(DNS) denen sunuculara bağlanıp "ornek.com.tr'nin IP adresini rica ediyorum." sorgusunu yaparlar ve ilgili IP'ye ulaşırlar. Dünya üzerinde birçok DNS sunucusu vardır(örnek olarak ttnet kullanıcıları özel olarak bir DNS kullanımı ayarlamamışlarsa ttnet'in 195.175.39.39 ve 195.175.39.40 IP'li kendi DNS sunucularına bağlanırlar) ve düzenli iletişim kurarak listelerini güncellerler.

Alan adınızı satın aldığınızda sizden bir Alan Adı Sunucusu (Name Server) ismi ve IP'si isterler, bu sizin alan adınızın internete yayılmasının başlangıç noktası olarak kullanılacaktır. Ben de kayıtlarımı düzgün yapmak istediğim için kendi DNS sunucumu kullanmaya karar verdim. Bunun için önce Berkeley Internet Name Domain 9. versiyonu (BIND9) kurdum:


BIND9 konfigürasyonu /etc/bind/ içerisinde. İlk olarak ilgilenmeniz gereken dosya ise /etc/bind/named.conf.local. Bu dosyayı aşağıdaki gibi değiştirdim (tüm IP'ler ve alan adları anonimleştirilmiştir; sunucunun alan adı ornek.com.tr ve IP'si 12.34.56.78 olarak kabul edilmiştir):


Bunların anlamı ise ornek.com.tr ve 56.34.12.in-addr.arpa adlı iki "bölge (zone)" (konum olarak karşılıkları olan alan adı toplulukları olarak düşünülebilir) olduğu ve bu bölgelerin konfigürasyonları /etc/bind/zones/bölge_dosyası şeklinde dosyaların içerisinde olduğudur (burada dosya isimlerinin fazla önemi yoktur, bölge adlarının doğru girilmesi yeterlidir).

ornek.com.tr bölgesi kendi kendini açıklar durumda. 56.34.12.in-addr.arpa ise IP'nizin ters DNS (reverse DNS, rDNS) kaydının bulunduğu bölgenin ismidir. Ters DNS, ismiyle aynı işi yapar: "12.34.56.78 IP'si hangi alan adına ait?" gibi soruları cevaplar. Tüm ters DNS kaydı bölgeleri (3 nolu IP bölümü).(2 nolu IP bölümü).(1 nolu IP bölümü).in-addr.arpa şeklindedir; başka bir deyişle IP'nizin ilk 3 numarasının ters sıralı haline .in-addr.arpa eklenmiş şeklidir. Bu doğrultuda 12.34.56.78 IP adresinin ters DNS kaydı için bölge 56.34.12.in-addr.arpa adında olacaktır. IP'nin son bölümünün eklenmemesi, genelde IP bloklarının (örneğin 12.34.56.0'dan 12.34.56.255'e kadar) bütün olarak satın alınmasından kaynaklanır (ancak ters DNS kaydı da bir DNS kaydı olduğundan dolayı her bir IP adresi tek bir alan adına işaret edebilir). Benim sistemimde ise tek bir IP adresi kullanılmıştır.

Önce ters DNS kaydının olacağı dosyayı düzenlemek için /etc/bind/zones/ klasörünü (yoksa) yaratıp /etc/bind/zones/rev.56.34.12.in-addr.arpa dosyasını yarattım ve içerisini şöyle düzenledim:


Teker teker açıklamak gerekirse:

$TTL, Time to Live, dosyanızdaki kayıtların, bu kayıtları depolayan(cache) diğer DNS sunucularında ne kadar tutulacağını belirler.
SOA kaydı (Start of Authority) ismi verilen DNS sunucusunun, dosyada verilen kayıtlar için "en yetkili" sunucu olduğunu anlatır.
hostmaster.ornek.com.tr bir sorunla karşılaşıldığında kullanılacak mail adresidir (
Bu forumdaki linkleri ve resimleri görebilmek için en az 25 mesajınız olması gerekir.
.tr kullanılmayıp hostmaster.ornek.com.tr kullanıldığına dikkat ediniz).
SOA kaydının içerisindeki ilk sayı seri numarasıdır (bu dosyada her değişiklik yapıldığında 1 artırılır) ve zaman değerleri ise çeşitli güncellemeler için kullanılan zaman aşımı değerleridir.
IN NS ns1.ornek.com.tr. satırı bir DNS sunucusu belirtir: ben kendi sistemimde ns1.ornek.com.tr adlı tek bir DNS sunucusu tercih ettim.
78 IN PTR mail.ornek.com.tr. satırı asıl ters DNS kaydıdır (türü PTR'dir): Buradaki ilk sayı IP adresinizin son bölümüdür. Ters DNS neredeyse sadece mail işlerine has bir teknoloji olduğu için kaydın son bölümünde adres olarak mail.ornek.com.tr. (ileride anlatacağım DNS kaydınızda kullandığınız MX kaydı hangi alan adına işaret ediyorsa) kullanılmalıdır.
Tüm alan adlarının sonuna bir adet . (nokta) konulduğuna dikkat edilmelidir.

ÖNEMLİ NOT: ttnet, bağımsız DNS sunucularındaki PTR kayıtlarını dikkate almıyor ve PTR kaydını ttnet DNS sunucularına ekletmek (aşağıda anlattığım şekilde) için ayrıca uğraşmanız gerekiyor; ancak ters DNS ayarlarının DNS sunucumda yapılı durmasında bir sakınca görmedim.

Sonra /etc/bind/zones/ornek.com.tr.db dosyasını yarattım ve içerisini şöyle düzenledim:


Teker teker açıklamak gerekirse:

@ sembolü, bölgenin isminin lakabıdır (alias). Bu örnekte ise ornek.com.tr.'ye çözümlenir.
@ IN MX 10 mail.ornek.com.tr. satırı mecburi bir mail sunucusu kaydıdır ve sunucunuzun mail işlerinden hangi alan adının sorumlu olduğunu anlatır. Doğru yapılmazsa birçok mail sunucusu gönderdiğiniz maili geri çevirir. "MX (Mail eXchanger)" olarak geçen bu kayıtta 10, tercih sırasıdır ve birden fazla MX kaydı olduğunda düşük numaralı olan (primary) tercih edilir. Adresi ise mail.ornek.com.tr olarak belirledim.
A (Address) kayıtlarında her bir satır sunucunun bir alt-sunucusunun IP karşılığını verir. Burada
Bu forumdaki linkleri ve resimleri görebilmek için en az 25 mesajınız olması gerekir.
ns1, mail, webmail gibi alt-sunucu (subdomain) adresleri için birer kayıt ve ek olarak @ için bir kayıt gereklidir.
ornek.com.tr. IN TXT "v=spf1 a mx ip4:12.34.56.78 mx:mail.ornek.com.tr -all" satırı bir "SPF (Sender Policy Framework)" kaydıdır. Bazı büyük mail sağlayıcıları tarafından "Olursa çok daha iyi olur, olmazsa Spam klasörüne düşmeyeceğinizi garanti edemeyiz." psikolojisiyle uygulanması için baskı kurduğu, spam'i engellemekte büyük payı olduğu sanılan ama aslında kolay taklit edilen ve pek bir işe yaramayan bir teknolojidir. Yine de bu konuda elimden bir şey gelmiyor ve uygulamaya karar veriyorum (örnek kayıttaki SPF metni [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresindeki yönergeler takip edilerek oluşturulmuştur). Ayrıca Hotmail'da Junk klasörüne düşmemek için kayıt olunması gereken Microsoft SenderID'nin uygulanmasını zorunlu kıldığı bir teknolojidir.

Ardından /etc/bind/named.conf.local adlı dosyayı, forwarders kısmına bir adet ttnet DNS sunucusu ekleyerek değiştirdim (bulunamayan alan adları için sorgulanması gereken DNS sunucuları forwarders'a eklenir ve benimki gibi sadece kendi alan adının kaydı bulunan DNS sunucuları için gereklidir):


Son olarak bind9'u yeniden başlattım:


Eğer bind9 doğru çalışıyorsa aşağıdaki komutu kullanınca benzer satırlar göreceksiniz:


Domain, 53 portunun standart ismidir ve DNS trafiği için (genelde UDP protokolünde) kullanılır.

Şu komutu sunucu üzerinde kullanarak bind9'un doğru çalışıp çalışmadığını kontrol edebilirsiniz:


Tabii ki bu alan adınızın dünyanın her yerinden aynı IP'ye çözümleneceği anl***** gelmez. Bu komut yalnızca ;; SERVER: 192.168.1.100#53(192.168.1.100) kısmında belirtilen IP'deki DNS sunucusunu sorgular. Başka bir DNS sunucusunu sorgulamak veya başka bir bilgisayardan kendi sunucunuzun DNS'ini sorgulamak için şu komutu kullanabilirsiniz:


DNS ayarlarımı bitirdiğim zaman alan adımı satın aldığım kurumun web sitesinden alan adı ayarlarıma girdim ve 'Alan adı sunucularını değiştir' kısmından ns1.ornek.com.tr adında ve 12.34.56.78 IP'sindeki DNS sunucumu tek DNS sunucusu olacak şekilde ayarladım.

DNS sunucuları kendilerini çok sık olmamakla birlikte düzenli olarak yenilerler. Deniyor ki alan adı kaydının Türkiye'nin tam***** yayılması 24 saate kadar, dünyanın tam***** yayılması 72 saate kadar sürebilir. Kendi alan adı sağlayıcımda iş saatleri içerisinde saat başı DNS sunucusu güncellemesi yapılıyordu ve ilk saat başından 5 dakika kadar sonra ttnet'in DNS sunucularında doğru IP görünmeye başlamıştı bile; ancak dünyanın geneline yayılması gerçekten 72 saate kadar sürdü.

Google'da arayınca çıkan whois hizmeti veren yabancı web siteleri tahminimce nadiren yenilenen statik listeler kullanıyorlar ve güncellemelerden anında haberdar olamıyorlar. Bunun yerine alan adınızın yayılıp yayılmadığını kontrol etmek için dünyanın birçok yerindeki sunuculardan alan adınızı çözümleyip işaret ettiği IP'ye ping atan [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresindeki aracı kullandım. Bana çok yardımı dokundu; kesinlikle kullanmanızı tavsiye ediyorum.

SPF kaydınızı doğrulamak için [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresindeki sorgulama botunu kullanabilirsiniz.

Bilgiler karma olarak toplanmış ve makale haline getirilmiştir.

ayberkozgur.blogspot.com & destek.inetmar.com

 

Çevrimdışı

Ters DNS kaydı eklettirmek hakkında

Büyük mail sağlayıcılarının tamamına ve diğer mail sunucularının çoğuna bir mail gönderdiğiniz zaman bu sunucu, mailin geldiği IP adresine ters DNS sorgusu yapar ve eline geçen alan adı, mailin geldiği
Bu forumdaki linkleri ve resimleri görebilmek için en az 25 mesajınız olması gerekir.
adresindeki ornek.com.tr alan adının MX kaydıyla birebir uyuşmuyorsa “Bu IP'den gelen maillere güvenmiyorum” şeklinde 4xx veya 5xx kodlu bir STMP hatasıyla mailinizi geri çevirir. Ters DNS, spam'i önlemede en etkili ve en güvenilir yoldur ve bu nedenle doğru yapılması şarttır.

Eğer gönderdiğiniz mailler spam kutularına dahi düşmüyor ve mail loglarını incelediğinizde aşağıdaki gibi hatalar alıyorsanız bu büyük ihtimalle ters DNS kaydının yapılmamış olduğundan kaynaklanıyordur:


Ters DNS kaydı eklettirmek ttnet'te çok zor alabileceğiniz bir hizmet. Resmi ttnet web sitelerinin hiçbirinde bu konuyla ilgili bilgi olmadığı gibi destek hatlarındaki görevlilerin de konuyla ilgili hiçbir bilgisi yok. Ortamda bulunan birilerine sorup “Şuraya sorun belki biliyorlardır.” şeklinde sizi tamamen yanlış yerlere yönlendiriyorlar. Bu doğrultuda makaleme bir 'Ters DNS için beyhude telefon numaraları listesi'ni uygun gördüm:

+90 312 313 19 50
+90 312 313 18 90
+90 312 313 18 92
+90 212 343 88 88
+90 212 253 43 24
+90 212 288 85 39
+90 312 555 47 62
ve kesinlikle 444 0 375

Yapılması gereken şey aslında dnsadmin@[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...].com.tr (veya dnsadmin@[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...].net.tr, tam olarak çözemedim ama ulaştığım kişiler ilkinin doğru olduğunu söylediler) adresine ters DNS kaydı talebinizi “12.34.56.78 IP'sine mail.ornek.com.tr kaydı” şeklinde resmi bir dille ifade eden bir mail atmak. Bu maili Gmail hesabım üzerinden göndermeme rağmen birkaç gün içinde cevap gelmeyince telefona sarıldım. DNS yönetimi departmanına en yakın bulabildiğim departman telefonu +90 312 555 19 20 (bu departman telefonlarının internette izine rastlanmıyor) oldu.

Oradaki görevlide ulaşmaya çalıştığım departmandaki görevlilerin cep telefonları varmış, öğrendiğime göre sorun böyle bir mailin onlara ulaşmamış olmasıymış. İlgili kişilere forwardlayabileceğini söylemesi üzerine bu görevlinin kişisel mailine DNS talebi mailimi gönderdim; aynı zamanda (kullanmamama rağmen) birer Yahoo ve Hotmail hesabı açıp onlar üzerinden de birer kopyasını hem dnsadmin@[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...].com.tr hem de dnsadmin@[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...].net.tr'ye gönderdim.

Bir süre sonra Hotmail hesabına “Talebiniz gerçekleştirilmiştir.” şeklinde bir mail geldi; bunun üzerine arayıp ters DNS kaydımın gerçekleştirildiğini teyit ettim. Ardından bir süre (10 dakika kadar) bekleyip testlerimi gerçekleştirmeye başladım. Eğer ters DNS ayarlarınız doğru yapılmışsa aşağıdaki komutu sunucunuz dışında başka bir bilgisayardan gerçekleştirince benzer sonuçlar alırsınız:

$ host 12.34.56.78
78.56.34.12.in-addr.arpa domain name pointer mail.ornek.com.tr.

Beni asıl şaşkınlığa uğratan şey dünyanın her yerinde ters DNS kaydının anında güncellenmiş olmasıydı. Internette kolayca ulaştığım ters DNS sorgularının hepsi doğru adresi gösteriyordu. Sonradan öğrendim ki reverse-IP kayıtları yalnızca internetin üst alan adlarından (TLD, Top Level Domain) “arpa” üzerinde tutuluyormuş; bu da DNS'lere yavaş yayılan alan adı kaydına karşılık ttnet'in anında ters DNS değişikliği yapabilmesini açıklıyor.

Karalisteler ve onlardan çıkmak (Blacklist removal) hakkında

Birçok büyük mail sağlayıcısı DNS karalisteleri (DNSBL, DNS Blacklist) ve gerçek-zamanlı karalistelerden (RBL, Realtime Blacklist) yararlanarak spam gönderen IP'leri filtrelemeye çalışırlar. Bu karalistelerden bazılarında dinamik IP aralıkları yasaklı vaziyettedir. Bu karalistelerden en büyüklerini bünyesinde barındıran Spamhaus projesinin PBL (Policy Black List) listesinde dinamik IP aralıkları yasaklıdır. Eğer gönderdiğiniz mail hedefine ulaşmıyor ve mail loglarında şöyle hatalar görüyorsanız bazı karalistelerde yer alıyorsunuz demektir:


Benim de bulunduğum bu listeden IP'mi çıkarmak için [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresinden müracaat etmem gerekti. Neyse ki sistem tamamen otomatize edilmiş ve doğrulama adına sunucuma maille gelen kodu siteye geri teslim edince çok kısa sürede listeden çıkabildim. Mail sağlayıcılarının listelerini güncellemeleri için birkaç saat bekledikten sonra aynı karalistelerde yer aldığıma dair hataları bir daha almadığımı gördüm.

Belli başlı karalistelerde yer alıp almadığınızı topluca kontrol etmek için [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresindeki aracı veya internetteki birçok bedava sorgulama aracını kullanabilirsiniz. Eğer belli bir karalistede gözüküyorsanız oradan çıkmanın tek yolunun o karalistenin web sitesine bir şekilde müracaat etmek olduğunu unutmayın.

NOT: Eğer karalistelere girmeye sebep olabilecek şekilde bir mail trafiği sergilerseniz çıktığınız karalistelere tekrar girmeniz an meselesidir; ancak bu sefer çıkması daha zor/imkansız karalistelere alınabilirsiniz. Bu nedenle attığınız maillere çok dikkat edin:

Mail gönderirken sendmail kullanmayın.
Başlıksız ve ana metinsiz mailler göndermeyin.
Genelde spam maillerinde kullanılan anahtar kelimeleri kullanmayın.

Portlar hakkında

Mail sunucusu kurarken router modem kullanılıyorsa dikkat edilmesi gereken en önemli noktalardan bir tanesi port açmak/kapatmaktır. Fazladan bir açık port bile sunucunuzu saldırılara maruz bırakma riski taşır. Aşağıda web/mail sunucunuzun lokal IP'si için açılması gereken portların bir listesini veriyorum, bunun dışındaki tüm portları kapayın:

Web sunucusu kullanılıyorsa TCP protokolüne 80 portu
SSH kullanılıyorsa TCP protokolüne 22 portu
DNS sunucusu kullanılıyorsa TCP ve UDP protokollerine 53 portu
Mail sunucusu kullanılıyorsa:
SMTP için TCP protokolüne 25 portu (birçok mail sunucusunu sizin 25 portunuza bağlanıp mail gönderecektir ve açılması zorunludur, ayrıca ttnet tarafından dinamik IP'lere hem giriş hem de çıkışı kapatılmıştır)
Yine SMTP için TCP protokolüne standart adı Submission olan 587 (mail istemcileriyle mail göndermek isteyen kullanıcılar genelde dinamik IP'ler üzerinden sunucunuza bağlanacakları için 25 alternatifi olan 587 portunu kullanmak zorundadılar; ancak bu büyük mail sunucularının size mail gönderirken 25'in yanında 587 portunu da deneyecekleri anlamına gelmez)
IMAP için TCP protokolüne 143 portu
POP3 için TCP protokolüne 110 portu

Aynı zamanda sunucunuzdaki belli bir hizmete dışarıdan ulaşmaya çalışıyor ve 'Timeout' hatası alıyorsanız bu büyük ihtimalle ulaşmaya çalıştığınız hizmetin dinlediği port kapalı demektir.

ÇOK ÖNEMLİ NOT: SSH portunu (22), sunucunuza SSH ile bağlanıp ayar yapmadığınız sürece kapalı tutun. Aşağıda sunucumdaki /var/log/auth.log'dan alıntılar veriyorum; bu alıntılarda dinamik IP'lerden sözlükten çekilmiş kullanıcı adlarıyla (büyük ihtimalle sözlükten çekilmiş şifreler deneyerek) ve root kullanıcısıyla sürekli çıkış portunu değiştirerek sunucuma izinsiz giriş yapılmaya çalışıldığı görülüyor:


Kesinlikle kullanıcılarınızın şifrelerinde (ve kullanıcı adlarında) sözlükteki kelimelerin bulunmamasına dikkat edin. Mümkünse şifreler için rastgele rakam/harf/sembol karışımlarını zorunlu hale getirin, bunun için internetteki “Random Password Generator”ları kullanın; özel olarak ezberlenmesi kolay karmaşık şifreler üretiyorlar. Eğer bir spam botu sunucunuzdaki bir kullanıcı adını ve şifreyi ele geçirirse sunucunuzu “aktarma sunucusu” (“relay host”) olarak kullanıp toplu spam gönderir ve bu da IP'nizin kalıcı olarak karalistelere girmesi demektir.

[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresinden ve internetteki diğer birçok bedava port tarama (port scan) aracından IP'nize port taraması gerçekleştirip sunucunuzda hangi sık kullanılan portların açık ve dinlemede olduğunu görebilirsiniz.

Giden mailin alıcıya ulaşıp ulaşmadığını kontrol etmek hakkında

Mail gönderirken ve özellikle gönderilen sunucunun alıp almadığını kontrol ederken bakmanız gereken /var/log/mail.log dosyasıdır. Ön tanımlı olarak postfix başarılı veya başarısız tüm mail trafiğini buraya kaydeder.

Aşağıdaki komutu kullanınca status=sent ve 250 kodlu bir SMTP mesajı görüyorsanız mailiniz karşıya başarıyla ulaşmış demektir; bunun dışındaki bütün SMTP kodları mailin ulaşmadığı anlamına gelir:


Mailinizin 250 kodu döndürmesi, mail sağlayıcılarının kendi iç filtreleriyle mailinizi spam kutusuna atmayacağı anlamına gelmez.

3 büyük mail sağlayıcısı, bazı diğer sağlayıcılar ve maillerimi onlara nasıl kabul ettir(eme)diğim hakkında

1.Gmail

Söylenecek fazla bir şey yok. Ters DNS, SPF gibi ayarlarım yapılı olmadığında bile mailimi spam olarak işaretlemedi; çünkü Google bazı standartları kullanma konusunda baskı uygulamak yerine spam'i akıllıca filtrelemeyi başarmış bir mail sağlayıcısıdır. Gmail'i kurulduğu ve sadece davetiyeyle üye aldığı zamandan (2004) beri kullanıyorum; spam kutumdaki maillerin başlıklarına tek tek bakar öyle silerim ve bir kez dahi olsun spam olmayan bir mail spam kutuma düşmemiştir; ancak şu ana kadar belki 5-6 kez bir spam gelen kutuma ulaşmıştır.

2.Superonline ve Garanti Bankası

Sunucunun hizmet verdiği şirketin posta trafiği dolayısıyla bu iki mail sunucusuyla muhatap olmamız gerekti ve çeşitli sorunlar yaşadık, diğer sunucularla da benzer sorunlar yaşanabileceğinden dolayı belirtmek istiyorum:


garanti.com.tr'den gelen hata mesajında gönderen MTA(Mail Transfer Agent, benim sistemimde postfix)'nın kötü bir itibara sahip olduğu söyleniyordu. Bu, “Postfix'in iyi bir MTA olduğuna inanmadığımdan postanızı kabul etmiyorum.” demekle eşdeğerdi. Bu doğru olamayacağından (belki komik olabilir) küçük bir araştırma yaptım; genelde karalistelerde bulunmakla bağlantılı bir mesaj olduğundan bahsediliyordu. IP'mi bulunduğu karalistelerden çıkarmamdan 5 saat kadar sonra, büyük mail sunucularının karalistelerini güncellemelerindense 3 saat kadar sonra mailin garanti.com.tr'ye ulaştığını gördüm:


Superonline'dan gelen hata mesajına göre Superonline gri listeleme (Greylisting) adı verilen ve benim kullanmayı tercih etmediğim teknolojiyi kullanıyor. Buna göre attığınız maili geçici olarak reddediliyor ve dolayısıyla MTA'nız bu maili sıraya alıyor(queue). Kısa bir süre (benim için bu süre 10 dakikaydı) bekledikten sonra bu mail tekrar gönderiliyor ve bu sefer kabul ediliyor:


Tahmin edebileceğiniz gibi otomatik toplu spam gönderenlerin kabul edemeyeceği bir bekleme süresi bu.

3.Hotmail

Microsoft'a ait tüm mail sağlayıcı kurumlar SenderID denen bir doğrulama yöntemi kullanıyor. Basit olarak SenderID'ye kayıt olmadıysanız Microsoft'un mail sistemlerine gönderdiğiniz mailler Junk kutusuna atılıyor. Ancak sizin Junk'a düşen mailinize cevap verilirse gönderdiğiniz mail bir kereliğine mahsus olmak üzere Inbox'a atılıyor.

SenderID'ye kayıt olmadan önce gönderdiğim mailler 250 kodu döndürüp Junk kutusuna atılıyordu:


[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresindeki yönergeleri takip ederek (SPF kaydınızın yapılı ve doğru olması gerekiyor çünkü zaten SenderID SPF kaydının yayınlanması ve incelenmesi üzerine kurulu bir sistem) kayıt işlemini gerçekleştirdim. Birkaç saat içerisinde sağladığım iletişim adresine şu mail geldi:

Hello,

Thank you for writing to the Sender ID Management Team. My name is Jaycee and I am responding to your request for the enrollment to the Sender ID program. I appreciate your interest in joining this program.

We have added your ornek.com.tr domain to the Sender ID program. This may take up to 2 business days to be fully replicated in our systems. If you have any questions regarding this please let me know.

We reviewed your SPF record and note that it includes the "ptr" or reverse DNS lookup mechanism. The specification for SPF records (RFC 4408) discourages use of "ptr" for performance and reliability reasons. This is especially important for Windows Live Mail, Hotmail and other large ISPs as a result of the very high volume of mail we receive each day. We highly recommend you remove the "ptr" mechanism from your SPF record and, if necessary, replace it with other SPF mechanisms that do not require a reverse DNS lookup, such as "a", "mx", "ip4" and "include." This will help ensure that Sender ID validation is performed as accurately as possible, maximizing your email deliverability while protecting your domain from spoofing.

You do not need to notify us when you make this or any revision to your SPF record since we will automatically pull the current record from the DNS daily. Thanks again for your support in improving online trust and confidence. You can find technical information on the Sender ID program at [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...].

Thanks again for your support in improving online trust and confidence.

Sincerely,

Jaycee C.

Sender ID Management Team

Bu maile göre SPF kaydımdaki “ptr” mekanizması ters DNS sorgulaması yapılmasını gerektirdiği için Microsoft sunucularına fazladan yük bindiriyormuş; bunun üzerine sunucumdaki SPF kaydından (/etc/bind/zones/ornek.com.tr.db dosyasındaki) “ptr” mekanizmasını kaldırdım (yukarıdaki SPF açıklamalarında düzeltilmiş hali yer almaktadır, eski hali "v=spf1 a mx ptr ip4:12.34.56.78 mx:mail.ornek.com.tr -all" şeklindeydi). Aynı zamanda “Sisteme yayılması 2 iş günü kadar sürebilir.” ve “SPF kaydınızda yaptığınız değişikliklerden bizi haberdar etmek zorunda değilsiniz.” deniyordu.

Tam bir gün sonra şu maili aldım:

Hi,

We've successfully added your domain to the Sender ID program. However, please take note that this does not guarantee that your emails will de delivered to your recipients' inbox. Publishing your SPF records and enrolling in our Junk Mail Reporting Program (JMRP) are the two policy requirements of Hotmail.

If you are still unable to send emails to Hotmail users, please confirm that your emails comply with Windows Live Hotmail's technical standards. Additional information on common deliverability issues and best practices can be found on the Windows Live/Hotmail Postmaster Site found at [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]

To enroll in our Junk Mail Reporting program, please visit [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]

Regards,

Renan

Sender ID Support Team

Bu SenderID kaydının başarıyla yapıldığını anlatıyordu; ancak bunun yine de Hotmail'in Junk kutusuna atılmamayı garanti etmeyeceği söyleniyordu. Bunun için ayrıca Junk Mail Reporting programına ([Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]) kayıt olmalıymışım. Kayıt formunu biraz inceleyince programın zaten düşük bütçeli ve sınırlı bağlantılı sunucumun Hotmail sunucularıyla fazladan haşır neşir olmasını gerektirdiğini anladım. Aynı zamanda JMR, mail gönderen kullanıcı sayısının ve kimliğinin sabit olmadığı sunucular için bir programa benziyordu. Kayıt yapmamaya karar verip, yeni açtığım bir Hotmail hesabı üzerinde testi gerçekleştirdim:


Giden mailim eskisiyle aynı şekilde 250 kodu döndürdü ve bu sefer Gelen kutusuna iletildi. Mutlu olup Hotmail defterini kapattım.

4.Yahoo

Gelen kutusuna mail iletmesi en zor mail sağlayıcı Yahoo'dur; çünkü büyük mail sağlayıcıları içerisinde spam'i engellemeye yönelik en agresif, ve son zamanlarda abartıya kaçan yöntemlere başvuranıdır. Yapabileceğim bütün ayarları yapıp IP'mi bütün karalistelerden çıkarmamın ardından yeni açılmış bir Yahoo hesabı üzerinde yaptığım testlerde şu sonucu aldım:


[Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresindeki yardım metninin sonunda yazıyor ki: “If you do not see these or similar error messages, you should see an SMTP confirmation code similar to '250 ok dirdel' that indicates your message has been delivered.” Bu “Mailiniz 250 dirdel döndürürse bize ulaşmış demektir.” demekle eşdeğerdi. Ancak mailim iç filtrelemeyle Spam kutusuna atılıyordu.

Bunun üzerine [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] adresinden 'Yahoo! Mail Delivery Issues Form'u sorunumu anlatacak şekilde (mail 250'ye rağmen Spam'e düşüyor şeklinde bir seçenek olmamasına karşın) doldurup gönderdim. Bir süre sonra
Bu forumdaki linkleri ve resimleri görebilmek için en az 25 mesajınız olması gerekir.
adresinden uzun ve otomatize olduğu çok belli bir mail aldım. Bu mailin benimle ilgili olan kısmında “4xx 5xx kodlu SMTP hatası almıyorsanız ve toplu mail göndermiyorsanız sorunla ilgili ve sunucunuzla ilgili bilgilerinizi gönderin, ilgilenelim.” deniyordu.

Yaptığım araştırmalarda ulaştığım [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] ve [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...] makalelerinde (tarihleri geçmiş olsa da Yahoo'nun spam politikalarını hafifletmiş olabileceğini hiç sanmıyorum) belirtilen, Yahoo'nun mailinizi Spam kutusuna atmaması için sunucunuzun en ince detayına kadar (belki de mail yöneticilerinin güvenlik sebebiyle açıklamak istemeyeceği kadar detaylı) tüm konfigürasyonunu bilmek istediğiydi.

Eğer abuse-admin ile yazışmaya devam edersem bu çeşit bilgilerin isteneceğinden emindim. Bu nedenle Yahoo serüvenimi burada noktaladım. Sunucumun hizmet verdiği şirketteki kullanıcıların Yahoo hesapları ile yazışmaları olursa, şirket mail adreslerinin mail alacak hesapların irtibat listelerine eklenmesi doğrultusunda giden maillerin Spam kutusuna düşmemesini sağlamanın en kolay yöntem olduğuna karar verdim. Eğer sunucunuzun verdiği hizmet dolayısıyla (kullanıcılara aktivasyon maili göndermek vs.) Yahoo'da Spam kutusuna düşmemek zorundaysanız, benim bıraktığım yerden devam edebilirsiniz.

NOT: Bütün yaptıklarıma rağmen Yahoo'nun Gelen kutusuna mail ulaştıramamamın sebebi yaptığım testlerde attığım çöp içerikli deneme mailleri olabilir.

Netice

Makalemi baştan sona okuduysanız “E-Mail”in bu gün hangi noktaya geldiğini, dünyada her gün ne kadar spam gönderildiğini (ve biraz araştırma yaptıysanız her gün ne kadar mailin spam olmadığı halde spam olarak işaretlendiğini) anlamışsınızdır. Eğer gerçekten mail sağlayıcılarına sunucunuzu kabul ettirmek istiyorsanız bir miktar uğraşmayı göze almak zorundasınız. Umarım benim çabalarım sizin çabalarınıza biraz olsun yol gösterebilmiştir.

ayberkozgur.blogspot.com

 

Çevrimdışı

emeğine sağlık çok güzel bir çalışma. intodns deki hataları bir bir giderdim bu makale sayesinde.

ancak postfix/exim gibi bir mta kurulumu ve yapılandırması konusunda detaylı doküman bulmak neredeyse imkansız. bu konuda da bir makale çok süper olur. iyi çalışmalar..

 

Çevrimdışı

Merhaba ben bir şeyi anlamadım. Açıklarsanız sevinirim.
Ben bir reseller bayiden shell hizmeti alıyorum ve IRC girişlerinde BNC bot için hesabımda bulunan sabit IP adresinin hostname kısmının sahibi olduğum domain.com şeklinde gözükmesini istiyorum. Domain -> IP olarak çözümleniyor ama IP -> domain olarak değil de bayi reseller paketinin bağlı olduğu datacenter IP hostname ibareleri içeriyor.

Bu ayarlamayı kim nasıl yapabilmektedir?
Shell hesabımdan kendim mi yapabiliyorum?
Bağlı olduğum bayi reseller firması mı bu ayarlamayı yapıyor?
Yoksa bayi reseller firmasının bağlı olduğu datacenter mi bu ayarlamayı yapıyor?
rDNS kaydında PTR ve diğer ayarlar ne olmalı TTL, SOA vs. ekstra neler yapılması lazım. Bu konuda yardımcı olmanızı rica edeceğim.

 

Çevrimdışı

Anladığım kadarıyla rDNS kaydını (datacenter/reseller bayi/shell) bu sıralandırmada reseller bayi yapıyor. Peki reseller bayi bu işlemi nasıl yapıyor? rDNS işlemleri için işlem aşamaları nedir? Detaylı anlatabilir misin? (Cpanel)