On Tue, Sep 23, 2003 at 01:16:38PM -0600, Jacob Anawalt wrote: > I've already mentioned the web authorization idea and the rotate your > email address on some schedule ideas in another thread. I've even seen a > web site go so far as to use a .js file function to put together the email > address from a bunch of fragments when you click the mailto link. That > would take more work to parse, but it is still possible by having an email > grabbing webbot that can run javascript.
That would also break for people who use non-Javascript enabled browsers. > Another though I've had on the mailing list issues (besides wondering why > I'm trying to make mail act like a news client with threads and looking > for a 'watch thread' capable client) is if I had an email address to use > on mailing lists that only accepted email from the list servers I was on > and reject all others I should only get the spam that relayed through the > list. Interesting. But managing that would require some energy from you... > The mail server would need to have access to my personal list of > acceptable email addresses so it could give a 550 with the appropriate > extended SMTP code for unauthorized/security and an appropriate error > message after the HELO and MAIL FROM and RCPT TO: have been given. It > should only do this for mail accounts that have entries in the safe list. > If your list is empty, all email is valid. If you have one or more > entries, only those ones can send you email. > > Some ideas for rules to accept or reject the email may include: > > If HELO does not match a reverse DNS lookup and doesn't match the domain > of RCPT TO: or to a user specified value then the mail is rejected. Blocks big ISPs... I've found two already. One of them is movistar.com. Can't remember the other Also, probably breaks small businesses who use DSL and can't use their ISPs smarthosts (see the recent thread, "OT: Martin Krafft - mail bouncing". > A looser match would be just on the HELO <name> where the name given is > some md5hash of the user's email address and some value noted on the > mailing list. People start getting spammed, the list admin changes the key > used to generate the name value and people go to the web to see what it > has been changed to. If I use taht, I'll have to keep changing the key every now and then. Spam is bad not only because it takes a lot of bandwidth, but also because it's not convenient. Challenge-response solution can be as inconvenient as spam itself, for example. And I think the same would work for this solution... > I'm sure there are other better ideas to be had along the lines of how to > quickly identify that the sending server is who they say they are and look > up a safe list to see if the user accepts email from that server. Make the list server PGP-sign the messages, maybe? You install the list server key once, and never worry about it again? > Compare this to the "dog chasing cars" method of inventing a new filter > rule that looks through the MIME data to decide if this is the latest worm > you don't want or the kissing picture that you do. Sure it's cool to be a > geek and figure out the rules. If you like doing this, do it. Maybe spam > isn't a cost to you but a benifit if you consider your enjoyment at > solving each filter puzzle. I think that's why I like finding bugs, to > help find and solve puzzles. On the other hand this method of filtering is > more expensive in every measure I can think of except the freedom of > allowing anyone to email you anytime. You spend time thinking up rules, > writing rules and testing rules. The rules are applied after you have > accepted the bandwidth of the transfer. Running the rules takes CPU time > and possibly more bandwidth as you do RBL DNS or Razor and storing the > email takes disk space. I agree. But then I think any technical solution has the same problem. The "real solution" would be making spammers not want to spam (so we don't have to block them). You'd need to understand the intricacies of their business, and so something that makes them give up. A very naïve thing would be to start doing statistical research, asking people how they feel when they get spam, and make that get to the clients of these spammers. But as I said, this is naïve, and assumes that we know how that business works. (I don't think I know that) But something along those lines will have to work, someday -- I hope! J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
