NAME
Mail::DMARC::PurePerl - Pure Perl implementation of DMARC
VERSION
version 0.20130524
METHODS
init
Resets the Mail::DMARC object, preparing it for a fresh request.
validate
discover_policy
is_aligned
is_dkim_aligned
is_spf_aligned
has_valid_reporting_uri
get_organizational_domain
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
get_from_dom
get_dom_from_header
external_report
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:
verify_external_reporting
AUTHORS
Matt Simerson <msimerson@cpan.org>
Davide Migliavacca <shari@cpan.org>
CONTRIBUTOR
ColocateUSA.net <company@colocateusa.net>
COPYRIGHT AND LICENSE
This software is copyright (c) 2013 by ColocateUSA.com.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.