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

2023-06-22 Thread Sebastiaan de Vos
It's not easy to set a DKIM key, I can agree with that. I do think, 
Marty should have tested before sending, though.


None of this, however, solves the issue of SPF weakening the DMARC 
standard. The weakness in SPF is not incidental, but systematic. That is 
- independent of the numbers - the reason why I vote to have SPF removed 
from the DMARC standard.


On 22.06.23 15:31, Todd Herr wrote:
When we look at the numbers others have posted on the topic, and we 
see a perhaps higher than expected percentage of DMARC passes that 
relied on SPF only (or at least a higher than expected rate of DKIM 
failures) I'd posit that many of those DKIM failures are due to the 
challenges that Marty and people like them face with getting the key 
published.

--

Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

InboxSys Brochure <https://inboxsys.com/inb_files/2019/04/InboxSys.pdf>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


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

2023-06-22 Thread Sebastiaan de Vos
In that case, if I understand correctly, Marty is sending his E-mail 
untested and unmonitored. Is that not Marty's problem, really? Where are 
we heading if we try to fix that problem?


On 22.06.23 14:59, Douglas Foster wrote:
Right, but the messages often get sent anyway.  So the evaluator who 
blocks the message as malicious impersonation is blocking incorrectly 
because the fail result is unreliable.   If it only affects nuisance 
advertising, the error may not matter to the evaluator.  But I think 
the problem affects some messages that matter to the recipient.


Doug



On Thu, Jun 22, 2023, 7:46 AM Sebastiaan de Vos 
 wrote:


If I don't know how to control the zone for the domain I want to
send from, I can't authenticate my mail from that domain. Isn't
that part of the purpose of DKIM in the first place?

On 21.06.23 15:36, Todd Herr wrote:

Maybe Marty knows who does control DNS, and Marty is good at
cutting and pasting, and Marty can successfully communicate the
request to the DNS people for wesellstuff.com
<http://wesellstuff.com>
    -- 


Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

InboxSys Brochure
<https://inboxsys.com/inb_files/2019/04/InboxSys.pdf>

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--

Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

InboxSys Brochure <https://inboxsys.com/inb_files/2019/04/InboxSys.pdf>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


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

2023-06-22 Thread Sebastiaan de Vos
If I don't know how to control the zone for the domain I want to send 
from, I can't authenticate my mail from that domain. Isn't that part of 
the purpose of DKIM in the first place?


On 21.06.23 15:36, Todd Herr wrote:
Maybe Marty knows who does control DNS, and Marty is good at cutting 
and pasting, and Marty can successfully communicate the request to the 
DNS people for wesellstuff.com <http://wesellstuff.com>

--

Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

InboxSys Brochure <https://inboxsys.com/inb_files/2019/04/InboxSys.pdf>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


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

2023-06-16 Thread Sebastiaan de Vos
The need for separate DKIM failure codes to be able to separate between 
in-transit changes and public key errors is more than just valid and I 
don't consider SPF worthless in general, but I just find it disturbing 
how the obviously misplaced confidence in SPF currently weakens the 
whole DMARC standard.


Is it not in our best interest to encourage and motivate in particular 
the less sophisticated senders to use the higher confidence mechanisms?



On 16.06.23 13:02, Douglas Foster wrote:
RFC 7489 takes 8 different authentication mechanisms and lumps them 
into a single PASS result:
DKIM or SPF, each with up to four types of alignment:  same domain, 
parent->child, child->parent, and sibling->sibling


These eight mechanisms all provide some level of confidence that the 
message is not impersonated, but they do not provide an equal level of 
confidence.


Unsophisticated senders have little incentive to use the higher 
confidence mechanisms because any PASS result is still PASS.   The 
solution is not to pretend that SPF is worthless, because that is an 
overstatement.   The solution is to talk about the differences in 
confidence provided by the different authentication methods, and note 
that evaluators have reason to distrust some of them.   That distrust 
could cause a weakly authenticated message to be distrusted by some 
evaluators.


Similarly, needs multiple types of FAIL.   Since the data indicates 
that missing (or invalid) public keys are a significant portion of all 
failures, it needs a separate failure code from "normal" failures 
which suggest in-transit changes.   The DKIM group needs to define the 
result code but this group would need to integrate it into our 
aggregate reports.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


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

2023-06-16 Thread Sebastiaan de Vos


Many thanks.  That figure seems to be more or less in agreement with 
what others here have obtained on smaller samples.  However small, it 
may confer to SPF the role of a stabilizer in DMARC mail flows. 


How could SPF be a stabilizer when it's proven to be a highly unreliable 
mechanism? I'd rather consider that a de-stabiliser. From what I 
understand, SPF is part of the problem, not part of the solution.


Sebastiaan

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc