Xác thực địa chỉ email: regex chứng minh được gì, và không

Bốn câu hỏi dùng chung một từ

“Đây có phải là một địa chỉ email hợp lệ không?” không phải là một câu hỏi. Đó là bốn câu hỏi, chúng khó dần theo thứ tự, và câu cuối cùng là câu duy nhất mà thực ra ai cũng muốn có câu trả lời — đó là lý do vì sao rất nhiều đoạn mã xác thực cầu kỳ ở câu đầu tiên và im lặng về những câu còn lại.

Đây là bốn câu hỏi đó, theo đúng thứ tự mà một biểu mẫu đăng ký gặp phải.

Nó có hình dạng của một địa chỉ không?

Một bước kiểm tra cú pháp. Nó chạy trong trình duyệt, không tốn gì cả, và bắt được dấu phẩy gõ nhầm cùng dấu @ bị thiếu. Đây là tầng duy nhất có thể tự mình từ chối bất cứ điều gì một cách chính đáng — và ngay cả khi đó, nó cũng nên từ chối ít hơn nhiều so với phần lớn các mẫu vẫn làm.

Tên miền đó có thể nhận thư hay không?

Một bước kiểm tra DNS. Một truy vấn duy nhất cho biết liệu có bất cứ thứ gì, ở bất cứ đâu, sẵn sàng nhận thư cho phần đứng sau dấu @ hay không. Nó bắt được một tên miền thiếu mất một chữ cái và một tên miền đã hết hạn từ năm ngoái, nhưng không thể nói cho bạn biết bất cứ điều gì về hộp thư.

Hộp thư đó có tồn tại không?

Một bước kiểm tra SMTP — và là bước mà hướng dẫn này sẽ dành nhiều thời gian nhất để khuyên bạn đừng tin. Bạn có thể hỏi. Câu trả lời thường là một lời đồng ý lịch sự từ một máy chủ chấp nhận mọi cái tên, hoặc một thất bại tạm thời có chủ đích, hoặc một sự chấp nhận rồi theo sau bởi một bounce vài phút sau đó.

Đó có phải địa chỉ của chính họ không?

Không có gì về mặt kỹ thuật có thể trả lời được câu này. Một địa chỉ có thể hoàn hảo, gửi đến được, và vẫn là của một người khác — gõ sai một ký tự, hoặc cố tình gõ sai để qua mặt bạn. Chỉ một thư đến nơi và được dùng đến mới khép lại được câu hỏi này.

Ba bước đầu đều rẻ và chứng minh được rất ít. Bước thứ tư là bước duy nhất xứng đáng với cái tên đó, và cũng là bước tốn một lá thư. Mọi thứ dưới đây đều nói về việc dùng ba bước rẻ đó cho khôn ngoan để bước tốn kém kia không bị lãng phí.

Tầng một: mẫu kiểm tra, và bốn điều nó không thể biết

Không có biểu thức chính quy chính thức nào cho địa chỉ email, và không thể có. RFC 5322 định nghĩa một văn phạm chứ không phải một mẫu, và văn phạm đó cho phép chú thích trong ngoặc đơn, khoảng trắng được gấp lại và chuỗi trong dấu ngoặc kép chứa gần như bất kỳ ký tự nào — không điều nào trong số đó nên được một biểu mẫu đăng ký thực sự chấp nhận, còn một mẫu trung thành với văn phạm đó thì buộc phải chấp nhận tất cả.

Thứ thực sự tồn tại là một định nghĩa hẹp hơn một cách có chủ đích mà các trình duyệt đã cài sẵn: định nghĩa mà đặc tả HTML đưa ra cho một trường <input type="email">. Đó là một sự thỏa hiệp có chủ ý chứ không phải một bản sao của chuẩn kỹ thuật, nó là thứ biểu mẫu của bạn đã bị ràng buộc vào ngay cả trước khi một dòng mã nào của bạn chạy, và nó đủ ngắn để đọc hết trong một lần:

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

