[ Laporan & investigasi ]

Pengidentifikasi laporan, nama pelapor dan periode pelaporan

Hapus duplikat pengiriman laporan tanpa salah mengira jendela yang tumpang tindih sebagai bukti yang identik.

Oleh tim peneliti EmailAuth

[Poin-poin penting]

  • Jaga agar identitas laporan, asal muatan, dan waktu tiba tetap berbeda.
  • Tangani pengulangan yang tepat dan sebagian tumpang tindih sebagai keputusan terpisah.
  • Jadikan setiap total yang ditampilkan dapat ditelusuri ke kebijakan penyertaan yang eksplisit.
Di halaman ini

Hal yang sama laporan agregat dapat tiba dua kali, dan laporan yang berbeda dapat mencakup periode yang tumpang tindih. Perlakukan ini sebagai masalah yang terpisah. Pertahankan identitas pelapor, ID laporan, domain kebijakan, interval pelaporan, dan asal muatan sebelum memutuskan apakah akan menghitung atau membuang data.

Baca pengidentifikasi dengan konteksnya

Referensi: RFC 9990 §3.5.1, RFC 9990 §3.1.1.3.

RFC 9990 mengharuskan ID Laporan bersifat unik di antara laporan-laporan pada domain yang sama dan menjelaskan bagaimana pengidentifikasi tersebut mendukung deteksi duplikat. Ini bukan ID pesan untuk email individual. Nama organisasi pelapor berguna untuk konteks, namun label tampilan saja tidak dapat menjadi bukti kuat asal usulnya.

Simpan lampiran asli, hash konten, waktu kedatangan, dan asal pengiriman yang relevan di samping report_metadata. Pertahankan domain kebijakan dan nilai awal dan akhir yang dinormalisasi. Perlakukan kunci database komposit apa pun yang Anda pilih sebagai desain penyerapan, bukan sebagai pengganti persyaratan keunikan spesifikasi.

Bedakan periode pelaporan dari waktu kedatangan

Referensi: RFC 9990 §3.1.1.4.

Nilai awal dan akhir menggambarkan interval pelaporan UTC dalam hitungan detik sejak zaman tersebut. Ini bukan stempel waktu dari pesan pertama dan terakhir yang diamati. Waktu pengiriman bisa lebih lama, dan intervalnya bisa mencakup penerapan atau perubahan kebijakan DNS.

Konversikan interval untuk tampilan manusia sambil mempertahankan angka asli dan representasi UTC. Jangan diam-diam memberi label ulang jendela reporter agar sesuai dengan hari kalender lokal Anda. Perubahan volume harian yang nyata dapat disebabkan oleh masalah durasi interval atau kedatangan yang tertunda, bukan perubahan pengiriman yang sebenarnya.

Tangani duplikat dan tumpang tindih secara terpisah

Referensi: RFC 9990 §3.5.4.

Contoh kasus: dua pengiriman memiliki identitas laporan yang sama dan hash XML terdekompresi yang identik. Yang kedua dapat dicatat sebagai kwitansi duplikat tanpa menambah hitungannya lagi. Pertahankan fakta bahwa data tersebut telah tiba sehingga keputusan pemrosesan dapat diaudit.

Sekarang anggaplah laporan kedua mencakup sebagian interval yang tumpang tindih namun memiliki jumlah yang berbeda. Data gabungan umumnya tidak mengidentifikasi pesan individual mana yang tumpang-tindih, sehingga mengurangi separuh jumlah karena separuh jam tumpang tindih adalah tindakan yang tidak dapat dibenarkan. RFC 9990 mencatat ketidakpastian sebagian tumpang tindih. Pilih dan dokumentasikan kebijakan inklusi, tandai batasan yang diakibatkannya, dan hindari menyajikan keseluruhannya sebagai kebenaran yang tidak terduplikasi.

ID laporan yang digunakan kembali dengan konten yang diubah layak untuk diperiksa, bukan ditolak atau diganti secara otomatis. Simpan kedua versi, bandingkan periode dan baris, dan catat bukti mana yang berkontribusi terhadap total yang ditampilkan. Skenario di sini bersifat sintetik dan tidak mencerminkan perilaku reporter sebenarnya.

Jadikan keputusan konsumsi dapat dibatalkan

Pertahankan status terpisah untuk laporan yang diterima, duplikat persis, identitas bertentangan, sebagian tumpang tindih, dan laporan tidak valid. Simpan tautan yang dapat direproduksi dari setiap total dasbor ke catatan yang disertakan. Jangan menghancurkan bukti asli hanya karena bukti tersebut dikeluarkan dari pengumpulan.

Tinjau anomali berulang dengan sumber pelaporan ketika saluran resmi tersedia. Sampai terselesaikan, uraikan liputan dengan jujur. Total yang dapat dipercaya menjelaskan jangka waktunya, memberikan kontribusi reporter dan menduplikasi kebijakan alih-alih menyembunyikan pilihan tersebut di balik satu angka.

Rekonsiliasi lima kwitansi secara numerik

Gunakan kebijakan penyerapan sintetis yang eksplisit ini: simpan semua tanda terima; mengecualikan pengulangan muatan yang dinormalisasi secara tepat; menahan kedua versi payload ketika salah satu reporter menggunakan kembali identitas dengan konten yang diubah; dan mengecualikan laporan yang tumpang tindih sebagian dari total perbandingan khusus ini. Kebijakan lain yang terdokumentasi juga dimungkinkan.

Penerima A mengirimkan ID 42 untuk domain kebijakan brand.example , jendela 0–86400 dan hitungan 10: total 10. Tanda terima kedua yang identik menambahkan nol: total 10. Untuk memodelkan tabrakan pengidentifikasi lintas pelapor daripada menegaskan bahwa penggunaan kembali mematuhi aturan keunikan, penerima B mengirimkan ID 42 melalui jendela yang sama dengan hitungan 7: menyertakannya sebagai pelapor berbeda, memberikan 17. A kemudian mengirimkan ID 42 dengan hitungan 12: tahan kedua versi A, revisi totalnya menjadi 7. B mengirimkan ID 43 melalui jendela 43200–129600 dengan hitungan 9: kecualikan dan tandai sebagian yang tumpang tindih, menyisakan 7. Windows adalah detik waktu berlalu sintetis.

Latihan aritmatika lokal yang disediakan mereproduksi total 10, 10, 17, 7 dan 7. Angka terakhir mewakili observasi penerima yang disertakan, bukan pesan unik di seluruh dunia. Tidak ada pecahan yang tumpang tindih yang disimpulkan, dan data yang dikecualikan tetap tersedia untuk diselidiki.

Pertahankan latihan dalam cakupannya

Contohnya adalah proyeksi lapangan parsial, bukan laporan valid skema atau lalu lintas terukur. Pemeriksaan lokal menggunakan hasil otentikasi dan hubungan organisasi yang diberikan secara eksplisit; mereka tidak melakukan penemuan DNS , SPF evaluasi, verifikasi kriptografi, penyerapan laporan, atau tes pengiriman penerima. Pertahankan laporan asli dan bukti pesan tepercaya sebelum melakukan perubahan produksi.

[ Membawa pergi ]

Jaga agar identitas laporan, asal muatan, dan waktu tiba tetap berbeda. Tangani pengulangan yang tepat dan sebagian tumpang tindih sebagai keputusan terpisah. Jadikan setiap total yang ditampilkan dapat ditelusuri ke kebijakan penyertaan yang eksplisit.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Admin TI / Surat

Pastikan keputusan konsumsi dapat dilacak

ID, hash, dan titik memecahkan masalah yang terkait namun berbeda.

Langkah selanjutnya

  1. Simpan asal muatan asli.
  2. Tandai konten yang diubah dalam satu identitas.
  3. Catat keputusan inklusi dan eksklusi.

