Alan adı Anahtarlarıyla Tanımlanmış E-Posta

Vikipedi, özgür ansiklopedi

İnternet güvenlik
protokolleri
Anahtar yönetimi
Uygulama katmanı
Domain Name System
İnternet Katmanı

Alan adı Anahtarlarıyla Tanımlanmış E-Posta (DKIM) e-posta sahteciliğini algılamak için tasarlanmış bir [Email authentication e-posta kimlik doğrulama] yöntemidir. Alıcının, belirli bir alandan geldiği iddia edilen bir e-postanın gerçekten bu alanın sahibi tarafından yetkilendirildiğini kontrol etmesini sağlar.[1] Bu yöntemle e-postalarda sahte gönderici adresleriyle yemleme ve yığın e-posta gibi saldırıları önlemek amaçlanmıştır.

Teknik terimlerle, DKIM bir alan adının bir e-posta mesajı ile bir elektronik imza ekleyerek ilişkilendirmesini sağlar. Doğrulama, imzalayan kişinin DNS'de yayınlanan açık anahtarı kullanılarak gerçekleştirilir. Geçerli bir imza, imzalandıktan sonra e-postanın bazı bölümlerinin (muhtemelen ekler dahil) değiştirilmediğini garanti eder.[2] Genellikle DKIM imzaları son kullanıcılar tarafından görülemez ve mesajın yazarları ve alıcıları yerine altyapı tarafından yapıştırılır veya doğrulanır. Bu açıdan DKIM, uçtan uca dijital imzalardan farklıdır.

Tarihçe[değiştir | kaynağı değiştir]

DKIM, benzer amaçla Yahoo tarafından yürütülen ‘geliştirilmiş alan adı doğrulaması’ ve CISCO tarafından yürütülen ‘tanımlanmış internet postası’ projelerinin 2004 yılında birleştirilmesi ile oluşturuldu.[3][4] ] Birleştirilmiş bu yöntem IETF standartları ve parça tanımlamalarının temelini oluşturdu ve nihayetinde şu anda[rfc:6376 RFC 6376] olan STD 76’nin oluşturulmasındaki dokümanları desteklemiştir.[5] "Tanımlanmış İnternet Postası", Cisco tarafından imza tabanlı bir posta kimlik doğrulama standardı olarak önerildi;[6][7] DomainKeys ise Yahoo tarafından bir e-posta göndereninDNS alan adını ve mesaj bütünlüğünü doğrulamak üzere tasarlandı.[8]

DomainKeys'in bazı parçaları, "Tanımlanmış İnternet Postası"nın parçalarıyla Alan Adı Anahtarlarıyla Tanımlanan E-posta (DKIM) oluşturmak için birleştirildi.[9][10][11] Trendleri belirleyen DKIM sağlayıcıları arasında Yahoo, Gmail,AOL ve FastMail bulunuyor. Bu kuruluşlardan gelen bütün postalar DKIM imzasını taşımalıdır.[12][13][14]

DKIM, 2010' ların başlarında DMARC'ın kurulduğu iki sütundan biri oldu.[15] Dolaylı e-posta akışlarında geçen DKIM imzaları hakkında yeni protokolün ilk kabullerinden sonra düzenli e-posta listesi kullanımında DMARC çalışma grubunda tartışmalar ortaya çıktı. Ancak DKIM’de önerilen değişikliklerin hiç biri yapılmadı. Bunun yerine e-posta listesi yazılımı değiştirildi[16]