Hãy dùng mẫu đó, hoặc dùng mẫu mà nền tảng của bạn đã có sẵn. Bốn lựa chọn dưới đây đều thuộc cùng một tầng, và chọn cái nào trong số đó là một quyết định nhỏ hơn nhiều so với điều bạn làm sau đó:

Dù bạn dùng cái nào, điều quan trọng là những gì nó im lặng không nói tới. Một mẫu trả về true đã nói cho bạn đúng một điều, và giữ im lặng về bốn điều còn lại.

Không chứng minh được rằng tên miền tồn tại

Một địa chỉ trên một tên miền chưa từng có ai đăng ký vẫn vượt qua mọi mẫu trong phần này. Không có gì được tra cứu và không có gì được liên hệ; chưa từng có một biểu thức chính quy nào thực hiện một yêu cầu mạng.

Không chứng minh được rằng hộp thư tồn tại

Ngay cả trên một tên miền có thật, mẫu đó cũng không có ý kiến gì về phần đứng trước dấu @. Phần đó chỉ thuộc về máy chủ nhận, và đó chính xác là điều DNS sẽ không bao giờ cho bạn biết.

Không chứng minh được rằng thư sẽ đến được

Một tên miền có thể có bản ghi hoàn hảo và một máy chủ thư đã bị tắt suốt một tháng. Cú pháp là một thuộc tính của một chuỗi ký tự; khả năng gửi đến nơi là một thuộc tính của thế giới thực tại đúng thời điểm bạn nhấn gửi.

Không chứng minh được rằng nó thuộc về người đang gõ nó

Loại địa chỉ xấu phổ biến nhất trong bất kỳ cơ sở dữ liệu nào là một địa chỉ có thật, gửi đến được, nhưng thuộc về một người chưa từng đăng ký — vì một chữ cái đã bị gõ sai, hoặc vì biểu mẫu đã được điền bằng một lời nói dối trông có vẻ hợp lý.

Điều gì hợp lệ, và điều gì bị loại bỏ oan uổng

Phần lớn lỗi xác thực không phải là những địa chỉ xấu lọt được vào. Đó là những người không thể đăng ký được, và họ không bao giờ xuất hiện trong bất kỳ log nào ai đó đọc — biểu mẫu nói không, và họ bỏ đi nơi khác. Sáu trường hợp sau đây là những trường hợp gây ra chuyện đó nhiều nhất.

Và ba con số, đáng để viết thẳng vào mã nguồn của bạn vì chúng không hề thay đổi:

64 ký tự

Độ dài tối đa của phần đứng trước dấu @. Bất cứ thứ gì dài hơn không phải là một địa chỉ dài, mà không phải là một địa chỉ.

255 ký tự

Độ dài tối đa của tên miền, kể cả các dấu chấm. Chưa từng có gì hợp pháp đến gần mức đó, và giới hạn này tồn tại chủ yếu để bạn có một con số để dùng.

254 ký tự

Độ dài tối đa của toàn bộ địa chỉ khi một máy chủ vận chuyển nó — con số này nhỏ hơn tổng của hai con số ở trên cộng lại. Đây là con số nên đặt vào cột trong cơ sở dữ liệu và vào maxlength của trường nhập liệu.

Tầng hai: một lượt tra cứu, và nó giải quyết được điều gì

Phần đứng sau dấu @ là một tên miền, và một tên miền thì hoặc có nơi để đặt thư, hoặc không có. Một truy vấn DNS trả lời điều đó chỉ trong vài mili giây, và đây là bước kiểm tra đáng giá nhất trong toàn bộ hướng dẫn này — vì lỗi mà nó bắt được, một tên miền bị gõ sai đôi chút, bỏ xa mọi loại lỗi thực sự phổ biến khác.

$ dig +short MX example.com

Có câu trả lời nghĩa là đã có một máy chủ được nêu tên. Không có câu trả lời không có nghĩa là không nhận được thư: một tên miền không có bản ghi MX nhưng có bản ghi A vẫn nhận được thư, vì bên gửi sẽ quay sang dùng bản ghi đó. Có bốn kết quả có thể xảy ra, và chỉ hai trong số đó là thất bại.

