Scott Kitterman writes: > Performing prosepective DMARC validation on receipt to determine if > mail would be subject to p=reject processing on the distant end if > reransmited.
I assume you mean "... and prospectively reject"? (GNU Mailman at least already provides options to munge From or wrap the message, conditional on the result of such a test.) For completeness it should be listed, but practically speaking, for tens of thousands of lists it just ain't gonna happen, sorry. The Author Domains that *want* "POLICY" control already have a local policy in place prohibiting their users from posting to mailing lists and the like, and are a very small problem because indirect messages from them are very few. It's the p=reject abusers that are the problem, but *they* *want* mailing lists to distribute their users' posts, despite what "POLICY" advocates claim is implied by publishing p=reject. Those users *want* to post, and they blame the *list*, not their mailbox providers, if anything goes wrong or if their posts are treated differently from users at other providers. List owners by and large are not RFC zealots, quite the reverse, and quickly cave in to the importunate posters. Bottom line: The only people who want this policy are some of us in this working group. Nobody[1] actually involved does. Even my colleagues at GNU Mailman who are sympathetic to the idea of prospectively doing what the policy requests have found that in practice it's socially untenable on lists they administer. Footnotes: [1] Well, I do, but my lists are special cases. My public lists have less than 0.5% p=reject subscribers and less than 0.1% posts from them, so I can tell them where to go, and my university lists are covered by Japanese Ministry of Education policy deprecating use of Yahoo! mailboxes (without reference to p=reject and including domains that publish p=none!) _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
