Akun uji tanpa batas di satu domain catch-all

Mengapa sebuah provider mail adalah bentuk yang salah untuk QA

Setiap cara memberi sebuah test suite alamat email sudah pernah dicoba, dan masing-masing bocor di tempat yang berbeda:

Baris keempat adalah panduan ini. Ini mekanisme yang sama seperti yang dijalankan domain sekali pakai publik — sebuah server yang menerima setiap alamat pada sebuah domain, bukan sebuah daftar kotak surat — diterapkan pada sebuah nama yang tidak dipakai siapa pun kecuali Anda.

Satu-satunya record DNS

Di provider DNS Anda, tambahkan satu record MX pada apex sebuah domain yang Anda miliki. Tidak ada record lain di sini, tidak ada TXT untuk membuktikan apa pun, tidak ada akun di situs ini:

Record MX untuk domain10 smtp.grabmail.ioSalin

1. Publikasikan MX-nya. Prioritas 10, menunjuk ke smtp.grabmail.io. Hapus MX lain mana pun pada domain itu — email hanya bisa dikirim ke satu tempat, dan record yang tersisa akan mengirim sebagian emailnya ke tempat lain.
2. Tunggu DNS-nya. Biasanya beberapa menit; sesekali selama TTL dari record apa pun yang ada sebelumnya. dig MX qa-example.com menunjukkan kapan itu sudah berlaku.
3. Kirim satu pesan ke alamat mana pun di dalamnya. Pengiriman pertama itulah yang menghubungkan domainnya: server-nya mencari MX-nya pada saat itu, melihat dirinya sendiri, dan menerimanya. Sejak saat itu, setiap alamat pada domain itu adalah sebuah kotak surat.

Skema penamaan yang menyebutkan siapa yang membuat kotak suratnya

Dengan setiap alamat yang valid, bagian lokalnya bebas membawa informasi — dan pada jam dua pagi, dengan sebuah run yang gagal dan sebuah kotak surat yang terbuka, Anda akan menginginkan itu. Tiga bagian, digabung dengan tanda hubung, dengan urutan ini:

// one helper, every runner: who made it, which run, and eight random characters
export const testAddress = (who: string, run = process.env.GITHUB_RUN_ID ?? 'local') =>
  `${who}-${run}-${crypto.randomUUID().slice(0, 8)}@qa-example.com`;

testAddress('signup');        // signup-1234567890-3f9a1c2e@qa-example.com

Membaca alamat mana pun, dengan tiga panggilan yang sama

Tidak ada apa pun soal API-nya yang berubah untuk domain Anda sendiri. Panggilan listing yang sama, panggilan pesan yang sama, delete yang sama — tanpa kunci pada tingkatan publiknya, dan domain di dalam alamatnya adalah satu-satunya yang berbeda:

$ curl -sG https://grabmail.io/api/v1/mailbox --data-urlencode "address=signup-1234567890-3f9a1c2e@qa-example.com"

Yang berarti setiap helper di situs ini berfungsi tanpa perubahan setelah satu konstanta diedit: fixture Playwright, task Cypress, modul Python dan Node. Ada tiga hal yang layak diketahui, yang tidak pernah perlu Anda pikirkan di domain publik:

404 berarti MX-nya belum ada

Listing-nya menjawab 404 untuk domain yang tidak di-hosting di sini. Pada domain Anda sendiri, itu berarti masalah DNS — record-nya belum menyebar, atau menunjuk ke tempat lain — bukan masalah API. Cek dengan dig MX dulu.

Alias juga berfungsi pada domain Anda

Setiap kotak surat, pada domain mana pun, punya alamat kedua pada domain terpisah yang mengantarkan surat ke dalamnya tapi tidak bisa membacanya. Berikan itu ke sebuah situs saat Anda tidak ingin situs itu bisa membuka kotak masuknya; lakukan polling pada alamat Anda sendiri.

Alamat yang sibuk di-paging

Sebuah alamat catch-all yang menampung bounce atau notifikasi selama sehari bisa menyimpan lebih dari satu halaman berisi 200. Sertakan next kembali sebagai before sampai nilainya null.

Menjaga domain pengujian tetap bisa dipakai

