Een gegenereerd record is een beslissingsartefact
A DMARC record Generator kan een voorgesteld beleid opmaken, maar kan niet beslissen welke legitieme afzenders de organisatie heeft, welk bedrijfsrisico zij accepteert of of een rapportagebestemming is geautoriseerd. De output moet elke beleidskeuze en de aannames erachter verklaren. Een kopieerbare string zonder deze beslissingen kan de publicatie aanmoedigen van een syntactisch plausibel beleid dat niet past bij de werkelijke e-mailstromen van de organisatie.
RFC 9989 definieert het huidige beleidsformaat en -mechanisme. In dit artikel worden vereisten voorgesteld voor een generator en een beoordeling van de geannoteerde uitvoer. Er wordt niet beweerd dat EmailAuth een generator implementeert, een record produceert dat klaar is voor productie of DNS wijzigt. De benodigde originele testgevallen en operationeel bewijsmateriaal blijven gescheiden van het verklarende kader.
Bepaal het beleidsdomein en het eigenaarschap
Registreer het domein waarvoor het beleid wordt voorbereid, de bedrijfseigenaar, de eigenaar van de DNS publicatie en de legitieme verzendworkflows die in aanmerking komen. Maak onderscheid tussen de exacte naam van de eigenaar waar een beleid zou worden gepubliceerd en de domeinidentiteiten die door afzenders worden gebruikt. Een generator mag niet stilletjes een bovenliggend of onderliggend domein kiezen op basis van een weergavelabel of een veronderstelde organisatorische grens.
De huidige beleidsdetectie omvat de DNS -boomwandeling beschreven door RFC 9989. De annotatie van de generator moet de beoogde reikwijdte en eventuele overervingsgerelateerde aannames die moeten worden herzien toelichten, in plaats van dat te beloven een record heeft alleen invloed op het adres dat de gebruiker heeft getypt. Het feitelijk toepasselijke gedrag is afhankelijk van de standaard- en ontvangerimplementatie. Tijdens dit werk zijn er geen vragen gesteld over de domeinhiërarchie of bestaand beleid.
Geef uitleg over het gevraagde beleid en de gereedheid
Het gevraagde beleid geeft uitdrukking aan de beoordelingsvoorkeur van de domeineigenaar onder het protocol; het is geen garantie voor de uiteindelijke beslissing van een ontvanger, of een verklaring dat iedere legitieme afzender gereed is. Voordat u handhaving aanbeveelt, moet u een beoordeling van de gereedheid per afzender en een geautoriseerde beslissing over resterende fouten vereisen. Een generator kan keuzes en consequenties presenteren, maar hij mag de bedrijfsgoedkeuring daarachter niet uitvinden.
Uitleggen uitlijning keuzes los van de ernst van het beleid. Het zichtbare Van-domein, geverifieerd SPF identiteit en DKIM ondertekeningsdomein hebben relaties gedefinieerd onder DMARC. Een strikte en ontspannen afstemming zijn niet slechts labels voor een sterkere en zwakkere algemene veiligheid; hun operationele implicaties zijn afhankelijk van de domeinstructuur van de organisatie en de zenddiensten. Behoud de geselecteerde grondgedachte en onopgeloste afhankelijkheden in de geannoteerde uitvoer.
Behoud de huidige versie en tag-semantiek
RFC 9989 specificeert nog steeds de hoofdlettergevoelige versiewaarde DMARC1 . Een generator mag een nieuw standaarddocument niet adverteren als een overstap naar DMARC2. De vereiste positie en waarde van de versietag moeten worden gevalideerd volgens het huidige formaat. Onbekende tags moeten worden genegeerd door protocolverwerking volgens de formele definitie, dus de tool moet een waarschuwing voor niet-ondersteunde tags onderscheiden van een verzonnen regel dat elke onbekende tag het hele beleid ongeldig maakt.
In bijlage A.6 wordt de verwijdering van pct en de introductie van t met y- en n-waarden uitgelegd. Een huidige generator mag een verouderde percentageschuif niet voortzetten alsof het een huidige normatieve controle is, en mag er ook niet van uitgaan dat het vervangen van elk historisch percentage door t een veilige universele migratie is. Het moet de norm documenteren waarop het zich richt, de exacte testsemantiek en compatibiliteitsvragen die overblijven voor de beoogde omgeving.
Behandel rapportagebestemmingen als goedgekeurde ontvangers
RFC 9990 definieert geaggregeerde rapportage en verificatie van externe bestemmingen. Een generator moet uitleggen dat het publiceren van een rapportverzoek en het ontvangen van rapporten verschillende stappen zijn. Het moet de voorgestelde ontvanger, het doel van de gegevens en of de toepasselijke toestemming voor de externe bestemming aanwezig is, identificeren. Leid geen autorisatie af alleen maar omdat een gebruiker een adres in een formulier heeft geplakt.
Dit artikel verstrekt geen rapportageadres, publiceert geen autorisatierecord en verzendt geen gegevens naar een derde partij. Een voorgestelde uitvoer moet duidelijk niet-operationele tijdelijke aanduidingen gebruiken totdat een bestemming is goedgekeurd. In de annotatie moet ook worden vermeld dat de beschikbaarheid van rapporten afhangt van de ontvangers en de levering. Het opnemen van een URI is dus geen garantie voor volledige waarnemingen. Keuzes voor het rapporteren van mislukkingen vereisen, indien aangeboden, hun eigen ondersteunde specificatie en privacybeoordeling, in plaats van dat ze terloops worden gebundeld in een setting met geaggregeerde rapporten.
Verklaar de afhandeling van bestaande records en duplicaten
Een generator moet vragen hoe het voorgestelde beleid zich verhoudt tot de bestaande gepubliceerde staat. Het produceren van een tweede beleidskandidaat bij dezelfde eigenaar kan een ander resultaat opleveren dan het vervangen van een goedgekeurd bestaand record. De uitvoer moet daarom het beoogde exacte verschil beschrijven en het herstelmateriaal behouden, en niet simpelweg zeggen: voeg dit toe TXT record. Bestaande niet-gerelateerde TXT gegevens mogen niet worden verwijderd als neveneffect van het genereren van beleid.
RFC 1035 definieert TXT recordstructuur. Meerdere tekenreeksen binnen één TXT record zijn niet hetzelfde als meerdere beleidsrecords. De annotaties en tests moeten dat onderscheid behouden, zodat de weergave van een editor de operator niet misleidt. Er is hier geen bestaande DNS status geïnspecteerd; Het hanteren van dubbele handelingen blijft eerder een voorgestelde testvereiste dan een geverifieerd resultaat.
Een werkblad met geannoteerde uitvoer
Maak een werkblad met het beleidsdomein, de publicatie-eigenaar, het voorgestelde record, de betekenis van elke tag, de geselecteerde reden, het vereiste bewijsmateriaal en de goedkeuringseigenaar. Voeg de bestaande statusreferentie, het exacte beoogde verschil, de autorisatie van de rapportage-ontvanger, compatibiliteitsbeperkingen, het verificatieplan en de terugdraaicriteria toe. Houd de gegenereerde syntaxis gescheiden van de goedkeurings- en publicatiestatus. Een ingevuld formulier impliceert niet automatisch toestemming om een live wijziging door te voeren.
De vereiste armatuurset moet een positief geldig geval, een ongeldige versie of een vereist formaat, dubbele beleidskandidaten en niet-ondersteund taggedrag bevatten. Vermeld de verwachte uitkomsten van de huidige norm en de presentatieregels van het product afzonderlijk. Bewaar de generatorversie, testinvoer en waargenomen uitvoer wanneer geautoriseerde tests later worden uitgevoerd. Dit concept heeft deze armaturen niet gegenereerd of geëvalueerd en maakt geen aanspraak op implementatie-conformiteit.
Fictieve diagnose: een percentageschuifregelaar verbergt de beslissing
Een fictief team gebruikt een oud beleidsformulier met een percentageschuifregelaar en gaat ervan uit dat het selecteren van een kleiner aantal elke handhavingswijziging veilig maakt. De reviewer vraagt welke standaard het formulier implementeert, wat de legitieme afzenderbereidheid van de organisatie is en hoe de voorgestelde output zich zal gedragen bij relevante ontvangers. Het uiterlijk van de besturing beantwoordt deze vragen niet.
De voorgestelde reactie is het verkrijgen van huidig, aan standaarden gekoppeld gedrag, het documenteren van de beleidsbeslissing en het verifiëren van een exact veranderingsplan in plaats van de schuifregelaar mechanisch in een andere tag te vertalen. Geen enkele echte generator of aanbieder wordt van dit gedrag beschuldigd. De oefening is fictief, er wordt geen record gegenereerd, DNS wijziging of ontvangertest uitgevoerd. Het illustreert waarom de beleidsgrondslag naast de syntaxis zichtbaar moet blijven.
Vereist bewijs voordat u de uitvoer gereed noemt
Een nuttig generatorresultaat geeft aan welke input is geleverd, welke aannames er nog zijn en wat er moet gebeuren vóór publicatie. Het kan een gekwalificeerde eigenaar helpen een consistente beslissing te nemen zonder te beweren dat opgemaakte tekst een veilige handhaving mogelijk maakt. De uiteindelijke autoriteit blijft bij het goedgekeurde zakelijke en technische veranderingsproces.
De catalogus vereist een geannoteerd record en positieve, ongeldige, dubbele en niet-ondersteunde testcases. Die originele artefacten blijven open. Beoordeling door menselijke specialisten, toepasbaarheid van bronnen, productieroutes, toegankelijkheid en vrijgave door de eigenaar blijven ook open. Dit concept bevat een voorgesteld werkblad en een fictieve diagnose, geen kant-en-klaar beleid, voltooide tests of geverifieerde functies EmailAuth tool.