Nơi bước kiểm tra này thường đi sai không bao giờ là bản thân lượt tra cứu. Mà là vị trí lượt tra cứu đó được đặt vào — trên đường găng, sau mỗi lần gõ phím, với một thất bại chặn luôn cả việc gửi biểu mẫu. Sáu quy tắc sau giữ cho nó luôn hữu ích:

1. Chạy nó khi trường đã được điền xong, không phải trong lúc đang gõ. Một truy vấn khi mất focus, hoặc một truy vấn khi gửi biểu mẫu. Một truy vấn cho mỗi lần gõ phím đúng là một truy vấn cho mỗi lần gõ phím.
2. Chuyển tên miền về chữ thường trước. DNS không quan tâm điều đó, nhưng cache của bạn thì có: hai cách viết của cùng một tên miền chỉ là một truy vấn, không phải hai.
3. Hỏi bản ghi MX trước, rồi dự phòng bằng A. Hai truy vấn, trong đó chỉ truy vấn thứ hai là có điều kiện. Một thư viện chỉ kiểm tra MX mà thôi sẽ từ chối những tên miền vẫn hoạt động tốt.
4. Lưu cache câu trả lời trong vài phút. Chỉ một nhúm tên miền đã chiếm phần lớn lượt đăng ký ở bất kỳ đâu, nên phần lớn các lượt tra cứu rốt cuộc chẳng cần tra cứu gì cả.
5. Thất bại thì cứ cho qua. Nếu trình phân giải hết thời gian chờ, hãy chấp nhận địa chỉ đó. Một phút trục trặc ở nhà cung cấp DNS của bạn không bao giờ được phép biến thành một biểu mẫu từ chối tất cả mọi người.
6. Gợi ý một sửa lỗi; đừng bao giờ tự áp dụng nó. Khi tên miền chỉ lệch một chữ cái so với một tên miền phổ biến, hãy đưa ra gợi ý sửa đó như một thứ để bấm vào. Âm thầm viết lại những gì ai đó đã gõ chính là cách một liên kết xác nhận rơi vào tay người lạ.

Lượt tra cứu này có một cái giá đáng để biết: đó là khoảnh khắc đầu tiên biểu mẫu của bạn nói chuyện với thế giới bên ngoài về điều gì đó một khách truy cập đã gõ vào. Ở nơi điều đó quan trọng, phương án thay thế là bỏ hẳn tầng này và để chính lá thư trở thành toàn bộ bước kiểm tra.

Tầng ba: hỏi thẳng máy chủ, và vì sao câu trả lời không phải là một câu trả lời

Có một cách để hỏi một máy chủ thư liệu nó có nhận một địa chỉ cụ thể hay không mà không cần gửi bất cứ thứ gì đến đó. Mở phiên trao đổi, nêu tên người gửi, nêu tên người nhận, đọc phản hồi cho đúng một lệnh đó, rồi cúp máy trước khi đến phần nội dung thư:

220 mx1.example.com ESMTP ready
EHLO checker.example.net
250 mx1.example.com
MAIL FROM:<probe@example.net>
250 2.1.0 Ok
RCPT TO:<someone@example.com>
250 2.1.5 Ok
QUIT
221 2.0.0 Bye

250 sau RCPT TO chính là thứ mà mọi dịch vụ xác minh địa chỉ trên thế giới, xét cho cùng, đang bán. Đáng để nói rõ ràng nó thực sự đáng giá bao nhiêu — tức là rất ít.

Một tên miền catch-all trả lời có với mọi thứ

Một tên miền được cấu hình để chấp nhận mọi cái tên — đúng như dịch vụ này làm, và như rất nhiều tên miền công ty khác cũng làm — sẽ đáp 250 cho một địa chỉ chưa từng có ai dùng đến. Câu trả lời đó đúng, nhưng nó không phải là thông tin.

Một máy chủ cẩn trọng cố ý đáp 450