Domain milik Anda sendiri tidak ada di daftar blokir email sekali pakai mana pun, dan itu sering kali justru alasan utama memakainya: aplikasi yang sedang diuji menolak grabmail.io dan setiap domain publik lainnya, persis seperti seharusnya. Empat kebiasaan berikut menjaganya tetap begitu:

• Pakai domain khusus — qa-example.com, bukan subdomain dari production dan bukan domain yang dipakai pelanggan untuk mengirim surat. Layanan ini hanya menerima domain yang bisa didaftarkan (example.com, bukan pernah mail.example.com), dan sebuah domain pengujian sebaiknya tidak punya tugas lain.
• Jangan publikasikan domainnya. Daftar-daftar itu dibangun dari apa yang muncul di situs temp-mail publik dan di dump alamat yang dibagikan. Domain yang hanya pernah muncul di dalam test suite Anda sendiri tidak punya cara untuk masuk ke daftar-daftar itu.
• Kunci dengan SPF dan DMARC. Domain yang hanya menerima tanpa SPF adalah domain yang mail-nya bisa dipalsukan siapa saja seolah berasal dari situ; dua record menutup celah itu, dan tidak ada biayanya.
• Jangan arahkan email sungguhan ke sana. Begitu sebuah sistem staging mengirim notifikasi pelanggan ke sebuah alamat catch-all, sebuah kotak surat publik jadi menyimpan data pelanggan. Domain pengujian membawa email pengujian.

Jika aplikasinya menolak semua domain catch-all — sebagian pemeriksaan fraud memang melakukan ini, dengan menguji apakah sebuah alamat acak pada domain itu diterima — ada sekumpulan domain .com berbayar yang terlihat biasa saja, dijaga agar tidak masuk daftar-daftar itu, dijelaskan di halaman harga. Mengapa formulir pendaftaran memblokir email sekali pakai menjelaskan apa yang dilihat masing-masing jenis pemeriksaan.

Untuk sebuah tim: satu domain, banyak tester, banyak pipeline

Satu domain catch-all melayani semua orang, karena bagian lokalnya adalah satu-satunya yang harus berbeda dan itu gratis. Yang dibutuhkan sebuah tim hanyalah kesepakatan soal penamaan di atas dan tiga konvensi kecil:

Sebuah awalan per pipeline dan per orang

e2e-, nightly-, alice-. Mencari sebuah log job untuk awalan itu menemukan setiap kotak surat yang dibuatnya; mencari awalan milik seorang rekan kerja menemukan bug yang sedang mereka selidiki.

Tidak ada yang dibagikan, sama sekali

Tidak ada “kotak masuk tim” pada domain itu dan tidak ada fixture yang membagikan alamat tetap. Jika dua orang butuh kotak surat yang sama, salah satu dari mereka mengirimkan alamatnya ke yang lain.

Rate limit-nya berlaku per klien

Satu kali baca per detik per alamat, 1200 request per menit per klien — sebuah runner CI adalah satu klien, sebuah laptop adalah klien yang lain. Sebuah tim beranggotakan sepuluh orang yang menjalankan suite secara bersamaan adalah sepuluh klien, bukan satu.

Batasan-batasan yang berlaku

Domain Anda sendiri mendapatkan layanan yang sama seperti domain publik, dengan batas atas yang sama pula. Tidak satu pun dari batasan ini bisa disesuaikan, dan tidak satu pun jadi masalah untuk sebuah test suite:

Sebelum Anda menganggapnya selesai

• Sebuah domain khusus yang bisa didaftarkan, dengan satu record MX: 10 smtp.grabmail.io, dan tidak ada MX lain.
• Satu pesan terkirim ke alamat mana pun di dalamnya, dan berhasil dibaca kembali lewat API.
• SPF dan DMARC dipublikasikan, sehingga tidak ada yang bisa mengirim sebagai domain itu.
• Sebuah helper penamaan — siapa, run yang mana, delapan karakter acak — dipakai oleh setiap suite.
• Domainnya disimpan di dalam konfigurasi environment, jangan pernah di dalam kode, screenshot, atau tiket.
• Tidak ada apa pun yang mengirim email pelanggan sungguhan diarahkan ke sana.

Dari sini, suite-suitenya adalah yang sudah pernah ditulis: Playwright dengan domainnya di dalam fixture-nya, disiplin yang tidak terikat runner tertentu, dan workflow GitHub Actions dengan domainnya di dalam sebuah variabel.

Pertanyaan