Re: [ietf-822] WSJ/gmail/ML, was a permission to...

John R Levine <johnl(_at_)taugh(_dot_)com> wrote:
    >> FWIW, I agree with Arnt on this one. In fact the case has yet to be
    >> made that DKIM-based whitelisting of list mail is more than a
    >> nice-to-have; per-user whitelisting on the basis of List-id alone
    >> along with the usual checks for blatent viruses and whatnot seems to
    >> work pretty well.

    > Currently, I agree with you.  But if List-ID always meant to skip the
    > DMARC rejection checks, how long would it take for every paypal.com
    > phish to include a List-ID?  Presumably competent filters would
    > subsequently catch it, but it would make DMARC, which is intended to be
    > a cheap anti-phish technique, totally pointless.

So, I think that we need more p= options.

If we had:
   p=reject-even-if-list-id

that would satisfy the paypal case. (But, wait, btw, paypal employees are
@paypal.com.  They need corp.paypal.com or some such).

And the classic:
   p=reject-unless-list-id-in-which-case-do-more-work

would work for yahoo.

To me, it seems that really we need an in-SMTP protocol by which senders are
told that they are sending to a re-distributor, and their current policy
won't do, but that they can do X.  That has to go back to the user.

Along the way, we probably should be standardizing the 
prove-that-you-own-this-mailbox,
back and forth so that the user's MUA/MTA can recognize that it is a list
already.   Maybe if one does that, then providers-of-mailboxes will start
putting a different From: on mailing list traffic, different from 1:1
traffic.

--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

pgpewa6q0lACh.pgp
Description: PGP signature

_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822