RFC 4954: Phần mở rộng SMTP AUTH

Standards Track Email Authentication Published March 2026

ELI5: Hãy tưởng tượng một bưu điện nơi bất cứ ai cũng có thể bước vào và gửi thư, tuyên bố là từ bất cứ ai. Hỗn loạn, phải không? SMTP AUTH là kiểm tra CMND tại quầy. Trước khi bạn gửi thư, bạn phải chứng minh danh tính của mình — tên người dùng, mật khẩu, tất cả. Chỉ sau khi nhân viên xác minh danh tính của bạn, bạn mới có thể gửi tin nhắn. Nếu không có AUTH, SMTP là cánh cửa mở cho sự lạm dụng.

Tại Sao Điều Này Tồn Tại

SMTP gốc (RFC 5321) không có khái niệm xác thực người gửi. Bất kỳ khách hàng nào cũng có thể kết nối với bất kỳ máy chủ nào và gửi thư như bất kỳ người nào. Thiết kế này hoạt động trong internet sớm nơi tất cả những người tham gia đều được tin tưởng, nhưng nó trở thành nền tảng của vấn đề thư rác.

RFC 4954 định nghĩa tiện ích AUTH cho SMTP, cung cấp một cách tiêu chuẩn để khách hàng xác thực với máy chủ thư trước khi gửi thư. Nó sử dụng khung SASL (Simple Authentication and Security Layer), cho phép nhiều cơ chế xác thực được kết nối mà không thay đổi bản thân giao thức SMTP.

RFC này thay thế RFC 2554 (1999), khắc phục các lỗi bảo mật và làm rõ tương tác giữa AUTH và các tiện ích SMTP khác như STARTTLS.

Cách Hoạt Động

Thương Lượng AUTH

Khách hàng kết nối và phát hành EHLO.
Máy chủ quảng cáo 250-AUTH theo sau là danh sách các cơ chế SASL được hỗ trợ.
Khách hàng chọn một cơ chế và gửi AUTH <mechanism>, tùy chọn có phản hồi ban đầu.
Máy chủ và khách hàng trao đổi một hoặc nhiều vòng thử thách/phản hồi (phụ thuộc cơ chế).
Máy chủ phản hồi với 235 (xác thực thành công) hoặc 535 (xác thực thất bại).

Bảng Ghi Dấu SMTP: AUTH PLAIN

Cơ chế PLAIN gửi thông tin đăng nhập trong một chuỗi được mã hóa Base64 chứa danh tính ủy quyền, danh tính xác thực và mật khẩu:

# Kết nối và khám phá khả năng S: 220 smtp.mailertogo.com ESMTP C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN XOAUTH2 S: 250-SIZE 26214400 S: 250 ENHANCEDSTATUSCODES # Nâng cấp lên TLS trước (luôn trước AUTH) C: STARTTLS S: 220 2.0.0 Ready to start TLS # ... Bắt tay TLS ... yêu cầu EHLO lại C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-AUTH PLAIN LOGIN XOAUTH2 S: 250 ENHANCEDSTATUSCODES # Xác thực với AUTH PLAIN # Base64 của "\0alice@example.com\0secretpassword" C: AUTH PLAIN AGFsaWNlQGV4YW1wbGUuY29tAHNlY3JldHBhc3N3b3Jk S: 235 2.7.0 Authentication successful # Bây giờ được phép gửi thư C: MAIL FROM:<alice@example.com> S: 250 2.1.0 OK

Bảng Ghi Dấu SMTP: AUTH LOGIN

Cơ chế LOGIN sử dụng thử thách/phản hồi riêng biệt cho tên người dùng và mật khẩu:

C: AUTH LOGIN S: 334 VXNlcm5hbWU6 ← Base64 của "Username:" C: YWxpY2VAZXhhbXBsZS5jb20= ← Base64 của "alice@example.com" S: 334 UGFzc3dvcmQ6 ← Base64 của "Password:" C: c2VjcmV0cGFzc3dvcmQ= ← Base64 của "secretpassword" S: 235 2.7.0 Authentication successful

Bảng Ghi Dấu SMTP: AUTH Thất Bại

C: AUTH PLAIN AGJhZEBleGFtcGxlLmNvbQB3cm9uZw== S: 535 5.7.8 Authentication credentials invalid # Khách hàng KHÔNG ĐƯỢC phép cố gắng gửi thư sau lỗi 535