Greylisting từ chối lượt thử đầu tiên của một người gửi lạ và yêu cầu quay lại sau ít lâu. Một người gửi thật sẽ quay lại; một kẻ thăm dò thì không bao giờ quay lại. Thất bại tạm thời đó là một sự cố tình không trả lời, và hiểu nó thành “không có hộp thư này” chính xác là sai lầm mà nó được thiết kế ra để gây nên.

Một số máy chủ chấp nhận trước rồi mới từ chối sau

Các nhà cung cấp lớn thường xuyên nhận thư ngay trong phiên trao đổi rồi mới quyết định về nó sau, điều đó biến một lời từ chối thành một bounce đến vài phút sau khi lượt thăm dò của bạn đã báo về sạch sẽ.

Một số máy chủ nói không với bất kỳ ai nó không nhận ra

Một máy chủ đã quyết định rằng địa chỉ của bạn là người lạ có thể từ chối người nhận vì những lý do chẳng liên quan gì đến người nhận đó cả. Thứ bạn vừa đo được là chính uy tín của bạn, chứ không phải hộp thư của họ.

Và nó tiêu tốn chính uy tín bạn đang cố bảo vệ

Một kết nối chỉ nêu tên người nhận mà chẳng bao giờ gửi gì cả có đúng hình dạng của một cuộc thu hoạch danh bạ, vì nó chính là như vậy. Làm điều đó với khối lượng lớn từ chính địa chỉ của bạn là con đường nhanh nhất để lọt vào một danh sách chặn — và một người gửi bị đưa vào danh sách chặn là một người gửi mà những lá thư thật sự của họ ngừng đến nơi.

Có đúng một trường hợp hẹp mà việc thăm dò thực sự hữu ích: một địa chỉ duy nhất, được kiểm tra bằng tay, trên một tên miền bạn tự vận hành hoặc có quyền động vào. Còn là một bước bên trong một biểu mẫu đăng ký, nó chậm, thường xuyên sai, và đôi khi còn gây hại cho chính thứ nó được thêm vào để bảo vệ.

Địa chỉ chức năng, tên miền dùng-rồi-bỏ, và danh sách bạn sắp mua

Nằm giữa lượt tra cứu tên miền và lá thư thật là cả một họ các bước kiểm tra không hề liên quan gì đến tính hợp lệ. Chúng liên quan đến việc bạn có muốn địa chỉ này hay không, đó là một quyết định kinh doanh khoác áo kỹ thuật — và chỉ riêng lý do đó cũng đáng để tách nó khỏi ba tầng xung quanh.

Địa chỉ chức năng

Những cái tên như info@, support@ và admin@. Chúng có thật, và thường là một hộp thư dùng chung chứ không phải của một con người, khiến chúng là một nơi tệ để đặt bất cứ thứ gì có mật khẩu đứng sau. Đáng để gắn cờ. Hiếm khi đáng để từ chối.

Tên miền dùng một lần

Những địa chỉ giống như những địa chỉ trang này phát ra, trên các tên miền tồn tại chỉ để bị vứt bỏ. Đối chiếu với một danh sách công khai các tên miền đó là điều hợp lý, miễn là bạn thành thật thừa nhận rằng mọi danh sách như vậy đều không đầy đủ và đã hơi lỗi thời ngay vào ngày bạn tải nó về.

Địa chỉ từ nhà cung cấp miễn phí

Một số biểu mẫu doanh nghiệp từ chối bất cứ thứ gì không phải tên miền công ty. Đó là một chính sách, đôi khi là chính sách đúng đắn, và nó xứng đáng được viết ra thành một chính sách — một câu mà khách truy cập có thể đọc được — thay vì bị giấu bên trong thứ gọi là xác thực.

Những cái gần trùng với tên miền phổ biến

Tên của một nhà cung cấp nổi tiếng nhưng sai mất một chữ cái. Trường hợp này khác hẳn ba trường hợp trên: nó không phải một chính sách, nó bắt được một lỗi thực sự, và người dùng luôn thấy vui vì điều đó. Đây là mục duy nhất trong danh sách này đáng để xây dựng.