2017 yılında imzalama tekniklerinin gözden geçirilmesi için belirli kısıtlamaları oluşturmak için bir başka çalışma grubu olan DKIM Crypto Update (dcrup) oluşturuldu.[17] 2018 Ocak ayında [rfc:8301 RFC 8301' de] SHA-1 ve anahtar uzunluğunun değiştirilmesi yasaklandı(512-2048 dan 1024-4096).[18]

Geliştirme[değiştir | kaynağı değiştir]

Orijinal geliştirilmiş alan adı doğrulaması, 2004'ten bu yana birçok katkı sağlayanın yorumlarıyla Yahoo’dan Mark Delany tarafından geliştirildi. Bu, Stardart İzleme RFC 4871 ile yerine geçtiği tarihi RFC 4870’de ve Alan adı anahtarıyla e-posta kimlik doğrulaması (DKIM)’de belirtildi ve her ikisi de Mayıs 2007'de yayınlandı. Daha sonra bir takım açıklamalar ve kavramsallaştırmalar toplanmış ve mevcut şartnamenin düzeltilmesi şeklinde düzenlenen ve Ağustos 2009’da yayınlanan [rfc:5672 RFC 5672’de] belirtilmiştir. Eylül 2011'de, RFC 6376, DKIM protokolünün özünü korurken, bu iki belgeyi birleştirdi ve güncelledi. Daha önceki DomainKeys ile ortak anahtar uyumluluğu da mümkün hale geldi.

DKIM başlangıçta gayri resmi bir sanayi konsorsiyumu tarafından üretildi ve daha sonra Barry Leiba ve Stephen Farrell başkanlığındaki IETF DKIM Çalışma Grubu, PGP Şirketi'nden Jon Callas,Mark Delany ve Yahoo'dan Miles Libbey'den oluşan bir grup tarafından geliştirme ve standardizasyon için sunuldu ve Jim Fenton ve Cisco' dan Michael Thomas, birincil yazar olarak nitelendirildi.

En son protokol eklemeleriyle birlikte ortak bir kaynak kodu kütüphanesinin geliştirilmesi OpenDKIM Projesi tarafından Yeni BSD Lisansı kapsamında yönetiliyor.[19]

Genel bakış[değiştir | kaynağı değiştir]

DKIM imzalama ve doğrulama olmak üzere 2 ayrı işlem sağlıyor. Her ikisi de bir posta aktarım aracısı (MTA) modülüyle yönetilebilir. İmzalama kuruluşu, yazar,gönderme sitesi veya transit yolu boyunca başka bir aracı veya doğrudan işleyiciye yardım sağlayan bağımsız bir hizmet gibi dolaylı bir işleyici gibi mesajın doğrudan işleyicisi olabilir. İmzalama modülleri, bir veya daha fazla DKIM-Signature ekler ve bir imza; başlık alanlarını, muhtemelen yazar organizasyonunun veya kaynak servis sağlayıcısının yerine ekler. Doğrulama modülleri tipik olarak alıcı organizasyonun yerine etki eder.

İstenmeyen postalar(spam) sahte adres ve içerik hazırladığı için bu tür onaylanmış kimliklere duyulan ihtiyaç ortaya çıkmıştır. Örneğin, bir spam iletisi, bu adres veya alan ya da varlıktan olmamasına rağmen, sender@example.com adresinden olduğunu iddia edebilir. Buradaki spammer'ın amacı, alıcının e-postayı kabul etmeye ve okumaya ikna etmektir. Alıcıların belirli bir mesaja veya hatta alana güvenip güvensizlik yapıp yapmayacağına karar vermesi zordur ve sistem yöneticileri, sistemlerinden kaynaklanmış gibi görünen, ancak spam olmayan şikayetlerle de uğraşmak zorunda kalabilirler. DKIM, imzalayıcıların hangi başlık alanlarını imzalamak istediklerini seçmelerine izin verir, ancak Kimden: alanı her zaman imzalanmış olmalıdır. DKIM, imza sahibinin (yazar örgütü) meşru gördüğü e-postaları iletmesini sağlar. Bu durum doğrudan kötüye kullanımı engelleyemez. Gerçek postayı potansiyel sahte postalardan ayırt edebilme özelliği, e-posta alıcılarının yanı sıra gönderenlere de fayda sağlar.

DKIM , Basit Posta Aktarım Protokolü (SMTP)'nün yönlendirme yönlerinden bağımsız olarak iletilen mailin başlık ve gövde kısmında RFC 5322 ' ye dayanarak çalışır. Bu nedenle DKIM imzası çoklu MTA'lar boyunca temel aktarımdan geçer.

Teknik detaylar[değiştir | kaynağı değiştir]

DKIM İmza başlık alanı etiket=değerleri içeren bir listeden oluşur. Etiketler kısadır ve genellikle sadece bir veya iki harftir. En yaygın olanlar mail mesajının içeriğinin(başlık ve gövde) gerçek elektronik imzası için b, gövde özeti için bh, alan adı imzası için d ve seçici için s kullanılır. Kimlik doğrulama mekanizması için varsayılan parametreler, SHA-256'yı şifreli özet ve RSA'yı açık anahtar şifreleme şeması olarak kullanmak ve Base64 kullanarak şifrelenmiş hash kodlamaktır.

Hem başlık hem de gövde imzaya katkıda bulunur. İlk olarak, ileti gövdesinin özeti(hash) başından itibaren alınır ve verilen bir uzunlukta kesilir. İkincisi, seçilen başlık dosyasının alanları verilen h' ye bağlı olarak özetlenir. Tekrarlanan alan adları, başlığın alt kısmından yukarı doğru sıralanır; bu sıra Alındı: alanlarının başlığa eklenmesiyle aynı sıradır. Mevcut olmayan bir alan boş dizeyle eşleşirse, bu şekilde bu isimle bir alan eklemek imzayı bozar. Bu DKIM İmza: , yaratılan imzanın alanları, bh ile eşit hesaplanan gövde özeti(hash) ve b boş diziye eşitse, bu ikinci özete dolaylı olarak eklenir ve ismi h' da görülmez. Eğer görülürse, daha önceden oluşmuş bir imzayı gösteriyor olur. Her iki özet(hash) için metin, ilgili c algoritmalarına göre standartlaştırılmıştır ve sonuç b olmuştur. Algoritmalar, alanlar ve gövde uzunluğu, açık bir şekilde mesaj tanımını garantilemek için seçilecek, ancak imzalarda meydana gelecek olan kaçınılmaz değişiklikleri devam ettirebilecek imzalara izin verecek şekilde seçilmelidir.

Alıcı SMTP sunucusu, bir DNS araması yapmak için alan adını ve seçiciyi kullanır. Bir örneği aşağıda verilmiştir : 

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;      c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;      t=1117574938; x=1118006938; l=200;      h=from:to:subject:date:keywords:keywords;      z=From:foo@eng.example.net|To:joe@example.com|        Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;      bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;      b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ               VoG4ZHRNiYzR

Bir doğrulayıcı brisbane._domainkey.example.net'in,TXT kaynak kayıt türünü sorgular. Burada example.net bu yazarın doğrulanacak alan adı için (d alanının içinde), brisbane ise verilen s alanındaki seçicidir ve son olarak _domainkey protokolün sabit kısmıdır. DKIM anahtar yönetiminde yer alan herhangi bir sertifika otoritesi veya iptal listesi yoktur ve seçici, imzalayanların istedikleri zaman anahtar ekleme ve çıkarmalarına izin veren basit bir yöntemdir - arşivleme amaçlı uzun süreli imzalar DKIM'in kapsamı dışındadır. Daha fazla etiket, aşağıda görülmektedir :

  • v versiyon
  • a imzalama algoritması,
  • d alan adı,
  • s seçici,
  • c başlık ve gövde için standartlaştırma algoritması,
  • q varsayılan sorgu yöntemi,
  • l imzalanmış gövdenin standartlaştırılmış kısmının uzunluğu,
  • t imza zaman damgası,
  • x onun son tarihi ve
  • h, birden çok kez oluşan alanlar için tekrarlanan imzalı başlık alanlarının listesidir.

Sorgudan döndürülen veriler ayrıca etiket - değer çiftlerinin bir listesidir. Bu, diğer anahtar kullanım belirteçleri ve bayraklarının yanı sıra alan adının açık anahtarını da içerir. Alıcı bunu daha sonra başlık alanındaki özet(hash) değerini çözmek ve aynı zamanda alınan posta mesajı (üstbilgiler ve gövde) için özet değerini yeniden hesaplamak için kullanabilir. İki değer eşleşirse, bu, postanın belirtilen etki alanı tarafından imzalandığını ve geçiş sırasında değiştirilmediğini kriptografik olarak kanıtlar.

İmza doğrulama hatası mesajın reddedilmesi için zorlamaz. Bunun yerine, mesajın doğruluğunun kanıtlanamamasının kesin nedenleri, aşağı yönde ve yukarı yönde işlemlere açık hale getirilmelidir. Bunu yapma yöntemleri, bir FBL mesajının geri gönderilmesini veya[rfc:7001 RFC 7001]'de açıklandığı gibi mesaja bir Doğrulama-Sonuçları başlık alanı eklemeyi içerebilir.

Patent Yükümlülüğü[değiştir | kaynağı değiştir]

Alan adı anahtarları(DomainKeys) Yahoo! ' ya atanan ABD patent 6.986.049 sayılı patent ile korunmaktadır. Yahoo, DKIM IETF Working Group'un amacı için artık kullanılmayan (mülga) DK kütüphanesini ikili lisans şeması altında yayınladı : imzasız bir versiyonu halen bulunabilen [22] Geliştirilmiş Alan Adı Doğrulaması Lisans Sözleşmesi v1.2 ve GNU Genel Kamu Lisansı v2.0 (ve başka bir sürümü yok).[20][21]

Avantajları[değiştir | kaynağı değiştir]

Bu sistemin e-posta alıcıları için birincil avantajı, imza alan adının meşru e-posta akışını güvenilir bir şekilde tanımlamasına izin vermesidir, böylece alan tabanlı kara listeler ve beyaz listelerin daha etkili olmasını sağlar.[22] Bu durum ayrıca yemleme saldırılarının belli bir kısmının kolayca tespit edilebilir hale gelmesini sağlar.

E-posta gönderenlerin giden e-postaları imzalaması için bazı teşvikler edici unsurlar vardır:

  • Eğer e-posta alıcısı DKIM sistemi kullanıyorsa o alan adından geldiğini iddia eden sahte e-postaları tespit edebilir.
  • Alan adı sahibi, eforunu kötü amaçlı kullanıcılara ayırmak yerine uygun bir şekilde alan adını kullanan kullanıcılara ayırabilir.

Spam Filtreleme ile Kullanımı[değiştir | kaynağı değiştir]

DKIM bir iletiyi etiketleme yöntemidir ve kendi başına spam'i filtrelemez veya tanımlamaz. Bununla birlikte, DKIM'in yaygın kullanımı, spam göndericilerin mesajlarının kaynak adresini oluşturmasını engelleyebilir ve bugün kullandıkları bir tekniktir. Spam gönderenler doğru bir kaynak alan adı göstermeye zorlanıyorsa, diğer filtreleme teknikleri daha etkili bir şekilde çalışabilir. Kaynak alan adı itibar sistemine verilerek spam'ların daha iyi bir şekilde tespit edilmesine yardımcı olabilir. Tersine, DKIM, spam olmadığı bilinen ve filtrelenmesi gerekmeyen postayı tanımlamayı kolaylaştırır. Bir alıcı sistem, yerel olarak ya da üçüncü taraf onaylayıcıları tarafından bilinen iyi gönderim alanlarının beyaz listesini barındırıyorsa, bu alanlardan gelen imzalı postadaki filtrelemeyi atlayabilir ve belki de kalan postaları daha agresif bir şekilde filtreleyebilir.

Anti-Kimlik Avı[değiştir | kaynağı değiştir]

DKIM bir yemleme karşıtı(anti-phishing) bir teknoloji olarak yararlı olabilir. Ağır şekilde yemlenen alan adlarında bulunan postalar, postalarının gerçek olduğunu göstermek için postalarını imzalayabilir. Alıcılar bu alan adlarından alınan postalarda imzayı belirleyemezse e-postanın büyük olasılıkla sahte olduğunu anlayabilirler. Bu derece bir denetlemeyi gerektirecek alan adlarına karar vermek kolay değildir. DKIM eskiden yazarların maillerini kendi kimlikleriyle imzaladığı ADSP diye adlandırılan ekstra bir özelliğe sahipti fakat 2013 Kasım' da eski teknoloji olarak sınıflandırıldı.[23] Bunun yerine, DMARC denilen aynı amaç için kullanılan [24] ve alan adlarına kendi kendine hangi teknikleri kullanacaklarını yayınlama(SPF ve DKIM de dahil) hakkı veren ve alıcının gelen e-postanın spam olup olmadığına karar vermesini kolaylaştıran bir yöntem bulunur.[25] Örneğin Gmail, DMARC kullanarak eBay ve PayPal' dan gelen kimliği doğrulanmamış bütün e-postaları reddetmiştir.[26]

Uyumluluk[değiştir | kaynağı değiştir]

DNS kayıtları ve eklenen bir RFC 5322 başlık alanı kullanılarak uygulandığından, DKIM mevcut e-posta altyapısı ile uyumludur. Özellikle, DKIM desteğine sahip olmayan mevcut e-posta sistemlerine karşı şeffaftır.[27]

Bu tasarım yaklaşımı, S / MIME ve OpenPGP içerik koruma standartları gibi diğer ilgili hizmetler ile de uyumludur. DKIM ayrıca DNSSEC standardı ve SPF ile de uyumludur.

Protokolün ek yükü[değiştir | kaynağı değiştir]

DKIM, bir posta sunucusu aracılığıyla gönderilen her mesaj için oluşturulacak şifrelenmiş sağlama toplamı gerektirir; bu da, e-posta teslimi için başka türlü gerekli olmayanhesaplama ek yükü ile sonuçlanır. Bu ek hesaplama yükü, toplu spam e-posta göndermeyi zorlaştırır.[28] DKIM bu yönden, hashcash'a benzer görünebilir, ancak alıcı tarafının doğrulanması ihmal edilebilir miktarda bir çalışma değildir ve tipik bir hashcash algoritması çok daha fazla iş gerektirecektir.

İnkar Edilememe[değiştir | kaynağı değiştir]

DKIM' in inkar edilememe özelliği, göndericileri(mesela spammerlar) e-postayı göndermediğini iddia etmesini engeller. Bu durumun işe yararlılığı WikiLeaks gibi haber kaynakları tarafından sızdırılan e-postaların gerçek olduğunu ve değiştirilmediğini kanıtlamak için kullandığında(Hillary Clinton' ın 2016 Başkanlık Seçimindeki yol arkadaşı Tim Kaine ile olduğu gibi) gözlenmiştir.[29]

