Analisis Mendalam Alamat Email

• Alamat email bukan sekadar gabungan nama pengguna dan domain, tetapi sebuah sistem yang mencakup struktur dan aturan kompleks yang didefinisikan dalam standar RFC, serta jebakan keamanan
• Pada local part (sebelum @), terdapat berbagai format valid yang umumnya tidak diketahui, seperti format bertanda kutip, komentar, dan Unicode, tetapi sebagian besar tidak didukung di lingkungan praktik nyata
• Setiap email memiliki dua alamat pengirim, yaitu Envelope Sender dan header From, dan perbedaan ini merupakan penyebab mendasar spoofing dan phishing
• Kebijakan pengabaian titik (dot) Gmail, plus addressing, alias domain, dan perilaku khas tiap penyedia secara langsung memengaruhi keamanan dan validasi
• Saat membangun sistem yang mengumpulkan atau memvalidasi alamat email, memahami secara tepat kesenjangan antara standar RFC dan perilaku nyata adalah hal yang esensial

---

Struktur dasar

• Alamat email terdiri dari tiga bagian: local part (sebelum @), pemisah @, dan domain (setelah @)
• Meski terlihat sederhana, tiap bagian memiliki aturan dan edge case yang memengaruhi keamanan, privasi, dan validasi

Local part

• Karakter yang diizinkan

  • Karakter yang diizinkan dalam format tanpa tanda kutip standar (dot-atom): huruf a-z, A-Z, angka 0-9, karakter khusus . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • Panjang maksimum adalah 64 oktet (octet); dalam ASCII standar nilainya sama dengan 64 karakter, tetapi pada local part Unicode bisa berbeda
    • Oktet secara tepat berarti grup 8 bit, dan digunakan dalam jaringan (IPv4) untuk merepresentasikan rentang 0~255
    • 64 oktet setara dengan blok data sepanjang 512 bit

• Peka huruf besar-kecil

  • Menurut RFC 5321, local part secara teknis membedakan huruf besar dan kecil, sehingga [e-mail] dan [e-mail] dapat menjadi mailbox yang berbeda
  • Dalam praktiknya, semua penyedia email utama tidak membedakan huruf besar-kecil, sehingga menormalkan ke huruf kecil sebelum penyimpanan atau perbandingan adalah nilai default yang aman
  • Bagian domain selalu tidak membedakan huruf besar-kecil

• Pengalamatan titik (Dot)

  • Titik diizinkan di local part, tetapi ada tiga batasan: tidak boleh diawali titik, tidak boleh diakhiri titik, dan titik berurutan tidak diizinkan
  • Normalisasi titik Gmail: Gmail sepenuhnya mengabaikan titik pada local part, sehingga [e-mail], [e-mail], dan [e-mail] semuanya dikirim ke inbox yang sama
    • Ini bukan standar RFC, melainkan perilaku khusus Gmail
    • Ini adalah vektor serangan nyata yang dapat disalahgunakan penyerang untuk membuat akun terpisah dengan variasi titik guna melewati batas satu akun atau memperoleh uji coba gratis berulang

• Subaddressing (plus addressing)

  • Tag dapat ditambahkan ke local part menggunakan pemisah, dan server mail akan mengirimkannya ke alamat dasar sambil mempertahankan tag tersebut (standar RFC 5233)
  • Pemisah yang paling umum adalah +, dan didukung oleh Gmail, Outlook, ProtonMail, Fastmail, dan lainnya
    • Pada beberapa konfigurasi Yahoo dan pengaturan Postfix tertentu, digunakan -
    • Pada qmail, = adalah pemisah default, dan inilah alasan VERP mengodekan @ menjadi =
  • Kasus penggunaan utama:
    • Pelacakan kebocoran: mendaftar dengan tag unik per layanan (misalnya [e-mail]) untuk mengetahui sumber kebocoran saat menerima spam
    • Penyaringan inbox: secara otomatis mengelompokkan email ke alamat bertag tertentu dengan aturan mail
    • Banyak akun: pada layanan yang tidak menormalkan tanda plus, akun terpisah dapat dibuat dengan satu email yang sama
  • Banyak validator email di situs web menolak +, tetapi itu adalah bug pada kode validasi, bukan batasan email itu sendiri

• Format quoted string

  • Jika local part dibungkus dengan tanda kutip ganda, sebagian besar batasan karakter dilonggarkan, sehingga spasi, @, titik berurutan, serta titik di awal atau akhir menjadi diizinkan
  • Contoh: "john doe"@example.com, "user@name"@example.com, " "@example.com
  • Dalam praktiknya, hampir semua penyedia email tidak menerima local part bertanda kutip, sehingga valid menurut RFC tetapi tidak berguna dalam penggunaan nyata

• Komentar (Comments)

  • Komentar di dalam tanda kurung dapat muncul di awal atau akhir local part, dan akan dihapus oleh server mail tanpa memengaruhi pengiriman
  • Secara teknis valid menurut RFC 5322, tetapi tidak digunakan di era modern
  • Validator yang menolak tanda kurung berarti lebih ketat daripada RFC

• Local part Unicode (EAI)

  • Internationalization of email addresses (EAI) yang didefinisikan dalam RFC 6530, 6531, dan 6532 mengizinkan karakter UTF-8 pada local part
  • Ekstensi SMTPUTF8 harus digunakan dalam sesi SMTP, dan server pengirim maupun penerima harus sama-sama mendukungnya
  • Hingga 2026, adopsinya masih terbatas, dan karena karakter Unicode memakai 2~4 oktet, batas 64 oktet bisa tercapai sebelum jumlah karakter visual mencapai 64

• Format historis

  • Bang path (UUCP): metode routing yang menggunakan jalur hostname yang dipisahkan ! (machine1!machine2!user) pada jaringan mesin Unix yang terhubung modem sebelum era DNS; inilah alasan ! masuk dalam daftar karakter yang diizinkan. Kini sudah sepenuhnya ditinggalkan
  • Percent hack: trik routing relay berbentuk [e-mail]; karakter % tetap valid di local part meskipun mekanisme routing tersebut sudah dihapus dari RFC 5321
  • Source routing: daftar hop relay eksplisit (@relay1,@relay2:user@domain) dalam perintah SMTP RCPT TO. Dihapus dari RFC 5321

• VERP (Variable Envelope Return Path)

  • Teknik dalam sistem email massal untuk melacak penerima yang tepat yang menyebabkan bounce
  • Alamat penerima dikodekan ke envelope sender (MAIL FROM), dengan @ pada alamat penerima diganti menjadi =
    • Contoh: bounces+alice=[e-mail]
  • Mailchimp, SendGrid, dan Amazon SES menggunakan VERP atau variannya untuk penanganan bounce skala besar

• SRS (Sender Rewriting Scheme)

  • Format alamat yang muncul ketika server meneruskan email sambil menulis ulang envelope sender agar lolos pemeriksaan SPF
  • Berbentuk SRS0=HASH=TT=originaldomain.com=[e-mail]
  • Pada penerusan multi-hop, berbentuk SRS1=HASH=[e-mail]
  • Ini adalah alamat email yang valid secara struktural, tetapi merupakan artefak infrastruktur dan bukan alamat yang digunakan manusia
  • Komponen HASH adalah HMAC atas stempel waktu dan alamat asli, yang berfungsi mencegah pemalsuan serta membatasi masa berlaku token

Bagian Domain (Domain Part)

• Aturan label

  • Domain terdiri dari label yang dipisahkan titik, dan setiap label dapat berisi huruf a-z, angka 0-9, serta tanda hubung -
  • Tidak boleh diawali atau diakhiri dengan tanda hubung, dan tidak boleh ada tanda hubung ganda berurutan pada posisi ke-3~4 (namun, label Punycode yang diawali xn-- adalah pengecualian)
  • Maksimum 63 karakter per label, maksimum 253 karakter untuk seluruh domain, dan maksimum 254 karakter untuk seluruh alamat email (addr-spec)

• Subdomain

  • Domain dapat memiliki banyak level, dan selain batas total panjang domain 253 karakter, tidak ada batas keras terhadap kedalaman subdomain
  • Penggunaan umum: infrastruktur email (mail., smtp., mx.), pemisahan organisasi (sales.company.com), pengiriman oleh ESP (email.company.com)

• Literal alamat IP

  • Alamat IP di dalam tanda kurung siku dapat digunakan sebagai pengganti nama domain: user@[192.168.1.1], user@[IPv6:2001:db8::1]
  • Valid menurut RFC 5321, tetapi hampir tidak pernah diterima oleh server email publik, dan digunakan untuk sistem email internal serta pengujian SMTP

• Domain label tunggal

  • Domain tanpa titik (misalnya user@localhost) secara teknis valid dalam beberapa konteks, tetapi ditolak oleh server email publik
  • postmaster@localhost adalah kasus khusus konvensional untuk email sistem lokal pada sistem mirip Unix

• Nama domain internasional (IDN) dan Punycode

  • Karena DNS hanya mendukung ASCII, karakter non-ASCII dikodekan dengan Punycode (RFC 3492), dan semua label yang dikodekan diawali dengan prefiks xn--
  • Klien email menampilkan skrip native, dan SMTP mengirimkannya dalam bentuk Punycode
  • Serangan homograf: dimungkinkan mendaftarkan domain yang mirip dengan domain terkenal dengan memakai karakter yang tampak sama dari skrip Unicode lain. Browser memiliki mekanisme pertahanan dengan menampilkan Punycode untuk IDN yang mencurigakan, tetapi kebanyakan klien email tidak memiliki pertahanan semacam ini, sehingga serangan ini lebih efektif di email

• Titik penutup (Trailing Dot)

  • Dalam DNS, semua domain secara teknis berakhir dengan titik penutup yang menunjukkan root zone, tetapi dalam email hal ini selalu implisit dan dihilangkan
  • Sebagian besar validator menolak bentuk [e-mail].

• Rekor MX

  • Domain pada alamat email tidak harus menjadi tempat server email berada; server pengirim akan mencari rekor DNS MX (Mail Exchanger) untuk menemukan nama host server email yang sebenarnya
  • Angka prioritas yang lebih rendah berarti prioritas yang lebih tinggi, dan jika sama sekali tidak ada rekor MX, maka akan fallback ke rekor A domain
  • Jika sebuah domain sama sekali tidak boleh menerima email, publikasikan rekor null MX (MX 0 .) untuk secara eksplisit memberi tahu server pengirim agar tidak mencoba melakukan pengiriman (RFC 7505)

Domain Tingkat Atas (TLD)

• gTLD umum asli

  • 7 gTLD awal internet: .com (komersial, kini tidak dibatasi, dioperasikan oleh Verisign), .net (jaringan, tidak dibatasi), .org (organisasi, tidak dibatasi), .edu (institusi pendidikan terakreditasi AS, terbatas), .gov (pemerintah AS, terbatas), .mil (militer AS, terbatas), .int (organisasi internasional berbasis perjanjian, sangat terbatas)
  • .arpa adalah TLD infrastruktur yang dikelola IANA dan digunakan untuk pencarian DNS terbalik

• TLD kode negara (ccTLD)

  • Kode 2 huruf berbasis kode negara ISO 3166-1 alpha-2, dengan sekitar 250 yang ada
  • Sejumlah ccTLD dialihfungsikan oleh industri lain:
    • .io (British Indian Ocean Territory → perusahaan teknologi), .tv (Tuvalu → media·streaming), .ai (Anguilla → perusahaan AI), .co (Kolombia → alternatif .com), .me (Montenegro → situs pribadi), .ly (Libya → pemendek URL), .sh (Saint Helena → proyek perangkat lunak)
  • Jika menggunakan ccTLD yang dialihfungsikan, secara teknis Anda berada di bawah yurisdiksi registry negara tersebut, dan domain dikendalikan oleh registry negara asal, bukan ICANN

• TLD bersponsor (sTLD)

  • TLD dengan organisasi sponsor dan persyaratan kelayakan: .aero (transportasi udara, disponsori SITA), .coop (koperasi), .museum (museum), .jobs (ketenagakerjaan), .xxx (dewasa), .post (pos), .cat (bahasa·budaya Katalan)

• gTLD baru (sejak 2012)

  • Pada 2012, ICANN membuka pendaftaran gTLD baru, dan lebih dari 1.200 TLD baru telah didelegasikan
  • Dampak penting bagi validasi email: validator yang membatasi panjang TLD menjadi 4~6 karakter akan gagal (.photography, .international, .construction, dll.)
  • Terkait developer: .app, .dev, .web, .code / komersial: .shop, .store, .online / konten: .blog, .news, .media / bisnis: .tech, .agency, .cloud
  • gTLD baru terlalu banyak terwakili dalam spam dan phishing karena biaya pendaftaran yang rendah dan kebijakan penyalahgunaan yang lemah pada sebagian registry

• TLD merek

  • Dalam ekspansi ICANN 2012, perusahaan besar mengajukan TLD mereka sendiri: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
  • Kebanyakan tidak digunakan sebagai alamat email publik, melainkan terutama untuk keperluan internal atau bahkan tidak digunakan sama sekali

• TLD geografis·kota

  • TLD milik kota dan wilayah: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
  • Saat mendaftar biasanya perlu membuktikan keterkaitan dengan wilayah tersebut

• TLD internasional

  • Ada banyak TLD dalam skrip non-ASCII di berbagai negara, dan di DNS semuanya dikodekan dalam Punycode
    • .xn--p1ai (Rusia, aksara Sirilik), .xn--fiqz9s (Tiongkok, Hanzi sederhana), .xn--mgberp4a5d4ar (Arab Saudi, aksara Arab), .xn--h2brj9c (India, aksara Dewanagari)

• TLD yang dicadangkan·didokumentasikan

  • TLD yang dicadangkan oleh RFC 2606 dan RFC 6761 untuk pengujian dan dokumentasi:
    • .test (tidak akan pernah ada di DNS publik sehingga aman untuk pengujian perangkat lunak), .example (untuk contoh dokumentasi), .invalid (saat memerlukan domain yang dipastikan tidak dapat diresolusikan), .localhost (untuk loopback)
  • IANA telah mendaftarkan example.com, example.net, dan example.org untuk dokumentasi dan contoh, sehingga dapat bebas dipakai dalam contoh kode tanpa khawatir mencapai mailbox sungguhan

• TLD yang dihentikan

  • ccTLD yang dihapus karena negara bubar: .yu (Yugoslavia, dihapus pada 2010), .cs (Cekoslowakia, dihapus pada 1995), .dd (Jerman Timur, dihapus pada 1990), .tp (Timor Timur, digantikan oleh .tl lalu dihapus sepenuhnya pada 2015)
  • Pengecualian: .su (Uni Soviet) masih memiliki domain aktif meski negara itu bubar pada 1991, dan walau IANA telah membahas transisinya selama bertahun-tahun, statusnya tetap aktif

Domain tingkat kedua pada ccTLD

• Banyak ccTLD menambahkan kategori tingkat kedua fungsional antara nama yang dapat didaftarkan dan TLD
  • Inggris: .co.uk, .org.uk, .gov.uk / Australia: .com.au, .edu.au / Jepang: .co.jp, .ac.jp / India: .co.in, .gov.in / Brasil: .com.br, .gov.br
• Dalam sistem verifikasi email, hal ini memengaruhi validasi dan pendeteksian domain organisasi ketika perlu menemukan domain organisasi

• Public Suffix List (PSL)

  • Daftar yang dikelola komunitas di publicsuffix.org, berisi semua sufiks domain yang dapat didaftarkan langsung oleh pengguna internet
  • Mencakup delegasi resmi (.co.uk, .com.au) maupun registri privat (github.io, wordpress.com, herokuapp.com)
  • Menggunakan notasi wildcard (misalnya *.ck), dan pengecualian ditandai dengan ! (misalnya !www.ck)
  • Digunakan oleh validator email dan filter spam untuk mengidentifikasi domain organisasi dari keseluruhan string domain
  • Bukan standar IETF, tetapi merupakan standar de facto untuk masalah ini

Format alamat email

• Alamat dasar (Bare Address)

  • addr-spec berbentuk local@domain, digunakan dalam perintah SMTP dan konteks sederhana

• Format angle bracket

  • Dalam SMTP, perintah MAIL FROM dan RCPT TO membungkus alamat dengan tanda kurung sudut: MAIL FROM:<[e-mail]>
  • Tanda kurung sudut adalah bagian dari sintaks perintah SMTP, bukan bagian dari alamat itu sendiri

• Format nama tampilan (Display Name Format)

  • Dalam header pesan (From, To, Cc), nama yang dapat dibaca manusia dapat muncul sebelum alamat dalam tanda kurung sudut: "John Doe" <[e-mail]>
  • Jika nama tampilan mengandung karakter khusus, tanda kutip wajib digunakan
  • Spoofing nama tampilan: pengirim dapat mengatur nama tampilan sesuka hati, sehingga serangan seperti "PayPal Security <[e-mail]>" <[e-mail]> dimungkinkan
    • Banyak klien email hanya menampilkan nama tampilan di daftar kotak masuk, sehingga ini menjadi salah satu teknik phishing paling umum

