On 2020-08-14 10:27 a.m., Dotzero wrote:
On Thu, Aug 13, 2020 at 10:08 PM John Levine <[email protected]> wrote:
In article <caj4xoyfpgmumkdkqyn0qzenfi_xzjfr99yvu0dglz-z19i...@mail.gmail.com>
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
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