CISO / Detik

Simpan bukti tanpa mengklaim secara berlebihan

Label pelapor dan jendela agregat tidak membuktikan liputan pesan yang lengkap atau unik.

Langkah selanjutnya

  1. Tinjau kepercayaan sumber.
  2. Kontrol retensi bukti.
  3. Audit pengurangan konsekuensial dari tumpang tindih.

Pendiri / Non-teknis

Tanyakan berapa total cakupannya

Tren volume memerlukan waktu dan aturan penyerapan yang konsisten.

Langkah selanjutnya

  1. Tinjau panjang interval.
  2. Pisahkan penundaan pengiriman dari perubahan lalu lintas.
  3. Memerlukan batasan selain total yang terpengaruh.

[ FAQ ]

Pertanyaan yang sering diajukan

Apakah report_id merupakan pengidentifikasi pesan?

Tidak. Ini mengidentifikasi sebuah laporan, yang dapat merangkum banyak pesan.

RFC 9990 §3.5.1

Bisakah saya menghapus duplikat hanya menggunakan report_id?

Pertahankan pelapor, domain kebijakan, periode, dan asal konten sehingga tabrakan atau perubahan muatan dapat diselidiki.

RFC 9990 §3.5.1 RFC 9990 §3.5.4

Apakah stempel waktu mulai dan akhir pesan?

Tidak. Mereka menentukan interval pelaporan dalam detik waktu UTC.

RFC 9990 §3.1.1.4

Apakah keterlambatan kedatangan mengubah periode pelaporan?

Tidak. Pisahkan waktu kedatangan dari periode yang dijelaskan dalam laporan.

RFC 9990 §3.1.1.4

Bisakah jam kerja yang tumpang tindih dikurangi secara proporsional?

Tidak. Jumlah agregat tidak mengungkapkan distribusi pesan individual duplikat.

RFC 9990 §3.5.4

Bagaimana jika ID yang sama telah mengubah XML?

Simpan kedua muatan dan selidiki sebelum mengganti atau menghitung secara otomatis.

Haruskah kuitansi duplikat dihapus?

Pertahankan sumber yang cukup untuk mengaudit keputusan pengecualian berdasarkan kebijakan penyimpanan.

Apa yang membuat total dapat direproduksi?

Jangka waktu eksplisit, termasuk kumpulan laporan, kebijakan duplikat, dan jumlah sumber yang dapat dilacak.

[ Sumber ]

Sumber

  1. RFC 9990

    Bagian §3.1.1.3 · §3.1.1.4 · §3.5.1 · §3.5.4

[ Glosarium ]

Glosarium

ID Laporan
Pengidentifikasi laporan yang harus unik di antara laporan-laporan pada domain yang sama; ini bukan pengenal email individual.

RFC 9990 §3.5.1

Periode pelaporan
Interval UTC dijelaskan berdasarkan detik periode awal dan akhir, bukan stempel waktu pesan pertama dan terakhir yang diamati.

RFC 9990 §3.1.1.4

Asal perusahaan

Mengapa lembaga keuangan dan pemerintah terkemuka menghentikan dasbor keamanan email mereka.

Platform autentikasi email tradisional menjual dasbor kepada Anda dan meminta teknisi Anda melakukan pekerjaannya. Di lingkungan berisiko tinggi, pengawasan manual berarti penegakan yang tertunda, penyimpangan konfigurasi, dan domain bayangan yang tidak dipantau.

EmailAuth adalah platform asal email agen. Agen kami menegakkan p=reject, jaga agar pengirim pihak ketiga tetap selaras dan pindahkan domain Anda ke kapasitas penuh RFC 9989 kepatuhan, standar DMARC baru, dengan kemampuan audit yang dapat dilakukan secara langsung oleh manusia.

Pemerintah Perusahaan besar Lembaga keuangan tingkat 1

SaaS · Penyewaan khusus · On-prem dengan celah udara · Enkripsi BYOK

Basis Pengetahuan