Mail-SpamCannibal

 view release on metacpan or  search on metacpan

INSTALL  view on Meta::CPAN

    expires very old records and checks that there are not multiple entries
    in the database for the same IP address or an entry that is present in
    one database that is missing a corresponding entry in a companion
    database.

    For example:

      A spam messages arrives and makes it through the system to your in
      box. Subsequently, sc_BLcheck.pl finds the IP address of the spam host
      in a remote DNSBL and adds records to the tarpit and blcontrib
      databases. You find the spam on your desktop and add it to the tarpit
      and evidence databases via the sc_mailfilter.pl robot script. Now
      there is an extra record in blcontrib that is unused.

    There are many more possible ways for such inconsistencies to occur and
    sc_cleanup.pl removes these records automatically.

    Login as the spamcannibal user and put an entry in your crontab
    something like this:

      # check valid blcontrib every few days

SpamCannibal.pm  view on Meta::CPAN

this is harmless. Any contact by a sending mail server will update the tarpit 
time tag resulting in a check being performed at the next CRON interval and 
the entry being removed if the IP address is no longer in the external DNSBL.

Also see sc_BlackList.conf.sample in the spamcannibal config directory.

=item * sc_mailcheck.pl

This script is a robot mail recipient set up in the spamcannibal user's
.forward file. Secure mail with a message body containing the headers and
spam content of a 'spam' message sent from your desktop is parsed to extract
the origination MTA. The IP address of the MTA is added to the spamcannibal
'tarpit' database and the 'spam' content is added to the spamcannibal
'evidence' database for use by the web interface.

Also see sc_mailfilter.conf.sample in the spamcannibal config directory

=item * sc_admin.pl

This script provides the site administrator with direct access to the fields
in the SpamCannibal databases for manual updates, deletes or other tasks

config/sc_mailfilter.conf.sample  view on Meta::CPAN

# Require that a least on of these headers is present. Use this in place of
# PGP above to limit the source of entries to the database.
# This is a single value or an array of values. The values may be regular
# expressions. They will be matched in a case insensitive manner and the
# pattern must be the 'start' of a header.
#
#	REQHEAD		=> 'received:.+myhost\.com',
#	  or
#	REQHEAD		=> [	'received:.+mylaptop',
#				'received:.+desktop\.pc',
#	],

# Use dirty read of headers. Use this procedure only if you can not avoid
# auto-wrapping in your mail client. Some goofy stuff can slip through or
# headers may be mangled and not properly parsed.
#
# See man Mail::SpamCannibal::ParseMessage 'headers' and 'rfheaders'
# for a detailed explanation.
#
# [ OPTIONAL ] not recommended, sigh... but usually needed

pods/INSTALL.pod  view on Meta::CPAN

the database for the same IP address or an entry that is present in one
database that is missing a corresponding entry in a companion database. 

For example:

=over 2

A spam messages arrives and makes it through the system to your in box.
Subsequently, sc_BLcheck.pl finds the IP address of the spam host in a
remote DNSBL and adds records to the B<tarpit> and B<blcontrib> databases.
You find the spam on your desktop and add it to the B<tarpit> and
B<evidence> databases via the sc_mailfilter.pl robot script. Now there is an
extra record in B<blcontrib> that is unused. 

=back

There are many more possible
ways for such inconsistencies to occur and B<sc_cleanup.pl> removes these
records automatically.

Login as the spamcannibal user and put an entry in your crontab something

pods/howitworks.pod  view on Meta::CPAN

<p>
<li>Activated by a cron job, <a href=scripts.html>sc_BLcheck.pl</a> processes the 'archive' database and checks each
IP address against the list of DNSBL servers in its configuration file.
Addresses found in a remote DNSBL database that meet the necessary match
criteria are added to the 'tarpit' database. The TXT record (if any) or a
default TXT record from the config file is added to the 'blcontrib' database
along with the identity of the remote DNSBL for use by the DNSBLserver
daemon and web server client.
<p>
<li>Spam that is not identified by the automated tools that get's
through to your desktop is handled by the <a href=scripts.html>sc_mailfilter.pl</a> mail client.
This script accepts mail sent to it as a designated 'robot' user. Its
configuration file contains the known mail servers and aliases within your
domain(s). Simply email a copy of the headers and message to the 'robot' spam
account from your PGP enabled (optional for security) mail client. It will
be decrypted by sc_maifilter.pl and the first originating server in the 
Received-from: headers that is not a known-acceptable mail host is extracted 
and added to the 'tarpit' database. The headers and message content are added 
to the 'evidence' database for use by the web client.
</ul>
<p>

public_html/docs/admin_screens.html  view on Meta::CPAN

</td></tr>

<tr><td>
<hr>
<p>
<img src=../images/spamsg.jpg align=right
width=280 height=283
><a name="#email interface"></a>
<font size='+1'>Add Spam via E-mail</font>
<p>
Spam can be added to the SpamCannibal database by email from your desktop.
Optionally, to protect the interface from malicious data entry, it can (and
should) be encrypted using PGP. Follow these simple steps:
<ol>
<li>Pop a new message window and address it to your SPAM mail client.
Messages addressed to this client will be caught and processed by the
sc_mailfilter.pl script.
<li>Expand the mail message to show the headers
<li>Copy and paste the headers and salient portions of the message into the
new message window.
<li>Encrypt the message