[Mimedefang] Re: Newbie question - testing

[Jan Pieter Cornet]

On Thu, Jul 21, 2005 at 04:02:09PM -0400, WBrown at e1b.org wrote:
> > Ole Craig wrote:
> > 
> > >>>HTML::TokeParser              : yes
> > >>Freudian slip? ;)
> > > Well, we are trying to weed out the bad mail, after all...
> > 
> > This is a civil list; please don't take pot shots.
> 
> I thought it was being decriminalized up there north of the border...

It already is this side of the Atlantic, so I hope I've got the
right stuff for the OP :)

Dan:
What's the output of mimedefang.pl -features *when run as the user it
is configured to run under*, eg as "defang":

su -s /bin/bash -c "mimedefang.pl -features" defang

.. if that's another list than you originally sent, there's your problem:
permission of stuff in perl's @INC include dirs. Sometimes a root umask of
077 breaks perl modules if you install them. (Use "perl -V" if you forgot
the default perl include dirs).

Virusscanning/clamd might not be working due to permissions on the
clamd socket. You either have to run clamd as the user mimedefang runs
as (usually "defang"), or you have to play games with group permissions.
If clamAV is only used by mimedefang, simply change it to run as the
defang user. And make sure the clamd socket is where mimedefang expects
it to be (usually /var/spool/MIMEDefang/clamd.sock).

Spamassassin really should work if the perl modules are available.
You could try sprinkling some md_syslog('info', "I am here...")
or similar calls over your code at key points, to see if they are
reached (and with what variable contents, if necessary). (and remember
to md-mx-ctrl reread)

As a last measure, try disabling the embedded perl interpreter. It
shouldn't make any difference regarding functionality (it should only
add speed and reduce memory usage), but sometimes it does change things.
That's the '-E' switch to mimedefang-multiplexor, or the MX_EMBED_PERL
setting in mimedefang.conf.

A last tip: if you want to experiment with your email on a production
server, but you don't want it to touch real production email, and
you haven't got a scratch monkey nearby, then edit /etc/services,
find the line that says or starts with "smtp    25/tcp", and change
the portnumber/protocol to read: 26/tcp.

Then you can safely start sendmail, which will listen on port 26,
and try to reach other mail servers on port 26, which will of course
never work, but it will allow you to send mail from localhost, or
telnet to the machine. And while you're at it, add an alias to the lo0
localhost interface, of 127.0.0.2 ("ifconfig lo:1 127.0.0.2" on linux,
"ifconfig lo0 127.0.0.2 alias" on BSD), and then use netcat to connect
to your server from 127.0.0.2: "nc -v -s 127.0.0.2 localhost 26"
(or use port 25 if sendmail runs there), and walk the SMTP protocol
to test if spamassassin network tests are working. 127.0.0.2 should
appear on practically all blacklists you have in use.

PS: Don't forget to set /etc/services back the way it was, and restart
the lot, or you have just built the world's most aggressive spamfilter.

Have the appropriate amount of fun,

-- 
#!perl -wpl # mmfppfmpmmpp mmpffm <pmmppfmfpppppfmmmf at fpffmm4mmmpmfpmf.ppppmf>
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}->(map{/p|f/i+/f/i}split//,$&)+97):qw(m p f)[map{((ord$&)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$&;$f.eig;                                # Jan-Pieter Cornet