Chi Tiết Kỹ Thuật Chính

Cơ Chế SASL

RFC 4954 không định nghĩa cơ chế xác thực trực tiếp. Nó cung cấp khung; cơ chế đến từ sổ đăng ký SASL. Các cơ chế được sử dụng phổ biến nhất trong SMTP:

Cơ Chế	Cách Hoạt Động	Ghi Chú Bảo Mật
`PLAIN`	Chuỗi Base64 duy nhất: `\0authzid\0password`	Đơn giản, được hỗ trợ rộng rãi. Chỉ được sử dụng qua TLS.
`LOGIN`	Thử thách/phản hồi hai bước cho tên người dùng và mật khẩu	Không tiêu chuẩn nhưng phổ biến. Chỉ được sử dụng qua TLS.
`XOAUTH2`	Token OAuth 2.0 bearer trong một chuỗi định dạng	Không truyền mật khẩu. Dựa trên token, được sử dụng bởi Gmail và Microsoft 365.
`SCRAM-SHA-256`	Thử thách/phản hồi muối với liên kết kênh	Mật khẩu không bao giờ được gửi, ngay cả khi băm. Xác thực lẫn nhau. Bảo mật tốt nhất nhưng chấp nhận hạn chế trong SMTP.
`CRAM-MD5`	Thử thách/phản hồi với HMAC MD5	Đã bỏ dùng. MD5 được coi là yếu. Tránh gửi mật khẩu nhưng không bảo vệ chống tấn công phát lại.

Định Dạng Thông Tin Đăng Nhập AUTH PLAIN

Cơ chế PLAIN mã hóa ba trường được phân tách bằng byte null (\0), sau đó mã hóa Base64 kết quả:

# Định dạng: [authzid] \0 authcid \0 password # authzid = danh tính ủy quyền (thường trống hoặc giống authcid) # authcid = danh tính xác thực (tên người dùng) # password = mật khẩu văn bản rõ # Ví dụ: authzid trống, authcid "alice@example.com", password "s3cret" \0alice@example.com\0s3cret # Mã hóa Base64: AGFsaWNlQGV4YW1wbGUuY29tAHMzY3JldA==

Tối Ưu Hóa Phản Hồi Ban Đầu

RFC 4954 cho phép khách hàng gửi phản hồi SASL ban đầu trên cùng một dòng với lệnh AUTH (như được hiển thị trong ví dụ PLAIN ở trên). Điều này tiết kiệm một lượt so với phương pháp hai bước cũ hơn nơi máy chủ trước tiên gửi một thử thách trống. Đối với các cơ chế như PLAIN nơi khách hàng nói trước, tối ưu hóa này là tiêu chuẩn.

Tương Tác Với STARTTLS

RFC 4954 mạnh mẽ khuyến nghị rằng máy chủ không quảng cáo AUTH cho đến sau khi TLS được thiết lập. Điều này ngăn chặn khách hàng vô tình gửi thông tin xác thực dưới dạng văn bản rõ. Luồng điển hình là:

Kết nối → EHLO → máy chủ quảng cáo STARTTLS nhưng không AUTH
STARTTLS → Bắt tay TLS
EHLO lại → máy chủ bây giờ quảng cáo AUTH (STARTTLS không còn được liệt kê)
AUTH → gửi thư

Mã Phản Hồi

Mã	Ý Nghĩa
`235`	Xác thực thành công
`334`	Thử thách máy chủ (tiếp tục trao đổi SASL)
`432`	Cần chuyển đổi mật khẩu (máy chủ yêu cầu thay đổi mật khẩu)
`454`	Lỗi xác thực tạm thời (thử lại sau)
`500`	Lệnh AUTH không được công nhận (máy chủ không hỗ trợ AUTH)
`534`	Cơ chế xác thực quá yếu (máy chủ yêu cầu cơ chế mạnh hơn)
`535`	Thông tin xác thực không hợp lệ

AUTH và Danh Tính MAIL FROM

Sau khi xác thực thành công, máy chủ liên kết kết nối với danh tính đã xác thực. MSA sau đó có thể thực thi rằng các địa chỉ MAIL FROM và tiêu đề From: phù hợp (hoặc được ủy quyền cho) người dùng đã xác thực. Điều này ngăn chặn người dùng đã xác thực từ giả mạo các địa chỉ người gửi tùy ý.

