Lampiran Email Sekali Pakai: Ukuran Maksimal & Keamanan

Apa yang dianggap lampiran email?

Sebuah pesan adalah rangkaian bagian-bagian, dan hanya sebagian yang berupa berkas. Aturan di sini sengaja dibuat longgar, karena alternatifnya — memercayai pengirim untuk memberi label yang benar — diam-diam menghilangkan lampiran yang sebenarnya akan ditampilkan oleh klien email biasa:

Apa pun yang ditandai sebagai lampiran

Bagian yang Content-Disposition-nya berisi attachment. Kasus paling umum, dan yang disepakati oleh semua klien email.

Apa pun yang membawa nama berkas

Bagian yang memiliki filename, apa pun label lain yang menyertainya. Pengirim sering salah memberi label, dan berkas yang punya nama tetaplah berkas.

Bagian bernama yang bukan teks

Bagian yang punya name dengan jenis selain text/…. Inilah yang menangkap logo pada tanda tangan HTML — jadi sebuah pesan bisa tiba dengan lampiran yang tidak Anda duga, yang bahkan tidak dianggap lampiran oleh pengirimnya.

Jadi jumlah yang Anda lihat sering kali lebih banyak daripada yang dimaksudkan pengirim. Dua puluh adalah jumlah maksimum yang disimpan satu pesan; pesan yang membawa bagian dengan nama berkas lebih dari itu hanya menyimpan dua puluh yang pertama dan membuang sisanya — penting diketahui sebelum Anda membangun sesuatu di atasnya.

Nama berkas yang datang dari jaringan tidak pernah dipakai sebagai path. Berkas ditulis dengan nama yang dibuat sistem, dan nama aslinya disertakan sebagai data terpisah, sehingga pengirim tidak bisa menentukan sendiri lokasi berkasnya dengan menyisipkan garis miring pada namanya.

Berapa batas ukuran lampiran email sekali pakai?

Angka yang dipublikasikan adalah 5 MB, dan penting untuk tepat soal apa yang diukurnya: seluruh pesan yang sudah dienkode. Bukan lampirannya saja, bukan jumlah semua lampiran — melainkan segala sesuatu yang diserahkan server pengirim, setelah pengkodean MIME membuatnya lebih besar.

Base64 — cara sebuah biner melewati protokol yang dibuat untuk teks — mengubah setiap tiga byte menjadi empat. Tambahkan pemutusan baris yang dibutuhkannya, dan berkas tiba sekitar sepertiga lebih besar daripada ukurannya di disk, sedikit lebih lagi kalau itu ikut dihitung. Dihitung mundur dari 5 MB, batas sebenarnya berada di sekitar berkas 3,5 MB, dan lebih rendah lagi untuk pesan yang punya tanda tangan dan bagian HTML.

Apa yang diukur

Header, bagian teks, bagian HTML, dan setiap lampiran, semuanya setelah dienkode.

Lampiran per pesan

Dua puluh. Dalam praktiknya, batas ukuran akan tercapai lebih dulu.

Bagian teks

Disimpan hingga 2 MiB masing-masing setelah didekode. Isi yang lebih panjang dari itu disimpan dalam keadaan terpotong — email biasa tidak akan pernah mendekati itu, meski laporan hasil generate bisa saja.

Apa yang terjadi kalau berkas terlalu besar?

Ditolak di depan pintu, selama percakapan SMTP berlangsung, sebelum apa pun tersimpan. Server pengirim yang mengumumkan ukurannya lebih dulu langsung ditolak, dan percakapannya berakhir kira-kira seperti ini:

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

Ini lebih penting daripada kelihatannya. Layanan yang menerima pesan lalu membuangnya belakangan akan membuat pengirim percaya pesannya sudah terkirim, sementara Anda menunggu sesuatu yang tidak akan pernah muncul. Penolakan pada saat SMTP adalah kegagalan nyata yang dilaporkan ke orang sungguhan: pengirim menerima bounce lengkap dengan alasannya.

Pengirim yang tidak mengumumkan ukurannya lebih dulu akan mendapat jawaban yang sama di akhir pesan, setelah server mail menghitung sendiri jumlah byte-nya. Bagaimanapun caranya, tidak ada yang masuk ke kotak surat dan tidak ada yang tiba dalam keadaan terpotong.

Cara mengunduh lampiran dari kotak masuk

Di browser, lampiran ada di tempat yang Anda duga. Buka pesannya, dan lampiran akan terdaftar di bawahnya, masing-masing dengan nama yang diberikan pengirim dan ukuran yang benar-benar tiba.

1. Buka pesannya. Daftarnya memperbarui diri sendiri, jadi berkas yang tiba saat Anda sedang melihat kotak surat akan langsung muncul tanpa perlu memuat ulang.
2. Baca nama dan ukurannya sebelum mengklik. Keduanya adalah fakta tentang apa yang tiba, dan itulah hal terakhir yang Anda lihat sebelum berkasnya ada di komputer Anda.
3. Klik lampirannya. Berkasnya terunduh. Berkas tidak pernah terbuka di browser, apa pun yang diklaimnya sebagai jenisnya — bagian berikutnya menjelaskan kenapa itu justru sebuah fitur, bukan kekurangan.

Gambar jarak jauh di isi pesan diblokir sampai Anda memintanya ditampilkan, dan itu hal yang berbeda dari lampiran: gambar yang diblokir diambil dari server milik pengirim begitu Anda mengizinkannya, sedangkan lampiran datang bersama pesan dan tidak diambil dari mana pun.

Cara mengunduh lampiran lewat API

Membaca sebuah pesan akan mengembalikan lampirannya sebagai daftar, dan masing-masing sudah dilengkapi URL siap pakai:

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

URL itu adalah GET biasa dengan kotak surat sebagai parameter query, dan pada domain publik tidak dibutuhkan apa pun lagi — tanpa kunci, tanpa sesi, tanpa akun:

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

-OJ memberi tahu curl untuk menyimpan berkas dengan nama yang dikirim server, bukan dengan id-nya. Endpoint ini menjawab dengan salah satu dari tiga hal: berkasnya, 404 kalau lampiran itu tidak ada di kotak surat tersebut atau sudah kedaluwarsa, atau 429 kalau Anda meminta lebih dari sekali per detik.

Id lampiran terikat pada kotak suratnya, jadi id dari satu alamat akan menghasilkan 404 di alamat lain. Tidak ada endpoint yang mendaftar lampiran secara terpisah — lampiran datang bersama pesannya dan dibaca dari sana. Referensi API memuat bentuk lengkap respons sebuah pesan.

Kenapa semua lampiran terunduh sebagai biner?

Apa pun jenis yang diklaim pengirim untuk berkasnya, ia tetap kembali sebagai application/octet-stream dan langsung terunduh, bukan terbuka. Ini bukan kelalaian soal jenis konten — ini satu-satunya jawaban aman ketika berkas datang dari orang asing.

Jenis dari pengirim tidak pernah dikembalikan

Siapa pun yang memberi label text/html pada berkasnya dan berhasil membuatnya dirender di origin kami, pada dasarnya menjalankan halamannya sendiri sebagai kami, di dalam sesi Anda, dengan segala akses yang itu berikan. Karena itu labelnya dibuang, dan pemanggil yang menentukan sendiri jenis berkasnya dari metadata di sebelahnya.

Selalu diunduh, tidak pernah dibuka langsung

Content-Disposition: attachment ada di setiap respons, jadi tidak ada apa pun yang dirender langsung, apa pun labelnya.

Tidak ada penebakan jenis, dan tidak ada yang boleh berjalan

X-Content-Type-Options: nosniff menghentikan browser menebak-nebak jenis berkasnya, dan Content-Security-Policy berupa default-src 'none'; sandbox berarti bahkan kalau sesuatu sempat dirender, ia tidak bisa memuat apa pun dan tidak bisa menjalankan apa pun.

Nama berkas tidak bisa menjadi header

Namanya dienkode, bukan ditempel langsung ke dalam respons, sehingga berkas yang diberi nama dengan karakter baris baru di dalamnya tidak bisa menambahkan header pilihannya sendiri.

Berkasnya sendiri tidak diubah — byte demi byte persis seperti yang dikirim pengirim. Yang sengaja dibuat membosankan adalah bungkus di sekelilingnya. Berkas juga disimpan di luar web root, sehingga menebak-nebak path bukan jalan masuk: kotak suratnya harus dikenali dan diotorisasi lebih dulu sebelum berkasnya sama sekali bisa dibaca.

Apakah lampiran dipindai virus?

Tidak ada antivirus, tidak ada peledakan sandbox, dan tidak ada pemeriksaan reputasi. Ini batasan yang memang dinyatakan, bukan kelalaian, dan itu mengubah apa yang bisa Anda lakukan dengan aman terhadap apa pun yang tiba:

• Siapa pun bisa mengirim ke alamat publik. Mereka tidak perlu mengenal Anda — mereka hanya perlu tahu alamatnya, dan alamat yang pendek mudah ditebak. Secara default, berkas di kotak surat publik berasal dari pengirim yang tidak diketahui.
• Berkas eksekutabel dan skrip sama berbahayanya di sini seperti di tempat lain mana pun. Tidak ada yang disaring berdasarkan ekstensi, dan tidak ada yang memeriksa isi sebuah arsip.
• Dokumen yang bisa menjalankan sesuatu justru kasus yang paling umum. Berkas office dengan makro aktif dan PDF dengan aksi tersemat adalah cara kebanyakan hal ini sebenarnya terjadi, bukan berkas eksekutabel yang jelas-jelas mencurigakan.
• Namanya tidak memberi tahu apa-apa. Berkas bernama invoice.pdf adalah apa pun yang dikatakan oleh byte-nya, dan ekstensinya dipilih oleh siapa pun yang mengirimnya.

Kapan lampiran hilang?

Lampiran tidak punya masa hidup sendiri. Ia melekat pada pesannya, dan hilang begitu pesannya hilang:

Setelah 5 hari

Terhapus bersama pesannya, dibaca atau tidak, dengan hitungan waktu yang dimulai sejak pesan itu tiba. Tidak ada arsip dan tidak ada ekspor.

Saat Anda menghapus pesannya

Seketika itu juga, dan URL-nya berubah menjadi 404. Sama saja apakah Anda menghapus dari kotak masuk atau lewat API.

Tidak ada jalan kembali

Tidak ada pembatalan hapus, tidak ada masa tenggang, dan tidak ada kotak surat dukungan untuk ditanyai. Apa pun yang akan Anda butuhkan besok harus diunduh hari ini.

Kapan email bukan cara yang tepat?

Sebagian hal yang coba dilakukan orang dengan lampiran di sini bukan batasan yang perlu diakali — itu memang alat yang salah untuk pekerjaan itu:

• Berkas yang melebihi batas. Tidak ada yang bisa menaikkannya. Kirim tautan saja sebagai gantinya.
• Sesuatu yang akan Anda butuhkan bulan depan. 5 hari adalah batas keras yang dijalankan oleh sebuah proses otomatis, bukan pengaturan. Ambil sekarang, atau gunakan kotak surat sungguhan.
• Apa pun yang Anda keberatan dibaca orang asing. Pada domain publik, alamat adalah satu-satunya kunci pintu, dan kuncinya pendek.

Domain milik Anda sendiri mengubah yang ketiga dari daftar itu, tapi tidak mengubah dua yang pertama: batas ukuran dan masa retensinya tetap persis sama, tapi alamatnya berada di nama yang tidak muncul di mana pun pada situs ini, jadi tidak ada yang bisa mengirim berkas ke sana dengan menebak-nebak. Satu rekaman MX sudah cukup:

Rekaman MX untuk domain Anda10 smtp.grabmail.ioSalin

Panduan lengkapnya ada di sini — rekamannya, apa yang dibuktikan dengan mempublikasikannya, dan batasan jujur dari kotak surat tanpa kata sandi.

Pertanyaan