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:
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 protected]> 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 protected]> 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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
