Sender reputation is in use everywhere. What is lacking is an omniscient data source, but I have no hope of finding one. Small senders will always be at a disadvantage because sender reputation is entirely based on past experience, and smaller senders have less experience to draw upon. ARC does not change that dynamic.
Forwarding creates two problems: (1) knowing that a forwarding operation occurred, and (2) knowing how I would have dispositioned the message if the forwarding operation had not occurred. ARC helps with both of these. Forwarding tends to hide or discard data, and ARC offsets that data loss. One step in ARC evaluation is determining whether the data provided is sufficient and internally consistent with the rest of the header set. To be fully sufficient, I want to know Mail From address, Helo name, Source IP, and From address at the moment represented by the ARC Set. Without all of this, the ARC set is probably not actionable. With complete data, the ARC set can be matched to a Received header, to check for data consistency. For example, I don't trust a Microsoft ARC set that asserts DKIM Pass for a signature that does not exist. The complete data set also allows me to evaluate how I would have dispositioned the message if it had been received directly, based on the reputations of the prior server, Mail From domain, and From address. Exactly two points of trust come into this process: (a) deciding whether to trust DMARC Pass on a signature that no longer validates, and (b) whether to accept that the internally-consistent data is not a very sophisticated internally-consistent ruse. In the event that I make an incorrect "Allow" decision based on a fraudulent ARC Set, I have to hope that my content filtering will detect and block the attack. But this is nothing new. On a daily basis, I have well-authenticated messages that are malicious and have to be blocked by content filtering. So, I will accept some ARC data, ignore some ARC data, and maybe even block based on some suspicious-looking ARC data. I can only do that if I have the data available to use. Doug Foster On Thu, Apr 4, 2024 at 3:55 PM Jim Fenton <fen...@bluepopcorn.net> wrote: > On 4 Apr 2024, at 12:08, Murray S. Kucherawy wrote: > > > On Thu, Apr 4, 2024 at 12:02 PM Dotzero <dotz...@gmail.com> wrote: > > > >> > >> > >>> > >>> My overall point is that this thread makes it seem like we're not > putting > >>> forward a complete solution. It feels a lot more like a proposed > standard > >>> that for its clear success depends on a bunch of other things that > range > >>> from experimental to abstract to undefined. And if that's a correct > >>> summary, I'm asking if that's what we really want to do. It seems a > little > >>> haphazard, like we're scrambling to tie together the loose ends of a > movie > >>> plot. We need to do a good job of bringing our audience to as solid a > >>> conclusion as possible, or the critics' reviews might not come out > well. > >>> > >> > >> My response to your statement "... this thread makes it seem like we're > >> not putting forward a complete solution." is a complete solution to > what? > >> It seems like people are trying to throw in everything but the kitchen > >> sink, including new proposals and rehashing old issues that were > supposedly > >> settled, as we go through last call. > >> > > > > Yes, that's part of what I'm observing. It's possibly a form of scope > > creep, and indeed "We should stop that" is one valid response. :-) > > I don’t think it’s scope creep at all. The WG charter puts “Review and > refinement of the DMARC specification” in phase III, after “Specification > of DMARC improvements to support indirect mail flows”. It seems clear to me > that standards-track DMARC needs to incorporate those improvements. > > IESG accepted ARC as an improvement to support indirect mail flows, and I > think a complete solution needs to incorporate that. I wish there were > better data to support advancing ARC to standards track, and not just from > Google (it has to work for smaller players as well). > > But I am troubled by the possibility that ARC might require domain > reputation to avoid ARC header fields supporting From address spoofing. One > reason it might work for Google is because they’re big enough to derive > their own domain reputation. We’ve not had success with domain reputation > at internet scale. > > -Jim > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
