5. Extensible Reporting

Questa pagina riassume la sezione corrispondente di RFC 9990 e conserva schema XML, campi del report e valori IANA.

The extensible reporting model and XML extension examples are preserved below.

5.  Extensible Reporting

   DMARC reports allow for some extensibility, as defined by future
   documents that utilize DMARC as a foundation.  These extensions MUST
   be properly formatted XML and meant to exist within the structure of
   a DMARC report.  Two positions of type "<any>" are provided in the
   existing DMARC structure: one at file level in an "<extension>"
   element after "<policy_published>" and one at record level after
   "<auth_results>".  In either case, the extensions MUST contain a URI
   to the definition of the extension so that the receiver understands
   how to interpret the data.

   At file level:

   <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
             xmlns:ext="URI for an extension-supplied name space">
     ...
     <policy_published>
       <domain>example.com</domain>
       <p>quarantine</p>
       <sp>none</sp>
       <testing>n</testing>
     </policy_published>
     <extension>
       <ext:arc-override>never</ext:arc-override>
     </extension>

   Within the "record" element:

     ...
     <record>
       <row>
          ...
       </row>
       <identifiers>
          ...
       </identifiers>
       <auth_results>
          ...
       </auth_results>
       <ext:arc-results>
          ...
       </ext:arc-results>
     </record>
     <record>
        ...

   Here "arc-override" and "arc-results" are hypothetical element names
   defined in the extension's namespace.

   Extension elements are optional.  Any number of extensions is
   allowed.  If a processor is unable to handle an extension in a
   report, it SHOULD ignore the data and continue to the next extension.