Vermijd de alles-of-niets-beoordeling
Een helppagina van een provider kan nog steeds citeren RFC 7489 terwijl een huidig accountscherm of een ondersteunde verzendroute nauwkeurig wordt beschreven. Omgekeerd kan een nieuw gedateerde pagina historisch protocoladvies herhalen. De nuttige beoordelingseenheid is de individuele instructie of claim, niet alleen de leeftijd van het citaat. Een auditor moet identificeren wat geldig blijft, wat de huidige normen zijn veranderd en wat afhangt van de daadwerkelijke implementatie door de aanbieder.
RFC 9989 biedt de huidige kern DMARC specificatie en beschrijft wijzigingen ten opzichte van RFC 7489 . Geaggregeerde en foutrapportage worden nu afzonderlijk gespecificeerd in RFC 9990 En RFC 9991. Gebruik deze bronnen om protocolverklaringen te beoordelen, maar behandel ze niet als bewijs dat een provider al elk UI-veld heeft gewijzigd of een beoordelaar heeft ingezet. RFC 9989 , bijlage C; RFC 9990 , sectie 1; RFC 9991 , sectie 1
Behoud de exacte productcontext
Voordat u een gids annoteert, noteert u de URL, de bewaarde datum, het product, het plan of de accountomvang waar aangegeven, de regio, de route en de relevante vereisten. Een leveranciersmerk kan meerdere e-mailproducten met verschillende configuratiepaden bevatten. Een handleiding voor een aangepaste SMTP route is mogelijk niet van toepassing op een standaard API-route, en instructies voor het ene gehoste e-mailproduct gelden mogelijk niet voor een ander product van hetzelfde bedrijf.
Houd door accounts gegenereerde waarden gescheiden van verklarende voorbeelden. Een voorbeeld van een gids keuzeschakelaar of DNS doel mag niet worden gekopieerd als universele productiewaarde. Op dezelfde manier kan een UI-instructie nuttig blijven, zelfs als de uitleg van de omringende standaarden moet worden bijgewerkt. Houd dat onderscheid in stand, zodat de lezer een geldige onboarding-vereiste niet terzijde schuift alleen maar omdat er in de inleiding een historische RFC staat.
Dit manuscript controleert niet de lopende rekening van een genoemde aanbieder en beweert niet dat een specifieke dienst niet aan de regels voldoet. Het biedt een methode voor een toekomstige brongerichte beoordeling. Elke daadwerkelijke productinstructie moet worden gecontroleerd aan de hand van een leesbare primaire handleiding en de geautoriseerde accountcontext voordat deze als van toepassing wordt gepresenteerd.
Classificeer elke instructie op autoriteit
Gebruik ten minste vier annotatiecategorieën: productworkflow, protocolvereiste, providerspecifieke geschiktheid of beleid, en verklarende aanbeveling. Productworkflows hebben actueel bewijs van de leverancier nodig. Protocolvereisten hebben het juiste specificatiegedeelte nodig. De geschiktheid van een aanbieder kan strenger of anders zijn dan het protocolminimum en mag niet worden gegeneraliseerd naar elke ontvanger. Aanbevelingen moeten hun grondgedachte en beperkingen bekendmaken.
Schrijf voor elke regel de acteur en de conditie op. Het gedrag bij het ontdekken van beleid door een ontvanger verschilt van DNS publicatietaak van een domeineigenaar. Voor die dienst kan het nodig zijn een bepaald accountveld te configureren, zonder de recordsyntaxis van de standaard te wijzigen. De ontvangsttoestemming van een rapportbestemming verschilt van het verzoek van de afzender om rapporten daarheen te verzenden.
Wanneer een zin categorieën combineert, splitst u deze. Een instructie om een rapportageadres in te voeren kan bijvoorbeeld een geldige UI-stap zijn, terwijl een claim dat een extern adres automatisch rapporten ontvangt, onvolledig is. Bij de herziening moet de nuttige stap behouden blijven en de ontbrekende autorisatievoorwaarde worden toegevoegd, in plaats van de hele gids te vervangen door algemeen advies.
Vergelijk specifieke gewijzigde concepten
De huidige kernwaarde van DMARC -versie blijft DMARC1 . Een recensie mag geen DMARC2-record verzinnen of impliceren dat het bijwerken van een RFC-citatie een DNS versiewisseling vereist. De huidige specificatie documenteert ook de verwijdering van pct, terwijl het behouden IANA register deze markeringen als historisch markeert. Deze feiten ondersteunen het corrigeren van de bewering dat pct een huidige standaardsteekproefcontrole is, zonder te bewijzen hoe elke ingezette provider hiermee omgaat.
Beleidsontdekking en bepaling van het organisatiedomein moeten ook worden vergeleken met de huidige specificatie in plaats van met een oud, vereenvoudigd algoritme. Rapportageverklaringen moeten, indien van toepassing, worden gecontroleerd aan de hand van RFC 9990 of RFC 9991 . Leg het exacte verschil en de operationele betekenis ervan vast; gebruik niet “DMARCbis alles veranderd” als vervanging voor een beoordeling op sectieniveau. RFC 9989 , sectie 4.7, 4.10 en bijlage A.6; IANA DMARC Tags-register
Annotatiewerkblad en acceptatiecriteria
Maak een werkblad met het uittreksel uit de gids, momentopname van de bron, productomvang, instructiecategorie, huidige autoriteit, voorgestelde annotatie en nog vereist implementatiebewijs. Wijs een van de vier uitkomsten toe: behouden zoals van toepassing, behouden met een reikwijdtenotitie, bijgewerkt omdat de standaardclaim is gewijzigd, of onopgelost wachtend bewijs van de leverancier. Dit zijn redactionele uitkomsten, geen beweringen dat welk productiesysteem dan ook een test heeft doorstaan.
Het werkblad moet ook de eigenaar identificeren die accountspecifieke waarden en eventuele afzonderlijk geautoriseerde tests kan bevestigen die nodig zijn om gedrag vast te stellen. Als de handleiding van de provider niet toegankelijk is, label dan de bronkloof in plaats van een algemene installatiereeks te vervangen en deze 'verifieerd' te noemen.
Acceptatie vereist dat elke annotatie op zichzelf staat. Een recensent moet kunnen zien waarom een schermnavigatiestap werd behouden terwijl een protocoluitleg werd herzien. Houd het oorspronkelijke fragment en de voorgestelde bewoording bij elkaar, zodat de wijziging niet per ongeluk een nieuwe verplichting, een niet-ondersteunde functie of een universele belofte van leverbaarheid introduceert.
Fictieve recensie van een verouderde opstartpagina
Stel je een fictieve providerpagina voor met drie instructies: voer het gegenereerde account in DKIM records, voeg een rapportageadres toe via het instellingenscherm en gebruik pct als de uitrolcontrole van de huidige standaard. De pagina citeert RFC 7489 . Een dergelijke benoemde pagina is hier niet gecontroleerd; deze verzonnen instructies illustreren de classificatiemethode.
De DKIM stap kan geldig blijven als de huidige productdocumentatie en accountwaarden dit ondersteunen. De stap voor het rapporteren van het adres kan geldig blijven als UI-actie, maar vereist een aanvullende uitleg over de externe autorisatie. De pct-verklaring zou een annotatie nodig hebben die voldoet aan de huidige standaarden, terwijl de feitelijke omgang met dat veld door de provider een implementatievraag zou blijven. Eén citaat leidt dus tot drie verschillende review-uitkomsten.
De voorgestelde volgende actie is het behouden van ondersteunde productinstructies, het corrigeren van de standaardtaal en het verkrijgen van aanbiederspecifiek bewijsmateriaal voor onopgelost gedrag. Het is niet de bedoeling om alle bestaande records te verwijderen, de installatievereisten te omzeilen of de provider onveilig te verklaren. Het fictieve voorbeeld laat zien hoe een zorgvuldige beoordeling nuttig kan zijn zonder de toegang of testresultaten te overdrijven.
Houd operationele en redactionele release gescheiden
Een redactionele update kan een handleiding verbeteren voordat de productieverificatie is voltooid, op voorwaarde dat de beperkingen ervan zichtbaar zijn. Beschrijf een geannoteerd document niet als bewijs dat een live account correct is geconfigureerd. Omgekeerd mag een succesvolle accounttest niet worden gegeneraliseerd naar elke klantplan-, regio- of ontvangerimplementatie.
De catalogus vereist annotaties die aangeven welke stappen geldig blijven, welke zijn gewijzigd en welke afhankelijk zijn van de implementatie van de provider. Voor dit concept blijft een echte bronspecifieke geannoteerde gids open. Er wordt geen huidige uitrol van een benoemde provider, accountnavigatie, DNS bewerking of berichtentest geclaimd. De poort voor origineel bewijs en de andere vijf vrijgavepoorten blijven open.
Zorg ervoor dat u vóór de operationele publicatie de feitelijk leesbare bron van de leverancier verkrijgt en de exacte uittreksels, brondata en huidige standaardreferenties bewaart. Een gekwalificeerde reviewer moet controleren of elke behouden instructie overeenkomt met de productscope en dat onopgelost implementatiegedrag onopgelost blijft. Deze benadering levert een bruikbare gids op zonder te doen alsof alleen een oud citaat juistheid of mislukking bewijst.