[Mimedefang] Re: Spam Assassin

[Jeff Heinen]

-----Original Message-----
From: David F. Skoll [mailto:dfs at roaringpenguin.com]
Sent: Tuesday, January 08, 2002 4:42 PM
To: 'mimedefang at lists.roaringpenguin.com'
Cc: Jeff Heinen
Subject: RE: [Mimedefang] Re: Spam Assassin


> On Tue, 8 Jan 2002, Jeff Heinen wrote:
> 
> > Interesting, $status->finish() is the deconstructor for the status
object.
> > I'm running defang under the multiplexor and haven't seen any issues,
> 
> I haven't had problems either, but I added the call in is_spam and check.
> MIMEDefang kills the Perl process after it has processed (by default) 100
> messages, so this limits the propagation of memory leaks.

Limits, but if all 100 messages were large enough, it might be something.
Also, it might have been a strange off chance of left over global, or even
local data that wasn't cleared right. Something about the instantiation of
$status perhaps? That would leave dirty data laying around.

> 
> > That is what I resorted to. However, for some odd reason, adding a
> > boilerplate messed up all the MIME attachments on every message.
> 
> Really?  Are you resetting your variables in filter_begin?  Don't forget
> that in server mode, a given Perl process can process many e-mails, and
you
> need to explicitly set every global variable you use later on.

I use exactly what I sent over the list, and my filter_end was 6 lines:

sub filter_end {
	my($entity) = @_;
	if ( $is_spam ) {
		append_boilerplate($entity, $report);
	}
}		

You are right, I wasn't clearing our $is_spam or $report, yet oddly I wasn't
having any problems of bleed, or mismatched reports. All it was doing was
messing up the formatting of the message in Exchange. (Not like that is
difficult however).

> 
> > I've started looking for ways to add the
> > report as a text/plain attachment named 'SA Report' instead as a hopeful
> > replacement.
> 
> You can build a MIME::Entity and add it in.  The MIME::Tools man pages
> aren't bad.

That's what I'm looking at now. Anyone well versed in MIME to venture what
I'd need? Just content type, name, and data, right?
 
> > How much access is there to sendmail variables, etc. within a milter
> > script?  Is there any way to leverage the sendmail internal map
> > files?
> 
> No.  Milters don't necessarily even run on the same machine as
> sendmail, so they have no access to its databases.  Per-user stuff
> should NOT be done by MIMEDefang; it's best done by the delivery
> agent.  If a message comes for a at mydomain.net and b at mydomain.net,
> MIMEDefang processes it only *once*, and if "a" and "b" have different
> policies, you're in trouble.

This is a sticky part here. We did have this discussion, and the only
exception we had, really, was our pagers, which are bounced out to their
email address at the pager company. However, I think I know a way around
this in our exchange server. (Not very clean, but functional)
 
> > 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.
> 
> See stream_by_domain in mimedefang-filter(5).  You _can_ use MIMEDefang
> fairly efficiently to make per-domain decisions.

I did see this, but how is this written? If someone drops a 100 recipient
Spam on me, will I end out resending this to everyone? Or is it just
injected into sendmail as if the original sender sent it 100 messages with 1
recipient each? (To which sendmail would just drop the 99 others as 'we do
not relay'). All I need is to create a data structure with the extra
per-domain configuration information I need, and as mimedefang is persistent
for 100 connections, the overhead to load it would not be that noticeable.
Correct?


-Jeff