Câu trả lời ngắn gọn, và nửa phần khiến người ta bất ngờ
5 ngày. Đó là toàn bộ câu trả lời mà phần lớn mọi người tìm đến, và đáng để nói chính xác nó là câu trả lời cho điều gì: một thư có thể đọc được trong 5 ngày. Còn địa chỉ mà nó đến không hề hết hạn, vì đơn giản là chẳng có gì ở đó để hết hạn cả.
Đó là hai điều hoàn toàn khác nhau, và gộp chung chúng lại chính là nguồn gốc của cả hai câu chúng tôi thường nghe được — "địa chỉ của tôi ngừng hoạt động rồi", trong khi thực ra không phải vậy, và "bạn có thể giữ cái này lâu hơn không", mà với câu đó thì chẳng có cần gạt nào để kéo cả.
- Một thư
- Đọc được trong 5 ngày kể từ dấu thời gian riêng của nó, rồi biến mất. Nội dung, tiêu đề, bản xem trước và mọi tệp đính kèm, tất cả cùng biến mất trong một khoảnh khắc.
- Một địa chỉ
- Không hết hạn, vì không có bản ghi nào về nó được lưu giữ. Nó chỉ là một chuỗi ký tự. Nó hoạt động ngay lần đầu bạn dùng, và vẫn hoạt động một năm sau đó.
- Một hộp thư
- Bản ghi tính đếm cho một địa chỉ được tạo ra bởi thư đầu tiên đến nơi, và bị xóa đi khi thư cuối cùng rời khỏi. Bạn không bao giờ tự tạo ra hay tự xóa nó.
Chỉ một khoảng thời gian, giống nhau cho tất cả mọi người: miễn phí hay trả phí, tên miền công khai hay tên miền của riêng bạn. Đó không phải một tính năng theo gói, và không có tùy chọn nào ở bất cứ đâu có thể thay đổi nó.
Đồng hồ thực sự bắt đầu chạy từ lúc nào
Mốc hết hạn được tính ra đúng một lần, ngay khi thư được chuyển đến, và được ghi vào bản ghi đi kèm với nó. Không có gì tính lại nó sau đó — không có chính sách nào được tra cứu khi bạn đọc thư, không có gói dịch vụ nào được kiểm tra, không có đồng hồ nào chạy lại chỉ vì bạn đã mở thứ gì đó.
Phần đáng biết là nó được tính từ đâu. Một thư mang theo tiêu đề Date của riêng nó, do bất cứ thứ gì đã gửi nó ghi vào, và đó chính là điểm bắt đầu của 5 ngày — nhưng chỉ khi nào tiêu đề đó còn đáng tin.
- Tiêu đề đó cách hiện tại không quá một ngày. Nó được chấp nhận nguyên trạng. Gần như mọi thư đều rơi vào trường hợp này, và với chúng, khoảng thời gian 5 ngày được tính từ đúng lúc người gửi nhấn gửi.
- Tiêu đề đó lệch xa hơn mức đó, theo cả hai hướng. Nó bị bỏ qua, và thời điểm thư đến được dùng thay vào đó. Người gửi có thể ghi bất kỳ ngày nào họ muốn, kể cả một ngày còn cách hiện tại hàng trăm năm, và một thư không bao giờ hết hạn sẽ là một thư không bao giờ rời đi.
- Không có tiêu đề nào dùng được cả. Kết quả như nhau: dùng thời điểm thư đến.
Điều này chỉ có thể khiến bạn mất vài giờ, và nó chỉ có thể đi theo một chiều — một thư có thể đến nơi với thời gian còn lại hơi ít hơn 5 ngày một chút, chứ không bao giờ nhiều hơn. Một thư nằm chờ đâu đó trong hàng đợi suốt hai mươi giờ trước khi đến đây sẽ xuất hiện với khoảng bốn ngày bốn giờ còn lại.
Những gì mất đi cùng nó, và những gì còn lại
Khi một thư chạm đến mốc hết hạn, mọi thứ thuộc về nó biến mất cùng lúc. Không có gì được giữ lại trong một bảng khác, và không có gì tồn tại dưới dạng rút gọn — không có dấu vết nào sót lại, không có dòng tiêu đề nào được lưu làm bằng chứng, không có ảnh thu nhỏ nào của một tệp.
| Cái gì | Điều gì xảy ra với nó | Khi nào |
|---|---|---|
| Thư | Văn bản, HTML, tiêu đề và bản xem trước, bị xóa cùng lúc. | Vào mốc hết hạn của nó |
| Các tệp đính kèm của nó | Bị xóa khỏi ổ đĩa cũng như khỏi cơ sở dữ liệu. Một tệp chỉ có thể được truy cập thông qua thư đã mang nó đến, nên nó không thể tồn tại lâu hơn thư đó. | Cùng lúc với thư |
| Dấu đã đọc | Đó là một cột trên chính thư đó, chứ không phải một thứ độc lập. Nó mất đi khi bản ghi đó mất đi. | Cùng lúc với thư |
| Bản ghi hộp thư | Bản ghi tính đếm nội dung của một địa chỉ bị xóa ngay khi thư cuối cùng trong đó đã ra đi. Nó tồn tại vì có thư đến; nó không tồn tại lâu hơn số thư đó. | Cùng với thư cuối cùng |
| Địa chỉ | Không có gì để xóa cả. Nó chưa từng được lưu như một thứ có thể tồn tại hay ngừng tồn tại. | Không bao giờ |
| Một alias đã từng mang thư | Được giữ lại. Đó là mối liên hệ cho biết dịch vụ nào đã được trao địa chỉ nào, và điều đó đáng giá hơn chi phí của một bản ghi. | Không bao giờ |
| Một alias chưa từng mang thư nào | Bị loại bỏ sau 5 ngày không hoạt động — rồi được tính lại y hệt vào lần kế tiếp địa chỉ đó được dùng. Một alias được suy ra từ địa chỉ, chứ không phải được gán cho nó, nên vứt bỏ một alias không dùng đến chẳng làm mất gì cả. | Sau 5 ngày không hoạt động |
| Bản ghi MX của tên miền riêng bạn | Là của bạn, nằm trong DNS của bạn, không hề bị đụng đến bởi bất cứ điều nào ở đây. Thời gian lưu trữ liên quan đến thư, chứ không liên quan đến việc định tuyến. | Không bao giờ |
Tệp đính kèm được gỡ liên kết trước khi bản ghi của chúng bị xóa, và thứ tự này là có chủ đích: một sự cố xảy ra giữa chừng sẽ để lại những bản ghi mà tệp của chúng đã mất, và điều đó sẽ được đợt dọn dẹp kế tiếp xử lý gọn. Thứ tự ngược lại sẽ để lại những tệp mà không gì trỏ đến nữa, và sẽ không bao giờ có ai quay lại lấy chúng.
Không đọc được trước, bị xóa sau
Đó là hai sự kiện, và chúng không phải là cùng một sự kiện. Chỉ sự kiện đầu tiên diễn ra theo một lịch trình bạn có thể tin cậy, và đó cũng là sự kiện duy nhất bạn có thể quan sát được.
Mọi lần đọc ở đây đều được lọc qua mốc hết hạn. Liệt kê một hộp thư, mở một thư, tải một tệp đính kèm — cả ba đều mang cùng một điều kiện, và một thư đã qua khoảng thời gian của nó sẽ không khớp với bất kỳ điều kiện nào trong số đó. Không hề có một khoảng thời gian nào mà thư "về mặt kỹ thuật vẫn còn ở đó": ngay giây nó hết hạn, nó biến mất khỏi trang hộp thư, khỏi API và khỏi MCP server cùng một lúc.
Những gì xảy ra sau đó chỉ là việc dọn dẹp. Một đợt dọn dẹp đi qua và giải phóng lại bản ghi cùng các tệp, theo từng đợt có giới hạn, với nhịp độ được chọn sao cho việc xử lý phần tồn đọng không bao giờ xếp hàng chặn trước những thư đang đến thật. Nó xử lý đến một thư cụ thể nào sớm hay muộn cũng không làm thay đổi bất cứ điều gì mà ai đó có thể nhìn thấy.
- Mốc hết hạn
- Một điều kiện áp dụng cho mọi truy vấn có thể trả về một thư. Chính xác, và giống hệt nhau ở hộp thư, ở API và ở MCP server, vì cả ba đều đặt ra cùng một câu hỏi.
- Đợt dọn dẹp
- Một khối công việc có giới hạn, giải phóng lại những gì vốn đã không thể truy cập được nữa. Không bao giờ là thứ mà người đọc phải chờ, và cũng không bao giờ là thứ quyết định bạn có đọc được điều gì hay không.
Đó là lý do câu trả lời cho câu hỏi "nó bị xóa hay chỉ bị ẩn đi?" là "cả hai, theo đúng thứ tự đó" — và cũng là lý do vì sao chẳng có gì khác biệt giữa việc điều nào trong hai điều đó đã xảy ra vào lúc bạn hỏi.
Đọc mốc hết hạn ngay trên thư
Bạn không bao giờ phải tự tính ra ngày đó. Mọi thư mà API trả về đều mang theo mốc hết hạn đã được gán cho nó ngay lúc chuyển đến, dưới dạng dấu thời gian ISO 8601 theo giờ UTC.
$ curl -sG https://grabmail.io/api/v1/mailbox \
--data-urlencode "address=you@grabmail.io"Mỗi thư trong phản hồi đều mang theo cả hai đầu mốc của khoảng thời gian riêng nó:
{
"id": "01k4h2v9r7m3d8f0b6n5c1qtzx",
"from": "no-reply@example.com",
"subject": "Confirm your email address",
"date": "2026-09-01T09:00:00+00:00",
"seen": false,
"attachments": 0,
"expires_at": "2026-09-06T09:00:00+00:00"
}date là nơi đồng hồ bắt đầu tính, còn expires_at là nơi nó dừng lại. Lấy hiệu của hai giá trị đó, bạn sẽ luôn được 5 ngày — đó là cách nhanh nhất để tự xác nhận rằng không có gì bạn làm ở giữa khoảng đó đã làm thay đổi bất cứ điều gì.
expires_at- Thời điểm nó ngừng đọc được. Là một mốc tuyệt đối, theo giờ UTC, với phần lệch múi giờ được ghi đầy đủ chứ không rút gọn thành chữ Z ở cuối.
date- Dấu thời gian riêng của thư — được tin dùng khi nó cách thời điểm đến không quá một ngày, và lặng lẽ bị thay bằng thời điểm đến khi không phải vậy.
Hỏi về một thư đã qua mốc hết hạn của nó, và bạn nhận được đúng câu trả lời y hệt như hỏi về một thư chưa từng tồn tại:
{"error":"not_found","message":"no such message in that mailbox, or it has expired"}API sẽ không cho biết đó là trường hợp nào trong hai trường hợp trên, và đó không phải là một thiếu sót. Phân biệt được hai trường hợp đó sẽ biến một mã 404 thành một cách xác nhận rằng một id cụ thể nào đó từng có thật, mà đó là một câu hỏi không ai ở ngoài hộp thư này nên có khả năng đặt ra.
Giữ lại đúng thứ bạn thực sự cần
Gần như không có gì đến một địa chỉ dùng một lần cần tồn tại lâu hơn chính địa chỉ đó. Một vài ngoại lệ hiếm hoi thì đáng để xử lý một cách chủ động, thay vì phát hiện ra vào ngày thứ sáu.
- Một mã, một liên kết hoặc một mật khẩu tạm thời. Hãy dùng nó ngay. Đây vốn dĩ là những thứ có vòng đời ngắn nhất trong thư — phần lớn liên kết xác nhận ngừng hoạt động rất lâu trước khi 5 ngày kết thúc, và việc thư sống lâu hơn liên kết mới là trường hợp bình thường, chứ không phải ngược lại.
- Một tệp. Hãy tải nó về trong khi thư vẫn còn đó. Toàn bộ một thư bị giới hạn ở 5 MB, nên đây không bao giờ là một thao tác lớn, và tệp sẽ mất đi đúng vào khoảnh khắc thư mất đi.
- Một biên lai hay một hóa đơn. Đây là trường hợp duy nhất mà một địa chỉ dùng một lần đơn giản là sai công cụ. Hãy lưu nó vào nơi bạn vẫn giữ mọi thứ, hoặc dùng một địa chỉ bạn giữ lại lâu dài.
- Bất cứ thứ gì một bộ kiểm thử tạo ra. Hãy kiểm tra nó ngay trong lượt chạy đã tạo ra nó. Một tác vụ đọc lại hộp thư từ lượt chạy hôm qua là một tác vụ sẽ chập chờn vào đúng thứ Hai đầu tiên của một kỳ nghỉ dài.
- Bằng chứng về những gì một dịch vụ đã gửi cho bạn. Hãy lấy nó ra khỏi hộp thư ngay trong ngày nó đến. Ở đây không có chức năng xuất dữ liệu, và không có gì được ghi lại hai lần.
Xóa sớm, và vì sao một script nên làm vậy
Chờ đợi không phải là cách duy nhất để một thư ra đi. Một lượt gọi xóa một thư, và nó có hiệu lực ngay lập tức, chứ không phải chờ đến một đợt dọn dẹp nào đó sau này.
$ curl -sX DELETE -G https://grabmail.io/api/v1/message/01k4h2v9r7m3d8f0b6n5c1qtzx \
--data-urlencode "mailbox=you@grabmail.io"Với một con người, đó là sự gọn gàng. Với một script, nó gần với việc ghi sổ hơn: một hộp thư đã được dọn trống là lời khẳng định đơn giản nhất có thể có rằng mọi thứ từng ở đó đã được xử lý xong, và việc giữ cho điều đó luôn đúng không tốn kém gì cả. Phương án thay thế — một danh sách các id đã xử lý — là một danh sách phải tồn tại ở đâu đó, phải được ghi ở đâu đó, và phải được dọn dẹp ở đâu đó.
Nó không làm thay đổi gì về khoảng thời gian áp dụng cho những thứ khác, và cũng không cần phải vậy: bất cứ thứ gì bạn để lại sẽ tự ra đi theo đúng lịch của nó.
Xóa thư cuối cùng trong một hộp thư cũng xóa luôn bản ghi hộp thư đó, giống hệt như khi để nó tự hết hạn. Không có khác biệt nào ở trạng thái cuối cùng giữa việc xóa một thư và việc chờ nó tự hết hạn — chỉ khác nhau ở thời điểm.
Vì sao là 5 ngày chứ không phải ba mươi
Lý do thành thật không phải là chuyện dung lượng lưu trữ. Mà là trên một tên miền công khai, chính địa chỉ là bí mật — bất kỳ ai biết nó đều đọc được hộp thư, và đó chính xác là đặc tính cho phép bạn dùng nó mà không cần tài khoản, không cần mật khẩu, cũng không cần một email của riêng bạn để xác nhận. Vì vậy, thời gian lưu trữ không phải là một nút chỉnh mức độ hào phóng. Đó là kích thước của bán kính ảnh hưởng.
- 5 ngày là đủ dài cho mọi mục đích thực sự mà dịch vụ này hướng tới: một mã xác nhận, một liên kết tải xuống, một lượt kiểm thử, một biên lai bạn sắp chuyển sang nơi khác.
- Nó cũng đủ ngắn để một địa chỉ bạn gõ vào một biểu mẫu hồi tháng Ba sẽ không còn giữ bất cứ thứ gì vào tháng Tư, bất kể sau đó ai khác đã được trao địa chỉ ấy.
- Nó giống nhau cho tất cả mọi người, nên không có cấu hình nào để có thể cấu hình sai, và không có gói dịch vụ nào khiến thư của bạn âm thầm tồn tại lâu hơn những gì bạn từng mong đợi.
Nếu bạn còn muốn giữ bí mật cả địa chỉ, đó chính là mục đích của một alias: đưa alias ra ngoài, còn tự mình đọc ở địa chỉ thật. Bất kỳ ai thử dùng alias đó cũng sẽ luôn thấy một hộp thư trống, và hướng dẫn đăng ký mà không cần địa chỉ thật của bạn trình bày đầy đủ mẹo này.
Còn nếu điều bạn muốn là một khoảng thời gian dài hơn cho những thư bạn kiểm soát, câu trả lời là một hộp thư do chính bạn kiểm soát, chứ không phải một tùy chọn dài hơn ở đây. Trỏ một tên miền của riêng bạn vào dịch vụ này cũng không làm thay đổi khoảng thời gian đó — nó thay đổi ai là chủ sở hữu của các địa chỉ, và đó là một điều khác, đáng để khắc phục hơn nhiều.
Khi nó đã ra đi rồi
Không có gì để thử cả. Điều này đáng nói thẳng ra, vì mọi dịch vụ thư khác mà bạn từng dùng đều có một thùng rác ở đâu đó, và phản xạ tự nhiên là đi tìm thùng rác của dịch vụ này.
- Không có lưu trữ
- Không có gì được sao chép đi đâu cả trên đường ra đi.
- Không có thùng rác
- Không có trạng thái trung gian nào giữa đọc được và biến mất, và không có gì giữ một thư lại trong đó một thời gian.
- Không có ticket hỗ trợ
- Không có thao tác nào từ phía đội vận hành có thể khôi phục lại một thư đã hết hạn. Mọi con đường có thể đọc được nó đều mang cùng một mốc hết hạn, kể cả những con đường mà chính chúng tôi sẽ dùng đến.
Điều thực sự đáng làm chỉ là việc bình thường: hỏi lại người gửi. Một email xác nhận, một liên kết tải xuống và một biên lai đều là những thứ một dịch vụ sẽ cấp lại khi được yêu cầu, thường ngay từ trang bạn đang đứng. Hãy mở một địa chỉ mới trước, nếu địa chỉ cũ đã được đưa cho nhiều nơi khác.
Còn nếu thứ bạn đang chờ chưa từng xuất hiện ngay từ đầu, thì đây không phải trang bạn cần — hướng dẫn về thư không bao giờ đến nơi đi qua từng nguyên nhân theo đúng thứ tự đáng kiểm tra, bắt đầu từ nguyên nhân chỉ mất mười giây.
Trong thực tế
Toàn bộ điều đó, như một thói quen làm việc:
- Mở một địa chỉ và dùng nó. Không có gì cần kích hoạt, và không có gì bắt đầu đếm ngược.
- Làm việc mà bạn mở địa chỉ đó để làm — lấy mã, mở liên kết, tải tệp — trong khi bạn vẫn còn ở đó.
- Lấy ra khỏi hộp thư bất cứ thứ gì bạn định giữ lại, ngay trong ngày nó đến.
- Nếu một script đang đọc hộp thư đó, hãy rẽ nhánh theo
expires_atthay vì theo số lần thử lại. - Xóa những gì bạn đã xong việc, dù chỉ để hộp thư phản ánh đúng những gì còn phải làm.
- Quay lại đúng địa chỉ đó bất cứ khi nào bạn muốn. Nó sẽ vẫn ở đó, và nó sẽ trống rỗng.
Dòng cuối cùng đó mới là điều đáng nhớ nhất. Địa chỉ thì tồn tại vĩnh viễn còn thư thì không, ngược hẳn với mọi hộp thư bạn đang sở hữu — và đó chính là toàn bộ lý do vì sao hộp thư này không tốn của bạn một xu, và cũng không đòi hỏi gì ở bạn cả.
Câu hỏi
Tôi có thể lấy lại một thư sau 5 ngày không?
Không. Không có lưu trữ, không có thùng rác, và không có thao tác nào từ đội vận hành có thể khôi phục lại nó — mọi con đường có thể đọc được một thư đều mang cùng một mốc hết hạn, nên chẳng có nơi nào để nó quay trở lại từ đó.
Việc mở hay đọc một thư có làm đồng hồ chạy lại từ đầu không?
Không. Mốc hết hạn được ghi đúng một lần, ngay khi thư được chuyển đến, và không có gì tính lại nó. Đọc thư, đánh dấu đã đọc, tải lại trang, hay liệt kê hộp thư thêm lần nữa — tất cả đều để nguyên nó ở đúng chỗ cũ.
Địa chỉ có hết hạn nếu tôi ngừng dùng nó không?
Không, vì nó không được lưu trữ như một thứ có thể hết hạn. Một địa chỉ chỉ trở thành một bản ghi trong khi có thư ở trong đó, và bản ghi đó biến mất khi thư biến mất. Gõ lại đúng địa chỉ đó sau sáu tháng, nó vẫn hoạt động — trống rỗng, và sẵn sàng để bạn dùng.
Tôi có thể trả tiền để có thời gian lưu trữ dài hơn không?
Không. Chỉ có một khoảng thời gian duy nhất, và nó giống nhau trên mọi địa chỉ, mọi tên miền và mọi gói dịch vụ. Đó không phải một tùy chọn ở bất cứ đâu, và cũng không phải điều bộ phận hỗ trợ có thể nâng lên riêng cho một tài khoản.
Tệp đính kèm có tồn tại lâu bằng thư không?
Đúng bằng, không hơn không kém. Một tệp chỉ có thể truy cập được thông qua thư đã mang nó đến, và cả hai biến mất cùng một khoảnh khắc. Hướng dẫn về tệp đính kèm nói rõ giới hạn dung lượng và cách lấy một tệp ra trong khi nó vẫn còn đó.
Nếu ngày của người gửi bị sai thì sao?
Một tiêu đề Date lệch quá một ngày so với thời điểm thư đến sẽ bị bỏ qua, và thời điểm đến sẽ được dùng thay vào đó. Vậy nên một ngày sai lệch, trong trường hợp xấu nhất, chỉ có thể khiến một thư mất đi vài giờ trong khoảng thời gian của nó; nó không bao giờ có thể kéo dài thêm khoảng đó.
Thư của tôi bị xóa, hay chỉ bị ẩn đi sau mốc hết hạn?
Cả hai, theo đúng thứ tự đó. Nó ngừng đọc được ngay tại mốc hết hạn, vốn là một điều kiện áp dụng cho mọi truy vấn, và các byte được giải phóng sau đó bởi một đợt dọn dẹp mà không ai phải chờ. Ở cả hai trạng thái, bạn đều không thể đọc ra được bất cứ điều gì.
Xóa một thư có giải phóng địa chỉ ngay lập tức không?
Thư biến mất ngay lập tức, và bản ghi hộp thư biến mất cùng với thư cuối cùng trong đó. Nhưng địa chỉ đó chưa bao giờ bị giữ lại ngay từ đầu, nên chẳng có gì để giải phóng cả — nó vẫn sẵn sàng cho bạn dùng suốt từ đầu, và cho bất kỳ ai khác đoán ra nó.
Làm sao để giữ một hộp thư tồn tại cho một đợt kiểm thử kéo dài?
Bạn không cần phải làm vậy: địa chỉ không cần được giữ sống, chỉ có thư mới hết hạn. Điều một bộ kiểm thử dài thực sự cần là một địa chỉ mới cho mỗi lượt chạy, và đó chính là điều hướng dẫn kiểm thử các luồng xác minh xây dựng — một hộp thư dùng chung qua nhiều ngày là một hộp thư nơi thư của hôm qua vẫn khớp với điều kiện kiểm tra của hôm nay.
