E-posta adreslerine derinlemesine bakış

 (lasans.blog)
4 puan yazan GN⁺ 2 시간 전 | Henüz yorum yok. | WhatsApp'ta paylaş
  • E-posta adresleri, yalnızca bir kullanıcı adı ve alan adının birleşimi değil; RFC standartlarında tanımlanan karmaşık yapı ve kurallar ile güvenlik tuzaklarını içeren bir sistemdir
  • Yerel bölümde (@ öncesi), tırnaklı biçim, yorumlar, Unicode gibi genel olarak pek bilinmeyen çeşitli geçerli biçimler bulunur; ancak bunların çoğu pratikteki ortamlarda desteklenmez
  • Her e-postada Envelope Sender ve From başlığı olmak üzere iki gönderici adresi bulunur; bu fark, spoofing ve phishing’in temel nedenidir
  • Gmail’in nokta (dot) yok sayma politikası, artı adresleme ve alan adı takma adları gibi sağlayıcıya özgü davranışlar, güvenlik ve geçerlilik denetimini doğrudan etkiler
  • E-posta adresi toplayan veya doğrulayan bir sistem kurarken, RFC standartları ile gerçek davranış arasındaki boşluğu doğru anlamak kritik önemdedir

Temel yapı

  • Bir e-posta adresi üç bölümden oluşur: yerel bölüm (@ öncesi), @ ayıracı ve alan adı (@ sonrası)
  • Dışarıdan basit görünse de, her bölümde güvenlik, gizlilik ve geçerlilik denetimini etkileyen kurallar ve edge case’ler vardır

