Leggere la data dello stato prima di valutare la proposta
Il Domain Relationship Policy Framework propone un modo per i domini di descrivere e confermare reciprocamente le relazioni. Ciò potrebbe fornire a una parte che fa affidamento informazioni più esplicite rispetto a un logo simile, un design di sito Web condiviso o un'associazione aziendale dedotta. Se tali informazioni debbano influenzare una decisione relativa all'e-mail dipende dalla loro autorità, dalle regole di convalida e dal comportamento dei consumatori, non semplicemente dalla loro pubblicazione.
Quello del progetto pagina di stato, ispezionato il 9 novembre 2026, data esplicitamente il suo stato al 1 luglio 2024. Descrive un quadro proposto per l'esame pubblico ed elenca una presentazione Internet-Draft descrittiva come passo successivo. Quelle date devono restare separate: una pagina leggibile oggi non rende attuale il suo status. Per questa valutazione non è stato verificato lo stato definitivo del progetto, i risultati degli standard o l'adozione del destinatario.
IL home page del progetto descrive lo sviluppo ad hoc e riconosce i dettagli di distribuzione mancanti. UN Account sviluppatore di febbraio 2024 di J. Trent Adams allo stesso modo definisce il lavoro una proposta anticipata. Il suo linguaggio sulla standardizzazione dovrebbe essere letto in quel contesto. Questo articolo valuta quel modello documentato; non annuncia uno standard implementato né prescrive record DNS di produzione.
Separare il meccanismo di scoperta dal significato politico
La proposta architettura ha piccole asserzioni DNS TXT e, dove necessario, documenti politici più ricchi. Le asserzioni possono esprimere relazioni di base o aiutare a scoprire politiche dettagliate. I documenti distinguono i metadati dal contenuto delle politiche e consentono ai vocabolari di descrivere diversi tipi di relazioni. Gran parte del lavoro di interpretazione appartiene alla parte che fa affidamento.
Questa separazione è importante. Trovare un documento non dimostra che due consumatori ne interpretino il vocabolario in modo identico. Un consumatore avrebbe bisogno di un profilo concordato per la relazione da valutare, compresi i termini e il comportamento supportati per i termini sconosciuti. Le pagine disponibili illustrano le possibilità piuttosto che stabilire una grammatica interoperabile completa. Le loro differenti descrizioni del contenuto minimo delle asserzioni non dovrebbero essere tacitamente risolte in un formato obbligatorio inventato.
Una spiegazione architetturale richiede anche una qualifica DNS . RFC 1035 sezioni 3.3 e 3.3.14 definire i dati TXT come una o più stringhe di caratteri, ciascuna con una lunghezza di un ottetto. Il limite del contenuto di 255 ottetti si applica a una singola stringa, non a un massimo universale di 255 caratteri per l'intero record di risorse TXT . Questa correzione non fornisce la pubblicazione mancante o il profilo di analisi di DRPF.
Esaminare la conferma reciproca come affermazione specifica
L'account sviluppatore descrive la conferma in entrambe le direzioni: un'asserzione che nomina un altro dominio dovrebbe avere una dichiarazione corrispondente da quel dominio. Ciò mette in discussione una pretesa unilaterale di associazione. Non stabilisce in modo indipendente la proprietà legale, l'integrità degli account di entrambi gli amministratori o la sicurezza di un'istruzione di pagamento ricevuta via email.
Un valutatore dovrebbe identificare quale autorità effettivamente controlla ciascun editore e quali prove proteggono il recupero. Due affermazioni reciprocamente coerenti provenienti da sistemi compromessi rimangono un problema diverso da un dominio che avanza un'affermazione non supportata. Una revisione della sicurezza necessita quindi di un modello di minaccia, di presupposti di autenticità e di una gestione definita degli errori. Questi sono i requisiti di valutazione qui, non le capacità dimostrate dalla proposta o da un'implementazione testata per questo articolo.
Mappa una relazione di marca immaginaria dall'inizio alla fine
Considera i domini fittizi brand.example e parent.example . L'amministratore del marchio pubblicherebbe l'affermazione subordinata; l'amministratore principale pubblicherà la conferma corrispondente. Un'ipotetica applicazione di sicurezza sarebbe il consumatore. Il compito proposto è quello di confrontare le due dichiarazioni dirette per la stessa relazione, mantenendo l'associazione commerciale dichiarata separata dall'autenticazione del messaggio.
Quello del progetto caso d'uso del dominio correlato illustra due approcci di scoperta. Un consumatore può scoprire la politica del genitore attraverso l'asserzione del genitore, o seguire un percorso politico fornito più direttamente dal bambino. La pagina illustra anche un documento strutturato JSON-LD. Questi sono esempi concettuali, non prove che le aziende citate utilizzino DRPF o che le loro etichette campione formino un formato di trasferimento stabile.
Per questa mappa immaginaria, il consumatore registrerebbe quali documenti e interpretazioni supportano la relazione in un punto particolare. Se il genitore ritirasse la cresima, il rapporto non avrebbe più lo stesso sostegno reciproco. Nessun record è stato pubblicato o recuperato per questi domini fittizi e non è stato testato alcun parser, convalida della firma o comportamento delle parti coinvolte.
Richiedono un ciclo di vita oltre la capacità di ritiro
L'architettura descrive la rottura di una relazione modificandone la conferma. Questo è un utile meccanismo di revoca concettuale, ma non stabilisce un ritiro immediato ovunque. Le asserzioni memorizzate nella cache, i documenti politici conservati e gli editori temporaneamente non disponibili richiedono una gestione esplicita prima che un consumatore possa prendere decisioni affidabili.
Il revisore dovrebbe chiedere per quanto tempo le prove rimangono utilizzabili, cosa succede quando cambia solo una parte e in che modo una politica non disponibile differisce da un ritiro intenzionale. Anche la ripresa dopo la compromissione di un editore e le catene politiche contrastanti necessitano di risultati definiti. Queste domande dovrebbero produrre regole documentate sul ciclo di vita e test autorizzati, non ipotesi ottimistiche secondo cui la pubblicazione reciproca risolve ogni successiva transizione di stato.
Mantieni separate l'autenticazione e-mail e l'approvazione aziendale
Una relazione amministrativa dichiarata tra due domini distinti non cambia DMARC allineamento da solo. RFC 9989 sezione 4.4 definisce l'allineamento tra gli identificatori autenticati e il dominio dell'autore. Una rivendicazione di relazione non trasforma una firma passante non correlata in una firma allineata e questa valutazione non stabilisce alcuna regola del destinatario che tratti DRPF come un'eccezione.
Allo stesso modo, non viene dimostrato alcun vantaggio derivante dal posizionamento in casella di posta, reputazione ereditata o autorizzazione a pagare un fornitore. Se un futuro consumatore utilizza le informazioni sulla relazione, documenta la decisione precisa che influisce e mantieni controlli indipendenti per l'autenticazione dei messaggi e l'approvazione aziendale. Un possibile segnale futuro non dovrebbe diventare silenziosamente un’iscrizione nella lista consentita o un motivo per indebolire la politica esistente.
Registra ciò che rimane non confermato
La mappa delle relazioni proposta viene fornita come artefatto analitico, mentre il requisito dello stato rimane aperto. Il requisito esatto è: mappare una relazione proposta, il suo editore, consumatore, modello di convalida e revoca; confermare lo stato attuale del progetto. Il gate di messa in servizio è: Verificare il progetto attuale e lo stato di adozione. Descrivere la proposta senza presentarla come uno standard IETF adottato.
L'account social collegato e una ricerca Datatracker erano inaccessibili e non sono stati ritentati o ignorati. L'assenza di ricerca non può dimostrare che non esista alcuna opera successiva. Prima di una conclusione o pubblicazione più forte sono ancora necessari la conferma dello stato attuale, la revisione specialistica, i test di implementazione e interoperabilità, la revisione della presentazione dal vivo e l'approvazione del proprietario.