> 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 > <mailto: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 <mailto:client...@ag.dmarcian.com>; > snd=client-id.rhswl.dmarcian.com <http://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. =- Tim
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
