Following RFC7489 sec 6.6.3, we first look up the TXT records at _dmarc.vps1234.digitalocean.com. That returns no record with v= the current DMARC version (actually none at all) so we then query _dmarc.digitalocean.com (the organizational domain in this case) and find a valid v=DMARC1 p=reject record, so if we are Mailman doing this to determine whether or not to apply dmarc_moderation_action, we do apply the action.
If Mailman didn't apply dmarc_moderation_action and just processed the post, the ultimate receiver would get to the same point and determine the applicable DMARC policy is reject and then proceed with the DKIM and SPF checks to determine if the message passes DMARC. If we assume that the message didn't go via a list and instead went directly to the ultimate receiver, that receiver would determine the DMARC policy was reject in the same way. Then it would check DKIM and SPF. This is the first point at which adkim or aspf would be checked for strict/relaxed alignment between the From: domain and the DKIM signing or SPF domain. As Mailman we don't care about any of this because we aren't trying to validate DMARC on the incoming message, and we assume that DMARC won't validate against the outgoing message if we don't alter the From: domain because we aren't the From: domain for SPF and we transform the message in ways that break the DKIM sig, so all we want to know is what DMARC policy will be applied by the receiver. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1549420 Title: DMARC munging fails on subdomains that use parent domain policy To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1549420/+subscriptions _______________________________________________ Mailman-coders mailing list [email protected] https://mail.python.org/mailman/listinfo/mailman-coders
