Tệp đính kèm email tạm thời: giới hạn dung lượng và cách tải

Những gì được tính là tệp đính kèm?

Một thư là một cây gồm nhiều phần, và chỉ một số trong đó là tệp. Quy tắc ở đây cố tình rộng rãi, vì giải pháp thay thế — tin rằng người gửi luôn gắn nhãn đúng — sẽ âm thầm bỏ sót những tệp đính kèm mà một ứng dụng thư thông thường vẫn sẽ hiển thị:

Bất cứ thứ gì được gắn nhãn như vậy

Một phần có Content-Disposition ghi attachment. Đây là trường hợp thông thường, và là trường hợp mọi ứng dụng thư đều đồng thuận.

Bất cứ thứ gì mang theo tên tệp

Một phần có filename, dù được gắn nhãn kiểu gì khác đi nữa. Người gửi gắn nhãn sai liên tục, và một tệp có tên vẫn là một tệp.

Các phần có tên nhưng không phải văn bản

Một phần có name nhưng loại không phải text/…. Đây chính là cách bắt được logo trong chữ ký HTML — nên một thư có thể đến kèm những tệp đính kèm bạn không ngờ tới, mà chính người gửi cũng chưa từng nghĩ đó là tệp đính kèm.

Vì vậy, số lượng bạn thấy thường cao hơn số lượng người gửi hình dung trong đầu. Hai mươi là số tệp nhiều nhất mà một thư giữ lại; một thư mang nhiều phần có tên tệp hơn con số đó sẽ chỉ giữ hai mươi phần đầu tiên và bỏ phần còn lại — điều đáng biết trước khi bạn xây dựng bất cứ thứ gì dựa vào đó.

Tên tệp nhận từ đường truyền không bao giờ được dùng làm đường dẫn. Tệp được ghi dưới một tên do hệ thống tạo ra, còn tên gốc chỉ được mang theo như dữ liệu — nên người gửi không thể chọn nơi tệp của họ được lưu bằng cách đặt tên có dấu gạch chéo trong đó.

Giới hạn dung lượng tệp đính kèm là bao nhiêu?

Con số được công bố là 5 MB, và cần chính xác về việc nó đo cái gì: toàn bộ thư đã được mã hóa. Không phải tệp đính kèm, cũng không phải tổng các tệp đính kèm — mà là mọi thứ máy chủ gửi giao lại, sau khi mã hóa MIME đã khiến nó phình to thêm.

Base64 — cách một tệp nhị phân đi qua một giao thức vốn được xây cho văn bản — biến mỗi ba byte thành bốn byte. Cộng thêm các dấu xuống dòng mà nó cần, một tệp đến nơi lớn hơn khoảng một phần ba so với trên đĩa, và còn lớn hơn một chút nữa nếu tính cả phần đó. Tính ngược từ 5 MB, giới hạn thực tế rơi vào một tệp khoảng 3,5 MB, và còn thấp hơn nữa với một thư có chữ ký và phần HTML.

Những gì được đo

Tiêu đề, phần văn bản, phần HTML và mọi tệp đính kèm, tất cả sau khi đã mã hóa.

Số tệp đính kèm mỗi thư

Hai mươi. Trên thực tế, giới hạn dung lượng luôn đến trước.

Phần văn bản

Giữ tối đa 2 MiB mỗi phần sau khi giải mã. Nội dung dài hơn mức đó sẽ bị lưu lại ở dạng cắt bớt — điều mà một thư thông thường không bao giờ chạm tới, dù một báo cáo được tạo tự động thì có thể.

Điều gì xảy ra khi tệp quá lớn?

Tệp bị từ chối ngay từ cửa, trong lúc trao đổi SMTP, trước khi có bất cứ thứ gì được lưu lại. Một máy chủ gửi thư báo trước dung lượng ngay từ đầu sẽ bị từ chối ngay lập tức, và cuộc trao đổi kết thúc gần như thế này:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Điều đó quan trọng hơn vẻ ngoài của nó. Một dịch vụ chấp nhận thư rồi âm thầm loại bỏ sau đó sẽ khiến người gửi tin rằng thư đã được chuyển đi, còn bạn thì chờ đợi thứ sẽ chẳng bao giờ xuất hiện. Một lời từ chối ngay tại thời điểm SMTP là một thất bại thật sự, được báo cho một người thật sự: người gửi nhận được một bounce kèm lý do bên trong.

Một người gửi không báo trước dung lượng sẽ nhận được câu trả lời tương tự vào cuối thư, ngay sau khi máy chủ thư tự đếm xong số byte. Dù theo cách nào, cũng không có gì lọt vào hộp thư và không có gì đến ở dạng cắt cụt.

Cách tải tệp đính kèm từ hộp thư

Trên trình duyệt, mọi thứ nằm đúng chỗ bạn nghĩ. Mở thư ra, các tệp đính kèm được liệt kê ngay bên dưới, mỗi tệp kèm theo tên mà người gửi đặt cho nó và dung lượng thực sự đã đến.

1. Mở thư ra. Danh sách tự làm mới, nên một tệp đến trong lúc bạn đang xem hộp thư sẽ xuất hiện mà không cần tải lại trang.
2. Đọc tên và dung lượng trước khi nhấp vào. Cả hai đều là sự thật về những gì đã đến, và đó là thứ cuối cùng bạn thấy trước khi tệp nằm trên máy của bạn.
3. Nhấp vào đó. Tệp được tải xuống. Nó không bao giờ mở trực tiếp trong trình duyệt, dù nó tự nhận là gì đi nữa — phần tiếp theo sẽ giải thích vì sao đó là một tính năng chứ không phải một thiếu sót.

Hình ảnh từ xa trong nội dung thư bị chặn cho đến khi bạn yêu cầu hiển thị, và đó là chuyện khác hẳn với tệp đính kèm: một hình ảnh bị chặn được tải về từ chính máy chủ của người gửi ngay khi bạn cho phép, còn tệp đính kèm đã đi kèm sẵn với thư và không được tải về từ bất kỳ ai cả.

Cách tải tệp đính kèm qua API

Đọc một thư sẽ trả về các tệp đính kèm của nó dưới dạng danh sách, và mỗi tệp đi kèm sẵn một URL đã được dựng sẵn:

"attachments": [
  {
    "id":       "01JR8W2K4QATT1",
    "filename": "invoice.pdf",
    "mime":     "application/pdf",
    "size":     184320,
    "url":      "/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"
  }
]

URL đó chỉ là một GET thông thường với hộp thư là một tham số truy vấn, và trên các tên miền công khai, nó không cần thêm gì khác — không khóa, không phiên đăng nhập, không tài khoản:

curl -OJ "https://grabmail.io/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"

-OJ báo cho curl lưu tệp dưới tên mà máy chủ gửi về, thay vì dưới id. Endpoint trả về một trong ba thứ: tệp, một 404 nếu không có tệp đính kèm đó trong hộp thư ấy hoặc nó đã hết hạn, hoặc một 429 nếu bạn hỏi nhiều hơn một lần mỗi giây.

Id của một tệp đính kèm chỉ có giá trị trong phạm vi hộp thư của nó, nên một id lấy từ địa chỉ này sẽ là 404 ở địa chỉ khác. Không có endpoint nào liệt kê tệp đính kèm một cách độc lập — chúng luôn đi kèm với thư của mình và được đọc ra từ đó. Tài liệu tham khảo API có đầy đủ cấu trúc của một phản hồi thư.

Vì sao mọi tệp đều tải về dưới dạng nhị phân?

Dù người gửi khai báo tệp của họ là gì, nó vẫn được trả về dưới dạng application/octet-stream và được tải xuống thay vì mở ra. Đây không phải là sự cẩu thả về loại nội dung — đó là câu trả lời an toàn duy nhất khi tệp đến từ một người lạ.

Loại tệp do người gửi khai báo không bao giờ được trả lại nguyên vẹn

Ai đó gắn nhãn tệp của mình là text/html và khiến nó được hiển thị trên nguồn gốc của chúng tôi thì coi như đang chạy trang của họ dưới danh nghĩa chúng tôi, trong phiên của bạn, với bất cứ quyền truy cập nào điều đó mang lại. Vì vậy nhãn đó bị bỏ đi, và bên gọi tự quyết định tệp là gì dựa trên phần siêu dữ liệu đi kèm.

Luôn là tải xuống, không bao giờ là xem trực tiếp

Content-Disposition: attachment có mặt trên mọi phản hồi, nên không có gì được hiển thị tại chỗ, dù nó được gắn nhãn là gì.

Không dò đoán loại tệp, và không gì được phép chạy

X-Content-Type-Options: nosniff ngăn trình duyệt tự đoán loại tệp, còn Content-Security-Policy với giá trị default-src 'none'; sandbox nghĩa là ngay cả khi có thứ gì đó được hiển thị, nó cũng không thể tải hay chạy được bất cứ thứ gì.