Những Lỗi Phổ Biến

Gửi AUTH trước STARTTLS. Nếu máy chủ quảng cáo AUTH trên kết nối văn bản rõ (một số máy chủ sai cấu hình làm như vậy), thông tin xác thực của bạn vẫn truyền dưới dạng văn bản rõ. Luôn thiết lập TLS trước khi xác thực. Với TLS ngầm trên cổng 465, điều này là tự động.
Nhầm lẫn mã hóa Base64 với mã hóa. Base64 là một mã hóa, không phải mã hóa. AUTH PLAIN gửi thông tin xác thực trong một định dạng dễ dàng giải mã. Sự bảo vệ đến từ lớp TLS, không phải từ Base64.
Không xử lý lỗi 535. AUTH thất bại có nghĩa là máy chủ đã từ chối thông tin xác thực của bạn. Thử lại cùng một thông tin xác thực trong một vòng lặp sẽ khiến IP của bạn bị giới hạn tốc độ hoặc bị chặn. Kiểm tra thông tin xác thực và thất bại một cách duyên dáng.
Mã hóa cứng AUTH LOGIN khi PLAIN có sẵn. LOGIN là một cơ chế không tiêu chuẩn với các triển khai không nhất quán. Nếu máy chủ hỗ trợ PLAIN, hãy ưu tiên nó. Nếu nó hỗ trợ XOAUTH2 hoặc SCRAM, hãy ưu tiên những cơ chế đó.
Không phát hành lại EHLO sau STARTTLS. Danh sách khả năng thay đổi sau khi TLS được thiết lập. AUTH chỉ có thể xuất hiện trong phản hồi EHLO sau TLS. Bỏ qua EHLO thứ hai có nghĩa là khách hàng của bạn không bao giờ khám phá hỗ trợ AUTH.
Bỏ qua tối ưu hóa phản hồi ban đầu. Gửi AUTH PLAIN mà không có thông tin xác thực nội tuyến sẽ buộc một lượt bổ sung không cần thiết. Hầu hết các máy chủ hiện đại hỗ trợ phản hồi ban đầu.
Sử dụng CRAM-MD5 cho "bảo mật". CRAM-MD5 tránh gửi mật khẩu văn bản rõ, nhưng nó sử dụng MD5 (bị phá vỡ), không bảo vệ chống tấn công phát lại và yêu cầu máy chủ lưu trữ mật khẩu dưới dạng có thể khôi phục. PLAIN qua TLS hoàn toàn vượt trội.

Tác Động Khả Năng Gửi Thư

Yêu cầu cho việc gửi thư. Mỗi dịch vụ email hiện đại yêu cầu SMTP AUTH để gửi (RFC 6409). Nếu không xác thực, máy chủ sẽ từ chối thư của bạn bằng phản hồi 530 (yêu cầu xác thực).
Cho phép ràng buộc danh tính người gửi. Xác thực liên kết mỗi thư với một tài khoản đã biết. Điều này cho phép dịch vụ email thực thi các chính sách gửi, áp dụng chữ ký DKIM và theo dõi danh tiếng cho mỗi người gửi đã xác thực.
Ngăn chặn lạm dụng tiếp chuyển mở. Bằng cách yêu cầu xác thực trước khi chấp nhận thư để gửi, máy chủ tránh được khai thác như các tiếp chuyển mở — điều này sẽ nhanh chóng dẫn đến danh sách đen IP và lỗi gửi cho tất cả người dùng trên máy chủ.
OAuth2 cho các tích hợp hiện đại. Các dịch vụ như Gmail và Microsoft 365 đang từ bỏ xác thực dựa trên mật khẩu để ủng hộ XOAUTH2. Chuyển sang xác thực dựa trên token tránh gián đoạn dịch vụ khi xác thực cơ bản bị vô hiệu hóa.
Giới hạn tốc độ và phòng ngừa lạm dụng. Các phiên được xác thực cho phép giới hạn tốc độ cho mỗi người dùng. Nếu một tài khoản bị xâm phạm, dịch vụ có thể điều tiết hoặc vô hiệu hóa tài khoản đó mà không ảnh hưởng đến những người gửi khác trên cơ sở hạ tầng tương tự.