At 9:23 AM -0200 4/11/03, Kurt Magnusson wrote:
I was thinking more of where the email itself is encoded (e.g. base64 and the like). But it's not an insurmountable problem--just a speed issue.many many ways to encode those, making the filtering process time consuming unless it takes place on the end-user machine. It is also aI looked at the data I have since one year back and there are 4 basic URL-types, normal, undisguised; IP-numbers (easy to identify); IP-numbers with decimal coding (or what it called - also easy to compare) and then the "web disguised" URLs, with web coded chars, non readable.
This function will only be for the ISP's, rest of us have to wait to when the list maintainer releases a new list, once a day? It is also secure, to not allow spammers to taint new data.It's secure only if the reporting process is made and kept secure. Never mind the issue of which ISPs you trust. Again, not a show-stopper, but keep in mind that there are rogue ISPs, and certainly there are going to be employee access issues.
Okay. So basically what you are describing is virtually the same as what we have to day, but with a centralized filtering system instead of centralized RBLs.Spammers frequently include links to legit sites in their spam--you don't want to accidentally blacklist those. Finally, there's aYes, I agree, this is not solved, but with the steps above, it should be a lesser issue (in a global sense) and there have to be a process where a legit site can contact the list maintainer, get a copy of the spam and explain or start legal proceedings against the forger (if identified). As of today, if you can explain the mail or prove its falsity, you get of the hook.
That trust is far from universal. You tend to get what you pay for (except with Verisign, which still falls flat on its face when it comes to customer support, even though I *am* paying for it).Why do we trust the present blacklists, Verisign or Hotmail. The process is