Phân tích chuyên sâu về địa chỉ email

• Địa chỉ email không chỉ là sự kết hợp đơn giản giữa tên người dùng và tên miền, mà là một hệ thống bao gồm cấu trúc và quy tắc phức tạp được định nghĩa trong tiêu chuẩn RFC, cùng các bẫy bảo mật
• Phần local part (trước @) có nhiều định dạng hợp lệ đa dạng ít được biết đến như dạng có dấu ngoặc kép, chú thích, Unicode..., nhưng hầu như không được hỗ trợ trong phần lớn môi trường thực tế
• Mọi email đều có hai địa chỉ người gửi là Envelope Sender và header From, và sự khác biệt này là nguyên nhân gốc rễ của spoofing và phishing
• Chính sách bỏ qua dấu chấm (dot) của Gmail, cộng với plus addressing, domain alias và các hành vi riêng theo từng nhà cung cấp ảnh hưởng trực tiếp đến bảo mật và việc kiểm tra tính hợp lệ
• Khi xây dựng hệ thống thu thập hoặc xác thực địa chỉ email, việc hiểu chính xác khoảng cách giữa tiêu chuẩn RFC và cách vận hành thực tế là điều bắt buộc

---

Cấu trúc cơ bản

• Địa chỉ email gồm ba phần: local part (trước @), dấu phân cách @, và domain (sau @)
• Nhìn bề ngoài có vẻ đơn giản, nhưng mỗi phần đều có các quy tắc và edge case ảnh hưởng đến bảo mật, quyền riêng tư và việc kiểm tra tính hợp lệ

Local part

• Ký tự được phép

  • Các ký tự được phép trong dạng không có dấu ngoặc kép theo chuẩn (dot-atom): chữ cái a-z, A-Z, chữ số 0-9, ký tự đặc biệt . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • Độ dài tối đa là 64 octet, trong ASCII chuẩn thì tương đương 64 ký tự, nhưng với local part Unicode sẽ phát sinh khác biệt
    • Octet nghĩa chính xác là một nhóm 8 bit, được dùng trong mạng máy tính (IPv4) để biểu diễn phạm vi 0~255
    • 64 octet tương ứng với một khối dữ liệu dài 512 bit

• Phân biệt chữ hoa chữ thường

  • Theo RFC 5321, local part về mặt kỹ thuật có phân biệt chữ hoa chữ thường, nên [e-mail] và [e-mail] có thể là hai mailbox khác nhau
  • Trong thực tế, mọi nhà cung cấp email lớn đều không phân biệt chữ hoa chữ thường, vì vậy chuẩn hóa về chữ thường trước khi lưu trữ hoặc so sánh là mặc định an toàn
  • Phần domain thì luôn không phân biệt chữ hoa chữ thường

• Dot addressing

  • Dấu chấm được phép trong local part nhưng có ba giới hạn: không được bắt đầu bằng dấu chấm, không được kết thúc bằng dấu chấm, và không được có dấu chấm liên tiếp
  • Chuẩn hóa dấu chấm của Gmail: Gmail bỏ qua hoàn toàn dấu chấm trong local part, nên [e-mail], [e-mail], [e-mail] đều được chuyển đến cùng một hộp thư
    • Đây không phải là tiêu chuẩn RFC mà là hành vi riêng của Gmail
    • Đây là một vector tấn công thực tế có thể bị kẻ xấu lợi dụng bằng cách tạo tài khoản với biến thể dấu chấm để vượt qua giới hạn một tài khoản hoặc nhận lặp nhiều đợt dùng thử miễn phí

• Subaddressing (plus addressing)

  • Có thể thêm thẻ vào local part bằng ký tự phân tách, và mail server sẽ chuyển thư đến địa chỉ gốc trong khi vẫn giữ nguyên thẻ (RFC 5233)
  • Ký tự phân tách phổ biến nhất là +, được hỗ trợ trên Gmail, Outlook, ProtonMail, Fastmail...
    • Một số cấu hình của Yahoo và Postfix dùng -
    • Trong qmail, = là ký tự phân tách mặc định, đó cũng là lý do VERP mã hóa @ thành =
  • Các trường hợp sử dụng chính:
    • Theo dõi rò rỉ: đăng ký bằng thẻ riêng cho từng dịch vụ (ví dụ [e-mail]) để xác định nguồn rò rỉ khi nhận spam
    • Lọc hộp thư: dùng quy tắc email để tự động phân loại thư gửi đến các địa chỉ có thẻ cụ thể
    • Nhiều tài khoản: có thể tạo tài khoản riêng biệt bằng một email nếu dịch vụ không chuẩn hóa phần dấu cộng
  • Nhiều bộ kiểm tra tính hợp lệ email trên website từ chối +, nhưng đó là bug của mã xác thực, không phải giới hạn của email

• Dạng chuỗi có dấu ngoặc kép (Quoted String Form)

  • Nếu local part được đặt trong dấu ngoặc kép, phần lớn giới hạn ký tự sẽ được nới lỏng, cho phép khoảng trắng, @, dấu chấm liên tiếp, dấu chấm đầu hoặc cuối
  • Ví dụ: "john doe"@example.com, "user@name"@example.com, " "@example.com
  • Trên thực tế, gần như mọi nhà cung cấp email đều không chấp nhận local part có dấu ngoặc kép, nên hợp lệ theo RFC nhưng vô dụng trong thực tiễn

• Chú thích (Comments)

  • Chú thích trong dấu ngoặc đơn có thể xuất hiện ở đầu hoặc cuối local part, và mail server sẽ loại bỏ chúng mà không ảnh hưởng đến việc chuyển phát
  • Về mặt kỹ thuật, điều này hợp lệ theo RFC 5322 nhưng không còn được dùng trong thời hiện đại
  • Trình kiểm tra tính hợp lệ từ chối dấu ngoặc là nghiêm ngặt hơn RFC

• Local part Unicode (EAI)

  • Quốc tế hóa địa chỉ email (EAI), được định nghĩa trong RFC 6530, 6531, 6532, cho phép dùng ký tự UTF-8 trong local part
  • Phải sử dụng extension SMTPUTF8 trong phiên SMTP, và cả server gửi lẫn nhận đều phải hỗ trợ
  • Tính đến năm 2026, mức độ chấp nhận vẫn còn hạn chế; ký tự Unicode dùng 2~4 octet, nên có thể chạm giới hạn 64 octet trước cả khi đạt tới số ký tự nhìn thấy được

• Định dạng lịch sử

  • Bang path (UUCP): trước thời DNS, trong mạng lưới các máy Unix kết nối qua modem, việc định tuyến dùng đường dẫn hostname phân tách bằng ! (machine1!machine2!user), đây là lý do ! có trong danh sách ký tự được phép. Hiện nay đã ngừng sử dụng hoàn toàn
  • Percent hack: mẹo định tuyến relay dạng [e-mail]; ký tự % vẫn còn hợp lệ trong local part dù cơ chế định tuyến này đã bị RFC 5321 loại bỏ
  • Source routing: danh sách relay hop tường minh trong lệnh SMTP RCPT TO (@relay1,@relay2:user@domain). Đã bị RFC 5321 loại bỏ

• VERP (Variable Envelope Return Path)

  • Kỹ thuật trong hệ thống gửi email hàng loạt để theo dõi chính xác người nhận đã gây ra bounce
  • Mã hóa địa chỉ người nhận vào envelope sender (MAIL FROM), thay @ trong địa chỉ người nhận bằng =
    • Ví dụ: bounces+alice=[e-mail]
  • Mailchimp, SendGrid, Amazon SES... dùng VERP hoặc biến thể của nó để xử lý bounce ở quy mô lớn

• SRS (Sender Rewriting Scheme)

  • Dạng địa chỉ xuất hiện khi server chuyển tiếp thư và ghi lại envelope sender để SPF pass
  • Có dạng SRS0=HASH=TT=originaldomain.com=[e-mail]
  • Khi chuyển tiếp qua nhiều hop, có dạng SRS1=HASH=[e-mail]
  • Đây là địa chỉ email hợp lệ về mặt cấu trúc nhưng là sản phẩm của hạ tầng, không phải địa chỉ do con người sử dụng
  • Thành phần HASH là HMAC của timestamp và địa chỉ gốc, có vai trò chống giả mạo và giới hạn thời hạn hiệu lực của token

Phần tên miền (Domain Part)

• Quy tắc nhãn

  • Tên miền được cấu thành từ các nhãn phân tách bằng dấu chấm, và mỗi nhãn cho phép chữ cái a-z, chữ số 0-9, dấu gạch nối -
  • Không được bắt đầu hoặc kết thúc bằng dấu gạch nối, và không được có hai dấu gạch nối liên tiếp ở vị trí thứ 3~4 (tuy nhiên, nhãn Punycode bắt đầu bằng xn-- là ngoại lệ)
  • Mỗi nhãn tối đa 63 ký tự, toàn bộ tên miền tối đa 253 ký tự, và toàn bộ địa chỉ email (addr-spec) tối đa 254 ký tự

• Tên miền phụ

  • Tên miền có thể có nhiều cấp, và ngoài giới hạn tổng độ dài tên miền là 253 ký tự thì không có giới hạn cứng về độ sâu của tên miền phụ
  • Cách dùng phổ biến: hạ tầng mail (mail., smtp., mx.), tách biệt tổ chức (sales.company.com), gửi qua ESP (email.company.com)

• IP address literal

  • Có thể dùng địa chỉ IP trong dấu ngoặc vuông thay cho tên miền: user@[192.168.1.1], user@[IPv6:2001:db8::1]
  • Hợp lệ theo RFC 5321, nhưng hầu như không được máy chủ mail công khai chấp nhận, và được dùng cho hệ thống mail nội bộ và kiểm thử SMTP

• Tên miền nhãn đơn

  • Tên miền không có dấu chấm (ví dụ: user@localhost) về mặt kỹ thuật là hợp lệ trong một số ngữ cảnh, nhưng máy chủ mail công khai sẽ từ chối
  • postmaster@localhost là trường hợp đặc biệt theo thông lệ của mail hệ thống cục bộ trên các hệ thống kiểu Unix

• Tên miền quốc tế hóa (IDN) và Punycode

  • Vì DNS chỉ hỗ trợ ASCII, các ký tự không phải ASCII sẽ được mã hóa bằng Punycode (RFC 3492), và mọi nhãn đã mã hóa đều bắt đầu bằng tiền tố xn--
  • Ứng dụng email hiển thị bằng chữ viết gốc, còn SMTP truyền dưới dạng Punycode
  • Tấn công homograph: có thể đăng ký tên miền giống với một tên miền nổi tiếng bằng các ký tự trông giống hệt từ những bộ chữ Unicode khác. Trình duyệt có cơ chế phòng vệ hiển thị Punycode với IDN đáng ngờ, nhưng đa số ứng dụng email không có cơ chế này, khiến hình thức tấn công này hiệu quả hơn trong email

• Dấu chấm cuối (Trailing Dot)

  • Trong DNS, mọi tên miền về mặt kỹ thuật đều kết thúc bằng dấu chấm cuối biểu thị root zone, nhưng trong email điều này luôn được ngầm hiểu và bị lược bỏ
  • Hầu hết trình kiểm tra tính hợp lệ sẽ từ chối dạng [e-mail].

• Bản ghi MX

  • Tên miền của địa chỉ email không nhất thiết là nơi đặt máy chủ mail; máy chủ gửi sẽ tra cứu bản ghi DNS MX (Mail Exchanger) để xác định hostname của máy chủ mail thực tế
  • Số ưu tiên thấp hơn đồng nghĩa với mức ưu tiên cao hơn, và nếu hoàn toàn không có bản ghi MX thì sẽ fallback sang bản ghi A của tên miền
  • Nếu một tên miền tuyệt đối không nên nhận email, có thể công bố bản ghi null MX (MX 0 .) để thông báo rõ cho máy chủ gửi rằng không nên thử chuyển phát (RFC 7505)

Tên miền cấp cao nhất (TLD)

• gTLD nguyên thủy

  • 7 gTLD đầu tiên của Internet: .com (thương mại, hiện không hạn chế, do Verisign vận hành), .net (mạng, không hạn chế), .org (tổ chức, không hạn chế), .edu (cơ sở giáo dục được công nhận tại Mỹ, có hạn chế), .gov (chính phủ Mỹ, có hạn chế), .mil (quân đội Mỹ, có hạn chế), .int (tổ chức quốc tế theo hiệp ước, bị hạn chế rất chặt)
  • .arpa là TLD hạ tầng do IANA quản lý, được dùng trong tra cứu DNS ngược

• TLD mã quốc gia (ccTLD)

  • Mã 2 ký tự dựa trên mã quốc gia ISO 3166-1 alpha-2, có khoảng 250 mã
  • Một số ccTLD đã được tái định vị mục đích sử dụng bởi các ngành khác:
    • .io (Lãnh thổ Ấn Độ Dương thuộc Anh → công ty công nghệ), .tv (Tuvalu → truyền thông·streaming), .ai (Anguilla → công ty AI), .co (Colombia → lựa chọn thay thế cho .com), .me (Montenegro → website cá nhân), .ly (Libya → rút gọn URL), .sh (Saint Helena → dự án phần mềm)
  • Khi dùng ccTLD đã được tái định vị, về mặt kỹ thuật bạn vẫn chịu thẩm quyền của registry quốc gia đó, và tên miền do registry của quốc gia gốc kiểm soát chứ không phải ICANN

• TLD được bảo trợ (sTLD)

  • Các TLD có tổ chức bảo trợ và yêu cầu điều kiện đủ tư cách: .aero (vận tải hàng không, do SITA bảo trợ), .coop (hợp tác xã), .museum (bảo tàng), .jobs (việc làm), .xxx (người lớn), .post (bưu chính), .cat (ngôn ngữ·văn hóa Catalan)

• gTLD mới (từ sau năm 2012)

  • Năm 2012, ICANN mở nhận hồ sơ cho gTLD mới và đã ủy quyền hơn 1.200 TLD mới
  • Tác động quan trọng với việc kiểm tra tính hợp lệ email: các trình kiểm tra giới hạn độ dài TLD ở 4~6 ký tự sẽ bị lỗi (.photography, .international, .construction v.v.)
  • Liên quan đến lập trình viên: .app, .dev, .web, .code / thương mại: .shop, .store, .online / nội dung: .blog, .news, .media / doanh nghiệp: .tech, .agency, .cloud
  • Các gTLD mới bị đại diện quá mức trong spam và phishing do chi phí đăng ký thấp và chính sách chống lạm dụng lỏng lẻo của một số registry

• TLD thương hiệu

  • Trong đợt mở rộng của ICANN năm 2012, các tập đoàn lớn đã đăng ký TLD riêng: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
  • Phần lớn không được dùng làm địa chỉ email công khai, mà chủ yếu phục vụ mục đích nội bộ hoặc hoàn toàn không dùng

• TLD địa lý·thành phố

  • Các thành phố và khu vực có TLD riêng: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
  • Khi đăng ký thường cần chứng minh mối liên hệ với khu vực tương ứng

• TLD quốc tế hóa

  • Nhiều quốc gia có TLD dùng bộ chữ không phải ASCII, và trong DNS chúng được mã hóa bằng Punycode
    • .xn--p1ai (Nga, chữ Kirin), .xn--fiqz9s (Trung Quốc, chữ Hán giản thể), .xn--mgberp4a5d4ar (Saudi Arabia, chữ Ả Rập), .xn--h2brj9c (Ấn Độ, chữ Devanagari)

• TLD dành riêng·tài liệu hóa

  • Các TLD được RFC 2606, RFC 6761 dành riêng cho kiểm thử và tài liệu hóa:
    • .test (không bao giờ tồn tại trong DNS công khai nên an toàn cho kiểm thử phần mềm), .example (cho ví dụ trong tài liệu), .invalid (khi cần tên miền chắc chắn không phân giải được), .localhost (cho loopback)
  • IANA đã đăng ký example.com, example.net, example.org cho tài liệu và ví dụ, nên có thể thoải mái dùng trong ví dụ code mà không lo email đi tới hộp thư thật

• TLD đã bị loại bỏ

  • Các ccTLD bị gỡ bỏ do quốc gia không còn tồn tại: .yu (Nam Tư, xóa năm 2010), .cs (Tiệp Khắc, xóa năm 1995), .dd (Đông Đức, xóa năm 1990), .tp (Đông Timor, bị thay bằng .tl rồi bị xóa hoàn toàn năm 2015)
  • Ngoại lệ: .su (Liên Xô) vẫn còn tên miền đang hoạt động dù liên bang đã tan rã từ năm 1991; IANA đã thảo luận việc chuyển đổi trong nhiều năm nhưng nó vẫn ở trạng thái hoạt động

