Domain Haberleri

E-Posta Adreslerinin Uluslararasılaştırılması (IDN Problemi)

DUBLIN (uasg) — UASG’den IDN Domainlerin E-posta problemine çözüm. İlk destek Microsoft’tan.

Çok dilli internet için “Evrensel Kabul” bir zorunluluk. IDN (Uluslararasılaştırılmış Alan Adı (Internationalized Domain Name)) domainlerdeki yerel (ç, ğ, ı, ö, ş, ü vb.) karakterlerin kullanılabilmesini sağlayan “E-posta Adreslerinin Uluslararasılaşması” ise bu sürecin önemli bir parçası. Soruna çözüm odaklı yaklaşan UASG, şirketlere çalışmalarında yardımcı olmak amacıyla “Hızlı Başlangıç Kılavuzu” hazırladı. Geçtiğimiz günlerde ise UASG üyesi olan Microsoft, e-posta uygulamaları ve hizmetlerinde 15 Hint dilindeki e-posta adreslerine destek sağlayacağını duyurdu. Microsoft’un destek sağlayacağı uygulamalar arasında ise Office 365, Outlook 2016, Outlook.com, Exchange Online ve Exchange Online Protection (EOP) bulunuyor.

Evrensel Kabul (UA: Universal Acceptance), tüm e-posta ve alan adlarının,  tüm uygulama, cihaz ve sistemlerde doğru ve tutarlı bir şekilde çalıştığı, doğrulandığı, saklandığı, işlendiği ve görüntülenebilmesi durumudur.

Halen birçok sistem, yeni alan adlarını ya tanımıyor ya da kararlı bir şekilde çalışmıyor. Bu durum çoğunlukla alan adının ASCII formata uygun olmayışından kaynaklanmakta. Ayrıca çoğu yeni uzantıları içeren e-posta adresleri için de aynı sorun söz konusu.

ICANN‘in desteklediği Evrensel Kabul Yürütme Grubu (UASG: The Universal Acceptance Steering Group), alan adlarının evrensel kabulü konusunda farkındalık yaratmak, bu konudaki sorunları belirlemek ve çözmek için çalışmalar yapan topluluğun yönettiği, sektör çapında bir girişim. Amaç tabi ki, küresel anlamda tüm İnternet kullanıcıları için tutarlı bir deneyim sağlanmasına yardımcı olmak.

 

DOMAİNOG: Özellikle IDN alan adlarındaki sorunlar önemli bir konu. Şahsen kendi alan adıma ait bir e-postayı bile ne yazık ki kullanamıyorum. Aşağıdaki satırlar tamamen teknik ayrıntılardır. Konu ile teknik anlamda ilgilenmeyenler için pek bir anlam taşımayacak olsa da tek tek incelediğim için yer vermek istedim. Uzun yıllardır bekliyor olsam da umarım bu sorun uygulamalar, tarayıcılar, mobil vb. tüm platformlarda en yakın zamanda çözülür.

 

UASG Önerileri

KABUL ETME

Bir e-posta adresi ya da alan adının bir kullanıcı arayüzünden, dosyasından, bir yazılım uygulaması ya da çevrimiçi hizmet tarafından kullanılan bir API’dan (uygulama programı arayüzü) karakterler dizisi olarak alındığı süreç.

Kullanıcının bir alan adı ya da e-posta adresi yazmasını gerektiren tüm arayüz unsurlarının Unicode’u ve 256 karaktere kadar dizileri desteklemesi gerekmektedir.

Kullanıcıların, Unicode yerine ASCII Uyumlu Şifreli (“Punycoded”) metin girmelerine izin verilmeli, ancak kullanıcılar için böyle bir şart koyulmamalıdır. Ancak varsayılan ayarda Unicode gösterilmeli; sadece bir fayda sağlayacağı noktada Punycoded metin kullanıcıya gösterilmelidir.

DOĞRULAMA

