Re: Options for temporary operational solution to DMARC problem

[Ted Lemon <[e-mail]>]

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 <[e-mail]> wrote:
> 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