On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely <[email protected]> wrote:
> On 2020-08-10 7:24 p.m., John Levine wrote: > > In article <[email protected]> you > write: > >> Even an external reputation system requires recipient > >> participation. That is why I suggested both a > >> send3="parameters" clause to indicate sender support for > >> third-party authorization and a verify3="parameters" clause to > >> indicate recipient support for third-party authentication. When > >> both are visible to the non-domain message source, that source > >> can have confidence that the message will be handled as > >> authorized. > > > We have had a lot of attempts at third-party authorization schemes > > going back at least to vouch-by-reference in 2009 and ATPS in 2012, > > and the Spamhaus Whitelist in 2010. Every single one of them failed, > > not due to technical problems, but because nobody was interested. > > > We can either try and understand what was wrong in those schemes, or > abandon authorization schemes forever. > > Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent > success. > > PGP, GPG, and even personal CA certificates never became really > popular, so we could have concluded that digital signature aren't > worth considering for anti-spoof protocols. Yet, someone thought > about DKIM... > There is a little bit of history behind the impetus for SPF and DKIM. In 2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on Email Authentication and SPAM. It also let it be known that if the private sector didn't come up with solutions it was willing to move forward with regulation. This helped drive activity for SPF, the merger of DK and IIM to create DKIM and Microsoft's push for SenderID. Private sector folks did not want to risk what government regulation might look like. At that time there were also folks pushing for PGP, GPG, Personal Certificate and S/MIME as paths forward. Even with that, it took a while for industry efforts to gain some sense of clarity. Notice that the general path forward was basically domain based and not individual user/client based. There was a debate within the DKIM effort regarding i= vs d= to the extent that at one industry event people were walking around with little stickers on their badges to indicate which they supported. I believe that was courtesy of Dave Crocker. Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
