On Thu, Aug 20, 2020 at 1:36 PM Tim Draegen <t...@eudaemon.net> wrote:
> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy <superu...@gmail.com> > wrote: > > On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely <ves...@tana.it> wrote: > >> I am wondering whether companies like Dmarcian could implement third-pary >> whitelisting. As they receive and analyze DMARC aggregate reports on >> behalf of many mail sites, they probably are able to distinguish various >> level of authentication failures, from mailing lists to misaligned ESPs, to >> actual abusers. In that case, they could maintain a whitelist tailored for >> any given client. The client would set, say: >> >> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto: >> client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]" >> [...] >> > > Having spent a lot of time and energy building a DKIM-based reputation > system that (IMHO) showed promise, I made it available for people to try > for free. There was no uptake, even after presenting its promising results > in places like M3AAWG. Times may have changed, but in retrospect I think > there are too many "what-ifs" for add-ons of this nature to be seen as > feasible. The issues seem to be: > > > Hi MSK, hi Ale, > > I can second that MSK's DKIM-based reputation system is amazing. From > where I sit, it's like a flying saucer that humans just haven't figured out > how to fuel quite yet. I believe that fuel comes from widespread adoption > of domain-based email authentication aka DMARC. The challenge of getting > the email universe to embrace something like DMARC feels at times > impossible, but the fact is it just takes a lot of coordination, > dedication, and consistent levels of exercise to stay sane. > > That said, Ale, I like the idea of a Domain Owner being able to share some > sort of exception list for email flows that are recognized by the Domain > Owner, but are still (for various reasons) beyond the ability of the Domain > Owner to address. Something like, "I've got a vendor that will never send > DMARC-compliant email on my behalf". It appeals to my fondness to be able > to Just Fix Things without having to bother anyone. I don't think it would > work, though, because it relies on email receivers having to widely > implement new stuff, and it relies on Domain Owners accurately maintaining > another thing. It's easier and more effective to get the vendor to do the > right thing. > > Oh, on 2nd read (I've been consumed with the non-IETF world for a few > months and only took this up because Ale emailed me at work).. I think > keying off of "Sender:" is a really bad idea. Multiple policy keys into a > single piece of email has never made sense. > Third party authorization makes sense to me in theory as a tool for a very > specific problem. In practice, people and organizations struggle to get > first party authorization into place. Once they start to tackle their own > first party authorization, the need for third party authorization tends to > evaporate. What's left over? People that want to put together a list of > authorized third parties but aren't quite ready to do their own first party > auth? > > From a receiver's perspective, it then looks like the first party has no > idea what it is doing (which is the default anti-spam stance for all > Internet mail), so then the receiver is now looking at a bunch of factors > unrelated to first-party auth.. including any third party authorization. > EG, the receiver notes that the email is authorized by a third-party - a > newsletter company. "First party" authorization is NOT established, so the > receiver has to process the email based on the strength of the newsletter > company's reputation (among other things). So then why bother at all with > the construct of "third party authorization"? > > So I guess put me in the camp of not seeing utility in third party > authorizations. Better to make the work that needs to be done as clear and > as simple as possible. > I tend to agree with the negative stance on third party auth, but SPF obviously has the include: statement which is third party auth at the most basic level... atps[1] is the obvious equivalent for DKIM. I don't know if atps failed because it wasn't all that useful, or if it was tied in folks minds to adps, or the failure of the follow-on reputation system stuff.. Neither atps or spf include are really designed for large scale usage across thousands of "relays" etc, and I don't think they should be used for that, but for a bunch of small to medium entities, it could be the thing that makes higher p= possible. Brandon [1] I just looked atps again, but I might have missed something that makes it less useful
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
