Trước tiên, bạn dùng mail user agent (MUA) để đọc và gửi email từ thiết bị (Gmail, Mail app trên Apple). Các chương trình này chỉ hoạt động khi bạn dùng chúng.
Thông thường, chúng giao tiếp với mail transfer agent (MTA) (còn gọi mail server, MX host, mail exchanger), dùng để nhận và lưu trữ email.
Email được lưu trữ từ xa cho đến khi bạn mở MUA để check email. Email được delivered bởi mail delivery agents (MDA), thường đi kèm MTA.
Email dùng được gửi đến mail server bằng SMTP (Simple Mail Transfer Protocol). SMTP là communication protocol cho email.
Dù nhiều proprietary systems như Microsoft Exchange và webmail như Gmail dùng protocols riêng nội bộ, chúng dùng SMTP để transfer messages ra ngoài hệ thống (ví dụ: user Gmail gửi email đến Outlook client).
Mail sau đó download từ server dùng Post Office Protocol (POP3). POP3 là application-layer protocol cung cấp truy cập qua IP network cho user application contact mailbox trên mail server. Có thể connect, retrieve messages, lưu trên máy client, xóa hoặc retain trên server.
Được thiết kế quản lý temporary internet connections như dial-up (chỉ connect và retrieve email khi connected, cho phép xem messages khi offline). Phổ biến khi dial-up phổ biến.
Giờ, IMAP (Internet Message Access Protocol) thay thế POP3. IMAP cho phép multiple clients manage cùng mailbox (đọc email từ desktop, laptop, phone... mọi messages đều có, organized cùng cách).
Cuối cùng, webmail thay thế cả hai. Webmail cho phép login website nhận messages từ bất kỳ đâu/thiết bị nào (tuyệt!), nhưng cần internet khi dùng. Nếu website (như Gmail) là MUA, không cần biết SMTP/IMAP server settings.
Email được bảo mật như thế nào?
Thật đáng tiếc, security không được built vào mail protocols từ đầu (như hầu hết early internet protocols). Server chỉ kỳ vọng lấy message từ bất kỳ ai và pass along đến server khác route message đến destination cuối (recipient trong to: field).
Không ngạc nhiên, đây thành vấn đề khi internet mở rộng từ vài nhóm government/research thành thứ hầu hết thế giới dùng làm mọi thứ. Sớm spam và phishing emails thành (và vẫn là) vấn đề lớn.
Phản ứng, chúng ta tập thể implement các biện pháp ngăn chặn đọc tin nhắn người khác (encryption) và validate messages thực sự từ purported sender (authentication).
Hầu hết dùng TLS (transport layer security, thay thế SSL), cryptographic protocol cung cấp encryption in transit. Bảo vệ khi message đang transmitted, không phải khi data at rest (ví dụ: stored trên máy tính).
Đảm bảo message không bị altered hoặc snooped khi traveling từ MTA đến MTA. Tuy nhiên, không verify message không bị modified trong chuyến đi.
Ví dụ: email qua multiple mail servers trước khi đến destination, TLS đảm bảo encrypted giữa các server, nhưng mỗi server có thể alter message content. Để giải quyết, tạo SPF, DKIM, DMARC.
SPF (Sender Policy Framework)
SPF cho phép owner của domain (như google.com) set TXT record trong DNS khai báo servers được phép gửi mail từ domain đó (xem hướng dẫn cho các hosting providers tại đây).
Cách hoạt động?
Record liệt kê devices (thường bằng IP) được phép và kết thúc bằng một trong các option:
-all= Nếu check fail (source email không phải listed devices) → HardFail. Hầu hết mail systems mark spam.?all= Fail → neutral. Dùng cho testing, không phải production domains.~all= Fail → SoftFail. Message suspicious nhưng không nhất thiết known bad. Một số systems mark spam, hầu hết không.
SPF headers hữu ích cho servers khi processing messages. Ví dụ server ở edge của network biết messages nhận phải từ servers trong SPF record của sender. Giúp servers loại spam nhanh hơn. Tuy nghe hay, SPF có vài vấn đề lớn:
- SPF không bảo mail server làm gì với message - message có thể fail SPF check vẫn delivered.
- SPF record không nhìn 'from' address user thấy, mà 'return-path'. Địa chỉ trả thư tương đương. Nó báo mail servers handle letter nơi trả message (lưu trong email headers - technical info servers dùng process email). Nghĩa là tôi có thể put whatever vào from: address không ảnh hưởng SPF check. Cả hai email addresses đều có thể spoofed bởi hacker. Vì không encryption, SPF headers không fully trusted.
- SPF records cần keep constantly up to date - khó trong large, ever-changing organizations.
- Forwarding breaks SPF. Vì nếu email từ google.com forwarded bởi bob@bobsburgers.com, envelope sender unchanged (from address vẫn google.com). Receiving mail server nghĩ claim từ google.com nhưng coming from bobsburgers.com, fail SPF check (dù mail thực sự từ google.com).
Đọc thêm SPF tại đây. Check domain có SPF/DMARC records tại đây.
DKIM (DomainKeys Identified Mail)
DKIM tương tự SPF. Cũng dùng TXT records trong DNS sending domain, cung cấp authentication của message itself. Cố gắng verify messages không bị altered in transit.
Cách hoạt động?
Sending domain generate public/private key pair, đặt public key trong domain's DNS TXT record (nếu không biết public/private key pair, đọc bài cryptography tại đây).
Sau đó, domain's mail servers (outer boundary - servers gửi mail ngoài domain, ví dụ: gmail.com đến outlook.com) dùng private key generate signature của entire message body, including headers.
Generate signature thường yêu cầu text hashed và encrypted (chi tiết quy trình tại đây).
Receiving mail servers dùng public key trong DNS TXT record decrypt signature, sau đó hash message và relevant headers (headers tạo ra khi mail bên trong sender's infrastructure - ví dụ multiple gmail servers process email trước khi gửi externally đến outlook.com).
Server check two hashes match. Nếu match, message likely unaltered (trừ khi private key bị compromise) và legitimately từ purported sender. Nếu không match, message không từ purported sender, hoặc bị altered bởi server khác in transit, hoặc cả hai.
DKIM làm tốt một task cụ thể: trả lời 'email này có bị altered in transit hoặc không từ purported sender?'. Nhưng chỉ làm vậy. Không bảo làm sao deal với emails fail test, server nào altered, alterations gì.
DKIM cũng dùng bởi một số ISPs (Internet Service Providers) xác định reputation của domain (gửi nhiều spam? Low engagement? Bounce rate bao nhiêu?).
Đọc thêm DKIM tại đây. Validate DKIM record tại đây.
DMARC (Domain-Based Message Authentication, Reporting, and Conformance)
DMARC về cơ bản là instructions cho mail servers cách handle SPF và DKIM records. Không tự perform tests, nhưng bảo mail servers cách handle checks SPF/DKIM perform.
Participating ISPs xem published DMARC records và dùng để determine cách deal với DKIM/SPF fails. Ví dụ: brand bị spoofed thường publish DMARC record nói nếu DKIM/SPF fail, drop message.
Thường ISPs cũng gửi reports về domain activity cho bạn với source email và passed/failed DKIM/SPF. Nghĩa là bạn thấy khi nào người spoof (giả mạo gửi từ) domain bạn hoặc alter messages.
Để implement DMARC, tạo DMARC record dựa trên needs (từ monitoring email traffic tìm all email sources đến yêu cầu actions như reject emails fail DKIM/SPF). Học thêm tại đây và tại đây.
Đọc thêm DMARC tại đây. Check domain có SPF/DMARC records tại đây.
Tóm lại
Không biện pháp bảo mật nào hoàn hảo, nhưng cùng nhau, chúng làm việc khá tốt giúp cải thiện bảo mật email systems worldwide.
Càng nhiều organizations adopt các biện pháp này (dùng open source implementations hoặc trả tiền product) càng tốt cho mọi người.
Security thêm sau khi protocol/product developed thường tốn kém hơn, kém hiệu quả, khó implement hơn security built into product.
Tuy nhiên, hầu hết protocols internet hiện tại rely upon được thiết kế cho early internet - small group enthusiasts, scientists, government - không phải worldwide network chạy buildings, smart devices, public transit, nuclear plants(!), v.v.
Vì vậy,随着 internet mở rộng, cần tiếp tục adapt và develop mới ways để secure systems we rely upon.