Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

[Emanuel Schorsch <[e-mail]>]

I want to ask about the "hollow victory" aspect and what would turn it into
a more meaningful victory. If fromHeader rewriting is the damage we want to
avoid it seems there's two options:
1) Have the mailingList make a decision based on what they know about the
evaluator. This would need some mechanism for evaluators to indicate what
trust techniques they accept.
2) Have the mailingList rewrite the fromHeader but store the original
fromHeader and propagate the necessary trust information so that downstream
evaluators can undo the rewriting.

Given that currently many mailingList do fromHeader rewriting it seems that
#2 would allow gradual adoption and flexibility for experimentation over
time to see what trust methods work and allow downstream evaluators to make
personalized decisions depending on the recipients trust preferences.

What are your thoughts? What would be needed for that to result in a
non-hollow victory?


On Sun, Apr 30, 2023, 9:54 PM Douglas Foster <
[e-mail]> wrote:

> 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 <[e-mail]> wrote:
>
>>
>>
>> On Apr 29, 2023, at 4:42 PM, Douglas Foster <
>> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>