• Sintaks grup (Group Syntax)

  • Format grup bernama untuk beberapa penerima yang didefinisikan dalam RFC 5322: Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • Pola penerima tersembunyi: To: undisclosed-recipients:; — sintaks grup kosong, di mana penerima sebenarnya ada di amplop SMTP (RCPT TO) dan tidak terlihat di header pesan

• Nama tampilan terenkode

  • Dalam sistem email lama, karakter non-ASCII pada nama tampilan diproses sebagai encoded word RFC 2047: =?charset?encoding?encoded_text?=
  • Pengodeannya adalah B (base64) atau Q (quoted-printable)
  • Dengan dukungan SMTPUTF8 modern, UTF-8 dapat digunakan langsung di header tanpa wrapper encoding ini

Dua pengirim dalam setiap email

• Pengirim amplop (Envelope Sender / MAIL FROM)

  • Ditetapkan dalam perintah SMTP MAIL FROM:, dan bukan bagian dari isi pesan itu sendiri
  • Digunakan untuk perutean bounce, menjadi target verifikasi saat pemeriksaan SPF, dan disimpan oleh server penerima akhir sebagai header Return-Path:
  • Juga disebut envelope from, reverse path, atau RFC5321.MailFrom

• Header From

  • Alamat dalam header From: pesan, yaitu yang ditampilkan klien email sebagai pengirim
  • Menjadi target yang dilindungi DMARC bersama alignment SPF atau DKIM
  • Dapat diatur bebas oleh pengirim, dan pada sebagian besar server email tidak ada verifikasi khusus
  • Kedua alamat ini bisa sepenuhnya berbeda, dan ini adalah skenario yang normal serta diharapkan:
    • Saat pengiriman massal oleh ESP, MAIL FROM adalah [e-mail], sedangkan header From adalah [e-mail]
    • Pada mailing list, MAIL FROM adalah alamat bounce milik daftar, sedangkan header From adalah pengirim asli
    • Saat penerusan email, server penerus menulis ulang MAIL FROM dengan SRS, tetapi header From tetap mempertahankan pengirim asli
  • Jika domain tidak menerapkan DMARC, siapa pun dapat mengirim dengan menaruh domain tersebut di header From sambil menggunakan MAIL FROM yang sama sekali tidak terkait

• Header Sender

  • Mengidentifikasi pengirim sebenarnya ketika pengaju pesan yang sesungguhnya berbeda dari alamat From: Sender: [e-mail]

• Header Reply-To

  • Menentukan ke mana balasan harus dikirim, dan bisa berbeda dari alamat From
  • Juga dapat disalahgunakan sebagai vektor phishing: penyerang membuat From tampak sah dan mengatur Reply-To ke alamat miliknya sendiri

• Null Sender

  • MAIL FROM:<> adalah struktur SMTP yang valid dan penting; pengirim amplop kosong digunakan untuk pesan bounce, balasan otomatis, dan pesan yang tidak boleh menghasilkan bounce lagi
  • Mencegah loop bounce tak berujung ketika dua sistem terus saling bertukar notifikasi kegagalan

Alamat berbasis peran (Role-Based Addresses)

• Wajib menurut RFC 5321

  • postmaster@domain: menurut RFC 5321, semua domain yang menerima email wajib menerima email ke alamat ini, tanpa pengecualian

• Direkomendasikan oleh RFC 2142

  • abuse@domain (laporan spam/penyalahgunaan), hostmaster@domain (pengelolaan zona DNS), security@domain (pengungkapan kerentanan/laporan keamanan), webmaster@domain (masalah server web), noc@domain (operasi jaringan)

• Alamat peran yang bersifat konvensional

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ dan lainnya, tidak merupakan standar resmi tetapi digunakan secara luas
  • Alamat peran biasanya dibagikan oleh beberapa orang, sehingga saat mengirim informasi sensitif, banyak anggota tim mungkin dapat melihatnya
  • abuse@ dan postmaster@ menerima email keluhan, sehingga menjadi target social engineering