Miền cấp hai của ccTLD

• Nhiều ccTLD thêm các danh mục cấp hai mang tính chức năng giữa tên có thể đăng ký và TLD
  • Vương quốc Anh: .co.uk, .org.uk, .gov.uk / Úc: .com.au, .edu.au / Nhật Bản: .co.jp, .ac.jp / Ấn Độ: .co.in, .gov.in / Brazil: .com.br, .gov.br
• Ảnh hưởng đến việc kiểm tra tính hợp lệ và phát hiện miền tổ chức trong các hệ thống xác thực email khi cần tìm miền tổ chức

• Public Suffix List (PSL)

  • Danh sách do cộng đồng duy trì tại publicsuffix.org, liệt kê mọi hậu tố miền mà người dùng Internet có thể trực tiếp đăng ký tên
  • Bao gồm cả các ủy quyền chính thức (.co.uk, .com.au) và các registry tư nhân (github.io, wordpress.com, herokuapp.com)
  • Sử dụng ký pháp wildcard (ví dụ: *.ck), ngoại lệ được đánh dấu bằng ! (ví dụ: !www.ck)
  • Được trình kiểm tra tính hợp lệ email và bộ lọc spam dùng để xác định miền tổ chức từ toàn bộ chuỗi tên miền
  • Không phải tiêu chuẩn IETF nhưng là tiêu chuẩn thực tế (de facto standard) cho vấn đề này

Định dạng địa chỉ email

• Địa chỉ cơ bản (Bare Address)

  • addr-spec ở dạng local@domain, được dùng trong lệnh SMTP và các ngữ cảnh đơn giản

• Định dạng dấu ngoặc nhọn

  • Trong SMTP, địa chỉ trong lệnh MAIL FROM và RCPT TO được bọc bằng dấu ngoặc nhọn: MAIL FROM:<[e-mail]>
  • Dấu ngoặc nhọn là một phần của cú pháp lệnh SMTP, không phải một phần của chính địa chỉ

• Định dạng tên hiển thị (Display Name Format)

  • Trong header thư (From, To, Cc), tên mà con người có thể đọc được có thể đứng trước địa chỉ trong ngoặc nhọn: "John Doe" <[e-mail]>
  • Nếu tên hiển thị chứa ký tự đặc biệt thì bắt buộc phải dùng dấu ngoặc kép
  • Giả mạo tên hiển thị: người gửi có thể đặt tên hiển thị tùy ý, nên có thể tấn công theo dạng "PayPal Security <[e-mail]>" <[e-mail]>
    • Nhiều ứng dụng email chỉ hiển thị tên hiển thị trong danh sách hộp thư đến, nên đây là một trong những kỹ thuật phishing phổ biến nhất

• Cú pháp nhóm (Group Syntax)

  • Định dạng nhóm có tên cho nhiều người nhận, được định nghĩa trong RFC 5322: Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • Mẫu người nhận ẩn danh: To: undisclosed-recipients:; — cú pháp nhóm rỗng, trong đó người nhận thực tế nằm trong phong bì SMTP (RCPT TO) và không hiển thị trong header thư

• Tên hiển thị được mã hóa

  • Trong các hệ thống email cũ, ký tự không phải ASCII trong tên hiển thị được xử lý bằng encoded-word RFC 2047: =?charset?encoding?encoded_text?=
  • Kiểu mã hóa là B (base64) hoặc Q (quoted-printable)
  • Với hỗ trợ SMTPUTF8 hiện đại, có thể dùng trực tiếp UTF-8 trong header mà không cần lớp bọc mã hóa này

Hai người gửi của mọi email

• Người gửi phong bì (Envelope Sender / MAIL FROM)

  • Được thiết lập trong lệnh SMTP MAIL FROM:, và không phải là một phần của chính nội dung thư
  • Được dùng cho định tuyến bounce, là đối tượng được kiểm tra trong SPF, và được máy chủ nhận cuối cùng lưu vào header Return-Path:
  • Còn được gọi là envelope from, reverse path, hoặc RFC5321.MailFrom

• Header From

  • Là địa chỉ trong header From: của thư, tức thứ mà ứng dụng email hiển thị là người gửi
  • Là đối tượng được DMARC bảo vệ cùng với sự căn chỉnh SPF hoặc DKIM
  • Người gửi có thể tự do thiết lập và trên đa số máy chủ thư không có xác minh riêng biệt
  • Hai địa chỉ này có thể hoàn toàn khác nhau, và đây là kịch bản bình thường, được dự kiến trước:
    • Khi ESP gửi hàng loạt, MAIL FROM có thể là [e-mail], còn header From là [e-mail]
    • Trong mailing list, MAIL FROM là địa chỉ bounce của danh sách, còn header From là người đăng ban đầu
    • Khi chuyển tiếp email, máy chủ chuyển tiếp có thể viết lại MAIL FROM bằng SRS nhưng vẫn giữ nguyên header From của người gửi gốc
  • Nếu miền không áp dụng DMARC, bất kỳ ai cũng có thể gửi thư đặt miền đó vào header From trong khi dùng một MAIL FROM hoàn toàn không liên quan

• Header Sender

  • Xác định người gửi thực tế khi người nộp thư thực tế khác với địa chỉ From: Sender: [e-mail]

• Header Reply-To

  • Chỉ định nơi phản hồi cần được gửi tới và có thể khác với địa chỉ From
  • Cũng có thể bị lạm dụng làm vector phishing: kẻ tấn công làm cho From trông hợp lệ rồi đặt Reply-To thành địa chỉ của chính chúng

• Null Sender

  • MAIL FROM:<> là một cấu trúc SMTP hợp lệ và quan trọng; người gửi phong bì rỗng được dùng cho thư bounce, thư trả lời tự động, và các thư không được tự tạo bounce mới
  • Ngăn vòng lặp bounce vô hạn khi hai hệ thống liên tục trao đổi thông báo lỗi

Địa chỉ dựa trên vai trò (Role-Based Addresses)

• Bắt buộc theo RFC 5321

  • postmaster@domain: theo RFC 5321, mọi miền chấp nhận thư đều bắt buộc phải chấp nhận thư gửi tới địa chỉ này, không có ngoại lệ

• Được khuyến nghị theo RFC 2142

  • abuse@domain (báo cáo spam/lạm dụng), hostmaster@domain (quản lý DNS zone), security@domain (công bố lỗ hổng/báo cáo bảo mật), webmaster@domain (vấn đề máy chủ web), noc@domain (vận hành mạng)

• Địa chỉ vai trò theo thông lệ

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ v.v. không phải tiêu chuẩn chính thức nhưng được sử dụng rộng rãi
  • Các địa chỉ vai trò thường được nhiều người cùng dùng chung, nên khi gửi thông tin nhạy cảm cần lưu ý nhiều thành viên trong nhóm có thể xem được
  • abuse@ và postmaster@ nhận thư khiếu nại nên là mục tiêu của social engineering

• Địa chỉ catch-all (Catch-All Addresses)

  • Không phải một định dạng địa chỉ email cụ thể mà là cấu hình máy chủ thư chấp nhận chuyển phát cả với local-part không có mailbox cụ thể
  • Trường hợp sử dụng: bắt lỗi gõ sai, kiểm thử cho lập trình viên, tạo địa chỉ riêng cho từng dịch vụ mà không cần hệ thống alias chính thức
  • Nhược điểm: vì local-part nào cũng được chuyển phát nên dễ nhận lượng lớn spam, đồng thời không thể xác thực tính tồn tại của địa chỉ bằng SMTP probing (mọi probe đều nhận phản hồi thành công)

Hành vi riêng theo từng nhà cung cấp

• Gmail

  • Chuẩn hóa dấu chấm: bỏ qua mọi dấu chấm trong local part
  • Định địa chỉ bằng dấu cộng: hỗ trợ dấu phân tách +
  • @googlemail.com: bí danh lịch sử của @gmail.com do tranh chấp thương hiệu tại Đức và Anh; cả hai tên miền đều chuyển về cùng một hộp thư
  • Giới hạn ký tự: chỉ cho phép chữ cái Latin, chữ số và dấu chấm trong local part (bao gồm + cho định địa chỉ bằng dấu cộng). Không hỗ trợ đầy đủ bộ ký tự RFC
  • Giới hạn độ dài local part: chỉ 30 ký tự, thấp hơn nhiều so với mức tối đa 64 ký tự của RFC

• Microsoft (Outlook, Hotmail, Live)

  • Không chuẩn hóa dấu chấm: [e-mail] và [e-mail] là hai hộp thư riêng biệt
  • Bí danh tên miền: @hotmail.com, @live.com, @outlook.com có thể cùng tham chiếu một tài khoản khi cấu hình bí danh
  • Hỗ trợ định địa chỉ bằng dấu cộng

• Apple (iCloud)

  • Bí danh tên miền: @icloud.com, @me.com, @mac.com cùng về một hộp thư (lịch sử đổi tên dịch vụ từ .mac → .me → .icloud)
  • Hỗ trợ định địa chỉ bằng dấu cộng
  • Hide My Email: tạo bí danh ngẫu nhiên dạng [e-mail], giữ kín địa chỉ thật bằng bí danh riêng cho từng dịch vụ hoặc ứng dụng

• ProtonMail / Proton

  • Bí danh tên miền: @proton.me, @protonmail.com, @pm.me cùng về một hộp thư
  • Hỗ trợ định địa chỉ bằng dấu cộng

• Dịch vụ bí danh email

  • Khác với email dùng một lần, đây là các dịch vụ tạo địa chỉ chuyển tiếp lâu dài và có thể kiểm soát:
    • SimpleLogin (thuộc Proton): chuyển tiếp đến bất kỳ hộp thư nào bằng bí danh tùy chỉnh hoặc ngẫu nhiên
    • Addy.io (trước đây là AnonAddy): tương tự SimpleLogin, có thể tự lưu trữ
    • Firefox Relay (Mozilla): bí danh ngẫu nhiên giới hạn trong gói miễn phí
    • DuckDuckGo Email Protection: bí danh @duck.com
  • Tạo ra các địa chỉ mà với người gửi, không thể phân biệt về mặt cấu trúc với hộp thư thật
  • Khác biệt cốt lõi so với email dùng một lần: bí danh là lâu dài và có thể kiểm soát, có thể tắt từng bí danh, xác định dịch vụ nào đã gửi thư, và chuyển tiếp đến hộp thư mong muốn

Email dùng một lần / tạm thời

• Cung cấp hộp thư không cần đăng ký và thường hết hạn sau thời gian ngắn; các dịch vụ tiêu biểu gồm Mailinator, Guerrilla Mail, 10 Minute Mail, TempMail
• Phần lớn dùng định tuyến catch-all, nên bất kỳ local part nào trên tên miền đó cũng được chuyển vào hộp thư
• Nhiều hộp thư là công khai, nên bất kỳ ai biết địa chỉ đều có thể đọc thư
• Có các danh sách chặn tên miền dùng một lần đã biết (kho GitHub disposable-email-domains được tham chiếu nhiều nhất), nhưng luôn không đầy đủ và liên tục đổi sang tên miền mới để né chặn

Kiểm tra tính hợp lệ (Validation)

• Tính hợp lệ kỹ thuật vs tính hợp lệ thực tế

  • Hợp lệ theo RFC nhưng hầu như không được máy chủ thực tế chấp nhận: khoảng trắng trong dấu ngoặc kép(" "@example.com), ký tự @ trong dấu ngoặc kép("user@name"@example.com), tên miền dạng IP literal(user@[192.168.1.1]), một ký tự / một nhãn duy nhất(a@b)
  • Hợp lệ theo RFC và cũng được chấp nhận trong thực tế: [e-mail], [e-mail], [e-mail], [e-mail]
  • Với hầu hết ứng dụng, trình kiểm tra tính hợp lệ mang tính thực dụng tốt hơn trình kiểm tra tuân thủ RFC hoàn toàn: kiểm tra cấu trúc cơ bản, xác minh tập ký tự hợp lý, và tùy chọn truy vấn DNS MX của tên miền

• Các lỗi thường gặp của trình kiểm tra tính hợp lệ

  • Từ chối + trong local part: [e-mail] hoàn toàn hợp lệ; đây là lỗi rất phổ biến
  • Từ chối _ trong local part: cũng hợp lệ
  • Từ chối % trong local part: đây là ký tự hợp lệ; thứ đã bị loại bỏ chỉ là định tuyến percent-hack
  • Giới hạn độ dài TLD ở 4~6 ký tự: chặn hàng trăm gTLD mới như .photography, .international, .construction
  • Xác thực bằng danh sách TLD mã hóa cứng: vì danh sách liên tục thay đổi nên trình kiểm tra sẽ nhanh lỗi thời
  • Giới hạn tổng độ dài sai: dùng 255 hoặc 256 thay vì 254. Errata số 1690 của RFC 3696 đã sửa giá trị 320 thường bị trích dẫn sai thành 254
  • Từ chối chữ hoa trong local part: hợp lệ theo RFC
  • Từ chối [e-mail]: hợp lệ; tên miền nhiều dấu chấm theo mẫu ccTLD cấp hai là bình thường
  • Từ chối .dev, .app, .io làm TLD: tất cả đều là TLD hợp lệ đã được ủy quyền

• Giới hạn độ dài

  Phần	Giới hạn
  Local part	64 octet
  Nhãn tên miền	63 octet
  Toàn bộ tên miền	253 octet
  Toàn bộ địa chỉ (addr-spec)	254 octet

• Giới hạn local part tính theo octet chứ không phải ký tự, nên địa chỉ EAI có ký tự Unicode nhiều byte có thể nhìn dưới 64 ký tự nhưng vẫn chạm giới hạn octet

• Kiểm tra tính hợp lệ dựa trên DNS

  • Kiểm tra bản ghi MX: xác minh tên miền có bản ghi MX hay không; nhanh và ít rủi ro. Các tên miền dùng cơ chế dự phòng sang bản ghi A (không cấu hình MX) có thể trượt kiểm tra này
  • Kiểm tra Null MX: nếu tên miền có MX 0 . thì nó rõ ràng không nhận thư
  • Thăm dò SMTP RCPT TO: kết nối đến máy chủ thư và gửi lệnh RCPT TO để kiểm tra địa chỉ có được chấp nhận hay không, nhưng nhiều máy chủ trả về 250 cho mọi địa chỉ để ngăn thu thập địa chỉ nên không đáng tin cậy. Tên miền catch-all cũng luôn phản hồi tích cực. Ngoài ra còn có nguy cơ IP thăm dò bị đưa vào blacklist
  • Cách duy nhất để xác minh hoàn toàn đáng tin cậy một địa chỉ email là gửi thư thật và xác nhận nó được nhận; mọi cách khác đều chỉ là heuristic

Hàm ý bảo mật

• Giả mạo tên hiển thị

  • Bất kỳ ai cũng có thể đặt tên hiển thị của email tùy ý; trong chế độ xem hộp thư chỉ hiện tên hiển thị, người dùng sẽ không thể phân biệt người gửi hợp pháp với kẻ mạo danh nếu không chủ động kiểm tra địa chỉ thật

• Tấn công homograph qua Punycode

  • Có thể đăng ký tên miền trông giống hệt về mặt thị giác với tên miền nổi tiếng thật bằng cách dùng ký tự từ các bộ chữ Unicode khác nhau
  • Không giống trình duyệt, email client thường không hiển thị cảnh báo cho trường hợp này

• Lách giới hạn tài khoản bằng mẹo dấu chấm của Gmail

  • Vì Gmail bỏ qua dấu chấm, kẻ tấn công có thể đăng ký dịch vụ bằng biến thể có chấm của một địa chỉ Gmail có sẵn để vượt qua giới hạn một tài khoản, nhận trùng ưu đãi dùng thử miễn phí, hoặc nhận email vốn dành cho chủ tài khoản gốc

• Tái sử dụng địa chỉ email

  • Nhà cung cấp email có thể gán lại địa chỉ bị bỏ cho người dùng mới; chủ tài khoản mới có thể nhận email khôi phục tài khoản của các dịch vụ mà chủ cũ từng đăng ký và chiếm đoạt tài khoản bằng cách đặt lại mật khẩu
  • Gmail cho biết họ không gán lại địa chỉ, nhưng một số nhà cung cấp khác trong lịch sử từng có trường hợp gán lại

• Lộ thẻ subaddress

  • Nếu đăng ký bằng [e-mail], dịch vụ nhận sẽ thấy toàn bộ địa chỉ bao gồm cả thẻ
  • Dịch vụ xóa dấu cộng và lưu lại sẽ làm lộ địa chỉ gốc; dịch vụ lưu nguyên địa chỉ đầy đủ sẽ làm lộ chiến lược theo dõi trong phần cài đặt tài khoản hoặc dữ liệu xuất ra