Re: how can i fight __this__ Spam?

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: John Bolding
Fecha:  
A: exim-users
Asunto: Re: how can i fight __this__ Spam?
Although we are blocking all of *.earthlink.net,
the "From MAILER-DAEMON" email got through our antispam filter
because the filter was just looking at these things:

sender_address_domain
sender_address
sender_host_address
reply_address
return_path

At one time, many months ago, sender_host_name was not working.
It is now (exim 1.62 +), and plugging in a lookup on
sender_host_name in our filter works so that at least this
email can be classified as SPAM.

It is still not replyable, but with use of the $sender_host_name,
an abuse@$sender_host_name should do the trick.

    > From tom@??? Sat Aug 09 18:59:39 1997
    >   
    >   Another issue, earthlink.net has a bad reputation, as spamlink.  They
    > have about a half dozen mail server that allow open and unrestricted
    > relaying.  It is well known that these servers are open, and they are used
    > by spammers not only at spamlink, but worldwide.  I would very much like
    > to see a boycott of all mail from *.it.earthlink.net, in order to force
    > spamlink to clean up this mess.


A resounding YES!

    > From woods@??? Sat Aug 09 20:20:35 1997


    > I say that it's a "only & last" resort because many fine postmasters
    > have already given up pleading with the Earthlink.net to close down
    > third-party remote relay ability on their mailers (esp. those that live
    > in the *.it.earthlink.net domain -- I think they've managed to upgrade
    > at least some of their servers in the USA with protective measures).
    > (I personally don't know why Earthlink doesn't treat this as a criminal
    > trespass matter, though I agree that the jurisdictional problems are
    > indeed immense.)
    > 


    > This is indeed a very clever spam.  I urge each and every one of you to
    > contact all postmasters you know, regardless of which mailer they might
    > run, and implore them with the greatest degree of urgency you can muster
    > that they implement protection against third-party remote relay in *all*
    > of the mailers they control and that they do it *NOW*.  I for one have
    > seriously considered writing a module that opens a connection back to
    > the remote mailer and tests to see if it would permit me to relay mail
    > to a third remote site, and if so to reject the incoming connection
    > immediately.


More cries of YES from our cheap seats along the first base line.

-cc