Re: Options for temporary operational solution to DMARC problem

["John Levine" <[e-mail]>]

In article <[e-mail]> 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