Re: [exim] acl filter variable syntax

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] acl filter variable syntax
Michael F. Egglestone wrote:
> Todd Lyons<tlyons@???> writes:
> #There is no contains{} function provided by exim so I assume you were
> #just using pseudo-code.
>
> Thats correct. :)
>
> # The and{} function requires you to group your
> #functions differently:
> #
> #${if and{ \
> #            {def:header_X-FC-System:} \
> #            {${lookup{$h_Return-Path:}lsearch{/etc/exim4/listofnames}}} \
> #       } \
> #    {yes} \
> #    {no} \
> #}
> #
> #The "yes" and "no" are implied, so you could just shorten it to:
> #${if and{ {def:h_X-FC-System:}{${lookup{$h_Return-Path:}lsearch{/etc/exim4/listofnames}}}
> #} }

>
> I'm getting closer.
> Here's what works so far:
>
> condition = ${if and{ {def:h_X-FC-System:}{match {$h_To:}{usera@???} }}}
>
> My goal is to have a .txt file of email addresses, something like:
>
> # cat /etc/exim4/listofnames.txt
> usera@???
> userb@???
> userc@???
>
> And I want my ACL to to look at the text file, and if it finds any of those addresses in the To: header, AND, the X-FC-System header exists,
> then discard the email. So far I can only hard code an email address into the condition line.
>
> If I try the condition = with the lsearch, I get an error:
>
> discard
>     log_message = Email blackholed
>       condition = ${if and{ {def:h_X-FC-System:}{{match {$h_To:}lsearch{/etc/exim4/listofnames.txt}} }}}

>
> and here's the mainlog error when an email is sent:
>
> temporarily rejected after DATA: failed to expand ACL string "${if and{ {def:h_X-FC-System:}{{match {$h_To:}lsearch{/etc/exim4/listofnames.txt}} }}}": condition name expected, but found "{match {$h_To:}l" inside "and{...}" condition
>
> I'm not sure how to use "match" or "lookup" or "lsearch" properly. ;)
>
> Cheers,
> Mike
>
>


Here are proposed examples suitable for adaptation from some that have
been in production for some years now.

Note that rather than combine the conditions into one *complex* match,
one uses a *preceding* 'condition' or '!condition' to include or exempt
all but those of interest from further tests.

Short-circuiting simplifies coding & readability AND saves CPU cycles.
Your X_header would be used as an inclusive - or its *absence* an
exclusive condition.

Headers shown here can be any header.

Undo the MUA wrap-munging in the first example below. All are one-liners:

===

   # DATA_X: Check Local NAME Blacklist for Reply-to: name.
   #
   deny
     !condition    = <whatever. WL, VIP's, your own submission clients>
     condition    = ${lookup {$reply_address}wildlsearch \
      {/var/mail/filters/REGEXP-block}{yes}{no}}
     log_message    = DX $reply_address Blacklisted exact Reply-to


===

   # DATA_XX: IF message is from notorius spam-engine THEN deny
   #
   deny
     !condition    = <whatever. a few banks and airlines in this case>
     regex       = ^Received:: .*PowerMTA
     log_message = DXX PowerMTA spam engine unwanted
     message     = Sent via a Spam Engine. Get a blameless Mail Server.


===

   # DATA_XXX: IF message is from pernicious Marketeer THEN deny
   #
   deny
     condition    = <list of the $local_part of recipients who WANT this>
     regex       = ^Subject:: office*
     log_message = DXXX office rental scam rejected
     message     = Unwanted Mass market advertising.


===

CAVEAT1: 'regex' is not the cheapest of Exim's tools. OTOH, neither is a
wildlsearch. But both 'JFW'

CAVEAT2: some folk are so bored as to actually LIKE unsolicited
advertising, so blocking PowerMTA is not for all. Nor is it assured
effective- The more clever spammers option OFF that ID string, leaving
to ban their CIDR range with a different tool.

HTH,

Bill Hacker