Zayıflıkları[değiştir | kaynağı değiştir]

RFC'nin kendisi bir dizi potansiyel saldırı vektörünü tanımlar.[30]

DKIM imzaları, dönüş yolunu ve mesaj alıcılarını içeren mesaj zarfını kapsamaz. DKIM yanlış adreslemeye karşı koruma sağlamaya çalışmadığından, bu durum DKIM' in yararı konusunda olumsuz bir etki oluşturmaz.

Herhangi bir şifreleme çözümüyle ilgili bir endişemesaj tekrarının kötüye kullanılması olabilir. Yeniden oynatma kullanımı ile ortak anahtarlar kullanılarak, bu anahtarlar için DNS sorgularının izlenmesi ve e-postaların büyük e-posta listelerine gönderilmesiyle ilgili yüksek sayıda sorgunun filtrelenmesi veya kötü oyuncuların kötü amaçlı sorguları kullanılarak elde edilebilir.[kaynak belirtilmeli]

Bu konuyla ilgili farklı yöntemlerin karşılaştırılması içine-posta kimlik doğrulamasına bakılabilir.

Gelişigüzel İletme[değiştir | kaynağı değiştir]

Yukarıda belirtildiği gibi, kimlik doğrulama ile kötüye kullanımı önleme aynı değildir. Saygın bir alanın kötü niyetli bir e-posta kullanıcısı, kötü bir mesaj oluşturup ve onu DKIM imzalı halde alan adı içerisinden herhangi bir mesaj kutusuna gönderip onu dosya olarak elde ettiğinde, mesajın imzalı bir kopyasını ele geçirmiş olur. İmzalardaki l etiketinin kullanılması, bu tür mesajların daha kolay kendi çıkarlarına göre değiştirilmesini sağlar. İmzalı kopya daha sonra kontrolsüz bir botnet üzerinden bir milyon alıcıya iletilebilir. Mesajı imzalayan e-posta sağlayıcısı, rahatsız edici kullanıcıyı engelleyebilir, ancak önceden imzalı mesajların yayılmasını durduramaz. Bu tür mesajlardaki imzaların geçerliliği her zaman imzalardaki bir sona erme süresi etiketi veya periyodik olarak veya bir olayın bildirimi üzerine bir açık anahtarının iptal edilmesiyle sınırlandırılabilir. Senaryonun etkililiği, bir mesajın spam göndericilere potansiyel olarak yararlı olup olmadığını tespit etme kabiliyeti anlamına geldiğinden, giden postanın filtrelenmesi ile sınırlandırılamaz.[31]

