On 2020-08-14 4:12 p.m., Dotzero wrote:
On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely <ves...@tana.it> wrote:
On 2020-08-10 7:24 p.m., John Levine wrote:
In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> 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.
Thanks for that, I put a reference to your post on the wikipedia[*]
(the original link to the FTC event expired sometimes in 2012).
Best
Ale
--
[*] https://en.wikipedia.org/wiki/Email_authentication#Rationale
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
