Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Alessandro Vesely <[e-mail]>]

On 2020-08-14 7:04 p.m., Dotzero wrote:
> On Fri, Aug 14, 2020 at 12:42 PM John Levine <[e-mail]> wrote:
>> In article <[e-mail]> 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
--