On 6/14/2019 9:34 PM, [email protected] wrote:
The suggestion: provide guidelines on data integrity, which data
providers should follow.
Examples:
- raw SPF 'fail' should never result in DMARC-SPF 'pass'
- raw SPF 'pass' out of alignment with header_from should never result
in DMARC-SPF 'pass'
- raw DKIM not being shown should never result in DMARC-DKIM 'pass'
etc
I'm not saying that these situations don't occur for legitimate
reasons, but the DMARC result is a logical evaluation. If the result
of that evaluation is other than the receiving system wants to apply,
then all of the correct evaluations should still be listed, but the
disposition can change, and local_policy explain.
Is this something which can be simply stated in the specification, or
would it belong solely in a 'DMARC XML generator BCP' document?
Reasons for sending reports?
What I think you are saying is:
If a domain's DMARC restrictive policy is going be overridden by local
DMARC policy, then a DMARC report should be sent to the DMARC domain
providing the DMARC technical reasons why DMARC failures were not
rejected but instead accepted and passed to the user's eyeballs or
quarantined?
I think I would interesting to know which DMARC receivers are
accepting what are otherwise DMARC rejectable failures. A lawyer
might be interested too, in the off chance an innocent user was
damaged by the receiver's local DMARC policy. The DMARC domain did
its part. The DMARC receiver did not. <g>
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