Tên tệp không thể biến thành một tiêu đề

Tên tệp được mã hóa thay vì dán thẳng vào phản hồi, nên một tệp có tên chứa ký tự xuống dòng cũng không thể tự chèn thêm một tiêu đề tùy ý.

Bản thân tệp thì không bị đụng đến — từng byte đúng như những gì người gửi đã gửi. Chỉ có phần khung bao quanh nó là cố tình được làm cho tẻ nhạt. Tệp cũng được lưu bên ngoài thư mục gốc của web, nên đoán đường dẫn không phải là cách để lọt vào: hộp thư phải được xác định và cấp quyền trước khi tệp được đọc.

Tệp đính kèm có được quét virus không?

Không có phần mềm diệt virus, không có môi trường sandbox để kích nổ thử, và không có kiểm tra uy tín nguồn gửi. Đây là một giới hạn được nêu rõ chứ không phải một thiếu sót, và nó ảnh hưởng đến những gì bạn có thể làm một cách an toàn với thứ vừa đến:

• Bất kỳ ai cũng có thể gửi đến một địa chỉ công khai. Họ không cần biết bạn là ai — họ chỉ cần biết địa chỉ, và những địa chỉ ngắn thì bị đoán ra. Một tệp trong hộp thư công khai mặc định có tác giả không xác định.
• Tệp thực thi và script nguy hiểm ở đây không khác gì bất cứ nơi nào khác. Không có gì bị lọc theo phần mở rộng, và không có gì mở tệp nén ra để xem bên trong có gì.
• Những tài liệu có thể chạy được thứ gì đó mới là trường hợp phổ biến. Tệp văn phòng có bật macro và PDF chứa hành động nhúng sẵn mới là cách phần lớn chuyện này thực sự xảy ra, chứ không phải các tệp thực thi lộ liễu.
• Tên tệp không nói lên điều gì. Một tệp tên invoice.pdf thực chất là gì thì do các byte bên trong nó quyết định, còn phần mở rộng là do bất kỳ ai gửi nó tự chọn.

Tệp đính kèm lưu được bao lâu?

Một tệp đính kèm không có vòng đời riêng. Nó thuộc về thư chứa nó, và biến mất khi thư đó biến mất:

Sau 5 ngày

Bị xóa cùng với thư, dù đã đọc hay chưa, theo một chiếc đồng hồ bắt đầu tính từ lúc thư đến. Không có lưu trữ, không có xuất dữ liệu.

Khi bạn xóa thư

Ngay lập tức, và URL trở thành 404. Kết quả như nhau dù bạn xóa từ hộp thư hay qua API.

Không có đường quay lại

Không có khôi phục, không có thời gian ân hạn, và không có hộp thư hỗ trợ nào để hỏi. Bất cứ thứ gì bạn sẽ cần đến vào ngày mai đều phải được tải về ngay hôm nay.

Khi nào không nên dùng email để gửi tệp?

Một số việc người dùng cố làm với tệp đính kèm ở đây không phải là giới hạn cần lách qua — mà là dùng sai công cụ cho công việc đó:

• Một tệp vượt quá giới hạn. Không có gì nâng được giới hạn này lên. Hãy gửi một liên kết thay vào đó.
• Thứ gì đó bạn sẽ cần đến vào tháng sau. 5 ngày là một giới hạn cứng do một tác vụ tự động thực thi, chứ không phải một tùy chọn có thể chỉnh. Hãy tải nó về ngay bây giờ, hoặc dùng một hộp thư thật.
• Bất cứ thứ gì bạn sẽ không muốn một người lạ đọc được. Trên một tên miền công khai, địa chỉ là ổ khóa duy nhất trên cánh cửa, và đó là một ổ khóa ngắn.

Một tên miền của riêng bạn thay đổi điều thứ ba trong số đó nhưng không thay đổi hai điều đầu: giới hạn dung lượng và thời gian lưu trữ vẫn y nguyên, nhưng địa chỉ khi đó nằm trên một tên miền không xuất hiện ở bất kỳ đâu trên trang này, nên không ai gửi tệp đến đó bằng cách đoán mò. Chỉ cần một bản ghi MX là đủ:

Bản ghi MX cho tên miền của bạn10 smtp.grabmail.ioSao chép

Hướng dẫn đầy đủ, từng bước, ở đây — bản ghi cần thêm, nó chứng minh điều gì, và những giới hạn thực sự của một hộp thư không có mật khẩu bảo vệ.

Câu hỏi