Subject: [dmarc-ietf] DMARC mailing list policy with respect to DMARC bounces causing subscription suspensions

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Jul 2017 12:08:18 +0200

As noted in the IETF 99 minutes, we have announced a new policy for
the DMARC mailing list, at least until the list is under some DMARC
damage-mitigation:

If you post with an email address in a domain with a DMARC "reject"
policy, and that policy causes other subscribers to have their
subscriptions disabled due to the DMARC-related bounces, then:

1. You will be asked to post from a different address, in a domain
that does not have a "reject" policy.

2. If you continue to post from the problematic address, that address
will be blocked from posting on the grounds that it is disrupting the
operation of the working group.

Brandon, you are on notice that your <[email-masked]> address has
been causing problems for some time, and you have not responded to my
off-list notes.  I got a new batch of disabled subscriptions this
morning.  If it happens again, <[email-masked]> will not be allowed
to post.

I want to stress that your participation is valuable and we *do* want
you here.  It's just that the DMARC policy at <google.com> is
inconsistent with posting to mailing lists, and we can't continue to
accept the disruption that causes.

Barry, as chair

---

From: Hector Santos <[email-masked]>
Date: Thu, 20 Jul 2017 14:00:30 -0400

Wow.

This is why I always said the DKIM Policy Model "protocol"  should 
provide a guideline for Mailing List Server (MLS) processors/receivers 
to A) check for policies and B) not accept for submission the strong, 
exclusive domain policies.  Only accept relaxed policies.  I proposed 
this back with the 2006 DSAP draft:

    https://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-12
    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DSAP operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DSAP check to
       determine if a subscribing email domain DSAP policy is restrictive
       in regards to mail integrity changes or 3rd party signatures.  The
       MLS SHOULD only allow original domain policies who allow 3rd party
       signatures.

    Message Content Integrity Change

       List Servers which will alter the message content SHOULD only do
       so for original domains with optional DKIM signing practices and
       it should remove the original signature if present.  If the List
       Server is not going to alter the message, it SHOULD NOT remove the
       signature, if present.

Let software handle it, otherwise you (speaking in general) are going 
to always have this issue of blocking organizations who are using a 
DKIM Policy, whether it was ADSP with DISCARDable or DMARC with 
reject, for their operations.

Of course, they should be aware of it.  But this problem stems from 
the "ignorant" IETF or other mail list servers who want do play "DKIM" 
but don't want to 'correctly" fit into the Policy model namely because 
of old excuses "that it wasn't done like that for 30 years."

Well, they have to change now for the new, higher overhead, complex, 
big ARC push (or maybe they won't).   The issue will still apply -- if 
the MLS sees a restrictive DMARC policy, it should not accept it for 
submission.

Anyway, we been here and there already. I just find it interesting 
that it has come to this new manual "unfriendly" administrative 
policy.  It should to be codify into the integrated specs and everyone 
will quickly see what needs to be done.

Thanks

-- 
Hector Santos, CTO/Founder
Santronics Software, Inc.

On 7/20/2017 6:08 AM, Barry Leiba wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Tim Draegen <[email-masked]>
Date: Thu, 20 Jul 2017 14:21:48 -0400

> On Jul 20, 2017, at 2:00 PM, Hector Santos <[email-masked]> wrote:
> 
> Anyway, we been here and there already. I just find it interesting that it has come to this new manual "unfriendly" administrative policy. It should to be codify into the integrated specs and everyone will quickly see what needs to be done.

It's true. For this list specifically, the fallout is impacting the group's ability to address the problem... which is ironic?

Also, the draft minutes (https://www.ietf.org/proceedings/99/minutes/minutes-99-dmarc-02.txt) mention:

>Alexey: Also planning workaround that rewrites <from> addresses, start
>experimenting in September.  Different <from> rewriting than existing
>patches.

..so the giant wheel is turning, albeit *slowly*.

=- Tim