Yerel bölüm (Local Part)

  • İzin verilen karakterler

    • Standart tırnaksız biçimde (dot-atom) izin verilen karakterler: İngilizce harfler a-z, A-Z, rakamlar 0-9, özel karakterler . _ - + ! # $ % & ' * / = ? ^ { | } ~
    • Azami uzunluk 64 oktettir (octet); standart ASCII’de bu 64 karakterle aynıdır, ancak Unicode yerel bölümlerde fark oluşur
      • Oktet, tam olarak 8 bitlik bir grubu ifade eder ve ağ iletişiminde (IPv4) 0~255 aralığını göstermek için kullanılır
      • 64 oktet, 512 bit uzunluğunda bir veri bloğuna karşılık gelir

  • Büyük/küçük harf duyarlılığı

    • RFC 5321’e göre yerel bölüm teknik olarak büyük/küçük harfe duyarlıdır; User@example.com ile user@example.com ayrı posta kutuları olabilir
    • Pratikte tüm büyük e-posta sağlayıcıları büyük/küçük harf ayrımı yapmadığından, saklama ve karşılaştırma öncesinde küçük harfe normalize etmek güvenli varsayılandır
    • Alan adı bölümü hiçbir zaman büyük/küçük harfe duyarlı değildir

  • Nokta (Dot) adresleme

    • Noktaya yerel bölümde izin verilir, ancak üç kısıt vardır: noktayla başlayamaz, noktayla bitemez ve ardışık nokta olamaz
    • Gmail’in nokta normalizasyonu: Gmail, yerel bölümdeki noktaları tamamen yok sayar; bu nedenle johndoe@gmail.com, john.doe@gmail.com, j.o.h.n.d.o.e@gmail.com adreslerinin tümü aynı gelen kutusuna teslim edilir
      • Bu, RFC standardı değil Gmail’e özgü bir davranıştır
      • Saldırganlar, nokta varyasyonlu adreslerle ayrı hesaplar oluşturarak tek hesap sınırlamasını aşabilir veya ücretsiz denemeleri tekrar tekrar alabilir; bu gerçek bir saldırı vektörüdür

  • Alt adresleme (artı adresleme)

    • Ayıraç kullanarak yerel bölüme etiket eklenebilir; posta sunucusu etiketi korurken postayı temel adrese teslim eder (RFC 5233 standardı)
    • En yaygın ayıraç + işaretidir ve Gmail, Outlook, ProtonMail, Fastmail gibi hizmetlerde desteklenir
      • Yahoo’nun bazı yapılandırmalarında ve belirli Postfix ayarlarında - kullanılır
      • qmail’de varsayılan ayıraç = işaretidir; VERP’te @ karakterinin = ile kodlanmasının nedeni de budur
    • Başlıca kullanım senaryoları:
      • Sızıntı takibi: Hizmet başına benzersiz etiketle (ör. yourname+servicename@gmail.com) kayıt olup spam gelirse sızıntının kaynağını belirlemek
      • Gelen kutusu filtreleme: Posta kurallarıyla belirli etiketli adrese gelen iletileri otomatik sınıflandırmak
      • Çoklu hesap: Artı işaretini normalize etmeyen hizmetlerde tek bir e-posta ile ayrı hesaplar oluşturabilmek
    • Pek çok web sitesinin e-posta doğrulayıcısı + işaretini reddeder; ancak bu, e-postanın sınırlaması değil doğrulama kodunun hatasıdır

  • Tırnaklı dizge biçimi (Quoted String Form)

    • Yerel bölüm çift tırnak içine alınırsa, karakter kısıtlarının çoğu gevşer; boşluk, @, ardışık nokta, baştaki ve sondaki nokta gibi öğelere izin verilir
    • Örnek: "john doe"@example.com, "user@name"@example.com, " "@example.com
    • Pratikte neredeyse hiçbir e-posta sağlayıcısı tırnaklı yerel bölümü kabul etmez; bu yüzden RFC’ye göre geçerli olsa da gerçek kullanımda işe yaramaz

  • Yorumlar (Comments)

    • Parantez içindeki yorumlar yerel bölümün başında veya sonunda gelebilir; posta sunucusu bunları kaldırır ve teslimatı etkilemez
    • RFC 5322’ye göre teknik olarak geçerlidir, ancak modern kullanımda yer almaz
    • Parantezi reddeden doğrulayıcılar RFC’den daha katıdır

  • Unicode yerel bölüm (EAI)

    • RFC 6530, 6531, 6532’de tanımlanan e-posta adresi uluslararasılaştırması (EAI), yerel bölümde UTF-8 karakterlere izin verir
    • SMTP oturumunda SMTPUTF8 uzantısının kullanılması gerekir ve hem gönderen hem alan sunucunun bunu desteklemesi gerekir
    • 2026 itibarıyla benimsenme sınırlıdır; ayrıca Unicode karakterler 2~4 oktet kullandığından, görsel karakter sayısı 64’e ulaşmadan da 64 oktet sınırına ulaşılabilir

  • Tarihsel biçimler

    • Bang path (UUCP): DNS öncesinde modemle bağlı Unix makine ağlarında ! ile ayrılmış ana makine adı yolu (machine1!machine2!user) kullanan yönlendirme yöntemi; ! karakterinin izin verilen karakterler listesinde yer almasının nedeni budur. Günümüzde tamamen terk edilmiştir
    • Percent hack: user%otherdomain@relay.com biçiminde bir relay yönlendirme hilesi; % karakteri, yönlendirme mekanizması RFC 5321’de kullanımdan kaldırılsa da yerel bölümde hâlâ geçerlidir
    • Source routing: SMTP RCPT TO komutunda açık relay atlama listesi (@relay1,@relay2:user@domain). RFC 5321’de kullanımdan kaldırılmıştır

  • VERP (Variable Envelope Return Path)

    • Toplu e-posta sistemlerinde bounce üreten tam alıcıyı izlemek için kullanılan bir teknik
    • Alıcı adresi, zarf göndericisine (MAIL FROM) kodlanır; bu sırada alıcı adresindeki @, = ile değiştirilir
      • Örnek: bounces+alice=gmail.com@newsletter.com
    • Mailchimp, SendGrid, Amazon SES gibi hizmetler, büyük ölçekli bounce işleme için VERP veya türevlerini kullanır

  • SRS (Sender Rewriting Scheme)

    • Sunucunun, postayı iletirken SPF kontrolünden geçirebilmek için zarf göndericisini yeniden yazdığı durumlarda görülen adres biçimi
    • SRS0=HASH=TT=originaldomain.com=originaluser@forwardingdomain.com biçimindedir
    • Çoklu atlamalı iletimde SRS1=HASH=encodedSRS0@forwardingdomain.com biçimi kullanılır
    • Yapısal olarak geçerli bir e-posta adresidir, ancak altyapı çıktısıdır; insanlar tarafından kullanılan bir adres değildir
    • HASH bileşeni, zaman damgası ile özgün adres üzerinde hesaplanan HMAC’tir; sahteciliği önler ve token geçerlilik süresini sınırlar

