5. Extensible Reporting

Diese Seite fasst den entsprechenden Abschnitt von RFC 9990 zusammen und bewahrt XML-Schema, Report-Felder und IANA-Werte.

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.