on Thu, Dec 07, 2000 at 07:44:07PM +1100, Damon Muller (dm-debian-user@empire.net.au) wrote:
> Quoth kmself@ix.netcom.com,
> > There are also several resources listed at Freshmeat, in particular:
> >
> > parp: http://freshmeat.net/projects/parp/
> > ricochet: http://freshmeat.net/projects/ricochet/
> > spam.pl: http://freshmeat.net/projects/spam.pl/
> > Spamkill: http://freshmeat.net/projects/spamkill/
> > The Veganizer: http://freshmeat.net/projects/theveganizer/
> > Vipul's Razor: http://freshmeat.net/projects/vipulsrazor/
>
> I use spam.pl myself, and while it doesn't do everything that you'd want
> it to do, it is quite useful. It's set up to allow you to send the
> complaints to abuse.net, and let them do your dirty work, if you want.
> It also lets you run it in dummy mode, which shows you who it's going to
> complain about without actually sending any mail, which can help avoid
> embarrassing mistakes.
>
> It's certainly not perfect, but it's better than nothing.
I've been looking at both Ricochet and spam.pl over the past week,
here's my evaluation. Corrections and/or comments welcomed. Note that
Vipul's Razor, listed above, is also written by Vipul Ved Prakash, the
author of ricochet.
- Both will report spam to a number of addresses.
- Ricochet seems to do a better job of finding addresses through whois
lookups. Caching these lookups also results in faster performance
as the system "learns" domains.
- spam.pl seems to generate a more extensive list of reply addresses
(using the same friend/ignore lists). Whether this is good or bad
really depends on the accuracy of these lists.
- Neither tool seems to do a traceroute lookup to find out where spam
is originating from by way of edge domains, ISPs, hosting sites, or
open relays. This is unfortunate, because it is the upstream
provider who's most likely to be able to do something directly about
spam. All other complaints are largely pissing in the wind. This
is wishlisted for spam.pl.
- spam.pl is more elegantly put together and more usefully commented.
Use of command-line options is closer to GNU/Linux standards than
ricochet. These differences make me more inclined to work with
spam.pl than ricochet if I want to modify a script. spam.pl also
appears to be in current development, while ricochet's been static
for over a year. On the other hand, ricochet appears to do more of
the right things. And I really don't know Perl that well, but we
can get over this.
- Both systems appear to allow specifying of specific additional
addresses to send the spam message to. In ricochet, the complaint
letter includes headers, it's trivial to add specified addresses to
these for receipt or cc.
- Interactive mode for both programs needs help. Ricochet's is just
plain nonintuitive -- I still haven't figured out how to use it.
Supposedly, you can edit messages and/or addresses that a spam
response is to be sent to.
- ricochet has a cooler name. On a serious note, spam.pl really ought
to be called something like "spamresponse", "spamtattler", or
something indicative of its use as a spam _retaliation_ tool.
Features I'd like to see in either/both projects include:
- An ability to check for RBL/ORBs blacklisting and to file a report
against these lists (MAPS has a more involved submission procedure,
but ORBs will accept a one-line email with the address in question).
Including an ORBs submission in these scripts would be trivial --
each of the non-excluded (friendly/skip listed) domains relaying the
message would be submitted. This is wishlisted for spam.pl.
- Ability to run the scripts against an 'mbox'-style mail file or to
pipe through a set of tagged messages from mutt. Currently both
tools only accept a single email as input. The ability to batch and
background mass responses would be helpful, particularly if more
intensive research mechanisms such as whois and traceroute lookups
are used.
- Ability to generate a "ticket number" for spam reports -- a unique
key to be used in identifying responses to spam reports.
- Ability to log sender data to a file or database for later
retrieval. This would provide the basis for further hooks into a
spam retaliation system such as logging and analysis of spam
patterns and spam response, as well as for generating MAPS
submissions. Data logged should include:
o Date and time of incident and/or alert mail(s) sent.
o Domain and host reported.
o Message-id of original spam (incident identifier)
o Address incident was reported to
o Indication of relationship of address to the spam -- 'From',
relay ('Received:' header), upstream provider (traceroute), WHOIS
contact (and relationship -- relay, host, upstream provider).
o Indication of whether or not this host should be considered for
reporting, and to what list(s) it should be reported to, under
what criterion. Some lists (ORBS) allow immediate reporting, some
(MAPS) require a time interval pass without an appropriate abuse
response and/or a pattern of abuse be clearly indicated.
Cheers.
--
Karsten M. Self <kmself@ix.netcom.com> http://www.netcom.com/~kmself
Evangelist, Zelerate, Inc. http://www.zelerate.org
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
Attachment:
pgplJInFTCtHM.pgp
Description: PGP signature