Everything depends on an evaluator who trusts the alternate authentication protocol. We have at least three trust techniques: - local policy at evaluator - ARC set trusted by evaluator - ATPS trusted by evaluator.
Until the list knows that the evaluator will accept the credentials, he has to assume that rewrite is necessary to avoid message blocks, unsubscribes, and possibly blacklisting No such feedback exists at present, so even though ARC has some acceptance, it is a hollow victory. DF On Sun, Apr 30, 2023, 8:05 PM Hector Santos <hsan...@isdg.net> wrote: > > > 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. Relaxed policy. Minimal security. ietf.org Rewrite > destroys my isdg.net domain security even though I have 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