İçerik değişikliği[değiştir | kaynağı değiştir]

DKIM'in şu anda ikisi de MIME uyumlu olan, basit ve rahat olmak üzere 2 standartlaştırma algoritması bulunur.[32] Posta sunucuları yasal olarak farklı bir karakter kümesine dönüştürebilir ve genellikle bunu X-MIME-Otomatik dönüştürülmüş başlık alanları ile belgeleyebilir. Ayrıca, belirli durumlarda sunucuların MIME yapısını yeniden yazmaları gerekir, böylece girişlerin, epilogun ve varlık sınırlarının değiştirilmesi gerekir, bunların herhangi biri DKIM imzalarını kırabilir. MIME başlık alanlarının işaretlenmemiş olması koşuluyla, sadece ascii dilinde yazılmış düz metin mesajları, uçtan uca bütünlüğün gerektirdiği sağlamlığın tadını çıkarır.

OpenDKIM Projesi, 21 posta sunucusu ve milyonlarca mesaj içeren bir veri topladı ve gözlemlenen imzaların % 92.3'ü başarılı bir şekilde doğrulandı, başarı oranı e-posta trafiği düşünüldüğünde %90.5 a düşer.[33]

Posta listeleri ile ek açıklamalar[değiştir | kaynağı değiştir]

