On Mon, 2004-11-29 at 12:42, Hallam-Baker, Phillip wrote:
The fact is that we are going to need BOTH SPF and DK to address all the
email authentication requirements that are out there. For messaging
convenience I try to encourage people to push SPF as an anti-spam solution
and DK in the anti-phishing area but we will actually need both in both
problems.
I don't see that SPF, DK, or IIM as being directly anti-spam or
anti-phish... All of those are anti-forgery. Further I think that even a
little bit of anti-forgery can work some wonders. For example I recently
got some phish bait from someone claiming to be
custservice_ref_73(_at_)wamu(_dot_)com using ip 200.92.168.183 or
customer-VER-168-183.megared.net.mx . I reported it and got a legit
response back from spoof(_at_)wamu(_dot_)net from 167.88.201.32 aka
mtao002.wamu.net ... So even a loose match on 167.88.0.0/12 would have
been tons better. It would have filtered out 4095/4096 of all ip address
as being absurd. I am sure they could go a tad tighter than that and
reap even more benefits. The other thing even a loose policy would do is
draw all these potential forgers closer to you. Instead of it being an
international issue you can send your local cops to the phishers. It
also makes it more likely that you share the same isp, or higher up
bandwidth provider. So your complaint will be a customer complaint and
not just someone they had no prior business contact with.
So if even just loose spf got deployed the would be spammer or phisher
should be forced to using something like happy_teller(_at_)wamu-bank(_dot_)com
instead , which ups their exposure as they now have to register a domain
name using one of the peoples accounts they already phished. This is
also where if you want to fight spam and/or phish you start needing more
tools, like public-key cryptography, hashcash, rdf, reputation systems
and the like. That is because at this point the user might be fooled by
similar looking urls. So the question shifts from "is this really
happy_teller(_at_)wamu-bank(_dot_)com?" to "is
happy_teller(_at_)wamu-bank(_dot_)com a bank
teller that I can trust?" .
One way to do that is to use public-key signed rdf documents from:
1)people like governments that issue business licenses
2)people like the better business bureau or consumer reports that give
ratings
3)other banks and financial institutions
4)business groups like local chamber of commerces
5)Trusted financial auditors like Arther Anderson;->
6)happy customers
7)tax men like the IRS
The gist of those statements would be for wamu.com that it is a bank
that does between $100million to $500 Billion USD worth of transactions
a year. Something like the XBRL(Extensible Business Reporting Language)
might be usable for this purpose.
When you did the same kind of semantic web look up for wamu-bank.com
then if the phisher went to some more work I'm sure you'll find some err
interesting references, but your WOT(Web 'O Trust) won't verify them.
Other things that might be useful are reputation systems.
Well for truth in advertising purposes I'll tell you I just recently
inherited a project that aims to be a distributed P2P email reputation
system. http://sourceforge.net/projects/gossip-project/ BTW use the
sourceforge mailing lists and not the one at roadtoad if you wish to
sign up. I need to fix those web pages RSN.
Well hopefully how it goes is that good sites like wamu.com send out
email and people mark them as being good ham. They then get good
reputations and people are happy.
Then a site like wamu-bank.com starts up and it sends email to people,
well some people aren't too smart so they label it as ham, others label
it as phish so it's reputation hopefully going into the negative.
Reputation should be made visible to the end-user via their MUA, it
could also be used to prioritize, or filter email.
I also think that whitelisting known good people using something akin to
foaf would be great. doaml for mailing lists could also be great.
Basically further rdf or semantic web type information might be able to
help in various ways.
I also think that adding in a little-bit of hashcash.org to help
differentiate between not yet known one-on-one type email and bulk
mailers would be great.
Maybe useful links.
http://www.xbrl.org/
http://dmoz.org/Bookmarks/P/pollei/Misc._Computer_stuff/Mailing_Lists/
--
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part