• Alamat catch-all

  • Bukan format alamat email tertentu, melainkan konfigurasi server email yang menerima pengiriman bahkan untuk local part yang tidak memiliki mailbox khusus
  • Contoh penggunaan: menangkap salah ketik, pengujian pengembang, membuat alamat unik per layanan tanpa sistem alias resmi
  • Kekurangan: karena local part apa pun akan diteruskan, ini menyebabkan banjir spam dalam jumlah besar, dan validasi keberadaan alamat melalui SMTP probing menjadi tidak mungkin (semua probe akan mendapat respons berhasil)

Perilaku Khusus per Penyedia

• Gmail

  • Normalisasi titik: semua titik di local part diabaikan
  • Plus addressing: mendukung pemisah +
  • @googlemail.com: alias historis dari @gmail.com akibat sengketa merek dagang di Jerman dan Inggris, dan kedua domain dikirimkan ke kotak masuk yang sama
  • Batas karakter: hanya mengizinkan huruf Latin, angka, dan titik pada local part (termasuk + untuk plus addressing). Tidak mendukung seluruh set karakter RFC
  • Batas panjang local part: 30 karakter, jauh lebih rendah daripada maksimum RFC yaitu 64

• Microsoft (Outlook, Hotmail, Live)

  • Tidak ada normalisasi titik: [e-mail] dan [e-mail] adalah mailbox yang berbeda
  • Alias domain: @hotmail.com, @live.com, dan @outlook.com dapat merujuk ke akun yang sama saat alias dikonfigurasi
  • Mendukung plus addressing

• Apple (iCloud)

  • Alias domain: @icloud.com, @me.com, dan @mac.com menuju kotak masuk yang sama (riwayat pergantian nama layanan dari .mac → .me → .icloud)
  • Mendukung plus addressing
  • Hide My Email: membuat alias acak dalam bentuk [e-mail], menjaga alamat asli tetap privat dengan alias unik untuk tiap layanan atau aplikasi

• ProtonMail / Proton

  • Alias domain: @proton.me, @protonmail.com, dan @pm.me menuju kotak masuk yang sama
  • Mendukung plus addressing

• Layanan alias email

  • Terpisah dari email sekali pakai, ada layanan yang membuat alamat penerusan permanen dan dapat dikendalikan:
    • SimpleLogin (milik Proton): meneruskan ke kotak masuk mana pun dengan alias kustom atau acak
    • Addy.io (sebelumnya AnonAddy): mirip SimpleLogin, dapat di-self-host
    • Firefox Relay (Mozilla): alias acak terbatas di paket gratis
    • DuckDuckGo Email Protection: alias @duck.com
  • Bagi pengirim, alamat yang dibuat secara struktural tidak dapat dibedakan dari kotak masuk asli
  • Perbedaan utama dari email sekali pakai: alias bersifat permanen dan dapat dikendalikan, bisa menonaktifkan alias tertentu, memeriksa email per layanan, dan meneruskan ke kotak masuk yang diinginkan

Email Sekali Pakai dan Sementara

• Menyediakan kotak masuk yang tidak memerlukan pendaftaran dan biasanya kedaluwarsa setelah waktu singkat; contoh yang umum adalah Mailinator, Guerrilla Mail, 10 Minute Mail, dan TempMail
• Sebagian besar menggunakan routing catch-all, sehingga local part apa pun pada domain tersebut akan diteruskan ke kotak masuk
• Banyak kotak masuk bersifat publik, sehingga siapa pun yang mengetahui alamatnya dapat melihat pesan
• Ada daftar blokir domain sekali pakai yang dikenal (repositori GitHub disposable-email-domains adalah yang paling sering dirujuk), tetapi selalu tidak lengkap, dan untuk menghindari pemblokiran mereka terus mengganti ke domain baru

Validasi

• Validitas teknis vs validitas praktis

  • Valid menurut RFC tetapi hampir tidak pernah diterima server nyata: spasi di dalam tanda kutip(" "@example.com), @ di dalam tanda kutip("user@name"@example.com), domain literal IP(user@[192.168.1.1]), karakter tunggal/label tunggal(a@b)
  • Valid menurut RFC dan juga diterima dalam praktik: [e-mail], [e-mail], [e-mail], [e-mail]
  • Untuk sebagian besar aplikasi, validator yang praktis lebih baik daripada validator yang sepenuhnya patuh RFC: memeriksa struktur dasar, memvalidasi set karakter yang wajar, dan secara opsional melakukan lookup DNS MX domain