Filtreleme veya geçiş yazılımı bir mesajda değişiklik yaptığında sorunlar daha da kötüleşebilir. Gönderen tarafından uygulanan özel önlemler olmadan, posta listelerinin çoğu ve birçok merkezi antivirüs çözümü tarafından çalıştırılan altbilgi eklenmesi, DKIM imzasını kıracaktır. Olası bir etki azaltma, yalnızca mesaj gövdesinin belirtilen sayıda baytını imzalamaktır. DKIM-Signature başlığında l etiketi ile gösterilir. DKIM imzası hesaplanırken, mesaj gövdesinin belirtilen uzunluğunun ötesinde eklenmiş herhangi bir şey dikkate alınmaz. Bu MIME mesajları için işe yaramaz durumdadır.[34]

Başka bir geçici çözüm, bilinen ileticileri beyaz listeye almaktır; (örneğin SPF tarafından iletilenler). Başka bir geçici çözüm olarak ise, ileticilerin imzayı doğruladığı, e-postayı değiştirdiği ve iletiyi Gönderen: üstbilgisiyle yeniden imzalaması önerildi.[35] Bununla birlikte, bu çözümün, RFC 5617 ADSP protokolünü destekleyen SMTP alıcılarında alınan yönlendirilmiş 3. taraf imzalanmış mesajlarla riske girdiğine dikkat edilmelidir.

