[Mimedefang] Re: Spam Assassin

[Jeff Heinen]

-----Original Message-----
From: Nels Lindquist [mailto:nlindq at maei.ca]
Sent: Tuesday, January 08, 2002 2:36 PM
To: Jeff Heinen; mimedefang at lists.roaringpenguin.com
Subject: [Mimedefang] Re: Spam Assassin


On 4 Jan 2002 at 15:44, Jeff Heinen wrote:

> Below are two procedures, I've only tested the first, as I didn't have
time
> to rewrite the filter to test the second (yet). But most, if not all the
> data you would be able to get out if it is in the first one. Also, I have
> added a trimmed version of my filter_begin which I am using this data.

I ran into some problems with 'Fang 2.3 Beta 1 (prior to your 
submission, Jeff) and after a bit of reasearch (the 
Mail::SpamAssassin::PerMsgStatus man page) I found the 
$status->finish() call.  I put it in David's spam_assassin_is_spam 
function, just prior to the return call, and it seemed to eliminate 
my problem.  Would it be useful to add this to your functions as 
well?

--

Interesting, $status->finish() is the deconstructor for the status object.
I'm running defang under the multiplexor and haven't seen any issues, but I
don't see any harm in adding this after you are sure you are done with the
status object. (Either in spam_assassin_is_spam, or spam_assassin_check, but
not in spam_assassin_status. Anyone using the status object directly would
need to clean it up on its own.) I'll add this to my setup and see if it
does anything nasty.

How do you have it set up? I'm sure there are some setups that would keep at
least a semi-persistent environment.

--

> What I'm looking for now is a way to carry the $report into the top of the
> message. I could add it via append_boilerplate, but would the variables I
> set in filter_begin ($is_spam and $report) carry to filter_end? Plus, if
its
> spam, I want the explanation of why I think is spam right at the top.

What would be the impact of making these global variables (similar to 
$VirusScannerMessages) within mimedefang.pl?

--

That is what I resorted to. However, for some odd reason, adding a
boilerplate messed up all the MIME attachments on every message. Even with
'$Stupidity{"NoMultipleInlines"} = 1;' I'd get the same problem, the body of
a message being its own attachment. I've started looking for ways to add the
report as a text/plain attachment named 'SA Report' instead as a hopeful
replacement. 

--

> The other thing I'm looking for is ways to manage per-user differences.
For
> example, I want to tag all mail, except for those heading to my pager
which
> I want to deny everything that is close to spam. Custom SA configurations,
> or filter scripting are both acceptable I'm just wondering if someone has
a
> nice generic way that would be easy to adapt as we add more aliases.

How much access is there to sendmail variables, etc. within a milter 
script?  Is there any way to leverage the sendmail internal map 
files?  I'm thinking specifically of the FEATURE(delay_checks) stuff 
which results in /etc/mail/access.db lookups for "SPAMFRIEND" or 
"SPAMHATER" values.  I use this for turning RBL checks on and off for 
particular users, and it would be handy to add/edit users in only one 
place.  

--

This is an interesting use of the access.db. I've been worried that I'd have
to set up yet another database to keep tabs on this. Question tho, sendmail
ignores an answer that it doesn't know, right? So if its not RELAY, OK,
REJECT, or DISCARD, its treated as the default, correct?

I'm not sure, however, if it would handle multiple entries of the same
domain. (I.e.: you would need 'domain.com	RELAY' to allow an alias to
pass thought sendmail, but you would also need 'domain.com	DROP 10' to
drop all messages with greater then 10 hits. Correct?

Unfortunately for me, I need a little more customizability from it. I've
been asked for the ability to not only decide if I should PASS, TAG or DROP
a piece of mail based on hit limits, but also be able to include a
'per-domain' contact we forward the message to in each case. And I'm sure
feature-creep will find its way here as well. I'm trying to decide what I
can build that is adaptable enough to do whatever I need short of breaking
down and making a mini-config file:

--

domaina.com { DROP 10, NOTIFY 5 mailadmin at domaina.com } 
# Drop any SPAM over 10, but pass 5 and up to the false-positive checker at
domaina.com

domainb.com { PASS }
# Domainb.com doesn't want their email 'tagged' at all.

domainc.com { TAG }
# DomainC only wants their mail tagged, they will do all filtering at their
MDA.

mypager at myoffice.com { DROP 4 }
# If its even close to spam, I don't want it on my pager. 

--


If I'm missing something plain everyone feel free to fill me in. (Or, if
anyone has suggestions on what else I should make sure I add. I'm open to
ideas.)


-Jeff