Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Brandon Long <[e-mail]>]

On Thu, Aug 20, 2020 at 1:36 PM Tim Draegen <[e-mail]> wrote:

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy <[e-mail]>
> wrote:
>
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely <[e-mail]> 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:
>> [e-mail]; 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