On Mon, 13 Nov 2006 16:20:07 -0000, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
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.
Be careful there. We want people out there to welcome and accept these
protocols when they start to be deployed. A huge spate of false positives
and false negatives will rapidly cause it to come into disrepute and to
wither. This is not a technical problem - it is a social problem, but we
ignore it at our peril.
Q. "My cousin John, who uses the same bank as me, gets nice "SAFE" logos
on his bank messages. I don't see them. Should I be worried?"
A. "You need to use a different MUA."
Q. "I bank with Bank of America. I always used to get those "SAFE" logos.
Now they have suddenly stopped".
A. "I see from your headers that you are on holiday in the Netherlands
Antilles. The ISP you are using there doesn't use whitelists for American
Banks - just for the Bank of the Antilles and ABN/AMRO."
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.
No implementor of the popular MUAs is going to invest effort in
implementing this "SAFE" Logo if there are lots of different protocols
which might be used. But I see now this is "work for later" according to
our charter.
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>.)
And there you gave a good answer (and it also brings the thread back on
topic :-). OK, such schemes are possible. But the Bad Guy can still insert
the "SAFE" header and sign it, so there is still work for the verifying
agent to do by way of spotting such already present headers and acting
accordingly. Trouble is, lots of ISPs are going to do a poor job of this
if left to their own devices, so it needs a very tightly drawn
specification of how to do it. Otherwise we shall have those false
positives/negatives and the whole scheme will fail.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html