Hi again,
So just to confirm, there is no code/commands that can pipe a message
through an external program, and catch the message back with changes made to
it?
Just like how the 'xfilter' command works in my maildrop .mailfilter, which
pipes the message to the external program, and the output from that program
replaces the current message being delivered.
.mailfilter:
xfilter "/usr/bin/spamassassin"
Is there a way to duplicate this in tmda, maybe something like having my
"filter" file like this:
-------------------------------------------------------------------
from-cdb /etcmail/tmda/actrix_whitelist.cdb ok
from-cdb /etcmail/tmda/actrix_blacklist.cdb bounce
from-file -autocdb ~/.tmda/whitelist ok
from-file -autocdb ~/.tmda/blacklist bounce
# deliver all other mail (aka pending) to spamassassin
from * deliver=|/usr/local/bin/spamassassin
or if that doesn't work, the above last 2 lines could be replaced by
something like:
# deliver all other mail (aka pending) to procmail & spamassassin procmailrc
file
from * deliver=|/usr/bin/procmail .tmda-sa-rc
-------------------------------------------------------------------
Then in my .tmda-sa-rc file:
-------------------------------------------------------------------
# TMDA SpamAssassin procmailrc file - .tmda-sa-rc
# Filter all mail (pending items already missed by white/black lists)
through SpamAssassin:
:0fw: spamassassin.lock
| spamassassin
:0e
{
EXITCODE=$?
}
# Move all mail to tmda pending (not quite right, delivers to maildir
format, rather than pending dir)
DEFAULT=/usr/home/m/i/mike/.tmda/pending/
--------------------------------------------------------------------
Using the above setup with tmda delivering all pending items back to a
second procmail process, and through spamassassin, and then to the pending
folder, actually works, however in the last step
(DEFAULT=/usr/home/m/i/mike/.tmda/pending/) this creates maildir folders in
my pending folder: cur, new & tmp, and puts the pending in the new dur.
Is it possible using procmail to just move the msg to a folder, rather than
a maildir?
Secondly, I know that calling procmail a second time will create more load
on the server (eg processing a msg twice), but is there is any other way
around this for now? And would this load increase be less/more than the load
increase if I actually passed every msg through SpamAssassin before it gets
to TMDA, rather than using SpamAssassin on msgs that only get to pending.
Just something to think about.
Regards
Mike Usmar
Web Developer
Actrix Networks Ltd
[EMAIL PROTECTED]
0800 ACTRIX (228749) - ext 411
____________________________
----- Original Message -----
From: "Tim Legant" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 30, 2004 12:23 PM
Subject: Re: TMDA & SpamAssassin
> "Mike Usmar" <[EMAIL PROTECTED]> writes:
>
> > Currently having a few problems getting SpamAssassin working correctly
with
> > TMDA. Now I've searched through most of the mailing list archives, and
found
> > nothing in reference to having TMDA calling spamassassin after all
> > white/black lists have been checked. Only references to spamassassin is
> > where you run messages through SA first, then through TMDA.
> >
> > What I am trying to do, is run messages through TMDA like normal, and if
> > they do not match any whitelists or blacklists, then run message through
SA,
> > and tag the subject with [SPAM], and then in our web interface to the
> > Pending queue, the user can see which is definitely spam (tagged subject
by
> > SA), and which is just pending (and can order the pending items by
subject,
> > and put definite spam at the top... etc.)
> >
> > This is my current TMDA filter file:
> >
> > from-cdb /etcmail/tmda/actrix_whitelist.cdb ok
> > from-cdb /etcmail/tmda/actrix_blacklist.cdb bounce
> > from-file -autocdb ~/.tmda/whitelist ok
> > from-file -autocdb ~/.tmda/blacklist bounce
> > pipe "/usr/local/bin/spamassassin" confirm
>
> The 'pipe' rule pipes the mail to the specified program but doesn't
> read the message back; in other words, it doesn't treat the program as
> a filter. It uses the return code from the program to determine if
> the rule matched. Thus, any changes SpamAssassin makes to the message
> are not preserved.
>
> The behavior you were hoping for is interesting, though. I'm noting
> it as a possible additional feature sometime in version 1.x.
>
>
> Tim
>
> _____________________________________________
> tmda-users mailing list ([EMAIL PROTECTED])
> http://tmda.net/lists/listinfo/tmda-users
>
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
