Re: [exim] Deny/accept based on MySQL user lookup

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] Deny/accept based on MySQL user lookup
Rick Duval wrote:
> I have a passthru spam filter using mailscanner and Exim as the MTA's
>
> I'm already looking up domains that the system will accept mail for by
> populating the domainlist with:
>
> domainlist local_domains = ${lookup mysql {SELECT DISTINCT domain FROM
> domains WHERE Enabled = 1 and domain='${quote_mysql:$domain}'}}
>
> and then futher down using
>
>   require message = relay not permitted
>            domains = +local_domains

>
> Can I do this on a per address level as well? I get so much spam to
> non-existent addresses that I'd like to stop at the front door.
>


Sure hope so! And it is an easy one...

> Thanks, I'm a Newbie at Exim
>


IF you want an SQL select instead of the less-resource hungry

require verify = recipient

Which can make sense if your routers are also doing SQL SELECTS and
potentially more of them, even for a verify pass, THEN try:

deny
  set acl_m19 = ${lookup pgsql{SELECT pg_active from mailprof \
                WHERE pg_active AND pg_domain='${quote_pgsql:$domain}'  \
                AND pg_local_part='${quote_pgsql:$local_part}'}}
     !condition  = ${if eq{$acl_m19}{t}}



In which:

- acl_m is legacy. there are now other ways to 'trigger' an SQL call

- mailprof(ile) is the relation.

- pg_active is a boolean flag for active account (or not)

- pg_domain and pg_local_part should be obvious

- we don't want the data - only to know it was matched.

- the 'pg_' fieldname prefix just helps me remember which part is a DB
field and which part is an Exim variable.

- You can change 'pgsql' to 'mysql' Or not.

This should work unaltered with MySQL save for your relation and field
names. So long as none of the 'special' features of either DBMS are
used within, neither Exim nor RDBMS otherwise care.

HTH,

Bill