Kısa anahtar güvenlik açığı[değiştir | kaynağı değiştir]

Ekim 2012' de, Wired  matematikçi Zach Harris ' in google.com şirket alan adı için kısa DKIM anahtarları bir e-posta kaynak sızdırma güvenlik açığı tespit ettiğini ve gösterdiğini bildirdi. Harris kimlik doğrulamanın 384-bit için kendi dizüstü bilgisayarında 24 saatte, 512-bit anahtar için bulut bilişim bilgisayarlarıyla 72 saatte hesaplanabileceğini belirtti. Harris, birçok kuruluşun bu kısa anahtarlarla e-posta imzaladığını tespit etti; Hepsini çözdü ve bu açıklık hakkında kuruluşları haberdar etti. Harris 768-bit anahtar uzunluğunun çok fazla işlem gücü gerektirdiğini fakat daha güvenli sistemler için 1024-bitten daha uzun anahtarların kullanılmasını önerdi. Wired, Harris'in bildirmesi sonucu ve Google’ın kısa bir süre sonra yeni anahtarlar kullanmaya başladıklarını doğruladı. [rfc:6376 RFC 6376'ya] göre, alıcı taraf imzaları 512 bitten 2048 bite kadar olan anahtarlarla doğrulayabilir, dolayısıyla 512 bitten daha kısa olan anahtarların kullanımından kaçınılmalıdır. RFC 6376 ayrıca, uzun ömürlü anahtarlar için en az 1024 bit anahtar kullanması gerektiğini belirtir.[36]

Ayrıca bakınız[değiştir | kaynağı değiştir]

