Charles Lindsey wrote:
Well that implies that every MUA worldwide needs to be upgraded before
this whitelist solution will work.
A whitelist is useful as soon as a single recipient (filter, user, whatever) can
apply it. It's benefit improves as it is incrementally adopted. There are
plenty of black- or white- lists that demonstrate this.
And before that, you have to define a communication protocol to convey
this information from the verifier/whitelist-looker-up/whatever to the
MUA that the Bad Guys cannot spoof.
Although true, there is no requirement that it be "standardized". Different
existing lists have different access methods.
Enough of them tend to have strong similarities to make standardization worth
pursuing, but that is only recent. (eg.,
<http://www.domain-assurance.org/protocol-overview.phtml>.)
It can't go in the body, because I read all my mail as plain text, and
drop HTML on sight as being sure evidence of spam. And Bad Guys can
write bodies too.
I believe the mechanism that Steve was describing does not carry the trusted
logo along with the message, but affixes it as a result of out-of-band
validation methods. His reference to the browser lock was, I believe, an
exemplar of user interface design, rather than information-carriage along a path.
You can't do it in the headers, because Bad Guys can write headers too.
Not when the headers are signed. (eg, <http://goodmailsystems.com>.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html