I would observe that Outlook.com evaluates SPF/DKIM/DMARC, documents the test results, ignores the failed results, and then continues processing.
And it has never registered it's private registries in the PSL (and no one else can do it for them.) So I do not include Microsoft in a list of infrastructure vendors who deserve trust. They seem determined to undermine sender authentication. Doug DF On Sun, Oct 27, 2024, 9:19 AM Richard Clayton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected]>, Tero Kivinen > <[email protected]> writes > > >Richard Clayton writes: > > > >> One of the aims of DKIM2 is to make ARC unnecessary, and in particular > >> to ensure that cases where an intermediate system must be trusted relate > >> only to improving your heuristics which detect DKIM-replay or where you > >> have a contractual relationship with that intermediary. > > > >I have not checked out DKIM2, but I am wondering how it plans to solve > > those two statements are clearly connected ... the published draft is a > fairly straightforward read since it concentrates on the issues and > outlines the solutions > > <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation> > > >the ARC trust problem, i.e., how DKIM2 will solve the situation that > >someone in the middle changes the email and I assume in DKIM2 it will > >sign that modification, but how does the final recipient know it > >should trust that party in the middle to do those changes? > > by undoing the changes and checking the original signature ... it's not > actually necessary to check the signature on the undo instructions > (we're trying to reduce the amount of crypto you do) since all that > matters is whether or not they work. > > >I.e., even if DKIM2 allows me to recover the orignal email and know > >what changes are done, it does not help me to solve the issue that I > >do not know if those changes were malious or not. > > you're correct ... that is not (and IMNSHO cannot) be addressed. We did > discuss whether it was possible to limit changes in such a way that you > could not add some HTML (say) which hid the original post and replaced > it with something else. It did not seem possible to be that restrictive > and support what legitimate mailing lists do today. > > >We can solve that issue in the same way we solve that in ARC, i.e., > >recipient will know whether such changes should be allowed by the > >intermediary because it has set up or approved that intermediary. I > >think this will work, but some other people seemed to say it can't > >work as it requires final recipient to understand the issue... > > The problem with ARC is that you have to trust the intermediary is > documenting what they received and not inventing a message and lying > about its provenance. Trusting MAGY (Microsoft, Apple, Google, Yahoo) > the IETF and the Harvard alumni forwarder is probably OK. After that > (and possibly even before) opinions start to vary. > > Yes in DKIM2 you may discover that an alteration was malicious, but at > least it will be crystal clear (once, for forensic purposes you check > every signature to hand) which entity should be blocked henceforth. > > - -- > richard Richard Clayton > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBZx49wt2nQQHFxEViEQJXRQCgg2WNG87DO8C8Lx8RiEX73rVxCcgAoMQ2 > iX1Ht6z0MkLrLzX5uhsdwDGm > =sc/F > -----END PGP SIGNATURE----- > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
