Ambil satu pesan. Sebuah toko rekaan, Bright Parcel, baru saja didaftari seorang pengunjung dengan alamat quietfox42@veylax.com, dan sistemnya menekan semacam tombol Kirim untuk email konfirmasi. Sesaat kemudian pesan itu ada di layar pengunjung, dan sehari sesudahnya ia tidak ada lagi di mana pun pada layanan kotak masuk itu. Artikel ini mengikutinya sepanjang jalan.
Jadi, bagaimana cara kerja temp mail? Ia memakai mesin email internet yang biasa, dengan satu keunikan: sisi penerima menerima email untuk nama pengguna apa pun di domainnya dan menyimpannya hanya sebentar. Server pengirim mencari record MX domain itu di DNS, terhubung ke host yang tercantum lewat SMTP di port 25, dan mengantarkan pesannya. Sistem temp mail lalu menguraikannya, menampilkannya di kotak masuk, dan menghapusnya sesuai jadwal. Di VookMail, record MX domainnya mengarah ke penyedia pengiriman email, yang menerima sesi SMTP dan meneruskan setiap pesan ke VookMail lewat HTTPS.
Tahap 1: Meninggalkan pengirim
Aplikasi Bright Parcel menyusun pesannya. Pesan adalah teks terstruktur, ditata menurut Internet Message Format (RFC 5322): header seperti From, To, dan Subject, lalu satu baris kosong, lalu isi pesan. Aplikasi biasanya tidak mengantarkannya langsung. Ia menyerahkannya ke layanan email keluar, lewat koneksi SMTP terautentikasi di port 587 (atau 465 dengan TLS sejak awal) atau lewat API web milik perusahaan pengirim.
Penundaan pertama bisa terjadi tepat di sini. Banyak aplikasi menaruh email keluar ke dalam antrean pekerjaan dan memprosesnya per kelompok, terutama platform pemasaran. Jadi saat sebuah situs bilang "periksa email Anda" bisa jadi masih cukup jauh dari saat email benar-benar keluar. Pada contoh kita, anggap antreannya memakan dua puluh detik. Belum ada apa pun yang sampai ke sisi penerima, dan tidak ada layanan temp mail yang bisa melihat atau mempercepatnya.
Tahap 2: Mencari tahu ke mana veylax.com menerima emailnya
Server keluar membaca bagian setelah @, dalam hal ini veylax.com, dan menanyakan record MX domain itu ke DNS. Record MX (mail exchanger) menyebut server yang menerima email untuk domain tersebut. Dalam notasi zone file, beginilah record sebuah domain bisa terlihat. Namanya dikarang untuk ilustrasi:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
Angka 3600 adalah TTL (time to live), jumlah detik yang boleh dipakai resolver untuk menyimpan jawaban ini. Angka 10 dan 20 adalah preferensi: pengirim mencoba angka terkecil lebih dulu dan beralih ke yang lebih besar jika yang pertama tidak terjangkau. Nama host harus punya record A (IPv4) atau AAAA (IPv6) sendiri. Record MX seharusnya menunjuk ke nama host, bukan langsung ke alamat IP atau ke alias CNAME.
Anda bisa menjalankan pencarian ini sendiri untuk domain mana pun:
| Sistem | Perintah |
|---|---|
| Command Prompt Windows | nslookup -type=mx example.com |
| PowerShell Windows | Resolve-DnsName example.com -Type MX |
| macOS dan Linux | dig MX example.com +short |
Sistem antipenyalahgunaan memakai pencarian yang sama untuk mengenali domain yang mengarahkan email ke infrastruktur sekali pakai yang dikenal. Itu salah satu alasan sebagian situs web mengenali domain temp mail bahkan ketika domainnya sendiri baru.
Dua kasus tepi di DNS
Domain tanpa record MX tidak otomatis tak terjangkau. RFC 5321, standar SMTP, mendefinisikan cadangan: pengirim boleh menganggap record A atau AAAA milik domain itu sendiri sebagai host email tersirat. Domain yang tidak mau menerima email sama sekali bisa menyatakannya dengan null MX (RFC 7505), yaitu record MX dengan preferensi 0 dan satu titik sebagai host. Domain temp mail tentu menerbitkan record MX yang normal, karena menerima email adalah seluruh tujuannya.
Caching juga bisa mengganggu ketika layanan menambah domain. Resolver yang baru saja mendapat jawaban "tidak ada record" mungkin menyimpannya sampai masa negative cache habis, sebagaimana diatur oleh record SOA domain (RFC 2308). Domain yang benar-benar baru karena itu bisa butuh waktu sebelum dapat menerima dengan andal dari setiap pengirim.
Tahap 3: Percakapan antara dua server
Server keluar Bright Parcel kini membuka koneksi TCP ke host MX yang diutamakan di port 25. SMTP adalah protokol teks: klien mengirim perintah dan server menjawab dengan balasan bernomor. Berikut sesi yang disederhanakan untuk pesan kita, dengan S: adalah penerima dan C: adalah pengirim. Host dan angka ukurannya milik contoh rekaan ini.
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
(TLS handshake, then EHLO again)
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: (headers, blank line, body, then a line with a single dot)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Perintah | Tujuan | Artinya bagi temp mail |
|---|---|---|
EHLO | Memperkenalkan pengirim dan menanyakan apa yang didukung server | Balasannya mencantumkan ekstensi seperti STARTTLS dan SIZE maksimum |
STARTTLS | Meningkatkan koneksi ke TLS (RFC 3207) | Melindungi satu lompatan ini. Bukan enkripsi ujung ke ujung |
MAIL FROM | Menetapkan pengirim amplop, tempat bounce dikirim | Sering berbeda dari baris From yang terlihat, terutama pada pengirim massal |
RCPT TO | Menyebut penerima | Penerima catch-all menjawab 250 untuk nama pengguna apa pun di domainnya |
DATA | Memulai isi pesan | Diakhiri dengan satu titik di barisnya sendiri |
QUIT | Menutup sesi | Pengiriman sudah ditetapkan oleh 250 setelah DATA |
Saat tanggung jawab berpindah tangan
250 yang terakhir itu adalah baris terpenting dalam sesi. Sampai saat itu, pesan masih milik server Bright Parcel, dan jika koneksi putus ia mencoba lagi. Sesudahnya, penerima telah menerima tanggung jawab. Dasbor pengirim kini biasanya akan menulis "terkirim", yang hanya berarti lompatan ini berhasil. Itu tidak berarti ada orang yang melihat sesuatu.
Kode balasan menjelaskan banyak perilaku yang dilihat orang:
- 2xx berarti sukses, dan
250berarti diterima. - 3xx adalah langkah perantara, dan
354memberi tahu pengirim untuk mengirimkan pesannya. - 4xx adalah kegagalan sementara, misalnya
421atau451. Pengirim menyimpan pesan di antreannya dan mencoba lagi. - 5xx adalah kegagalan permanen, misalnya
550(kotak surat tidak tersedia atau ditolak) atau552(terlalu besar). Pengirim menyerah dan biasanya membuat pesan bounce.
Perbedaan antara 4xx dan 5xx menjelaskan sebagian besar email yang "lambat". Seandainya penerima menjawab 451 di titik ini, mungkin karena greylisting (RFC 6647), pesan kita akan duduk di antrean Bright Parcel, tidak hilang dan tidak terkirim. RFC 5321 menyarankan selang percobaan ulang umumnya minimal 30 menit dan batas menyerah minimal empat sampai lima hari, meskipun sistem nyata menetapkan jadwalnya sendiri, dan banyak yang mencoba ulang lebih cepat. Itulah sebabnya satu konfirmasi bisa muncul dalam beberapa detik dan konfirmasi berikutnya dua puluh menit kemudian, tanpa ada yang salah pada keduanya.
Dua set alamat
SMTP punya dua lapis pengalamatan. Amplop, yaitu MAIL FROM dan RCPT TO, adalah yang dipakai server untuk perutean. Header, yaitu From:, To:, dan Subject:, adalah bagian dari isi pesan dan itulah yang Anda lihat di layar. Keduanya bisa berbeda. Buletin mungkin menampilkan To: subscribers padahal penerima amplopnya adalah alamat sementara Anda. Karena itu sistem penerima mengarsipkan pesan menurut penerima amplop, nilai yang dapat diandalkan. Itu juga sebabnya header Return-Path, yang ditambahkan saat pengiriman akhir, mencatat pengirim amplop, bukan alamat From yang terlihat.
Tahap 4: Mengapa quietfox42 tidak perlu ada lebih dulu
Pada RCPT TO, server email biasa memeriksa apakah kotak suratnya ada dan menjawab 550 jika tidak. Domain temp mail bekerja sebaliknya. Ia berjalan sebagai penerima catch-all, atau wildcard: setiap bagian lokal (bagian sebelum @) diterima.
Satu pilihan itulah yang memungkinkan alamat instan. Ketika VookMail menampilkan alamat acak, tidak ada yang perlu dibuat di server email mana pun. Ketika Anda menekan Baru, mengetik nama pengguna sendiri, memilih domain, dan menekan tanda panah, nama itu sudah "ada", karena domainnya menerima semua nama. Aplikasi hanya perlu menampilkan pesan yang penerimanya cocok dengan alamat di layar Anda.
Dua aturan kecil berlaku untuk nama-nama itu. Standar mengatakan bagian lokal boleh peka huruf besar-kecil, tetapi hampir semua sistem nyata memperlakukan Test@ dan test@ sebagai satu kotak surat, jadi sistem temp mail wajar menormalkan huruf agar kapitalisasi pengirim tidak memecah satu kotak masuk menjadi dua. Dan RFC 5321 membatasi bagian lokal hingga 64 oktet, dengan batas praktis 254 karakter untuk seluruh alamat, sehingga nama yang dibuat otomatis sebaiknya jauh di bawah itu.
Tahap 5: Dari protokol email ke permintaan web
Pesan kita kini telah diterima oleh mesin yang berbicara SMTP. Situs web yang menampilkan kotak masuk adalah aplikasi web. Harus ada sesuatu yang menghubungkan keduanya.
Menjalankan server email yang menghadap seluruh internet adalah pekerjaan berat: TLS, banjir koneksi, antrean, malware, dan menjaga reputasi tetap baik. Jadi banyak aplikasi modern menyerahkan sisi SMTP kepada penyedia penerima khusus dan menerima pesan sebagai permintaan web, pola yang sering disebut inbound parse webhook. VookMail memakai model ini. Begini jalannya:
- Host MX penyedia menerima pesan dari server pengirim, seperti pada sesi di atas.
- Penyedia mengemasnya, entah sebagai sumber MIME mentah atau sebagai kolom yang sudah diurai seperti pengirim, penerima, subjek, teks, HTML, dan lampiran.
- Ia mengirim paket itu lewat HTTPS POST ke endpoint yang dijalankan aplikasi temp mail, yang mengenkripsi isi di antara kedua titik itu.
- Aplikasi menjawab dengan status sukses. Jika tidak terjangkau atau mengembalikan kesalahan, penyedia yang baik mencoba ulang sesuai kebijakannya sendiri.
- Aplikasi memvalidasi permintaan, mencocokkan penerima dengan sebuah alamat, dan menyimpan pesan untuk sementara.
| Hal yang diperhatikan | Penerima SMTP yang dihosting sendiri | Penyedia penerima plus HTTPS |
|---|---|---|
| Keterpaparan | Port 25 terbuka bagi setiap host di internet | Penyedia menangani lalu lintas SMTP, dan aplikasi hanya melihat permintaan HTTPS |
| Lonjakan lalu lintas | Operator harus menyediakan kapasitas | Infrastruktur penyedia menangani lonjakan |
| Penguraian MIME | Operator menulis atau merawat parser | Sering dikerjakan penyedia, meski sumber mentah tetap bisa dipakai |
| Kecocokan dengan aplikasi web | Butuh jembatan dari spool email ke aplikasi | Pesan tiba seperti permintaan API biasa |
| Ketergantungan | Lebih sedikit pihak luar | Bergantung pada ketersediaan dan konfigurasi penyedia |
Baris terakhir adalah biaya yang nyata. Jika penyedia penerima mengalami gangguan atau masalah konfigurasi, pengiriman ke setiap domain di baliknya bisa berhenti sampai diperbaiki, bahkan ketika situs temp mail itu sendiri berjalan normal. Pesan yang ditolak dengan kesalahan sementara selama masa itu mungkin tetap masuk ketika pengirim aslinya mencoba ulang, tergantung berapa lama antrean mereka menahannya.
Melindungi endpoint
Endpoint webhook adalah URL publik, sehingga siapa pun bisa mencoba mengirim pesan palsu ke sana. Implementasi yang cermat biasanya menggabungkan beberapa pertahanan:
- Verifikasi tanda tangan, ketika penyedia menandatangani setiap permintaan dan aplikasi menolak yang tidak cocok.
- Jalur rahasia atau token yang hanya diketahui penyedia dan aplikasi.
- Membatasi permintaan pada rentang alamat yang dipublikasikan penyedia, jika ada.
- Batas ukuran, yang menolak muatan terlalu besar sejak dini untuk melindungi memori dan penyimpanan.
- Idempotensi. Penyedia mencoba ulang, jadi pesan yang sama bisa tiba dua kali, dan Message-ID atau ID kejadian penyedia mencegah duplikat.
Tahap 6: Membongkar pesan
Yang tiba belum berupa sesuatu yang nyaman dibaca manusia. MIME (Multipurpose Internet Mail Extensions, RFC 2045 dan seterusnya) memungkinkan satu pesan membawa beberapa bagian dalam format berbeda. Email konfirmasi kita mungkin tersusun seperti ini, dengan faktur ditambahkan sebagai contoh:
| Bagian | Isinya |
|---|---|
multipart/mixed | Wadah terluar ketika ada lampiran |
multipart/alternative | Isi yang sama dua kali, sebagai text/plain dan text/html. Pembaca menampilkan bentuk terkaya yang didukungnya |
multipart/related | HTML yang dikelompokkan dengan gambar sebaris, dirujuk lewat pengenal cid: |
| Bagian lampiran | Header Content-Disposition: attachment dan nama berkas, lalu data berkas yang dikodekan |
Di atas semua itu ada header, termasuk Message-ID, Date, dan baris jejak Received, yang mencatat setiap server yang dilewati pesan. Jika suatu saat Anda ingin tahu di mana penundaan terjadi, cap waktu pada baris Received adalah tempat untuk mencarinya.
Parser juga harus membalik beberapa pengodean. Base64 membawa lampiran biner dan membesarkannya sekitar sepertiga, sehingga berkas 10 MB menjadi pesan sekitar 13 sampai 14 MB. Quoted-printable menangani teks yang sebagian besar ASCII dengan menulis karakter khusus sebagai =XX. Nilai charset= menyatakan bagaimana teks dikodekan, umumnya UTF-8, yang sangat penting bagi layanan yang dipakai dalam banyak bahasa. Dan baris subjek dengan karakter non-ASCII memakai sintaks =?UTF-8?B?...?= atau =?UTF-8?Q?...?= dari RFC 2047.
Membuat HTML aman untuk ditampilkan
HTML email ditulis oleh orang asing, jadi penampil tidak boleh membiarkannya menjalankan kode dalam konteks situs web. Implementasi yang cermat umumnya menghapus skrip, atribut penangan kejadian, dan skema URL berbahaya, lalu menampilkan pesan di bingkai terisolasi agar gaya dan isinya tidak memengaruhi halaman di sekitarnya.
Gambar jarak jauh juga perlu dipikirkan. Memuatnya memberi tahu pengirimnya bahwa pesan telah dibuka, begitulah cara kerja piksel pelacak. VookMail menghapus piksel pelacak tersembunyi dan menahan gambar sampai Anda mengizinkannya.
Penampil juga bisa melakukan hal berguna dengan teks yang sudah diurai. Untuk pesan konfirmasi kita, VookMail menampilkan kode verifikasi atau tautan konfirmasi di atas pesan, sehingga tidak ada yang perlu menggulir templat panjang untuk menemukannya.
Lampiran
Lampiran didekode dan disimpan sementara agar bisa diunduh. Di VookMail, berkas program umum seperti .exe, .bat, dan .apk ditolak, arsip seperti .zip menampilkan peringatan, dan ukuran maksimum berlaku. Lampiran dihapus bersama pesannya. Ingat bahwa keamanan sebuah berkas tidak ada hubungannya dengan tempat penyimpanannya: dokumen berisi makro sama berbahayanya ketika diunduh dari kotak masuk sementara.
Tahap 7: Sampai ke layar
Pesan kita kini tersimpan, tetapi browser yang menampilkan quietfox42@veylax.com belum tahu. Aplikasi web punya beberapa cara untuk mengetahuinya:
| Teknik | Cara kerja | Untung-rugi |
|---|---|---|
| Short polling | Halaman bertanya ke server setiap beberapa detik | Sederhana dan andal, tetapi membuat permintaan berulang |
| Long polling | Satu permintaan tetap terbuka sampai ada kabar atau habis waktu | Lebih sedikit jawaban kosong, lebih banyak koneksi terbuka |
| Server-Sent Events | Satu aliran berumur panjang dari server ke browser | Efisien satu arah, tersambung ulang dengan sendirinya |
| WebSockets | Koneksi dua arah yang persisten | Sepenuhnya interaktif, butuh infrastruktur khusus |
Kotak masuk VookMail memeriksa email setiap beberapa detik, dan tombol Segarkan memeriksa secara manual, misalnya setelah perangkat Anda tidur atau jaringan terputus. Beberapa detik itu biasanya bagian tersingkat dari seluruh perjalanan. Jika email terasa lambat, waktunya hampir selalu hilang di tahap sebelumnya, di antrean pengirim atau pada percobaan ulang.
Pembuatan alamat juga melewati sedikit perlindungan bot: perhitungan singkat di browser pengunjung, yang dikenal sebagai proof of work. Bagi pengunjung biasa ia nyaris tidak memakan biaya, dan membuat pembuatan alamat secara massal menjadi lebih mahal.
Alamat itu juga bisa dibuka di tempat lain. Karena alamat itu sendiri yang mengidentifikasi kotak masuk, memindahkannya ke perangkat lain hanya perlu meneruskan alamatnya. Tombol QR VookMail menampilkannya sebagai kode yang bisa dipindai ponsel, sehingga kotak masuk yang sama bisa dibuka di sana, dan aplikasi Android dan Huawei menampilkan email dengan cara yang sama. Ini praktis, dan sekaligus menunjukkan mengapa kotak masuk seperti ini berprivasi rendah: siapa pun yang tahu atau menebak sebuah alamat bisa membuka kotak masuk itu. Alamat acak adalah pilihan yang lebih aman, karena jauh lebih sulit ditebak daripada nama pendek.
Tahap 8: Penghapusan
Sekitar sehari setelah konfirmasi kita tiba, ia pergi. Masa penyimpanan pada sistem temp mail biasanya diterapkan dengan cap waktu pada setiap pesan tersimpan dan pekerjaan terjadwal yang menghapus apa pun yang lebih tua dari batasnya. Lampiran yang disimpan sebagai berkas terpisah ikut hilang pada saat yang sama. Rancangan lain memakai kedaluwarsa tingkat penyimpanan, ketika database sendiri menghapus catatan lama lewat pengaturan time-to-live. Pekerjaan berkelompok adalah salah satu alasan layanan cenderung menyebut kedaluwarsa "sekitar" sehari, karena saat pastinya bergantung pada kapan pekerjaan itu berjalan. Di VookMail, pesan, lampiran, dan alamat dihapus dalam sekitar 24 jam, dan tombol Hapus memungkinkan Anda menghapusnya lebih cepat.
Masa simpan yang singkat melayani dua tujuan sekaligus. Ia melindungi privasi, dan juga kebutuhan kapasitas: kotak masuk sekali pakai menerima banyak email pemasaran, dan menyimpannya lama tidak berguna bagi siapa pun. Kebijakan privasi dan halaman metodologi kami membahas penanganan data dengan lebih rinci.
Perhatikan apa yang tidak disentuh penghapusan. Bright Parcel masih menyimpan alamat itu di tabel pelanggannya, dan lognya masih menunjukkan bahwa pesan "terkirim". Yang hilang hanyalah salinan di sisi kotak masuk.
Seluruh rute dalam satu tabel
| Tahap | Komponen | Protokol atau mekanisme | Port atau format lazim |
|---|---|---|---|
| Penyusunan | Aplikasi atau klien email | Pesan RFC 5322, MIME | Teks dengan header dan bagian |
| Pengajuan | Layanan email pengirim | Submission SMTP atau API pengiriman | 587 atau 465 |
| Pencarian rute | Resolver DNS | Kueri MX, lalu A atau AAAA | DNS, port 53 |
| Relai | Server pengirim ke MX penerima | SMTP dengan STARTTLS oportunistik | 25 |
| Penerimaan masuk | Penyedia pengiriman email | Penerimaan catch-all untuk domain | Balasan 250, 4xx, 5xx |
| Penerusan | Penyedia ke VookMail | Permintaan HTTPS | 443 |
| Pemrosesan | Aplikasi temp mail | Penguraian MIME, pembersihan, penyimpanan | Database dan penyimpanan berkas |
| Tampilan | Browser atau aplikasi seluler | Memeriksa setiap beberapa detik, plus Segarkan manual | HTTPS |
| Kedaluwarsa | Pembersihan terjadwal | Aturan masa simpan | Sekitar sehari di VookMail |
Di mana SPF, DKIM, dan DMARC berperan
Ketiganya disebut hampir di setiap pembahasan email, jadi ada baiknya tepat soal posisinya di rute ini. Semuanya menyangkut pembuktian siapa pengirim sebuah pesan. Tidak satu pun menentukan apakah alamat sementara dapat menerimanya.
SPF (RFC 7208) adalah record TXT di DNS yang mendaftar server yang boleh mengirim memakai suatu domain pada pengirim amplop, dan penerima membandingkan IP yang terhubung dengannya. DKIM (RFC 6376) adalah tanda tangan kriptografis yang ditambahkan domain pengirim pada header tertentu dan isi pesan, diverifikasi dengan kunci publik di DNS. DMARC (RFC 7489) adalah kebijakan yang memberi tahu penerima apa yang harus dilakukan ketika pesan gagal dalam penyelarasan SPF dan DKIM dengan domain From yang terlihat, dan ke mana laporan dikirim.
Untuk pesan kita, pemeriksaan ini terjadi sekitar Tahap 3. Server Bright Parcel diperiksa terhadap record SPF-nya, dan tanda tangan DKIM-nya bisa diverifikasi memakai kunci yang dipublikasikannya. Penyedia penerima dapat memakai hasil itu untuk menandai pemalsuan. Penerusan sedikit memperumit keadaan: tanda tangan DKIM bertahan selama pesan tidak diubah, sedangkan hasil SPF hanya berkaitan dengan server terakhir yang terhubung. Ketika email direlai, ARC (Authenticated Received Chain, RFC 8617) dapat mencatat hasil sebelumnya. Pada akhirnya, namun, yang membuat pesan terkirim adalah record MX dan penerimaan oleh penerima.
Ketika sebuah pesan tak kunjung muncul
Setiap tahap di atas adalah tempat pesan bisa terhenti. Menelusuri dari sisi pengirim biasanya menemukan masalahnya paling cepat.
| Tahap | Yang salah | Yang Anda lihat atau lakukan |
|---|---|---|
| Sebelum mengirim | Salah ketik pada alamat | Email pergi ke tempat lain atau bounce. Pakai tombol Salin |
| Meninggalkan pengirim | Pesan masuk antrean, atau kelompoknya lambat | Satu atau dua menit itu wajar untuk sebagian layanan. Tunggu |
| Meninggalkan pengirim | Situs diam-diam melewati domain sekali pakai | Tidak ada yang tiba. Hormati itu dan pakai alamat permanen atau alias di sana |
| SMTP | Balasan 4xx dan percobaan ulang kemudian | Pesan tiba setelah penundaan yang bisa berupa beberapa menit atau lebih |
| SMTP | Pesan melebihi batas ukuran | Penolakan 552 dan bounce ke pengirim |
| Penyedia penerima | Gangguan atau masalah DNS | Pengiriman ke semua domain bisa terhenti sampai teratasi |
| Kotak masuk | Waktunya sudah lewat, atau alamat sudah dihapus | Pesan tiba terlalu terlambat untuk dilihat |
Membaca kegagalan ketika Anda memiliki sisi pengirim
Jika Anda menguji aplikasi sendiri, Anda bisa melihat jauh lebih banyak daripada pengguna, dan panduan kami tentang email sementara untuk pengembang membahas lebih jauh rancangan pengujian. Urutan pemeriksaan yang masuk akal:
- Buka log email aplikasi Anda atau dasbor penyedia pengiriman Anda. Apakah pesan diterima, dan status akhir apa yang ditampilkan?
- Cari bounce atau kejadian webhook yang melaporkan 5xx dari sisi penerima. Teks setelah kodenya sering menyebut alasannya.
- Selesaikan record MX domain penerima dari jaringan server Anda, memakai perintah di atas. Masalah resolver di sana mungkin tidak terlihat di tempat lain.
- Pastikan domain pengirim Anda sudah dikonfigurasi dengan SPF, DKIM, dan DMARC, karena sebagian penerima mencurigai email yang tidak terautentikasi.
- Kirim pesan teks biasa yang kecil untuk menyingkirkan kemungkinan penyaringan ukuran atau isi.
- Pakai nama pengguna yang berbeda untuk setiap pengujian agar Anda tahu proses mana yang menghasilkan pesan mana.
Jika sebuah pesan tiba terlambat di kotak masuk, baca header Received-nya dari bawah ke atas. Jeda panjang di antara dua cap waktu menunjukkan lompatan mana yang menahannya, dengan memperhitungkan selisih jam antarserver tersebut.
Mengapa menjalankan banyak domain?
VookMail memungkinkan Anda memilih dari lebih dari 30 domain. Ada alasan praktis untuk itu. Penguji bisa memisahkan proyek atau rangkaian uji menurut domain. Jika satu domain bermasalah di DNS atau pengiriman, yang lain mungkin masih berfungsi. Dan ketergantungan pada satu nama berkurang, yang membantu ketika sistem pengirim menilai domain penerima selain pengirimnya.
Banyak domain bukan alat untuk menghindari situs web yang sengaja menolak alamat sekali pakai. Jika sebuah layanan menolak domain temp mail, ia sedang memberi isyarat bahwa ia menginginkan kontak permanen, dan pilihan yang tepat adalah alamat asli Anda atau alias permanen untuk layanan itu. Penolakan bisa datang di formulir, lewat daftar domain atau pencarian MX seperti di Tahap 2, atau belakangan, ketika pengirim menolak mengirim.
Apa yang dikatakan rute ini tentang keamanan
Setelah mengikuti pesannya, Anda bisa melihat dengan tepat sejauh mana setiap perlindungan menjangkau.
Enkripsi diterapkan lompatan demi lompatan. STARTTLS melindungi setiap ruas antarserver ketika kedua sisi mendukungnya, dan sering bersifat oportunistik, sehingga koneksi bisa kembali ke teks biasa kecuali kebijakan seperti MTA-STS (RFC 8461) mewajibkan lain. HTTPS melindungi ruas penerusan dan penayangan. Tidak satu pun dari ini adalah enkripsi ujung ke ujung: setiap sistem yang menangani pesan bisa membacanya.
Akses adalah separuh lainnya. Tanpa kata sandi, mengetahui alamat sudah memberi jalan masuk, jadi jangan pernah membiarkan apa pun yang rahasia dikirim ke sana. Masa simpan yang singkat membatasi kerugian dari paparan apa pun, tetapi juga berarti kotak masuk tidak bisa menjadi catatan. Dan karena isinya tidak tepercaya, phishing dan malware bisa tiba di kotak masuk ini seperti di kotak masuk lain. Kotak masuk sementara melindungi alamat asli Anda, dan hanya sedikit melindungi perangkat Anda jika Anda membuka berkas yang buruk. Pemakaian yang pantas adalah privasi, pengendalian spam, dan pengujian, sebagaimana diuraikan syarat dan ketentuan kami, dan akun penting sebaiknya ada di tempat lain.
Seperti apa ini di VookMail
Seluruh mesin di atas sudah terpasang sebelum Anda datang. Ketika Anda membuka VookMail, sebuah alamat sudah siap. Anda bisa menekan Baru untuk mengetik nama pengguna dan memilih domain, atau memakai tombol Acak berwarna kuning yang dijelaskan dalam panduan kami tentang cara menggunakan VookMail. Tidak ada yang perlu didaftarkan, karena domainnya sudah menerima semua nama. Ketika pengirim mengantarkan email, penyedia di balik record MX menerimanya lewat SMTP dan meneruskannya lewat HTTPS, lalu email itu muncul di kotak masuk Anda beserta lampirannya saat halaman memeriksa berikutnya. Sekitar sehari kemudian, ia hilang.
Layanan ini juga tersedia sebagai aplikasi di Google Play dan Huawei AppGallery.
Beberapa pertanyaan teknis lagi
Port mana yang dipakai email masuk?
Pengiriman antarserver email memakai SMTP di port TCP 25. Port 587 dan 465 untuk mengajukan email keluar ke penyedia Anda sendiri, sehingga muncul di Tahap 1 dan bukan di Tahap 3. Itu juga sebabnya koneksi rumah yang memblokir port 25 biasanya tetap bisa mengirim lewat penyedianya.
Bisakah layanan temp mail melihat pesan saya?
Secara teknis, ya. Pesan sampai ke layanan dalam bentuk yang bisa dibaca, karena begitulah ia bisa menampilkannya kepada Anda, dan hal yang sama berlaku bagi penyedia pengiriman yang menanganinya di tengah jalan. Ini juga berlaku pada email berhosting biasa, kecuali isinya dienkripsi ujung ke ujung. Ini satu alasan lagi untuk menjauhkan hal sensitif dari kotak masuk sementara.
Mengapa pengirim bisa mengira pesan terkirim padahal saya tidak melihat apa-apa?
Karena "terkirim" di dasbor pengirim merujuk pada balasan 250 dari server penerima. Kejadian setelah titik itu, seperti langkah penerusan atau kedatangan terlambat setelah kotak masuk dibersihkan, tidak terlihat oleh pengirim.
Bisakah pengirim tahu bahwa alamat saya adalah catch-all?
Sering kali. Alat verifikasi bisa menguji nama pengguna karangan di domain itu, dan jika server menerimanya, domain itu kemungkinan catch-all. Itu saja tidak membuktikan bahwa domainnya sekali pakai, karena banyak domain perusahaan biasa dikonfigurasi sama, sehingga alat semacam itu biasanya menggabungkannya dengan sinyal lain.
Apakah membalas pesan berfungsi?
Balasan dari sisi Anda bukan tujuan rancangan ini, karena kotak masuknya terutama menerima. Jika Anda butuh pertukaran dua arah, kotak surat biasa atau layanan alias yang mendukung balasan lebih cocok.
Untuk informasi lebih lanjut tentang produknya sendiri, lihat FAQ kami. VookMail adalah bagian dari jaringan alat gratis PAYATE.