Alan Bölümü (Domain Part)

  • Etiket kuralları

    • Alan adı, noktayla ayrılmış etiketlerden oluşur; her etikette İngilizce harfler a-z, rakamlar 0-9 ve kısa çizgi - kullanılabilir
    • Kısa çizgiyle başlayamaz veya bitemez; ayrıca 3. ve 4. konumda art arda kısa çizgi bulunamaz (ancak xn-- ile başlayan Punycode etiketleri istisnadır)
    • Etiket başına en fazla 63 karakter, alan adının tamamı en fazla 253 karakter, e-posta adresinin tamamı (addr-spec) en fazla 254 karakter olabilir

  • Alt alan adları

    • Alan adları birden çok seviyeye sahip olabilir; toplam 253 karakterlik alan adı sınırı dışında alt alan adı derinliği için kesin bir sınır yoktur
    • Yaygın kullanım alanları: posta altyapısı (mail., smtp., mx.), kurumsal ayrım (sales.company.com), ESP gönderimi (email.company.com)

  • IP adresi literal'i

    • Alan adı yerine köşeli parantez içindeki IP adresi kullanılabilir: user@[192.168.1.1], user@[IPv6:2001:db8::1]
    • RFC 5321'e göre geçerlidir, ancak herkese açık posta sunucularında neredeyse hiç kabul edilmez; kurum içi posta sistemleri ve SMTP testleri için kullanılır

  • Tek etiketli alan adları

    • Nokta içermeyen alan adları (ör. user@localhost) bazı bağlamlarda teknik olarak geçerlidir, ancak herkese açık posta sunucuları bunları reddeder
    • postmaster@localhost, Unix türevi sistemlerde yerel sistem postası için geleneksel bir özel durumdur

  • Uluslararasılaştırılmış alan adları (IDN) ve Punycode

    • DNS yalnızca ASCII desteklediğinden, ASCII dışı karakterler Punycode (RFC 3492) ile kodlanır ve kodlanmış tüm etiketler xn-- önekiyle başlar
    • E-posta istemcileri bunları yerel yazı sisteminde gösterir, SMTP ise Punycode biçiminde iletir
    • Homograf saldırısı: Farklı Unicode yazı sistemlerindeki görsel olarak aynı karakterlerle, iyi bilinen alan adlarına benzeyen alan adları kaydedilebilir. Tarayıcılar şüpheli IDN'ler için Punycode gösteren savunmalara sahip olsa da, e-posta istemcilerinde çoğunlukla bu tür bir koruma yoktur, bu da saldırıyı e-postada daha etkili hale getirir

  • Sondaki nokta (Trailing Dot)

    • DNS'te tüm alan adları teknik olarak kök bölgeyi gösteren bir noktayla biter, ancak e-postada bu her zaman örtüktür ve atlanır
    • Çoğu doğrulayıcı user@example.com. biçimini reddeder

  • MX kaydı

    • E-posta adresindeki alan adı, posta sunucusunun mutlaka bulunduğu yer olmayabilir; gönderici sunucu gerçek posta sunucusunun ana makine adını bulmak için MX (Mail Exchanger) DNS kaydını sorgular
    • Düşük öncelik numarası daha yüksek öncelik anlamına gelir; hiç MX kaydı yoksa alan adının A kaydına fallback yapılır
    • Bir alan adının kesinlikle e-posta almaması gerekiyorsa, null MX kaydı (MX 0 .) yayımlanarak gönderici sunuculara teslimatı denememeleri açıkça bildirilir (RFC 7505)

