On 27/May/10 20:45, Douglas Otis wrote: > To better answer Steve's criticisms on phishing, our company among > others, offers browser plugins for web mail and popular email > applications that annotate messages using corporate icons.
Yes, perhaps a favicon would get more adoption than, say, "dkim=most" --which in turn would still be better than "unknown". This and the hypothesized MUA-hiding of unsigned "friendly from", that Mike mentioned, may increase DKIM's visibility, and possibly clarify how it works. I haven't found the rest of this discussion on ADSP overly constructive. If, as John said, domains publish inaccurate ADSP settings, it is the IETF's communication efficiency that has to be blamed --it's not an argument to favor private domains lists as an alternative. I agree ADSP currently leaves much to be desired. It deserves completion. (DKIM itself is in a similar situation, since it is still not MIME-compliant. A somewhat embarrassing circumstance for a protocol designed not to "break forwarding".) At any rate, let me note that besides countering phishing, ADSP plays a possibly more foundational role: it /characterizes/ DKIM signatures. Thus, there may be further *DSPs, e.g. * list signature, tied to the signed List-ID, * forwarder signature, tied to an SPF-validated 5321.mfrom. These characterizations integrate assessments. By qualifying the reasons why a given party signs a message, they give an insight into the mail transmission process, which may lead to the possibility of tuning it, e.g. by routing feedback appropriately. OTOH, unqualified signatures only entrust limited responsibility, as they don't say what questions the signer should be able to respond to. In this respect, an hypothetical reputation system that allowed to compute a message's worthiness up to 16 digits of precision, albeit useful, wouldn't differ much from spamassassin's fuzzy approach. I hope the WG will proceed and specify how LDSP should be, possibly leveraging any lesson that ADSP might have taught. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
