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

[Alessandro Vesely <[e-mail]>]

On 2020-08-14 10:27 a.m., Dotzero wrote:
> On Thu, Aug 13, 2020 at 10:08 PM John Levine <[e-mail]> wrote:
>> In article <[e-mail]> you write:
>>> "DISCUSS" shouldn't really be a joke. [...]


Adopting the I-D should boost the discussion, not hamper it.  No 
reason to discuss about adoption...


>> That's a feature, not a bug. I want recipients to be able to assess
>> the mail my lists send on its own merits.
>>
> 
> And recipient domains do just that using local policy override.
> DMARC policy is at best a request to the Validator/Receiving
> Domain. If a Validator/Receiving Domain chooses to honor the
> published DMARC policy for a domain such as p=reject, then they are
> in fact assessing the mail your lists send based on the merits as
> they see them. The same goes if they decide to not honor that
> published DMARC policy and accept mail from your lists.

Agreed.  However, local policy override based on unspecified external 
sources is not easy for medium-small domains.


> Earlier in my DMARC journey I felt that MLMs should adjust and
> send list mail as themselves. Now I have come to the conclusion
> that they should reject list submissions from accounts at domains
> which publish a DMARC policy of p=reject.


Oh, in case, users can get another freemail account, or use trash 
email addresses.  Should the email infrastructure depend on the 
existence of such operators?

IMHO, a myriad of medium-small domains is more robust and more 
reliable than a few gorillas managing the whole world communications.


> Domains should not be able to externalize their internal problems
> to others.

You're sticking to the original concept that DMARC protection shall 
only be granted to heavily abused domains which don't host users' 
mailboxes.  People's email must be spoofable.  Why?


Best
Ale
--