• Bug umum pada validator

  • Menolak + di local part: [e-mail] sepenuhnya valid, dan ini bug yang sangat umum
  • Menolak _ di local part: ini juga valid
  • Menolak % di local part: karakter ini valid; yang sudah usang hanyalah penggunaan percent-hack routing
  • Membatasi panjang TLD ke 4~6 karakter: memblokir ratusan gTLD baru seperti .photography, .international, .construction
  • Memvalidasi dengan daftar TLD yang di-hardcode: karena daftar terus berubah, validator akan menjadi usang
  • Batas panjang total yang salah: memakai 255 atau 256 alih-alih 254. RFC 3696 errata nomor 1690 mengoreksi nilai 320 yang dulu sering dikutip menjadi 254
  • Menolak huruf besar di local part: valid menurut RFC
  • Menolak [e-mail]: ini valid; domain bertitik banyak dengan pola ccTLD sekunder adalah hal normal
  • Menolak .dev, .app, .io sebagai TLD: semuanya adalah TLD terdelegasi yang valid

• Batas panjang

  Bagian	Batas
  Local part	64 oktet
  Label domain	63 oktet
  Seluruh domain	253 oktet
  Seluruh alamat (addr-spec)	254 oktet

• Batas local part dihitung dalam oktet, bukan karakter, sehingga alamat EAI dengan karakter Unicode multibita dapat secara visual kurang dari 64 karakter tetapi tetap mencapai batas oktet

• Validasi berbasis DNS

  • Pemeriksaan record MX: memverifikasi apakah domain memiliki record MX; cepat dan berisiko rendah. Domain yang memakai fallback ke record A (tanpa konfigurasi MX) dapat gagal pada pemeriksaan ini
  • Pemeriksaan Null MX: jika domain memiliki MX 0 ., maka domain tersebut secara eksplisit tidak menerima email
  • Probing SMTP RCPT TO: terhubung ke server email dan mengirim perintah RCPT TO untuk mengecek apakah alamat diterima, tetapi banyak server mengembalikan respons 250 untuk semua alamat guna mencegah pengumpulan alamat, sehingga tidak andal. Domain catch-all juga selalu memberi respons positif. Ada juga risiko IP probe masuk daftar hitam
  • Satu-satunya cara untuk memvalidasi alamat email dengan benar-benar andal adalah mengirim pesan nyata dan memeriksa apakah pesan tersebut sampai; sisanya hanyalah heuristik

Implikasi Keamanan

• Spoofing nama tampilan

  • Siapa pun dapat mengatur nama tampilan email sesuka hati, dan pada tampilan kotak masuk yang hanya menampilkan nama tampilan, pengguna tidak dapat membedakan pengirim sah dari peniru kecuali mereka secara eksplisit memeriksa alamat sebenarnya

• Serangan homograf melalui Punycode

  • Dimungkinkan mendaftarkan domain yang secara visual identik dengan domain terkenal yang asli dengan memakai karakter dari skrip Unicode lain
  • Tidak seperti browser, klien email umumnya tidak menampilkan peringatan untuk hal ini

• Bypass akun melalui trik titik Gmail

  • Karena Gmail mengabaikan titik, penyerang dapat mendaftar ke suatu layanan dengan variasi titik dari alamat Gmail yang sudah ada untuk melewati batas satu akun, memperoleh uji coba gratis berulang, atau menerima email yang ditujukan untuk pemilik akun asli

• Penggunaan ulang alamat email

  • Penyedia email dapat menetapkan ulang alamat yang ditinggalkan kepada pengguna baru, dan pemilik akun baru dapat menerima email pemulihan akun dari layanan yang pernah didaftarkan pemilik sebelumnya, sehingga pengambilalihan akun melalui reset kata sandi menjadi mungkin
  • Gmail menyatakan tidak menetapkan ulang alamat, tetapi beberapa penyedia lain secara historis pernah melakukannya

• Kebocoran tag subaddress

  • Jika mendaftar dengan [e-mail], layanan penerima dapat melihat alamat lengkap termasuk tag tersebut
  • Layanan yang menghapus tag plus lalu menyimpannya akan mengekspos alamat dasar, sedangkan layanan yang menyimpan alamat lengkap apa adanya akan membuat strategi pelacakan terlihat dalam pengaturan akun atau ekspor data