Upprepad rapportleverans bör inte öka trafikstatistiken. Samtidigt kan liknande rapporter representera distinkta observationer. En säker dedupliceringsprocess identifierar beprövade dubbletter, bevarar råbevis och isolerar osäkra kollisioner snarare än att ta bort allt som ser bekant ut.
Bevara bevis före normalisering
Referenser: RFC 9990 §3.5.1, RFC 9990 §3.5.4.
Lagra den ursprungliga skyddade bilagan, dess kryptografiska fingeravtryck, ankomstkontext och parserversion. Upprätthåll en separat importbeslutsjournal. Råbytes och normaliserade rapportdata tjänar olika syften: två bilagor kan koda motsvarande innehåll samtidigt som de skiljer sig i komprimering eller ofarlig formatering.
RFC 9990 definierar rapportidentifierare för att hjälpa till att känna igen dubbletter och kräver återanvändning av identifierande information vid vidaresändning. Enbart ett filnamn eller ämne är inte desto mindre opålitlig indata. Validera den analyserade rapporten och jämför dess policydomän, reporter, intervall och innehåll innan du fattar ett oåterkalleligt beslut om dataförlust.
Skilj dubbletter från kollisioner
En identisk bibehållen bilaga från samma rapportsammanhang är en stark kandidat för idempotent hantering. En matchande rapportidentitet med annat innehåll är en konflikt, inte automatiskt en säker dubblett. Bevara båda versionerna och markera det berörda metriska bidraget som preliminärt och tillämpa en explicit policy för inkludering av hela rapporten tills förhållandet är löst.
Liknande radvärden räcker inte. Två giltiga rapporter kan oberoende observera samma käll-IP och autentiseringsresultat. Deduplicering av rader globalt kan radera legitim upprepad trafik. Behåll ursprung på rapportnivå bifogat till varje rad.
Använd ett reversibelt importbeslut
En praktisk implementering tilldelar en stabil intern rapportpost och registrerar varje ankomst separat. En bekräftad upprepning pekar på den redan räknade rapporten istället för att infoga dess rader igen. Logga matchningskriterierna och algoritmversionen så att en senare reparation kan rekonstruera vad som hände.
Illustrativ testuppsättning: fil A innehåller 100 observationer; A kommer två gånger. Den räknade summan förblir 100 och ankomster blir två. Fil B använder samma rapportidentitet men innehåller 120 observationer. Systemet flaggar en innehållskonflikt istället för att tyst ersätta 100 med 120 eller räkna 220. Fil C är en verifierad distinkt rapport med 100 liknande observationer och bidrar separat. Dessa fixturer är föreslagna tester, inte produktionsresultat.
Behandla överlappning som ett annat problem
Referenser: RFC 9990 §3.5.4.
Partiell intervallöverlappning avslöjar inte vilka individuella observationer som upprepas. RFC 9990 avsnitt 3.5.4 erkänner att påverkan inte kan separeras rent från enbart samlad information. Subtrahera inte en tidsproportionell bråkdel och beskriv resten som exakt.
Håll osäkra rapporter utanför den primära avstämningssumman eller tillämpa en annan dokumenterad helrapportpolicy, och bevara det uteslutna materialet och dess inverkan. Publicera policyn med måttet. Testa uppspelning, innehållskonflikter och tydliga rapporter som ser likadana ut innan du kallar importören idempotent.
Granska importbeslutsloggen
Varje utesluten ankomst bör peka på den behållna räknade rapporten och jämförelsen som motiverade uteslutning. Varje olöst kollision bör ha en ägare och en synlig status. Begränsa behörigheter för att ändra dessa beslut och behåll en revisionshistorik när ett parserfel kräver återimport av gamla bevis. Testa återställning genom att bygga om ett litet mått från rårapporter och den sparade beslutsloggen. Om rekonstruktionen skiljer sig, undersök innan du använder summorna för ett policybeslut. Idempotens måste överleva försök och omstarter, inte bara en ren första import.
Fortsätt undersökningen
Använd genomgång av sammanlagd rapport att tolka de underliggande fälten och guide för inriktningsdiagnos när ett obearbetat autentiseringspass inte uppfyller DMARC.
Avrättade syntetiska bevis
Den medföljande lokalt återkörda offline Python-fixturen definierar sin logiska nyckel som (validerad reporteridentitet, policydomän, report_id). Den jämför en förenklad (start, slut, räkning) tupel separat från den logiska nyckeln; hashing och normalisering av full nyttolast ligger utanför denna modell. Att validera reportern är en ingångsförutsättning, inte något ett självrapporterat namn bevisar. Den lilla demonstrationen accepterar endast tillhandahållna betrodda identiteter och implementerar inte en produktionsautentiseringsgräns.
Dess utförda tester ger följande resultat:
- Fall: Första rapporten; Ingångsskillnad: receiver-a.example , brand.example , R1, count 100; Faktiskt resultat: accepterat; Ytterligare räknade observationer: 100
- Fall: Exakt repris; Ingångsskillnad: Samma nyckel och nyttolast; Faktiskt resultat: dubblett; Ytterligare räknade observationer: 0
- Fall: Innehållskollision; Ingångsskillnad: Samma nyckel, antalet ändrat till 120; Faktiskt resultat: content_conflict_hold; Ytterligare räknade observationer: 0
- Fall: Samma ID, annan källa; Ingångsskillnad: receiver-b.example , brand.example , R1, count 100; Faktiskt resultat: accepterat; Ytterligare räknade observationer: 100
- Fall: Partiell överlappning; Ingångsskillnad: receiver-a.example , R2, intervall 06:00–18:00 efter 00:00–12:00; Faktiskt resultat: overlap_hold; Ytterligare räknade observationer: 0
Påståenden verifierar alla fem utfallen och totalt 200. Konflikten och överlappande input förblir kvar för granskning. Den illustrativa regeln håller den första angivna rapporten räknad och håller den senare motstridiga ankomsten; den ersätter inte tyst den tidigare rapporten eller hävdar att den nödvändigtvis är korrekt. Ett produktionssystem bör exponera den berörda tidigare räkningen som provisorisk och tillåta en granskad korrigering. Ingången med samma ID/annan källa testar medvetet en identifierarkollision; det är inte ett påstående att ID-återanvändning uppfyller RFC 9990 :s unika krav. Reporterkontext förhindrar automatisk kollaps av potentiellt oberoende observationer medan kollisionen undersöks. Denna körning verifierar fixturlogiken, inte databassamtidighet, omstarter, källautentisering eller schemats fullständighet.
Håll resultatet inom det testade omfånget
Den medföljande lokala demonstrationen verifierar endast dess lilla syntetiska parser, medföljande stegingångar och beräkningar. Ingen riktig DNS auktorisering, SMTP leverans, samlarmigrering, leverantörsdeltagande eller produktionsdatabasbeteende testades. Ursprungliga indata förblir arkiverade och alla livejämförelser behöver sina egna skyddade bevis och ansvarsfullt godkännande.