Ba trường hợp đầu có chung một đặc điểm khiến chúng khó đánh giá: bạn có thể đo được những gì chúng để lọt qua, nhưng không thể đo được cái giá chúng khiến bạn phải trả.

Ở đây chúng tôi rõ ràng có một mối lợi ích riêng, nên đây là phiên bản thành thật nhất. Nếu thứ nằm sau biểu mẫu của bạn là một bản dùng thử miễn phí đi kèm thứ gì đó đắt tiền, từ chối các tên miền dùng-rồi-bỏ sẽ giúp bạn tiết kiệm tiền, và bạn nên làm vậy. Nếu đó là một bản tin, một lượt tải xuống, hay một tài khoản mà ai đó phải trả tiền, thì phần lớn những gì bạn đang làm là đánh thuế lên những người cẩn trọng — và những người cẩn trọng lại chính là những người đọc những gì bạn gửi.

Tầng bốn: lá thư chính là bước kiểm tra

Mọi thứ ở trên chỉ thu hẹp phạm vi. Không điều nào trong số đó xác lập được sự thật duy nhất thực sự quan trọng — rằng địa chỉ này đến được với đúng người đang đứng trước bạn — và có đúng một cách để làm điều đó: gửi thứ gì đó đến đấy, rồi xem nó có được dùng đến hay không.

Đây là vòng lặp mà gần như mọi lượt đăng ký đều đã có sẵn, và một nửa trong số đó coi nó chỉ như một thủ tục:

1. Chấp nhận địa chỉ chỉ qua một bước kiểm tra dễ dãi. Mẫu kiểm tra trong trình duyệt, và không có gì khác đứng giữa khách truy cập và cái nút bấm.
2. Tạo tài khoản ở trạng thái chưa xác minh. Không phải một sự tạm giữ trên biểu mẫu, không phải một màn hình “đang chờ”: người đó đã vào được, và điều họ chưa làm được chỉ là một số ít việc thực sự cần đến địa chỉ đó.
3. Gửi đúng một thư mang theo một liên kết hoặc mã dùng một lần. Chỉ một, có thời hạn, gắn với đúng tài khoản đó và đúng địa chỉ đó, không gắn với gì khác.
4. Để liên kết đó là bằng chứng. Một cú nhấp, hoặc một mã được gõ trở lại, chính là toàn bộ việc xác minh. Không điều gì khác trong hướng dẫn này tạo ra một câu trả lời chắc chắn đến gần như vậy.
5. Cho họ một đường lui. Một nút “gửi lại” hiển thị rõ ràng, và một cách để đổi địa chỉ mà không mất tài khoản — vì lý do phổ biến nhất khiến một liên kết chẳng bao giờ được bấm vào là một lỗi gõ sai mà giờ đây người đó cuối cùng cũng nhìn thấy được.
6. Cho hết hạn những tài khoản chẳng ai xác nhận. Một đợt dọn dẹp âm thầm sau một khoảng thời gian cố định ngăn những lỗi gõ sai và những địa chỉ dùng-rồi-bỏ chất đống thành một danh sách chẳng ai còn tin được.

Điều đó tạo ra một vấn đề thực tế, và đó chính là lý do trang này tồn tại. Vòng lặp đó giờ là đường đi quan trọng nhất trong sản phẩm, và kiểm thử nó nghĩa là phải nhận được thư thật tại một địa chỉ bạn kiểm soát được — lặp đi lặp lại, bên trong một pipeline, mà không cần một con người mở hộp thư lên.

Một địa chỉ trên một trong các tên miền công khai không cần đăng ký và không cần khóa, và bất cứ thứ gì đến đó đều đọc được qua HTTP chỉ một giây sau:

$ curl -sG https://grabmail.io/api/v1/mailbox \
  --data-urlencode "address=signup-42@grabmail.io"

