> On Apr 29, 2023, at 4:42 PM, Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: > > ... > > But I need to clarify whether I understand your point. What I am hearing is: > For the short term, mailing lists should refuse postings from DMARC-enforcing > domains. That position can be relaxed only if all participating domains > have agreed to ignore DMARC Fail for messages from the list (Ale floated > some ideas about that approach.) > For the longer term, we need a non-DKIM method for delegating rights to a > third party.
Ideally, the goal is to eliminate “From Rewrite” to return to the “good ol’ days.” So the first time is to recognize having subscription and submissions controls is a natural consideration for the DKIM Policy "Protocol Complete” model. If the MLS supports the protocol, it would consider this method more so than a destruction method that tear down security. This will also pass the buck back to the domain owner to deal with its user’s needs or not. > You talk about "incomplete protocol" as if this is a commonly understood and > accepted term. I interpret it to mean a third-party authentication method > other than DKIM. DKIM does serve for third-party authentication where it has > been embraced and deployed. So the issue is that it has not been practical > for many situations and we do need another option. Protocol complete is a client/server protocol negotiation concept. It basically means the “State Machine”, the conversation between the client and server is well-defined. No Loop Holes!!!! Very key concept in protocol design. In terms of DKIM Signing Practices, you can read "Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol https://www.rfc-editor.org/rfc/rfc5016.txt <https://www.rfc-editor.org/rfc/rfc5016.txt> for its definition. DKIM Signing Complete: a practice where the dtomain holder assert that all legitimate mail will be sent with a valid first party signature. But I believe it is not Protocol Complete and to achieve this with DKIM Policy Modeling, you have to cover the other signing scenarios which includes 3rd party signing scenarios. ATPS is the best we got and it works. You don’t have to worry, You are using gmail.com <http://gmail.com/>. Relaxed policy. Minimal security. ietf.org <http://ietf.org/> Rewrite destroys my isdg.net <http://isdg.net/> domain security even though I have ietf.org <http://ietf.org/> authorized as an ATPS signer. It should honor policy and reject my submissions. Idea. Add the option to the subscription. If you don’t care, let it rewrite to join or use another unsecured address. Not hard. — HLS
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
