In article <1F305C1D-7228-4084-9F33-8834AAAC82CB@xxxxxxxxx> you write: >-=-=-=-=-=- >My understanding is that there are really four possible approaches: > >Bounce messages from sites that have p=REJECT; users at those sites have to use some other email address for IETF business. >Rewrite From: header on messages from sites that have p=REJECT to point at discard address >Rewrite all From: headers to point at discard address >Rewrite all From: headers to reply to addresses that forward to senders for senders with p=REJECT You might want to look at the Mailman documentation since the second and third of those are wrong, and they've implemented other stuff, too. (Here it is: https://wiki.list.org/DEV/DMARC ) Its anti-DMARC header munging puts the list's address in the From: line, not a discard address. This has the advantage that replies don't get lost, with the disadvantage that the usual message display in a mail program doesn't show who the mail is from, and reply to author doesn't work. I tried adding .INVALID to the addresses which worked really badly, since a lot of spam filters (not unreasonably) dislike From: addresses with domains that don't resolve. I can see why one might rewrite a dev/null address to punish people who use dmarc'ed addresses, but it seems like a cruel joke. If the IESG believes that even though we've had this problem for 2 1/2 years, we need to do something about it NOW NOW NOW rather than waiting a few more months for ARC, I strongly recommend the per-sender rewrite. I did that over a year ago for the lists I run, and it works well. You can still see who the mail is from, and it doesn't change the way lists work. My users are mostly non-technical, and we have a lot with Yahoo and AOL addresses that get rewritten, and Gmail addresses where they get delivered. Most of them don't even notice the funky .dmarc.fail after the aol.com and yahoo.com addresses. It does require some extra programming for the forwarding addresses, but I wrote my version, the address rewriting shim and the daemon that manages the forwarding addresses, in an afternoon. It's not hard, and if it works as well here as it does for me, we might not need to add ARC headers. R's, John