Kaynakça[değiştir | kaynağı değiştir]

  1. ^ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (July 2009), DomainKeys Identified Mail (DKIM) Service Overview, IETF, doi:10.17487/RFC5585, RFC 5585, erişim tarihi: 6 Ocak 2016, Receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behaviors. DKIM does not, itself, prescribe any specific actions by the recipient; rather, it is an enabling technology for services that do. 
  2. ^ Dave Crocker; Tony Hansen; Murray S. Kucherawy, (Ed.) (September 2011), "Data Integrity", DomainKeys Identified Mail (DKIM) Signatures, IETF, sec. 1.5, doi:10.17487/RFC6376, RFC 6376, erişim tarihi: 6 Ocak 2016, Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message. 
  3. ^ "DKIM Frequently Asked Questions". DKIM.org. 16 Ekim 2007. 29 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Ocak 2016. DKIM was produced by an industry consortium in 2004. It merged and enhanced DomainKeys, from Yahoo! and Identified Internet Mail, from Cisco. 
  4. ^ Jim Fenton (15 Haziran 2009). "DomainKeys Identified Mail (DKIM) Grows Significantly". Cisco. 1 Kasım 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 28 Ekim 2014. 
  5. ^ "STD 76, RFC 6376 on DomainKeys Identified Mail (DKIM) Signatures". IETF. 11 Temmuz 2013. 4 Ağustos 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 12 Temmuz 2013. RFC 6376 has been elevated to Internet Standard. 
  6. ^ "Identified Internet Mail: A network based message signing approach to combat email fraud". 26 Nisan 2006. 9 Ekim 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Ocak 2016. 
  7. ^ Jim Fenton; Michael Thomas (1 Haziran 2004), Identified Internet Mail, IETF, I-D draft-fenton-identified-mail-00, erişim tarihi: 6 Ocak 2016 
  8. ^ ""May 19, 2004 Yahoo Releases Specs for DomainKeys"". 8 Mart 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2018. 
  9. ^ Delany, Mark (May 22, 2007). "One small step for email, one giant leap for Internet safety" 14 Mart 2013 tarihinde Wayback Machine sitesinde arşivlendi.. Yahoo! corporate blog. Delany is credited as Chief Architect, inventor of DomainKeys.
  10. ^ RFC 4870 ("Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)"; obsoleted by RFC 4871).
  11. ^ RFC 6376 ("DomainKeys Identified Mail (DKIM) Signatures"; obsoletes RFC 4871 and RFC 5672).
  12. ^ Taylor, Brad (July 8, 2008). "Fighting phishing with eBay and Paypal" 4 Mart 2016 tarihinde Wayback Machine sitesinde arşivlendi.. Gmail Blog.
  13. ^ "I’m having trouble sending messages in Gmail" 16 Eylül 2016 tarihinde Wayback Machine sitesinde arşivlendi.. Gmail Help entry, mentioning DKIM support when sending.
  14. ^ Mueller, Rob (August 13, 2009). "All outbound email now being DKIM signed" 6 Ekim 2011 tarihinde Wayback Machine sitesinde arşivlendi.. Fastmail blog.
  15. ^ "History". dmarc.org. 7 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2018. 
  16. ^ "DMARC Group History". IETF. 23 Nisan 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2018. 
  17. ^ "DKIM Crypto Update (dcrup)". IETF. 22 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2018. 
  18. ^ Scott Kitterman (January 2018), Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM), IETF, doi:10.17487/RFC8301, RFC 8301 
  19. ^ "OpenDKIM". 29 Eylül 2017 tarihinde kaynağından arşivlendi. 
  20. ^ Levine, John R. (25 Ocak 2010). "IPR disclosures, was Collecting re-chartering questions". ietf-dkim mailing list. Mutual Internet Practices Association. 14 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 30 Mayıs 2010. The reference to the GPL looks to me like it only covers the old Sourceforge DK library, which I don't think anyone uses any more. The patent, which is what's important, is covered by a separate license that Yahoo wrote. 
  21. ^ Chen, Andy (26 Eylül 2011). "Yahoo! Inc.'s Statement about IPR related to RFC 6376". IPR disclosure. IETF. 3 Mart 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 3 Ekim 2011. 
  22. ^ Falk, J.D. (17 Mart 2009). "Searching for Truth in DKIM". CircleID. 21 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2018. 
  23. ^ Barry Leiba (25 Kasım 2013). "Change the status of ADSP (RFC 5617) to Historic". IETF. 5 Mart 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 13 Mart 2015. 
  24. ^ "FAQ - DMARC Wiki". 4 Ocak 2018 tarihinde kaynağından arşivlendi. The DMARC standard states in Section 7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. 
  25. ^ "Add a DMARC record - Google Apps Administrator Help". 12 Temmuz 2017 tarihinde kaynağından arşivlendi. 
  26. ^ "About DMARC - Google Apps Administrator Help". 17 Aralık 2017 tarihinde kaynağından arşivlendi. Your policy can be strict or relaxed. For example, eBay and PayPal publish a policy requiring all of their mail to be authenticated in order to appear in someone's inbox. In accordance with their policy, Google rejects all messages from eBay or PayPal that aren’t authenticated. 
  27. ^ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (July 2009), DomainKeys Identified Mail (DKIM) Service Overview, IETF, doi:10.17487/RFC5585, RFC 5585, erişim tarihi: 1 Temmuz 2013 
  28. ^ Roic, Alessio (July 5, 2007). "Postmarking: helping the fight against spam" 17 Temmuz 2011 tarihinde Wayback Machine sitesinde arşivlendi.. Microsoft Office Outlook Blog.
  29. ^ "DKIM Verification". www.wikileaks.org. 4 Kasım 2016. 7 Kasım 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Kasım 2016. 
  30. ^ "Security considerations", ietf.org
  31. ^ Jim Fenton (September 2006), "Chosen Message Replay", Analysis of Threats Motivating DomainKeys Identified Mail (DKIM), IETF, sec. 4.1.4, doi:10.17487/RFC4686, RFC 4686, erişim tarihi: 10 Ocak 2016 
  32. ^ Ned Freed (with agreement by John Klensin) (5 Mart 2010). "secdir review of draft-ietf-yam-rfc1652bis-03". YAM mailing list. IETF. 14 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 30 Mayıs 2010. DKIM WG opted for canonical form simplicity over a canonical form that's robust in the face of encoding changes. It was their engineering choice to make and they made it. 
  33. ^ Kucherawy, Murray (28 Mart 2011). "RFC4871 Implementation Report". IETF. 8 Ekim 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Şubat 2012. 
  34. ^ Murray S. Kucherawy (September 2011), DomainKeys Identified Mail (DKIM) and Mailing Lists, IETF, doi:10.17487/RFC6377, RFC 6377, erişim tarihi: 10 Ocak 2016 
  35. ^ Eric Allman; Mark Delany; Jim Fenton (August 2006), "Mailing List Manager Actions", DKIM Sender Signing Practices, IETF, sec. 5.1, I-D draft-allman-dkim-ssp-02, erişim tarihi: 10 Ocak 2016 
  36. ^ Zetter, Kim (October 24, 2012). "How a Google Headhunter’s E-Mail Unraveled a Massive Net Security Hole" 15 Mart 2014 tarihinde Wayback Machine sitesinde arşivlendi.. Wired. Accessed October 24, 2012.

Notlar[değiştir | kaynağı değiştir]

Konuyla ilgili yayınlar[değiştir | kaynağı değiştir]

  • RFC 4686 Analizi Tehditler Motive dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM)
  • RFC 4871 dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM) İmzalar Önerilen Standart
  • RFC 5617 dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM) Yazar Etki İmzalama Uygulamaları (ADSP)
  • RFC 5585 dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM) Hizmet Genel Bakış
  • RFC 5672 RFC 4871 dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM) İmza Güncelleme
  • RFC 5863 DKIM Geliştirme, Dağıtım ve İşlemleri
  • RFC 6376 dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM) İmza Taslak Standart
  • RFC 6377 dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM) ve e-Posta Listeleri
  • RFC 8301 Şifreleme Algoritması ve Anahtar Kullanımı Güncellemek için dolandırıcılığı faaliyetlerini Belirlenen Posta (DKIM)
"https://tr.wikipedia.org/w/index.php?title=Alan_adı_Anahtarlarıyla_Tanımlanmış_E-Posta&oldid=31483647" sayfasından alınmıştır