Üst seviye alan adı (TLD)

  • Orijinal genel TLD'ler

    • Erken internetin 7 gTLD'si: .com (ticari, bugün sınırsız, Verisign tarafından işletilir), .net (ağ, sınırsız), .org (kuruluşlar, sınırsız), .edu (ABD akredite eğitim kurumları, kısıtlı), .gov (ABD hükümeti, kısıtlı), .mil (ABD ordusu, kısıtlı), .int (antlaşma temelli uluslararası kuruluşlar, çok kısıtlı)
    • .arpa, IANA tarafından yönetilen bir altyapı TLD'sidir ve ters DNS sorgularında kullanılır

  • Ülke kodu TLD'leri (ccTLD)

    • ISO 3166-1 alpha-2 ülke kodlarına dayanan 2 harfli kodlardır; yaklaşık 250 tane vardır
    • Bazı ccTLD'ler başka sektörler tarafından yeniden amaçlandırılmıştır:
      • .io (Britanya Hint Okyanusu Toprakları → teknoloji şirketleri), .tv (Tuvalu → medya ve streaming), .ai (Anguilla → AI şirketleri), .co (Kolombiya → .com alternatifi), .me (Karadağ → kişisel siteler), .ly (Libya → URL kısaltma), .sh (Saint Helena → yazılım projeleri)
    • Yeniden amaçlandırılmış ccTLD kullanıldığında teknik olarak ilgili ülkenin kayıt otoritesinin yetki alanına girilir; alan adı ICANN tarafından değil, asıl ülkenin kayıt otoritesi tarafından kontrol edilir

  • Sponsorlu TLD'ler (sTLD)

    • Sponsor kuruluşu ve uygunluk şartları olan TLD'ler: .aero (hava taşımacılığı, SITA sponsorluğunda), .coop (kooperatifler), .museum (müzeler), .jobs (istihdam), .xxx (yetişkin içerik), .post (posta), .cat (Katalan dili ve kültürü)

  • Yeni genel TLD'ler (2012 sonrası)

    • 2012'de ICANN yeni gTLD başvurularını açtı ve 1.200'den fazla yeni TLD tahsis edildi
    • E-posta doğrulaması açısından önemli etkisi: TLD uzunluğunu 4-6 karakterle sınırlayan doğrulayıcılar bozulur (.photography, .international, .construction vb.)
    • Geliştirici odaklı: .app, .dev, .web, .code / ticari: .shop, .store, .online / içerik: .blog, .news, .media / iş dünyası: .tech, .agency, .cloud
    • Yeni gTLD'ler, düşük kayıt maliyetleri ve bazı kayıt otoritelerinin zayıf kötüye kullanım politikaları nedeniyle spam ve phishing içinde orantısız şekilde temsil edilir

  • Marka TLD'leri

    • 2012 ICANN genişlemesinde büyük şirketler kendi TLD'leri için başvurdu: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
    • Bunların çoğu herkese açık e-posta adreslerinde kullanılmaz; daha çok kurum içi amaçlarla kullanılır ya da hiç kullanılmaz

  • Coğrafi/şehir TLD'leri

    • Şehirlerin ve bölgelerin kendi TLD'leri: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
    • Kayıt sırasında genellikle o bölgeyle bağın kanıtlanması gerekir

  • Uluslararasılaştırılmış TLD'ler

    • ASCII dışı yazı sistemlerindeki TLD'ler birçok ülkede vardır ve DNS'te Punycode ile kodlanır
      • .xn--p1ai (Rusya, Kiril alfabesi), .xn--fiqz9s (Çin, basitleştirilmiş Çince), .xn--mgberp4a5d4ar (Suudi Arabistan, Arap alfabesi), .xn--h2brj9c (Hindistan, Devanagari yazısı)

  • Ayrılmış/belgeleme amaçlı TLD'ler

    • RFC 2606 ve RFC 6761'de test ve belgeleme için ayrılan TLD'ler:
      • .test (genel DNS'te asla bulunmadığı için yazılım testi için güvenli), .example (belge örnekleri için), .invalid (kesinlikle çözümlenmeyen alan adı gerektiğinde), .localhost (loopback için)
    • IANA, belge ve örnek amaçlı example.com, example.net, example.org alan adlarını kaydetmiştir; böylece gerçek posta kutularına ulaşma endişesi olmadan kod örneklerinde serbestçe kullanılabilir

  • Kullanımdan kaldırılan TLD'ler

    • Ülkelerin ortadan kalkması nedeniyle kaldırılan ccTLD'ler: .yu (Yugoslavya, 2010'da silindi), .cs (Çekoslovakya, 1995'te silindi), .dd (Doğu Almanya, 1990'da silindi), .tp (Doğu Timor, .tl ile değiştirildikten sonra 2015'te tamamen silindi)
    • İstisna: .su (Sovyetler Birliği), 1991'de dağılmasına rağmen hâlâ etkin alan adlarına sahiptir; IANA yıllardır geçişi tartışsa da aktif durumunu korur

ccTLD’lerin ikinci seviye alan adları

  • Birçok ccTLD, kaydedilebilir ad ile TLD arasına işlevsel bir ikinci seviye kategori ekler
    • Birleşik Krallık: .co.uk, .org.uk, .gov.uk / Avustralya: .com.au, .edu.au / Japonya: .co.jp, .ac.jp / Hindistan: .co.in, .gov.in / Brezilya: .com.br, .gov.br
  • E-posta kimlik doğrulama sistemlerinde organizasyon alan adının bulunması gerektiğinde, doğrulama ve organizasyon alan adı tespitini etkiler

  • Public Suffix List (PSL)

    • publicsuffix.org üzerindeki topluluk tarafından sürdürülen bir listedir; internet kullanıcılarının doğrudan ad kaydedebildiği tüm alan adı son eklerini içerir
    • Hem resmî yetkilendirmeleri (.co.uk, .com.au) hem de özel kayıt yapılarını (github.io, wordpress.com, herokuapp.com) kapsar
    • Joker karakter gösterimi kullanır (örn. *.ck), istisnalar ! ile belirtilir (örn. !www.ck)
    • E-posta doğrulayıcıları ve spam filtreleri tarafından, tam alan adı dizesi içinden organizasyon alan adını belirlemek için kullanılır
    • IETF standardı değildir, ancak bu sorun için fiilî standarttır (de facto standard)

E-posta adresi biçimleri

  • Temel adres (Bare Address)

    • SMTP komutlarında ve basit bağlamlarda kullanılan, local@domain biçimindeki addr-spec

  • Açılı ayraç biçimi

    • SMTP’de MAIL FROM ve RCPT TO komutlarında adres açılı ayraç içine alınır: MAIL FROM:<sender@example.com>
    • Açılı ayraçlar, adresin kendisinin değil SMTP komut sözdiziminin bir parçasıdır

  • Görünen ad biçimi (Display Name Format)

    • İleti başlıklarında (From, To, Cc), insan tarafından okunabilen bir ad açılı ayraç içindeki adresten önce gelebilir: "John Doe" <john@example.com>
    • Görünen adda özel karakterler varsa tırnak işareti zorunludur
    • Görünen ad sahteciliği: gönderen görünen adı istediği gibi ayarlayabildiği için, "PayPal Security <paypal@paypal.com>" <attacker@evil.com> biçiminde saldırılar mümkündür
      • Birçok e-posta istemcisi gelen kutusu listesinde yalnızca görünen adı gösterdiğinden, bu en yaygın oltalama tekniklerinden biridir

  • Grup sözdizimi (Group Syntax)

    • RFC 5322’de tanımlanan, birden fazla alıcı için adlandırılmış grup biçimi: Marketing Team: alice@example.com, "Bob Smith" <bob@example.com>;
    • Gizli alıcı deseni: To: undisclosed-recipients:; — boş grup sözdizimidir; gerçek alıcılar SMTP zarfında (RCPT TO) bulunur ve ileti başlıklarında görünmez

  • Kodlanmış görünen ad

    • Eski e-posta sistemlerinde görünen addaki ASCII dışı karakterler RFC 2047 encoded-word biçimiyle işlenirdi: =?charset?encoding?encoded_text?=
    • Kodlama B (base64) veya Q (quoted-printable) olabilir
    • Modern SMTPUTF8 desteğinde, bu kodlama sarmalayıcısı olmadan başlıklarda doğrudan UTF-8 kullanılabilir

Her e-postadaki iki gönderici

  • Zarf göndericisi (Envelope Sender / MAIL FROM)

    • SMTP MAIL FROM: komutunda ayarlanır ve iletinin içeriğinin bir parçası değildir
    • Bounce yönlendirmesi için kullanılır, SPF denetiminde doğrulanan hedeftir ve nihai alıcı sunucu tarafından Return-Path: başlığı olarak saklanır
    • Envelope from, reverse path ve RFC5321.MailFrom olarak da adlandırılır

  • From başlığı

    • İletinin From: başlığındaki adrestir; e-posta istemcisinin gönderen olarak gösterdiği şey budur
    • DMARC’ın SPF veya DKIM hizalamasıyla birlikte koruduğu hedeftir
    • Gönderen tarafından serbestçe ayarlanabilir ve çoğu posta sunucusunda benzersiz bir doğrulaması yoktur
    • Bu iki adres tamamen farklı olabilir ve bu normal, beklenen bir senaryodur:
      • ESP toplu gönderiminde MAIL FROM bounce@esp.com, From başlığı ise newsletter@yourbrand.com olabilir
      • Bir e-posta listesinde MAIL FROM listenin bounce adresi, From başlığı ise asıl gönderendir
      • E-posta yönlendirmede, yönlendiren sunucu MAIL FROM’u SRS ile yeniden yazarken From başlığı özgün göndereni korur
    • Alan adında DMARC uygulanmıyorsa, herhangi biri tamamen alakasız bir MAIL FROM kullanırken o alan adını From başlığına koyarak gönderim yapabilir

  • Sender başlığı

    • Gerçek iletici, From adresinden farklı olduğunda onu belirtir: Sender: mailer@sendgrid.net

  • Reply-To başlığı

    • Yanıtların nereye gitmesi gerektiğini belirtir ve From adresinden farklı olabilir
    • Oltalama vektörü olarak da kötüye kullanılabilir: saldırgan From’u meşru görünecek şekilde ayarlayıp Reply-To’yu kendi adresine ayarlar

  • Null Sender

    • MAIL FROM:<> geçerli ve önemli bir SMTP yapısıdır; boş zarf göndericisi, bounce iletileri, otomatik yanıtlar ve kendileri bounce üretmemesi gereken iletiler için kullanılır
    • İki sistemin başarısızlık bildirimlerini sürekli birbirine göndermesinden kaynaklanan sonsuz bounce döngüsünü önler

Rol tabanlı adresler (Role-Based Addresses)

  • RFC 5321 zorunluluğu

    • postmaster@domain: RFC 5321’e göre posta kabul eden her alan adı bu adrese gelen postayı kabul etmek zorundadır, istisnası yoktur

  • RFC 2142 önerileri

    • abuse@domain (spam/kötüye kullanım bildirimleri), hostmaster@domain (DNS zone yönetimi), security@domain (zafiyet ifşası/güvenlik bildirimleri), webmaster@domain (web sunucusu sorunları), noc@domain (ağ operasyonları)

  • Geleneksel rol adresleri

    • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ vb. resmî standart değildir ama yaygın olarak kullanılır
    • Rol adresleri genellikle birden fazla kişi tarafından paylaşılır, bu nedenle hassas bilgiler gönderildiğinde birden çok ekip üyesi tarafından görülebilir
    • abuse@ ve postmaster@, şikâyet e-postaları aldıkları için sosyal mühendisliğin hedefi olabilir

  • Catch-all adresler (Catch-All Addresses)

    • Belirli bir e-posta adresi biçimi değil, posta sunucusu yapılandırmasıdır; belirli bir posta kutusu olmayan local part’lar için de teslimatı kabul eder
    • Kullanım örnekleri: yazım hatalarını yakalama, geliştirici testleri, resmî bir takma ad sistemi olmadan hizmet bazlı benzersiz adresler oluşturma
    • Dezavantajı: herhangi bir local part teslim edildiğinden çok miktarda spam girişi olur, SMTP probing yoluyla adres geçerliliği doğrulaması yapılamaz (tüm yoklamalara başarılı yanıt döner)

Sağlayıcıya özgü davranışlar

  • Gmail

    • Nokta normalizasyonu: Yerel bölümdeki tüm noktalar yok sayılır
    • Artı adresleme: + ayırıcısını destekler
    • @googlemail.com: Almanya ve Birleşik Krallık’taki ticari marka anlaşmazlıkları nedeniyle @gmail.com için kullanılan tarihsel bir takma addır; her iki alan adı da aynı gelen kutusuna yönlendirilir
    • Karakter kısıtlamaları: Yerel bölümde yalnızca İngilizce harfler, rakamlar ve noktalara izin verilir (+ ile artı adresleme dahil). RFC’deki tam karakter kümesini desteklemez
    • Yerel bölüm uzunluk sınırı: RFC’deki azami 64 karakterden çok daha düşük olan 30 karakter

  • Microsoft (Outlook, Hotmail, Live)

    • Nokta normalizasyonu yok: johndoe@outlook.com ve john.doe@outlook.com ayrı posta kutularıdır
    • Alan adı takma adları: @hotmail.com, @live.com, @outlook.com, takma ad yapılandırmasında aynı hesabı gösterebilir
    • Artı adresleme desteklenir

  • Apple (iCloud)

    • Alan adı takma adları: @icloud.com, @me.com, @mac.com aynı gelen kutusuna gider (.mac → .me → .icloud şeklinde hizmet adı değişimi geçmişi vardır)
    • Artı adresleme desteklenir
    • Hide My Email: randomstring@privaterelay.appleid.com biçiminde rastgele takma adlar üretir; her hizmet veya uygulama için benzersiz takma adlarla gerçek adres gizli tutulur

  • ProtonMail / Proton

    • Alan adı takma adları: @proton.me, @protonmail.com, @pm.me aynı gelen kutusuna gider
    • Artı adresleme desteklenir

  • E-posta takma ad hizmetleri

    • Tek kullanımlık e-postadan ayrı olarak, kalıcı ve yönetilebilir yönlendirme adresleri oluşturan hizmetler:
      • SimpleLogin (Proton bünyesinde): özel ve rastgele takma adlarla tüm gelen kutularına yönlendirme
      • Addy.io (eski adıyla AnonAddy): SimpleLogin’e benzer, self-hosting mümkündür
      • Firefox Relay (Mozilla): ücretsiz planda sınırlı sayıda rastgele takma ad
      • DuckDuckGo Email Protection: @duck.com takma adları
    • Gönderen açısından gerçek gelen kutusundan yapısal olarak ayırt edilemeyen adresler üretir
    • Tek kullanımlık e-postadan temel farkı: takma adlar kalıcıdır ve yönetilebilir; belirli bir takma ad devre dışı bırakılabilir, hangi hizmetten geldiği görülebilir ve istenen gelen kutusuna yönlendirilebilir

Tek kullanımlık ve geçici e-posta

  • Kayıt gerektirmeyen ve genellikle kısa bir süre sonra süresi dolan gelen kutuları sunar; Mailinator, Guerrilla Mail, 10 Minute Mail ve TempMail öne çıkan örneklerdir
  • Çoğu catch-all yönlendirme kullanır; bu nedenle ilgili alan adındaki herhangi bir yerel bölüm gelen kutusuna iletilir
  • Birçok gelen kutusu herkese açıktır; bu yüzden adresi bilen herkes iletileri görüntüleyebilir
  • Bilinen tek kullanımlık alan adları için engelleme listeleri vardır (disposable-email-domains GitHub deposu en sık başvurulan kaynaklardan biridir), ancak bunlar her zaman eksiktir ve engellemeleri aşmak için hizmetler sürekli yeni alan adlarına geçer

Geçerlilik denetimi (Validation)

  • Teknik geçerlilik ve pratik geçerlilik

    • RFC’ye göre geçerli olup pratikte gerçek sunucular tarafından neredeyse hiç kabul edilmeyen örnekler: tırnak içindeki boşluk (" "@example.com), tırnak içindeki @ ("user@name"@example.com), IP literal alan adları (user@[192.168.1.1]), tek karakterli/tek etiketli adresler (a@b)
    • RFC’ye göre geçerli olup pratikte de kabul edilen örnekler: user+tag@example.com, user_name@example.com, user@subdomain.example.co.uk, user@example.photography
    • Çoğu uygulamada pratik geçerlilik denetleyicileri, tam RFC uyumlu denetleyicilerden daha iyidir: temel yapı kontrolü, makul karakter kümesi doğrulaması ve isteğe bağlı olarak alan adı için DNS MX sorgusu

  • Yaygın doğrulayıcı hataları

    • Yerel bölümde + reddetme: user+tag@example.com tamamen geçerlidir ve bu çok yaygın bir hatadır
    • Yerel bölümde _ reddetme: bu da geçerlidir
    • Yerel bölümde % reddetme: geçerli bir karakterdir; kullanımdan kalkan şey yalnızca percent-hack yönlendirmesidir
    • TLD uzunluğunu 4~6 karakterle sınırlama: .photography, .international, .construction gibi yüzlerce yeni gTLD’yi engeller
    • Sabit kodlanmış TLD listeleriyle doğrulama: listeler sürekli değiştiği için doğrulayıcı hızla güncelliğini yitirir
    • Yanlış toplam uzunluk sınırı: 254 yerine 255 veya 256 kullanılması. RFC 3696 düzeltme notu 1690, yaygın şekilde alıntılanan yanlış 320 değerini 254 olarak düzeltir
    • Yerel bölümde büyük harf reddetme: RFC’ye göre geçerlidir
    • user@subdomain.co.uk reddetme: geçerlidir; ikinci seviye ccTLD desenlerinde çok noktalı alan adları normaldir
    • .dev, .app, .io’yu TLD olarak reddetme: bunların hepsi geçerli, tahsis edilmiş TLD’lerdir

  • Uzunluk sınırları

    Bölüm Sınır
    Yerel bölüm 64 oktet
    Alan adı etiketi 63 oktet
    Alan adının tamamı 253 oktet
    Adresin tamamı (addr-spec) 254 oktet

  • Yerel bölüm sınırı karaktere değil oktet sayısına göre olduğundan, çok baytlı Unicode karakterler içeren EAI adresleri görsel olarak 64 karakterden kısa olsa bile oktet sınırına ulaşabilir

  • DNS tabanlı geçerlilik denetimi

    • MX kaydı kontrolü: Alan adının MX kaydı olup olmadığını doğrular; hızlıdır ve düşük risklidir. A kaydı geri dönüşü kullanan alan adları (MX yapılandırılmamışsa) bu testte başarısız olabilir
    • Null MX kontrolü: Alan adında MX 0 . varsa, açıkça e-posta kabul etmiyor demektir
    • SMTP RCPT TO probing: Posta sunucusuna bağlanıp RCPT TO komutu göndererek adresin kabul edilip edilmediğini kontrol eder; ancak birçok sunucu adres toplama saldırılarını önlemek için tüm adreslere 250 yanıtı döndürdüğünden güvenilir değildir. Catch-all alan adları her zaman olumlu yanıt verir. Ayrıca sorgulama yapan IP’nin kara listeye alınma riski de vardır
    • Bir e-posta adresini tamamen güvenilir biçimde doğrulamanın tek yolu gerçek bir ileti gönderip teslim edilip edilmediğini görmektir; diğer her şey sezgiseldir

Güvenlik etkileri

  • Görünen ad sahteciliği

    • Herkes e-postadaki görünen adı istediği gibi ayarlayabilir; yalnızca görünen adın gösterildiği gelen kutusu görünümlerinde kullanıcı, gerçek adresi özellikle kontrol etmezse meşru gönderen ile taklitçiyi ayırt edemez

  • Punycode ile homograf saldırıları

    • Farklı Unicode alfabelerindeki karakterler kullanılarak, tanınmış gerçek alan adlarıyla görsel olarak aynı görünen alan adları kaydedilebilir
    • E-posta istemcileri, tarayıcıların aksine, bunun için genellikle uyarı göstermez

  • Gmail nokta hilesiyle hesap atlatma

    • Gmail noktaları yok saydığı için saldırgan, mevcut bir Gmail adresinin noktalı varyasyonuyla bir hizmete kaydolup tek hesap sınırını aşabilir, ücretsiz denemeleri çoğaltabilir ve asıl hesap sahibine gönderilmesi amaçlanan e-postaları alabilir

  • E-posta adreslerinin yeniden kullanımı

    • E-posta sağlayıcıları terk edilmiş adresleri yeni kullanıcılara yeniden atayabilir; böylece yeni hesap sahibi, önceki sahibin kayıtlı olduğu hizmetlerden gelen hesap kurtarma e-postalarını alabilir ve parola sıfırlama yoluyla hesabı ele geçirebilir
    • Gmail adresleri yeniden atamadığını belirtmiştir, ancak geçmişte bazı diğer sağlayıcıların bunu yaptığı görülmüştür

  • Alt adres etiketlerinin açığa çıkması

    • user+newsletter@gmail.com ile kayıt olursanız, alıcı hizmet etiket dahil tam adresi görebilir
    • Artı etiketini kaldırıp saklayan hizmetler temel adresi açığa çıkarır; tam adresi olduğu gibi saklayan hizmetlerde ise takip stratejiniz hesap ayarlarında veya veri dışa aktarımlarında ortaya çıkabilir

İlgili okumalar

Henüz yorum yok.

Henüz yorum yok.