> On Apr 19, 2023, at 10:29 PM, Jesse Thompson <z...@fastmail.com> wrote:
>
> The choice for both the mailing list and mail-service company is to:
>
> 1) ignore DMARC and continue to emit mail as the original author intended
> (the author might be ignorant of DMARC too) and assume the mailbox providers
> are smart enough to understand that, like mailing lists, mail-service
> companies and their mail emitting authors shouldn't be caught up by a DMARC
> misdeployment by the domain owner
This will cause the list bounce problem. This was seen immediately in the IETF
list when it 100% ignorance of DKIM. Signatures broke.
Solution: Support DKIM and resign as 3rd party
Problem: Policy does not allow a resigner.
No one honored broken signatures, policies. Recorded as fail but no lost until
YAHOO shook the world and began to honor p=reject policies. Bounce problem.
> 2) be cognisant of DMARC's effects, and in the interest of keeping the
> author's mail flowing, use a different domain and put the author's address in
> the friendly from or similar, or just refuse to accept the messages, until
> delegation can be set up
> I can say, anecdotally, that people really really want #1 to be true, but
> they eventually learn #2 leads to a better long term outcome. I'd like that
> "learning" to be less painful by having something unambiguous to point at in
> DMARCbis.
>
We allowed a protocol incomplete to take off without dealing with the known
potential problem. No one will honor DKIM policy stuff.
Now its broken.
As a Mailing List Server developer, we need a migration path to a 3rd option
(ATPS concept) which using #2 temporarily. Ideally no From destruction is the
goal. For now, I use #2 restrictions on subscription and submissions
—
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