Từ đó, cả một luồng xác minh có thể được điều khiển từ đầu đến cuối bởi một bộ kiểm thử, hoặc một tên miền bạn sở hữu có thể được trỏ về đây để mỗi lượt chạy đều có một địa chỉ chưa từng tồn tại trước đó. Thư được giữ lại trong 5 ngày rồi bị xóa, đó là vòng đời đúng đắn cho một fixture kiểm thử, nhưng sai đối với một hộp thư.

Thực sự nên đặt gì vào biểu mẫu

Tóm gọn lại, theo đúng thứ tự mã chạy:

1. Cắt khoảng trắng, và chỉ cắt khoảng trắng. Khoảng trắng ở hai đầu là dấu vết của việc dán vào và chưa bao giờ là chủ ý. Không điều gì khác trong chuỗi đó là của bạn để thay đổi.
2. Khớp với một mẫu dễ dãi. Mẫu của trình duyệt, hoặc của nền tảng bạn dùng. Từ chối trường hợp thiếu @ và dấu phẩy gõ nhầm, và đừng từ chối điều gì khác.
3. Giới hạn độ dài ở mức 254. Một con số duy nhất, đặt trong cả cột dữ liệu lẫn trường nhập liệu, và cả một nhóm input bạn có thể ngừng phải bận tâm tới.
4. Tra cứu tên miền, ở ngoài đường găng, và cho qua khi thất bại. MX rồi đến A, có cache, và không bao giờ là lý do để chặn một lượt gửi mà nếu không có nó thì vẫn hoạt động tốt.
5. Gợi ý một sửa lỗi; đừng tự thực hiện nó. Lệch một chữ cái so với một tên miền phổ biến là một câu hỏi cần đặt ra, không phải một phát hiện để hành động theo.
6. Gửi lá thư. Đó mới là xác thực. Mọi thứ ở trên chỉ là phân loại sơ bộ.
7. Nói rõ điều gì sai, bằng lời. Đây chính là phần quyết định liệu có ai hoàn tất được hay không:

Hãy để ý xem có bao nhiêu hàng nói cùng một điều sai. “Vui lòng nhập một email hợp lệ” là câu mặc định ở khắp mọi nơi vì nó đúng với mọi trường hợp và hữu ích với không trường hợp nào cả: trong ba trên năm hàng, địa chỉ đó vốn đã hợp lệ, và người đã gõ nó không có cách nào để biết mình đang ở hàng nào.

Bản tóm tắt

1. Cắt khoảng trắng của chuỗi. Đừng thay đổi gì khác về nó.
2. Khớp với một mẫu dễ dãi — của trình duyệt hoặc của nền tảng bạn dùng — và dừng lại ở đó. Đừng tự viết mẫu của riêng bạn.
3. Từ chối bất cứ thứ gì dài quá 254 ký tự, và lưu trữ một cột có đúng kích thước đó.
4. Tra cứu MX cho tên miền, dự phòng bằng A, lưu cache kết quả, thực hiện việc này ở ngoài đường găng, và chấp nhận địa chỉ khi lượt tra cứu thất bại.
5. Từ chối một tên miền không phân giải được và một tên miền công bố null MX. Chấp nhận mọi thứ khác mà DNS cho bạn biết.
6. Gợi ý một cách viết khác khi tên miền gần trùng với một tên miền phổ biến. Đừng bao giờ tự áp dụng nó.
7. Quyết định riêng biệt, và bằng văn bản, liệu bạn có đang chặn địa chỉ dùng-rồi-bỏ hay địa chỉ chức năng hay không — và vì sao.
8. Gửi một thư kèm một liên kết dùng một lần, coi cú nhấp vào đó là bước xác minh, và làm cho việc gửi lại cũng như sửa địa chỉ trở nên dễ dàng.
9. Kiểm thử vòng lặp đó trên một hộp thư thật, bao gồm cả những đường mà nó thất bại, và xóa các tài khoản chưa được xác nhận theo một lịch cố định.

Chín dòng, và chỉ hai dòng cuối cùng mới thực sự xác lập được điều gì đó. Bảy dòng còn lại tồn tại để lá thư ở cuối con đường đó đáng để gửi đi.

Câu hỏi