NAME

       Mail::DMARC::PurePerl - Pure Perl implementation of DMARC

VERSION

       version 1.20230215

METHODS

   init
       Reset the Mail::DMARC object, preparing it for a fresh request.

   validate
       This method does the following:

           * check if the RFC5322.From domain exists (exists_in_dns)

           * query DNS for a DMARC policy (discover_policy)

           * check DKIM alignment (is_dkim_aligned)

           * check SPF alignment (is_spf_aligned)

           * determine DMARC alignment (is_aligned)

           * calculate the effective DMARC policy

           * apply the DMARC policy (see Mail::DMARC::Result)

   discover_policy
       Query the DNS to determine if a DMARC policy exists. When the domain name in the email
       From header (header_from) is not an Organizational Domain (ex: www.example.com), an
       attempt is made to determine the O.D. using the Mozilla Public Suffix List. When the O.D.
       differs from the header_from, a second DNS query is sent to _dmarc.[O.D.].

       If a DMARC DNS record is found, it is parsed as a Mail::DMARC::Policy object and returned.

   is_aligned
       Determine if this message is DMARC aligned. To pass this test, the message must pass at
       least one of the alignment test (DKIM or SPF).

   is_dkim_aligned
       Determine if a valid DKIM signature in the message is aligned with the message's From
       header domain. This match can be in strict (exact match) or relaxed (subdomains match)
       alignment.

   is_spf_aligned
       Same as DKIM, but for SPF.

   has_valid_reporting_uri
       Check for the presence of a valid reporting URI in the rua or ruf DMARC policy tags.

   get_organizational_domain
       From the 2013 DMARC spec, section 4:

         Organizational Domain: ..is the domain that was registered with a domain
         name registrar. Heuristics are used to determine this...

   exists_in_dns
       Determine if a domain exists, reliably. The DMARC draft says:

         9.6 If the RFC5322.From domain does not exist in the DNS, Mail Receivers
             SHOULD direct the receiving SMTP server to reject the message {R9}.

       And in Appendix A.4:

          A common practice among MTA operators, and indeed one documented in
          [ADSP], is a test to determine domain existence prior to any more
          expensive processing.  This is typically done by querying the DNS for
          MX, A or AAAA resource records for the name being evaluated, and
          assuming the domain is non-existent if it could be determined that no
          such records were published for that domain name.

          The original pre-standardization version of this protocol included a
          mandatory check of this nature.  It was ultimately removed, as the
          method's error rate was too high without substantial manual tuning
          and heuristic work.  There are indeed use cases this work needs to
          address where such a method would return a negative result about a
          domain for which reporting is desired, such as a registered domain
          name that never sends legitimate mail and thus has none of these
          records present in the DNS.

       I went back to the ADSP (which led me to the ietf-dkim email list where some 'experts'
       failed to agree on The Right Way to test domain validity. They pointed out: MX records
       aren't mandatory, and A or AAAA aren't reliable.

       Some experimentation proved both arguments in real world usage. This module tests for
       existence by searching for a MX, NS, A, or AAAA record. Since this search may be repeated
       for the Organizational Name, if the NS query fails, there is no delegation from the TLD.
       That has proven very reliable.

   fetch_dmarc_record
       Query the DNS for the presence of a DMARC record at the header from domain name and the
       Organizational Domain name. Returns the discovered DNS record answers.

   get_from_dom
       Returns the header_from attribute, if defined.

       When header_from is not defined, crudely, and very quickly parse a From header and return
       the domain name (aka, the header_from domain).

       The From header format is defined in RFC 822 and is very complex. The From header can
       contain multiple email addresses, each with different domains. This method returns the
       last one. If you want to handle this differently, parse the From header yourself and set
       header_from.

   external_report
       Determine if a report URL is external. If the domain name portion of the URI is not the
       same as the domain where the DMARC record was discovered, the report address is considered
       external.

   verify_external_reporting
       8.2.  Verifying External Destinations

       It is possible to specify destinations for the different reports that are outside the
       domain making the request.  This is enabled to allow domains that do not have mail servers
       to request reports and have them go someplace that is able to receive and process them.

       Without checks, this would allow a bad actor to publish a DMARC policy record that
       requests reports be sent to a victim address, and then send a large volume of mail that
       will fail both DKIM and SPF checks to a wide variety of destinations, which will in turn
       flood the victim with unwanted reports.  Therefore, a verification mechanism is included.

       When a Mail Receiver discovers a DMARC policy in the DNS, and the domain at which that
       record was discovered is not identical to the host part of the authority component of a
       [URI] specified in the "rua" or "ruf" tag, the following verification steps SHOULD be
       taken:

         1.  Extract the host portion of the authority component of the URI.
             Call this the "destination host".
         2.  Prepend the string "_report._dmarc".
         3.  Prepend the domain name from which the policy was retrieved,
             after conversion to an A-label if needed.
         4.  Query the DNS for a TXT record at the constructed name.
         5.  For each record, parse the result...same overall format:
             "v=DMARC1" tag is mandatory and MUST appear first in the list.
         6.  If the result includes no TXT resource records...stop
         7.  If > 1 TXT resource record remains, external reporting authorized
         8.  If a "rua" or "ruf" tag is discovered, replace the
             corresponding value with the one found in this record.

       The overriding URI MUST use the same destination host from the first step.

AUTHORS

       •   Matt Simerson <msimerson@cpan.org>

       •   Davide Migliavacca <shari@cpan.org>

       •   Marc Bradshaw <marc@marcbradshaw.net>

COPYRIGHT AND LICENSE

       This software is copyright (c) 2023 by Matt Simerson.

       This is free software; you can redistribute it and/or modify it under the same terms as
       the Perl 5 programming language system itself.