Re: Changing Evaluation Order of Default Rule

  Sabahattin,

I've never had occasion to try it, but I think you might get this to 
work if you caught the addresses of interest and used a pipe delivery 
instruction, piping them to another instance of TMDA with a slightly 
different setup (basically a blank incoming filter file).

something like the following might work in your incoming filter:

to<username>-dated-*@your.domain.dom deliver=|/usr/bin/tmda-filter -I /dev/nul

the -I /dev/nul tells tmda-filter to use /dev/nul as your incoming 
filter instead of your default filter file.  Since this would be an 
empty filter, the mail piped into this second instance of tmda-filter 
would have their tagged addresses checked for validity and either 
delivered, or the default action would be performed.

Good luck,

Dave

On 9/20/2010 2:49 AM, Sabahattin Gucukoglu wrote:
> I've just run into another situation where having the ability to decide when to evaluate the default action for whatever kind of recipient address (default, dated, keyword, etc) relative to the rules in my incoming filter would be damned useful.
>
> Here's my problem: about 30% of my spam is of the I-am-you variety, and that includes my role accounts.  However, some of my software is going to generate mail as me, and I won't be under its control, so no use of the fingerprint.  I get a keyword address, with the understanding it bypasses *all* other filtering, but of course a check for my email address that drops could only come after a rule for the keyword address that permits, since the default action for the address type happens only after the filter file is completely evaluated.  This breaks the intended semantics of my keyword address; now I will have to know in advance whether or not my software generates mail as me, and add exceptions to my incoming filter file for each and every one of them.  If I add this rule after setting u
 p keyword addresses already for software that generates mail as me, I will get bitten and probably won't notice - as happened here, with TMDA's very own *_CC variables.  If instead I could do
>   something like:
>
> # Bad company. Bad.
> to [email protected] drop
> # Whitelist knows about your mailing lists, etc, on which you may appear
> from-file ~/.tmda/whitelist ok
> # If a dated or keyword address would accept the message:
> default-ok
> # Otherwise junk a load of obvious spam.
> from [email protected] drop
> from [email protected] drop
> # Assumed
> default
>
> ... then life would be so very much nicer. :-)
>
> Could this be implemented with what we have?
>
> Cheers,
> Sabahattin
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> tmda-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tmda-users

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
tmda-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tmda-users