On 2020-08-14 7:04 p.m., Dotzero wrote:
On Fri, Aug 14, 2020 at 12:42 PM John Levine <[email protected]> wrote:
In article <caj4xoycfbh8-naxjxzzrguahffhcgczq2ymf2ewv_-dgum...@mail.gmail.com>
you write:
[...]
This is why I made the point above that lists should respect DMARC
policy and not accept submissions from domains with DMARC p=reject
policies.
Lists have been around a lot longer than DMARC has.
That doesn't grant lists any extra right. Others consider current
global usage as a priority gauge.
Perhaps you meant to say that domains whose users participate in
mailing lists should not publish restrictive DMARC policies. If
they don't want their users to send mail to lists, they should
tell their users not to send mail to lists.
Should they file lawsuits against online infringers?
I meant what I wrote. Domains who actively want their users to participate
in mailing lists or even passively accept that their users participate in
mailing lists shouldn't publish p=reject for the domain their users are
sending from or should take steps to migrate the users to another
domain/subdomain, etc.
Why people's mailboxes must be spoofable?
Syllogism goes like so: Mailing list must not accept strict DMARC
policies, humans may happen to use mailing lists, therefore email
domains which hosts mailboxes used by humans must not publish strict
DMARC policies. Is that really what we seek? I hope not.
This is not the mailcore WG where they have to bring to full standard
a time-honored paper. We're talking about a protocol that is gaining
adoption slowly as it has some troubles. It's going to be Proposed
Standard anyway. Fixes may go as far as introducing Sender:. In such
a scenario, why should we stick to the restricted p=none except
transactional?
Conversely, if a domain IS publishing p=reject then yes, they
should be taking steps internally but I also believe others should
consider that domain's published policy as intentional and act
accordingly. I've never heard of a DMARC policy getting published
due to inaction. Someone with administrative rights actively
published that policy.
Possibly, that policy was pushed for security reasons. We may say
they don't know what they're doing. They may say the same of us.
If DMARC cannot secure people's mailboxes, perhaps we should invent a
different protocol. It may still be based on SPF and DKIM
authentication. And still be called DMARC, no?
There are lots of organizations that actively want their employees to
participate in the IETF, to the extent that they give them paid time
for IETF activities, yet publish p=reject policies to cripple that
participation. I wish they would make up their minds.
Me too.
We could make up our minds as well...
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
