Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Jan Dušátko <[e-mail]>]

Barry,
I understand your concerns. Use SPF *and* DKIM could cause issues for 
any kind of mail conferencing and forwarding. Situation are quite 
complicated right now. Use of these method, as well as combination of 
these methods, could lower deliverability due protection mechanism 
contrary of forwarding/conferencing principle. But the goal of 
protection methods is to ensure the authenticity of the e-mail source. 
This means that the sender is responsible for protecting the 
domain/brand. And this ultimately requires that the owner has methods 
that are able to provide enough data to ensure its full verifiability. 
Whether these methods are properly implemented is the responsibility of 
the sender's system administrator, whether they are checked upon receipt 
is the responsibility of the recipient's system administrator. Some of 
organization checks SPF only, some DKIM only, some SFP then DKIM, some 
SPF and DKIM (but logic of that use OR), in few tenth of precents also 
followed by DMARC. And some of organizations still does not check anything.
Please, can you consider the possibility that the owner of several 
hundred or even several thousand domains is trying to protect his 
business and does not have the possibility to provide verifiable 
authenticity? If he understands the situation with their impacts, the 
possibility of using SPF and DKIM is a method to ensure adequate 
protection. By this I mean protection from where the mail can be sent 
and at the same time whether it will be signed. Despite the problems 
with mail conferences and forwarding, this may be an acceptable way to 
solve specific problems. In other cases, how we can mitigate as much of 
situation mentioned above?
If the possibility of using only DKIM, I see the risk of how the DMARC 
policy will be evaluated. If the error state of the policy is ensured 
for specific cases (non-existent public key, non-existent subdomain, 
non-existing signature), I have no problem with the approach. All that 
is needed to ensure is a precise procedure, what conditions the 
implementation must meet. And we need method, how we can enforce use of 
DKIM, else we will be in situation without any protection. This is a 
reason, why I concern about protection.

Regards

Jan

Dne 26. 6. 2023 v 14:51 Barry Leiba napsal(a):
> If we consider this sort of thing, I want to push to keep one thing
> off the table:
>
> Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
> Let's please just remove that from consideration.  It has not been in
> DMARC up to this point, and it would be really bad to add it.
> Deliverability would be worse than ever because we would get the worst
> of both: fragility of SPF when messages are relayed/forwarded, *and*
> problems caused by misconfigurations in *either* SPF *or* DKIM.
>
> I can accept some mechanism for the sender to say "SPF only", "DKIM
> only", or "either SPF or DKIM".  I cannot except a version of DMARC
> where *both* must pass.
>
> Barry, as participant
>
> On Sat, Jun 24, 2023 at 3:01 PM Jan Dušátko
> <jan=[e-mail]> wrote:
>> Hector,
>> I think Levin's original suggestion to use the setting option like SPF
>> AND DKIM, SPF OR DKIM, SPF only, DKIM only is excellent. It could solve
>> a lot of problems. System administrators know best how to set up their
>> system and for what purposes they need that setting. I can imagine a
>> great many reasons for and against those combinations. What seems to me
>> to be important here is that DMARC is able to use policies to solve not
>> only common but also error states. In that case, it is able to
>> successfully solve the problems caused by the attackers.
>>
>> Jan
>>
>> Dne 23. 6. 2023 v 19:23 Hector Santos napsal(a):
>>> Levine makes a good point. A less complex option would be:
>>>
>>> auth=dkim          # apply dkim only, ignore spf, dkim failure is
>>> dmarc=fail
>>> auth=spf            # apply spf only, ignore dkim, spf failure is
>>> dmarc=fail
>>>
>>> the default auth=dkim,spf SHOULD NOT be explicitly be required. It
>>> adds no additional security value.  I would like to note that some DNS
>>> Zone Managers with DMARC record support will add the complete tags
>>> available for the protocol with the default conditions making the
>>> record look more complex than it really it.
>>>
>>> Other system integration options would (forgive me for I have sinned):
>>>
>>> atps=1     # we support ATPS protocol for 3rd party signer.
>>> rewrite=1  # we are perfectly fine with Author Rewrite
>>>
>>> --
>>> HLS
>>>
>>>
>>>
>>>
>>>
>>> On 6/22/2023 10:18 PM, John Levine wrote:
>>>> It appears that Emil Gustafsson <[e-mail]> said:
>>>>> I don't know if there is a better way to encode that, but I'm
>>>>> supportive of
>>>>> making a change that that would allow domains to tell us (gmail)
>>>>> that they
>>>>> prefer us to require both dkim and spf for DMARC evaluation (or
>>>>> whatever
>>>>> combination of DKIM and SPF they desire).
>>>> I really don't understand what problem this solves. More likely people
>>>> will see blog posts telling them auth=dkim+spf is "more secure",
>>>> they'll add that without understanding what it means, and all that
>>>> will happen is that more of their legit mail will disappear.
>>>>
>>>> If you're worried about DKIM replay attacks, let's fix that rather
>>>> than trying to use SPF, which as we know has all sorts of problems of
>>>> its own, as a band-aid.
>>>>
>>>> R's,
>>>> John
>>>>
>>>> _______________________________________________
>>>> dmarc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>>
>>>>
>>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc