[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Anti-Spam ideas for usenet/list harvested email addresses



Jeronimo Pellegrini said:
> On Tue, Sep 23, 2003 at 01:16:38PM -0600, Jacob Anawalt wrote:
[snip]
>> 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".
>

But my goal was to reduce the spam I get that is harvested from mailing
lists. If someone wants to subscribe to a mailing list that doesn't do
reverse dns, then there needs to be authentication before DATA on some
other bit of information. I could still get posts from the guy in Brazil
or the guy using SMTP off of his cable modem DHCP'd address because they
would be mailing the list, not me. The list is mailing me.

>> 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...

Well, that's the cost we pay for conveniance. I'm willing to give up that
freedom for less spam on the email address I use for mailing lists. My
first choice as a user will be to subscribe to lists that have proper
reverse dns.  I understand that others don't want that hassel.

>
>> 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?

If some small PGP/GPG data could be sent as part of a new EHLO syntax
command then OK, otherwise I'm in the DATA section again. It would have to
be a standard before I'd use that.

>
>> 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!
>

The latest churn on debian-user about Spam hasn't been UCE spam. It's been
worm spam. I don't know anyone personally who likes to recieve WORM/Virus
code in their inbox but it persists. I don't see a near-term solution for
convincing the individuals who write this code.

As for UCE/UBE, well someone else can deal with the politics of it. I will
also be glad when they just decide to stop.

I just want some good ideas on keeping them from getting my address in the
first place or on minimizing the bandwidth, cpu and human time on my end
to block any that did get my address.

-- 
Jacob
Trying out SquirrelMail



Reply to: