Hãy lấy một bức thư. Một cửa hàng giả định tên Bright Parcel vừa có khách đăng ký bằng địa chỉ quietfox42@veylax.com, và hệ thống của họ bấm tương đương nút Gửi cho một email xác nhận. Một lát sau thư hiện trên màn hình của khách, và một ngày sau nó không còn tồn tại ở bất cứ đâu trên dịch vụ hộp thư. Bài này đi theo nó suốt chặng đường.
Vậy thư tạm hoạt động thế nào? Nó dùng bộ máy thông thường của thư điện tử trên internet, chỉ thêm một điểm khác: phía nhận thư nhận cho mọi tên người dùng trên các tên miền của mình và chỉ giữ trong thời gian ngắn. Máy chủ của người gửi tra bản ghi MX của tên miền trong DNS, kết nối tới máy được liệt kê qua SMTP trên cổng 25, và giao thư. Hệ thống thư tạm sau đó phân tích thư, hiển thị trong hộp thư, và xóa theo lịch. Trên VookMail, bản ghi MX của các tên miền trỏ tới một nhà cung cấp chuyển thư, đơn vị này nhận phiên SMTP và chuyển từng thư cho VookMail qua HTTPS.
Giai đoạn 1: Rời khỏi người gửi
Ứng dụng của Bright Parcel dựng thư. Một thư là văn bản có cấu trúc, bố trí theo Internet Message Format (RFC 5322): các tiêu đề như From, To và Subject, rồi một dòng trống, rồi phần thân. Ứng dụng thường không giao thư trực tiếp. Nó giao cho một dịch vụ gửi thư, qua kết nối SMTP có xác thực trên cổng 587 (hoặc 465 với TLS ngay từ đầu) hoặc qua API web của công ty gửi thư.
Độ trễ đầu tiên có thể xảy ra ngay tại đây. Nhiều ứng dụng đưa thư gửi đi vào hàng đợi công việc và xử lý theo lô, đặc biệt là các nền tảng quảng cáo. Vì vậy lúc trang web báo “hãy kiểm tra email” có thể sớm hơn khá nhiều so với lúc thư thật sự rời đi. Trong ví dụ của chúng ta, giả sử hàng đợi mất hai mươi giây. Chưa có gì tới phía người nhận, và không dịch vụ thư tạm nào thấy được hay đẩy nhanh được.
Giai đoạn 2: Tìm xem veylax.com nhận thư ở đâu
Máy chủ gửi đi đọc phần sau dấu @, ở đây là veylax.com, và hỏi DNS các bản ghi MX của tên miền đó. Bản ghi MX (mail exchanger) nêu tên một máy chủ nhận thư cho tên miền. Theo ký hiệu tệp vùng, các bản ghi của một tên miền có thể trông như sau. Các tên được bịa ra để minh họa:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
Số 3600 là TTL (time to live), số giây một bộ phân giải được phép lưu đệm câu trả lời này. Số 10 và 20 là độ ưu tiên: bên gửi thử số thấp nhất trước và chuyển sang số cao hơn nếu không liên lạc được. Tên máy chủ phải có bản ghi A (IPv4) hoặc AAAA (IPv6) riêng. Bản ghi MX nên trỏ tới một tên máy chủ, không trỏ thẳng tới địa chỉ IP hay bí danh CNAME.
Bạn có thể tự chạy phép tra này cho bất kỳ tên miền nào:
| Hệ thống | Lệnh |
|---|---|
| Windows Command Prompt | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS và Linux | dig MX example.com +short |
Các hệ thống chống lạm dụng dùng chính phép tra này để phát hiện những tên miền chuyển thư tới hạ tầng dùng một lần đã biết. Đó là một lý do khiến một số trang web nhận ra được tên miền thư tạm ngay cả khi tên miền đó mới.
Hai trường hợp biên trong DNS
Tên miền không có bản ghi MX không tự động là không liên lạc được. RFC 5321, chuẩn SMTP, định nghĩa một phương án dự phòng: bên gửi có thể coi bản ghi A hoặc AAAA của chính tên miền là máy chủ thư ngầm định. Tên miền không muốn nhận thư nào có thể nói rõ điều đó bằng null MX (RFC 7505), là bản ghi MX với độ ưu tiên 0 và một dấu chấm làm tên máy chủ. Tất nhiên các tên miền thư tạm công bố bản ghi MX bình thường, vì nhận thư là toàn bộ mục đích của chúng.
Bộ nhớ đệm cũng có thể gây cản trở khi dịch vụ thêm một tên miền. Các bộ phân giải vừa nhận câu trả lời “không có bản ghi” có thể giữ nó cho tới khi hết thời gian đệm âm, do bản ghi SOA của tên miền kiểm soát (RFC 2308). Vì vậy một tên miền mới tinh có thể cần một thời gian mới nhận thư ổn định từ mọi bên gửi.
Giai đoạn 3: Cuộc trò chuyện giữa hai máy chủ
Máy chủ gửi đi của Bright Parcel giờ mở kết nối TCP tới máy MX ưu tiên trên cổng 25. SMTP là giao thức văn bản: máy khách gửi lệnh và máy chủ trả lời bằng các mã số. Đây là một phiên đã đơn giản hóa cho thư của chúng ta, trong đó S: là bên nhận và C: là bên gửi. Các máy chủ và con số dung lượng thuộc về ví dụ bịa này.
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(bắt tay TLS, rồi EHLO lại)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (tiêu đề, dòng trống, phần thân, rồi một dòng chỉ có một dấu chấm)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Lệnh | Mục đích | Ý nghĩa với thư tạm |
|---|---|---|
EHLO | Tự giới thiệu bên gửi và hỏi máy chủ hỗ trợ gì | Câu trả lời liệt kê các phần mở rộng như STARTTLS và SIZE tối đa |
STARTTLS | Nâng kết nối lên TLS (RFC 3207) | Bảo vệ riêng chặng này. Đây không phải mã hóa đầu cuối |
MAIL FROM | Đặt người gửi trên phong bì, nơi thư báo lỗi được trả về | Thường khác với dòng From hiển thị, nhất là với bên gửi hàng loạt |
RCPT TO | Nêu tên một người nhận | Bên nhận catch-all trả lời 250 cho bất kỳ tên người dùng nào trên các tên miền của mình |
DATA | Bắt đầu nội dung thư | Kết thúc bằng một dấu chấm đơn trên một dòng riêng |
QUIT | Đóng phiên | Việc giao thư đã được chốt bằng 250 sau DATA |
Khoảnh khắc trách nhiệm đổi chủ
250 cuối cùng đó là dòng quan trọng nhất của phiên. Cho đến lúc ấy, thư thuộc về máy chủ của Bright Parcel, và nếu kết nối đứt nó sẽ thử lại. Sau đó, bên nhận đã nhận trách nhiệm. Bảng điều khiển của bên gửi lúc này thường ghi “đã giao”, điều đó chỉ có nghĩa chặng này thành công. Nó không có nghĩa là có ai đó đã thấy thứ gì.
Các mã trả lời giải thích khá nhiều hành vi mà người ta gặp:
- 2xx là thành công, và
250nghĩa là đã chấp nhận. - 3xx là bước trung gian, và
354bảo bên gửi truyền thư. - 4xx là lỗi tạm thời, ví dụ
421hoặc451. Bên gửi giữ thư trong hàng đợi và thử lại. - 5xx là lỗi vĩnh viễn, ví dụ
550(hộp thư không có hoặc bị từ chối) hay552(quá lớn). Bên gửi bỏ cuộc và thường tạo một thư báo lỗi trả về.
Sự khác biệt giữa 4xx và 5xx giải thích hầu hết trường hợp thư “chậm”. Nếu lúc này bên nhận trả lời 451, có thể vì greylisting (RFC 6647), thư của chúng ta sẽ nằm trong hàng đợi của Bright Parcel, chưa mất mà cũng chưa giao. RFC 5321 khuyên khoảng cách thử lại nói chung ít nhất 30 phút và thời gian bỏ cuộc ít nhất bốn đến năm ngày, dù các hệ thống thực tế tự đặt lịch riêng, và nhiều nơi thử lại sớm hơn. Đó là lý do một email xác nhận có thể hiện sau vài giây còn cái tiếp theo sau hai mươi phút, mà không có gì sai ở cả hai trường hợp.
Hai bộ địa chỉ
SMTP có hai lớp địa chỉ. Phong bì, MAIL FROM và RCPT TO, là thứ máy chủ dùng để định tuyến. Các tiêu đề, From:, To: và Subject:, là một phần nội dung thư và là thứ bạn thấy trên màn hình. Chúng có thể khác nhau. Một bản tin có thể hiển thị To: subscribers dù người nhận trên phong bì là địa chỉ tạm thời của bạn. Vì vậy hệ thống nhận xếp thư theo người nhận trên phong bì, giá trị đáng tin cậy. Đó cũng là lý do tiêu đề Return-Path, được thêm vào lúc giao cuối cùng, ghi người gửi trên phong bì chứ không phải địa chỉ From hiển thị.
Giai đoạn 4: Vì sao quietfox42 không cần phải tồn tại
Ở RCPT TO, một máy chủ thư bình thường kiểm tra hộp thư có tồn tại không và trả lời 550 nếu không. Tên miền thư tạm làm ngược lại. Nó chạy như một bên nhận catch-all, hay ký tự đại diện: phần cục bộ nào (phần trước dấu @) cũng được nhận.
Chỉ riêng lựa chọn đó đã làm cho địa chỉ tức thì trở nên khả thi. Khi VookMail hiện cho bạn một địa chỉ ngẫu nhiên, không có gì phải được tạo trên máy chủ thư nào. Khi bạn bấm Mới, gõ tên người dùng của mình, chọn tên miền và bấm mũi tên, tên đó đã “tồn tại” sẵn, vì tên miền nhận mọi tên. Ứng dụng chỉ cần hiển thị những thư có người nhận khớp với địa chỉ trên màn hình của bạn.
Có hai quy tắc nhỏ cho các tên đó. Chuẩn nói rằng phần cục bộ có thể phân biệt hoa thường, nhưng gần như mọi hệ thống thực tế coi Test@ và test@ là một hộp thư, nên hệ thống thư tạm chuẩn hóa chữ hoa thường một cách hợp lý để cách viết hoa của bên gửi không tách một hộp thư thành hai. Và RFC 5321 giới hạn phần cục bộ ở 64 octet, với giới hạn thực tế 254 ký tự cho cả địa chỉ, nên các tên được tạo ra phải nằm gọn trong mức đó.
Giai đoạn 5: Từ giao thức thư sang yêu cầu web
Thư của chúng ta giờ đã được một máy nói SMTP chấp nhận. Trang web hiển thị hộp thư là một ứng dụng web. Phải có thứ gì đó nối hai bên.
Vận hành một máy chủ thư hướng ra toàn bộ internet là việc nặng thật sự: TLS, lũ kết nối, hàng đợi, mã độc và giữ uy tín tốt. Vì vậy nhiều ứng dụng hiện đại giao phần SMTP cho một nhà cung cấp nhận thư chuyên dụng và nhận thư dưới dạng yêu cầu web, mô hình thường gọi là inbound parse webhook. VookMail dùng mô hình này. Nó hoạt động như sau:
- Các máy MX của nhà cung cấp nhận thư từ máy chủ của người gửi, như trong phiên ở trên.
- Nhà cung cấp đóng gói thư, dưới dạng mã nguồn MIME thô hoặc các trường đã phân tích như người gửi, người nhận, tiêu đề, văn bản, HTML và tệp đính kèm.
- Nó gửi gói đó trong một HTTPS POST tới một điểm cuối do ứng dụng thư tạm vận hành, mã hóa nội dung giữa hai điểm đó.
- Ứng dụng trả lời bằng trạng thái thành công. Nếu không liên lạc được hoặc trả về lỗi, một nhà cung cấp tử tế sẽ thử lại theo chính sách riêng.
- Ứng dụng kiểm tra yêu cầu, ghép người nhận với một địa chỉ và lưu thư tạm thời.
| Mối quan tâm | Bên nhận SMTP tự vận hành | Nhà cung cấp nhận thư cộng HTTPS |
|---|---|---|
| Mức phơi bày | Cổng 25 mở cho mọi máy trên internet | Nhà cung cấp đón lưu lượng SMTP, và ứng dụng chỉ thấy các yêu cầu HTTPS |
| Lưu lượng tăng đột biến | Người vận hành phải chuẩn bị đủ năng lực | Hạ tầng của nhà cung cấp xử lý các đợt tăng vọt |
| Phân tích MIME | Người vận hành tự viết hoặc duy trì bộ phân tích | Thường do nhà cung cấp làm, dù vẫn có thể dùng mã nguồn thô |
| Phù hợp với ứng dụng web | Cần một cầu nối từ hàng đợi thư sang ứng dụng | Thư đến như một yêu cầu API bình thường |
| Phụ thuộc | Ít bên ngoài hơn | Dựa vào độ sẵn sàng và cấu hình của nhà cung cấp |
Dòng cuối là một cái giá thật. Nếu nhà cung cấp nhận thư gặp sự cố hay lỗi cấu hình, việc giao thư tới mọi tên miền phía sau nó có thể dừng cho tới khi được sửa, kể cả khi trang web thư tạm vẫn chạy bình thường. Các thư bị từ chối bằng lỗi tạm thời trong thời gian đó vẫn có thể đến khi các bên gửi ban đầu thử lại, tùy hàng đợi của họ giữ thư bao lâu.
Bảo vệ điểm cuối
Điểm cuối webhook là một URL công khai, nên ai cũng có thể thử gửi vào đó một thư giả. Các triển khai cẩn thận thường kết hợp nhiều lớp phòng thủ:
- Xác minh chữ ký, trong đó nhà cung cấp ký từng yêu cầu và ứng dụng từ chối những yêu cầu không khớp.
- Một đường dẫn bí mật hoặc token chỉ nhà cung cấp và ứng dụng biết.
- Giới hạn yêu cầu trong các dải địa chỉ mà nhà cung cấp công bố, nếu có.
- Giới hạn dung lượng, từ chối sớm các gói quá lớn để bảo vệ bộ nhớ và nơi lưu trữ.
- Tính bất biến lũy đẳng. Nhà cung cấp có thử lại, nên cùng một thư có thể đến hai lần, và Message-ID hoặc mã sự kiện của nhà cung cấp giúp tránh trùng lặp.
Giai đoạn 6: Tháo rời bức thư
Thứ đến nơi chưa phải thứ người ta đọc thoải mái. MIME (Multipurpose Internet Mail Extensions, RFC 2045 trở đi) cho phép một thư mang nhiều phần ở các định dạng khác nhau. Email xác nhận của chúng ta có thể được sắp xếp như sau, thêm một hóa đơn làm ví dụ:
| Phần | Chứa gì |
|---|---|
multipart/mixed | Vùng chứa ngoài cùng khi có tệp đính kèm |
multipart/alternative | Cùng một nội dung hai lần, dưới dạng text/plain và text/html. Trình đọc hiển thị dạng phong phú nhất mà nó hỗ trợ |
multipart/related | HTML nhóm cùng các hình ảnh nhúng, được tham chiếu bằng mã định danh cid: |
| Phần tệp đính kèm | Một tiêu đề Content-Disposition: attachment và tên tệp, rồi dữ liệu đã mã hóa của tệp |
Phía trên những phần đó là các tiêu đề, gồm Message-ID, Date và các dòng truy vết Received, ghi lại mọi máy chủ mà thư đã đi qua. Nếu bạn muốn biết độ trễ xảy ra ở đâu, dấu thời gian trong các dòng Received là nơi cần xem.
Bộ phân tích cũng phải đảo ngược nhiều kiểu mã hóa. Base64 mang các tệp đính kèm nhị phân và làm chúng phình ra khoảng một phần ba, nên tệp 10 MB trở thành thư khoảng 13 đến 14 MB. Quoted-printable xử lý văn bản chủ yếu là ASCII bằng cách ghi ký tự đặc biệt dưới dạng =XX. Giá trị charset= cho biết văn bản được mã hóa thế nào, thường là UTF-8, điều rất quan trọng với một dịch vụ dùng bằng nhiều ngôn ngữ. Và dòng tiêu đề có ký tự ngoài ASCII dùng cú pháp =?UTF-8?B?...?= hoặc =?UTF-8?Q?...?= từ RFC 2047.
Làm cho HTML an toàn khi hiển thị
HTML trong email do người lạ viết, nên trình xem không được để nó chạy mã trong ngữ cảnh của trang web. Các triển khai cẩn thận nói chung loại bỏ script, thuộc tính xử lý sự kiện và các lược đồ URL nguy hiểm, và hiển thị thư trong một khung cô lập để kiểu dáng và nội dung của nó không ảnh hưởng tới trang xung quanh.
Hình ảnh từ xa cũng cần cân nhắc. Tải một hình ảnh cho người gửi biết thư đã được mở, đó là cách điểm ảnh theo dõi (tracking pixel) hoạt động. VookMail loại bỏ các điểm ảnh theo dõi ẩn và giữ hình ảnh ở trạng thái tắt cho tới khi bạn cho phép.
Trình xem cũng có thể làm điều hữu ích với văn bản đã phân tích. Với thư xác nhận của chúng ta, VookMail hiện mã xác minh hoặc liên kết xác nhận phía trên thư, để không ai phải cuộn qua một mẫu thư dài để tìm.
Tệp đính kèm
Tệp đính kèm được giải mã và lưu tạm để có thể tải về. Trên VookMail, các tệp chương trình phổ biến như .exe, .bat và .apk bị từ chối, các tệp nén như .zip hiện cảnh báo, và có áp dụng dung lượng tối đa. Tệp đính kèm bị xóa cùng với thư. Hãy nhớ rằng độ an toàn của một tệp không liên quan tới nơi nó được lưu: tài liệu có bật macro nguy hiểm như nhau khi tải từ hộp thư tạm thời.
Giai đoạn 7: Hiện lên màn hình
Thư của chúng ta giờ đã được lưu, nhưng trình duyệt đang hiện quietfox42@veylax.com chưa biết điều đó. Ứng dụng web có nhiều cách để biết:
| Kỹ thuật | Cách hoạt động | Được và mất |
|---|---|---|
| Short polling | Trang hỏi máy chủ vài giây một lần | Đơn giản và đáng tin, nhưng tạo nhiều yêu cầu lặp lại |
| Long polling | Một yêu cầu giữ mở cho tới khi có tin hoặc hết thời gian chờ | Ít câu trả lời rỗng hơn, nhiều kết nối mở hơn |
| Server-Sent Events | Một luồng sống lâu từ máy chủ tới trình duyệt | Hiệu quả theo một chiều, tự kết nối lại |
| WebSockets | Một kết nối hai chiều bền vững | Tương tác hoàn toàn, cần hạ tầng riêng |
Hộp thư VookMail kiểm tra thư vài giây một lần, và nút Làm mới kiểm tra bằng tay, ví dụ sau khi thiết bị của bạn ngủ hoặc mạng bị mất. Vài giây đó thường là chặng ngắn nhất của hành trình. Nếu thư có vẻ chậm, thời gian hầu như luôn mất ở khâu trước đó, trong hàng đợi của người gửi hoặc ở một lần thử lại.
Việc tạo địa chỉ cũng đi qua một lớp chống bot nhỏ: một phép tính ngắn trong trình duyệt của khách, gọi là proof of work. Nó hầu như không tốn gì với khách bình thường, và làm cho việc tạo địa chỉ hàng loạt tốn kém hơn.
Địa chỉ cũng có thể được mở ở nơi khác. Vì chính địa chỉ xác định hộp thư, chuyển nó sang thiết bị khác chỉ cần truyền địa chỉ đi. Nút QR của VookMail hiện nó dưới dạng mã mà điện thoại quét được, để cùng hộp thư mở được ở đó, và các ứng dụng Android và Huawei hiện thư theo cách tương tự. Điều này tiện, và cũng cho thấy vì sao các hộp thư này có mức riêng tư thấp: ai biết hoặc đoán được địa chỉ đều mở được hộp thư đó. Địa chỉ ngẫu nhiên là lựa chọn an toàn hơn, vì khó đoán hơn nhiều so với một cái tên ngắn.
Giai đoạn 8: Xóa
Khoảng một ngày sau khi thư xác nhận của chúng ta đến, nó biến mất. Thời gian lưu giữ trong hệ thống thư tạm thường được triển khai bằng một dấu thời gian trên mỗi thư đã lưu và một công việc theo lịch xóa mọi thứ cũ hơn giới hạn. Tệp đính kèm được giữ dưới dạng tệp riêng bị xóa cùng lúc. Các thiết kế khác dùng cơ chế hết hạn ở tầng lưu trữ, trong đó chính cơ sở dữ liệu xóa các bản ghi cũ qua thiết lập time-to-live. Công việc theo lô là một lý do khiến các dịch vụ hay mô tả việc hết hạn là “khoảng” một ngày, vì thời điểm chính xác phụ thuộc vào lúc công việc chạy. Trên VookMail, thư, tệp đính kèm và địa chỉ bị xóa trong vòng khoảng 24 giờ, và nút Xóa cho phép bạn xóa sớm hơn.
Thời gian lưu giữ ngắn phục vụ hai mục đích cùng lúc. Nó bảo vệ quyền riêng tư, và cũng là điều bắt buộc về dung lượng: các hộp thư dùng một lần nhận rất nhiều thư quảng cáo, và giữ chúng lâu chẳng phục vụ ai. Chính sách quyền riêng tư và trang phương pháp của chúng tôi nói chi tiết hơn về việc xử lý dữ liệu.
Hãy để ý những gì việc xóa không chạm tới. Bright Parcel vẫn có địa chỉ đó trong bảng khách hàng, và nhật ký của họ vẫn ghi rằng nó đã “được giao”. Thứ duy nhất mất đi là bản sao phía hộp thư.
Toàn bộ tuyến đường trong một bảng
| Giai đoạn | Thành phần | Giao thức hoặc cơ chế | Cổng hoặc định dạng thường gặp |
|---|---|---|---|
| Soạn thư | Ứng dụng hoặc trình khách thư | Thư RFC 5322, MIME | Văn bản có tiêu đề và các phần |
| Gửi đi | Dịch vụ thư của bên gửi | SMTP submission hoặc API gửi thư | 587 hoặc 465 |
| Tra định tuyến | Bộ phân giải DNS | Truy vấn MX, rồi A hoặc AAAA | DNS, cổng 53 |
| Chuyển tiếp | Máy chủ bên gửi tới MX bên nhận | SMTP với STARTTLS cơ hội | 25 |
| Tiếp nhận đầu vào | Nhà cung cấp chuyển thư | Nhận catch-all cho các tên miền | Trả lời 250, 4xx, 5xx |
| Chuyển tiếp tiếp theo | Nhà cung cấp tới VookMail | Yêu cầu HTTPS | 443 |
| Xử lý | Ứng dụng thư tạm | Phân tích MIME, làm sạch, lưu trữ | Cơ sở dữ liệu và lưu trữ tệp |
| Hiển thị | Trình duyệt hoặc ứng dụng di động | Kiểm tra vài giây một lần, cộng Làm mới thủ công | HTTPS |
| Hết hạn | Dọn dẹp theo lịch | Quy tắc lưu giữ | Khoảng một ngày trên VookMail |
SPF, DKIM và DMARC nằm ở đâu
Ba thứ này được nhắc tới trong gần mọi cuộc bàn về email, nên cần chính xác về vị trí của chúng trên tuyến đường này. Tất cả đều liên quan đến việc chứng minh ai đã gửi một thư. Không cái nào quyết định liệu một địa chỉ tạm thời có nhận được thư hay không.
SPF (RFC 7208) là bản ghi DNS TXT liệt kê các máy chủ được phép gửi bằng một tên miền ở người gửi trên phong bì, và bên nhận so IP đang kết nối với danh sách đó. DKIM (RFC 6376) là chữ ký mật mã mà tên miền gửi thêm vào một số tiêu đề và phần thân, được xác minh bằng khóa công khai trong DNS. DMARC (RFC 7489) là chính sách bảo bên nhận làm gì khi thư không khớp SPF và DKIM với tên miền From hiển thị, và gửi báo cáo về đâu.
Với thư của chúng ta, những kiểm tra này diễn ra quanh Giai đoạn 3. Máy chủ của Bright Parcel được kiểm tra với bản ghi SPF của nó, và chữ ký DKIM của nó có thể được xác minh bằng khóa đã công bố. Nhà cung cấp nhận thư có thể dùng các kết quả đó để gắn cờ giả mạo. Việc chuyển tiếp làm mọi thứ phức tạp hơn một chút: chữ ký DKIM còn nguyên miễn là thư không bị sửa, trong khi kết quả SPF chỉ liên quan đến máy chủ kết nối cuối cùng. Khi thư được chuyển tiếp, ARC (Authenticated Received Chain, RFC 8617) có thể ghi lại các kết quả trước đó. Tuy vậy, cuối cùng chính bản ghi MX và việc bên nhận chấp nhận mới giúp thư được giao.
Khi một thư không bao giờ đến
Mỗi giai đoạn ở trên đều là nơi một thư có thể dừng lại. Đi từ phía người gửi thường tìm ra vấn đề nhanh nhất.
| Giai đoạn | Điều gì sai | Bạn thấy hoặc làm gì |
|---|---|---|
| Trước khi gửi | Gõ sai địa chỉ | Thư đã đi nơi khác hoặc bị trả lại. Hãy dùng nút Sao chép |
| Rời khỏi người gửi | Thư nằm trong hàng đợi, hoặc các lô chạy chậm | Một hai phút là bình thường với một số dịch vụ. Hãy chờ |
| Rời khỏi người gửi | Trang lặng lẽ bỏ qua các tên miền dùng một lần | Không có gì đến. Hãy tôn trọng điều đó và dùng địa chỉ lâu dài hoặc bí danh ở đó |
| SMTP | Trả lời 4xx và một lần thử lại sau đó | Thư đến sau một độ trễ có thể là vài phút hoặc hơn |
| SMTP | Thư vượt giới hạn dung lượng | Bị từ chối 552 và một thư báo lỗi trả về người gửi |
| Nhà cung cấp nhận thư | Sự cố hoặc lỗi DNS | Việc giao thư tới mọi tên miền có thể tạm dừng cho tới khi được giải quyết |
| Hộp thư | Khoảng thời gian đã qua, hoặc địa chỉ đã bị xóa | Thư đến quá muộn để được thấy |
Đọc một lỗi khi bạn sở hữu phía gửi
Nếu bạn đang thử ứng dụng của chính mình, bạn thấy được nhiều hơn người dùng rất nhiều, và hướng dẫn email tạm thời cho lập trình viên của chúng tôi đi sâu hơn vào việc thiết kế kiểm thử. Một thứ tự kiểm tra hợp lý:
- Mở nhật ký thư của ứng dụng hoặc bảng điều khiển của nhà cung cấp gửi thư. Thư đã được chấp nhận chưa, và trạng thái cuối cùng là gì?
- Tìm các thư báo lỗi hoặc sự kiện webhook báo 5xx từ phía người nhận. Phần văn bản sau mã thường nêu lý do.
- Phân giải bản ghi MX của tên miền người nhận từ mạng của máy chủ bạn, dùng các lệnh ở trên. Vấn đề bộ phân giải ở đó có thể không hiện ở đâu khác.
- Xác nhận tên miền gửi của bạn đã cấu hình SPF, DKIM và DMARC, vì một số bên nhận nghi ngờ thư không được xác thực.
- Gửi một thư văn bản thuần nhỏ để loại trừ lọc theo dung lượng hay nội dung.
- Dùng một tên người dùng riêng cho mỗi lần thử để biết lần chạy nào sinh ra thư nào.
Nếu một thư đến hộp thư muộn, hãy đọc các tiêu đề Received của nó từ dưới lên. Một khoảng cách dài giữa hai dấu thời gian cho thấy chặng nào đã giữ nó, có tính đến mọi chênh lệch giữa đồng hồ của các máy chủ đó.
Vì sao chạy nhiều tên miền?
VookMail cho bạn chọn trong hơn 30 tên miền. Có những lý do thực tế cho điều đó. Người kiểm thử có thể tách dự án hoặc bộ kiểm thử theo tên miền. Nếu một tên miền gặp sự cố DNS hay giao thư, các tên miền khác có thể vẫn chạy. Và ít phụ thuộc vào một cái tên duy nhất hơn, điều có ích khi các hệ thống gửi đánh giá cả tên miền người nhận lẫn người gửi.
Nhiều tên miền không phải công cụ để vượt qua các trang web cố tình từ chối địa chỉ dùng một lần. Nếu một dịch vụ từ chối tên miền thư tạm, nó đang báo rằng họ muốn một liên hệ lâu dài, và lựa chọn đúng là địa chỉ thật của bạn hoặc một bí danh lâu dài cho dịch vụ đó. Việc từ chối có thể xảy ra ở biểu mẫu, qua danh sách tên miền hoặc phép tra MX như ở Giai đoạn 2, hoặc muộn hơn, khi bên gửi từ chối gửi.
Tuyến đường này cho bạn biết gì về bảo mật
Sau khi theo dõi bức thư, bạn thấy chính xác mỗi lớp bảo vệ vươn tới đâu.
Mã hóa được áp dụng từng chặng một. STARTTLS bảo vệ từng chặng giữa các máy chủ khi cả hai bên hỗ trợ, và thường chỉ mang tính cơ hội, nên một kết nối có thể lùi về văn bản thuần trừ khi một chính sách như MTA-STS (RFC 8461) yêu cầu khác đi. HTTPS bảo vệ các chặng chuyển tiếp và xem thư. Không cái nào là mã hóa đầu cuối: mọi hệ thống xử lý thư đều đọc được nó.
Truy cập là nửa còn lại. Không có mật khẩu, biết địa chỉ là đủ để vào, nên đừng bao giờ để thứ gì bí mật được gửi tới đó. Thời gian lưu giữ ngắn hạn chế thiệt hại từ bất kỳ sự phơi bày nào, nhưng cũng có nghĩa hộp thư không thể dùng làm hồ sơ. Và vì nội dung là thứ không đáng tin, lừa đảo và mã độc có thể đến hộp thư này như mọi hộp thư khác. Hộp thư tạm thời bảo vệ địa chỉ thật của bạn, và làm được rất ít cho thiết bị của bạn nếu bạn mở một tệp xấu. Các mục đích phù hợp là quyền riêng tư, kiểm soát thư rác và thử nghiệm, như điều khoản và điều kiện của chúng tôi nêu, và các tài khoản quan trọng thuộc về nơi khác.
Trên VookMail trông như thế nào
Toàn bộ bộ máy ở trên đã được thiết lập trước khi bạn đến. Khi bạn mở VookMail, một địa chỉ đã sẵn sàng. Bạn có thể bấm Mới để gõ tên người dùng và chọn tên miền, hoặc dùng nút Ngẫu nhiên màu vàng được mô tả trong hướng dẫn cách dùng VookMail của chúng tôi. Không có gì để đăng ký, vì tên miền đã nhận mọi tên. Khi một bên gửi giao thư, nhà cung cấp đứng sau các bản ghi MX nhận nó qua SMTP và chuyển tiếp qua HTTPS, và nó hiện trong hộp thư của bạn cùng mọi tệp đính kèm ở lần kiểm tra tiếp theo của trang. Khoảng một ngày sau, nó biến mất.
Dịch vụ cũng có dưới dạng ứng dụng trên Google Play và Huawei AppGallery.
Thêm vài câu hỏi kỹ thuật
Thư đến dùng cổng nào?
Việc giao thư giữa các máy chủ thư dùng SMTP trên cổng TCP 25. Các cổng 587 và 465 dùng để gửi thư đi tới nhà cung cấp của chính bạn, nên chúng xuất hiện ở Giai đoạn 1 chứ không phải Giai đoạn 3. Đó cũng là lý do một kết nối gia đình chặn cổng 25 thường vẫn gửi được qua nhà cung cấp của nó.
Dịch vụ thư tạm có thấy được thư của tôi không?
Về mặt kỹ thuật là có. Thư đến dịch vụ ở dạng đọc được, vì đó là cách nó hiển thị cho bạn, và nhà cung cấp chuyển thư xử lý nó trên đường đi cũng vậy. Điều này đúng cả với email lưu trữ thông thường, trừ khi nội dung được mã hóa đầu cuối. Đó là thêm một lý do để giữ mọi thứ nhạy cảm ra khỏi hộp thư tạm thời.
Vì sao người gửi có thể nghĩ thư đã được giao khi tôi không thấy gì?
Vì “đã giao” trên bảng điều khiển của người gửi chỉ phản hồi 250 từ máy chủ nhận. Các sự kiện sau thời điểm đó, như bước chuyển tiếp hay một thư đến muộn sau khi hộp thư đã được dọn, người gửi không thấy được.
Người gửi có biết địa chỉ của tôi là catch-all không?
Thường là có. Một công cụ xác minh có thể thử một tên người dùng bịa ra tại tên miền, và nếu máy chủ chấp nhận, tên miền đó nhiều khả năng là catch-all. Chỉ riêng điều đó không chứng minh tên miền là dùng một lần, vì nhiều tên miền công ty bình thường cũng được cấu hình như vậy, nên các công cụ này thường kết hợp nó với các tín hiệu khác.
Trả lời thư có được không?
Trả lời từ phía bạn không phải mục tiêu của thiết kế, vì hộp thư chủ yếu để nhận. Nếu cần trao đổi hai chiều, một hộp thư thông thường hoặc dịch vụ bí danh hỗ trợ trả lời sẽ phù hợp hơn.
Để biết thêm về chính sản phẩm, xem phần hỏi đáp của chúng tôi. VookMail là một phần của mạng lưới công cụ miễn phí PAYATE.