Alınan ya da gönderilen bir e-posta adresi ya da alan adının, söz dizimi doğruluğu için kontrol edilmesi süreci. Çoğu programcı, bir üst seviye alan adının “doğru”sayıda harfi içerdiğini ya da harflerin ASCII karakterlerinden olduğunu kontrol etmeyi gerektiren sezgisel algoritmalar ile doğrulama yapmak üzere eğitilmiştir. Üç karakteri aşan alan adlarının ve Unicode (ASCII olmayan) karakterlerin ortaya çıkması dolayısıyla bu algoritmalar artık geçerli değildir.

Uygulamanın ya da hizmetin operasyonu için gerekli olmadıkça doğrulama gerçekleşmemelidir. Bu, tüm geçerli alan adlarının sistemlerde kabul edildiğinden emin olmanın en kolay yoludur.

Doğrulama gerekliyse aşağıdakileri uygulayınız:

Bir alan adının TLD kısmını güvenilir bir tablo ile doğrulayın:

  • http://www.internic.net/domain/root.zone
  • http://www.dns.icann.org/services/authoritative-dns/index.html
  • http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Ayrıca SAC070’e bakınız: https://www.icann.org/en/system/files/files/sac-070-en.pdf

  • Alan adını Alan Adı Sistemi (DNS) ile sorgulayın.
  • Yazım hatalarının önüne geçmek için e-posta adresinin tekrar yazılmasını isteyin.
  • U-etiketinin “GEÇERSİZ” kod noktaları ya da ilgili Unicode versiyonunda atanmamış olan kod noktalarını içermediğini belirlemek için etiketlerdeki karakterleri doğrulayın. (https://tools.ietf.org/html/rfc5892 adresini ziyaret edin.)
  • Etiketlerin doğrulanmasını, RFCs (Request for Comments) bölümünde tanımlanan bütün etiket kurallarının ufak bir kısmıyla sınırlandırın. (https://tools.ietf.org/html/rfc5894 adresini ziyaret edin.)
  • Bir alan adına benzeyen bir dizide ideografik nokta karakteri “。” bulunuyorsa, bu karakter doğrulamadan önce “.” ile değiştirilmelidir.

DEPOLAMA

Alan adlarının ya da e-posta adreslerinin uzun süreli ve/veya geçici olarak depolanması anlamına gelir. Verinin, ömrüne bakılmaksızın, RFC tanımlı formatlarda (tercih edilen yöntem) ya da RFC tanımlı formatlara dönüştürülebilen formatlarda depolanması gerekir.

  • Uygulamalar ve hizmetler uygun Unicode standartlarını desteklemelidir.
  • Mümkün ise bilgi, UTF-8 (Unicode Transformation Format) formatında depolanmalıdır. Bazı sistemler UTF-16 desteği de gerektirebilir ancak genellikle UTF-8 tercih edilir. UTF-7 ve UTF-32 kullanılmamalıdır (domainog.com).
  • A-Etiketlerini U-Etiketlerine dönüştürürken ve depolama aşamasında da tersini uygularken tüm ihtimalleri düşünün. Arama ve sıralama işlemlerini kolaylaştırdığı için sadece U-Etiketlerini bir dosya ya da veritabanında tutmak çekici olabilir. Ancak daha eski, Unicode ile yazılması mümkün olmayan uygulama ve hizmetlerle birlikte çalışırken dönüştürme işleminin sonuçları olabilir. İki formatı birden depolamayı düşünün.
  • Depolama aşamasında daha kolay erişim için e-posta adreslerini ve alan adlarını açıkça işaretleyin. E-posta adreslerinin ve alan adlarının bir belgeye ait “yazar” alanına ya da bir günlük dosyasında “iletişim bilgisi” içerisine yazıldığı durumlarda bir adres olarak kaynağın kaybedildiği görülmüştür.

İŞLEME

İşleme; bir e-posta adresi ya da alan adı, bir uygulama ya da hizmet tarafından bir faaliyetin gerçekleştirilmesi (ör: listede arama ya da sıralama yapmak) için kullanıldığında ya da farklı bir formata dönüştürüldüğünde (ör: ASCII’yi Unicode olarak depolamak) gerçekleşir. İşleme sırasında ek doğrulama da gerçekleşebilir. Alan adları ve e-posta adresleri birçok yoldan* işlenebilir, bu da verinin anlaşılması ve tutarlı olarak sınıflandırılmasını sağlayan kurallara olan ihtiyacı pekiştirir.

  • Unicode standardı sürekli olarak genişlediği için uygulama ya da hizmet oluşturulduğunda tanımlanmayan kod noktaları, kullanıcı deneyimini “bozmayacaklarından” emin olmak için kontrol edilmelidir. Temeli oluşturan işletim sisteminde eksik olan yazı tipleri, ortaya görüntülenemeyen karakterler çıkartabilir (bunları temsilen genelde “1”karakteri kullanılır) ancak bu durum ölümcül bir çökme ile sonuçlanmamalıdır.
  • Desteklenen Unicode destekli API‘ları kullanın.
  • Uluslararasılaştırılmış Alan Adları (IDN) için, en güncel Uygulamalardaki Uluslararasılaştırılmış Alan Adları (IDNA) Protokolü [http://tools.ietf.org/html/rfc5891] ve Tablolarını [http://tools.ietf.org/html/rfc5892] kullanın.
  • Mümkün oldukça UTF-8 formatını işleyin.
  • Ürünün ya da özelliğin sayıları beklendiği şekilde kullandığından emin olun. Örneğin, ASCII sayıları ve Asya ideografik sayı gösterimleri sayı gibi işlenmelidir. [RFC5892, link yukarıdadır]
  • Uygulamaları ve sunucuları/hizmetleri birlikte yükseltin. Sunucu Unicode iken istemci Unicode değilse ya da tam tersi durumunda, verinin, sunucu ve istemci arasında gidip gelirken her seferinde her bir kod sayfasına dönüştürülmesi gerekecektir.
  • Arabellek taşma saldırılarının önüne geçmek için kod incelemeleri yapın. Karakter dönüştürme yaparken metin dizileri önemli ölçüde büyüyebilir ya da küçülebilir.

*Örnekler: .nz ccTLD’si dahilinde arama yaparak Yeni Zelanda’daki insanların tespit edilmesi; kullanıcı@*.eczacı e-posta adreslerinde arama yaparak eczacıların tespit edilmesi.

GÖRÜNTÜLEME

Görüntüleme; bir e-posta adresi veya alan adı, bir kullanıcı arayüzünde oluşturulduğunda gerçekleşir. Kullanılan yazılar temeli oluşturan işletim sisteminde desteklendiğinde ve diziler Unicode’da depolandığında alan adları ve e-posta adreslerini görüntüleme genellikle anlaşılırdır ancak uygulamaya özel dönüşümler aksini gerektirebilir.

  • Temeli oluşturan işletim sistemi tarafından desteklenen tüm Unicode kod noktalarını görüntüleyin. Bir uygulama kendi yazı tipi kümelerini muhafaza ediyorsa, işletim sisteminden uygun olan yazı tipi koleksiyonuna kapsamlı Unicode desteği önerilmelidir.
  • Bir uygulama veya hizmet geliştirirken veya bir tescil merkezi çalışırken, desteklenen dilleri göz önünde bulundurun ve işletim sistemi ve uygulamaların bu dilleri kapsadığından emin olun.
  • Görüntülemeden önce Unicode olmayan veriyi Unicode’a dönüştürünüz. Örneğin, son kullanıcı “herkes.xn--q9jyb4c” olarak değil “herkes..みんな” olarak görmelidir. (Bu dönüştürme UA-hazırlama işleminin bir örneğidir.)
  • Unicode’u varsayılan olarak görüntüleyin. Sadece bir yararı olduğunda kullanıcıya Punycoded metin gösterin.Unicode görüntülemesini Punycoded bağlantı vurgusu metnini azaltma olarak kullanıp artırın.
  • Karışık yazı adreslerinin daha yaygın olacağını göz önünde bulundurun. Bazı Unicode karakterleri insan gözüne aynı görünebilirken bilgisayarlara farklı görünebilir. Karışık yazı dizilerinin şifre hırsızlığı gibi kötü amaçlara yönelik olarak kullanıldığını varsaymayın ve kullanıcı ara yüzü, kullanıcının dikkatini dizilere çekerse, bunu Latin harfleri kullanmayan kullanıcılar için zararlı olmayan bir şekilde yaptığından emin olun.Unicode Güvenlik Hususları hakkında daha fazla bilgi için: http://unicode.org/reports/tr36/
  • Kullanıcı beklentilerini karşılamak için Unicode IDNAUyumluluk İşleme sürecini kullanın. Daha fazla bilgi için: http://unicode.org/reports/tr46/
  • Atanmamış ve izin verilmeyen karakterlere dikkat edin. RFC5892‘den daha fazla bilgi alabilirsiniz: https://tools.ietf.org/rfc/rfc5892.txt

Evrensel Kabule Hazır Hale Gelme

Kaynak Kod İncelemeleri & Birim Test Etme

Kaynak kodu denetleme ve sadece doğru programlama tekniklerinin, yazılım kitaplıklarının ve arayüzlerin (“API’lar”) kullanıldığını doğrulama süreci. Bu süreç tamamlandıktan sonra yönetici, yukarıda listelenen belirli becerilerle (kabul etme, doğrulama vb.) test ederek uygulama veya hizmet çalışmalarını doğrulayabilir. Bu yöntem genellikle sadece uygulama geliştiriciler ve çevrimiçi hizmet sağlayıcıları tarafından kullanılır. UASG’nin farkındalık çalışmalarının bir parçası olarak grup, doğrudan uygulama geliştiricilere ve en geniş çevrimiçi hizmet sağlayıcılara evrensel kabul kaynak kodu incelemeleri ve test yapmaları ve test etmeyi geliştirmek için kullanılabilecek kriter listesi paylaşmaları için teşvik etmek üzere ulaşmaktadır.

Elle Test Etme

Çevrimiçi bir hizmete kayıt olurken e-posta adresi gönderip bu adresin kabul edildiğini doğrulama gibi yeni ve ASCII olmayan alan adlarında çoklu test yapmayı gerektirmektedir. Olası yeni e-posta adres kombinasyonları kadar kaydolacak çok sayıda olası çevrimiçi hizmet olması sebebiyle, bu yöntem geniş bir kullanım durumu yelpazesi sağlamak için uygulamaların, hizmetlerin, e-posta adreslerinin ve/veya alan adlarının farklı kombinasyonlarını denemeyi gerektirmektedir. Bu yöntem herkes tarafından uygulanabilir ama en çok emek içeren de budur. UASG, test etme için uygun üst seviye web siteleri, uygulamalar, e-posta adresleri ve alan adları listesi geliştirerek bu yöntemi desteklemeye yardımcı olmaktadır.

Otomatik Test Etme

Çeşitli URL’leri test etmek için otomatik yazıların ve yönergelerin kullanımı. Bu yöntemde önceden yapılan teknik iş daha fazladır ama büyük ölçme ve denetleme çalışmaları açısından daha ölçeklendirilebilirdir. ICANN adına APNIC tarafından yürütülen güncel gTLD araştırması gerçek bir örnek olarak sunulabilir:

  • http://www.potaroo.net/reports/Universal-Acceptance/UA-Report.pdf

UASG, evrensel kabul için otomatik test etme yöntemlerini araştırmaktadır ve hazır olduğunda bulgularını paylaşacaktır.

 

Kaynak: https://uasg.tech/wp-content/uploads/2017/02/UASG014_20170206.pdf

Türkçe Çeviri Kaynağı: https://uasg.tech/wp-content/uploads/2016/07/UASG005-160302-tr-quickguide-digital_Turkish.pdf

 

domain haberleri