That sounds good to me, as long as it doesn't silently drop mail.
On Thu, Nov 3, 2016 at 10:48 PM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
In article <1F305C1D-7228-4084-9F33-8834AAAC82CB(_at_)fugue(_dot_)com> 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