Rick Duval wrote:
> Thanks much for the detailed and very speedy comeback.
>
> Problem is I don't understand how to setup the logins to the DB, etc.
> I am currently using something like:
> "hide mysql_servers = localhost/db/user/password"
> and I'm not sure how I'd do that in your example or will that
> statement still work for your example
The MySQL and PostgreSQL logins differ only slightly, IIRC.
For one thing, I use Unix socketx, not IP.
Either way - they have nothing to do with the SELECT (or other) SQL call
itself. They just make them possible.
>
> BTW, I'm not that concerned about resources and this is the only db
> call that Exim will be doing so is there a simpler (albeit more
> resource intensive) way that's easier for a newbie like me to
> understand?
>
> Thanks again.
>
'Simpler' is twofold:
- first, the local_domains list has nothing *whatsoever* to do with
controlling what traffic is presented to your server.
The global DNS system handles that.
What it does do is tell the MTA what traffic should NOT LEAVE your local
environment over a remote_smtp connection to a 'foreign' server.
IOW - the listed domains are presumed to require only 'local'
deliveries, where 'local' may mean on-box or onto another box in the
pool you control - via NFS or lmtp, AoE, iSCSI ... whatever. Just not
to 'strangers'.
You'll want to insure your router/transport sets have matching logic.
That might require a second SQL call.
If/as/when they do have, then instead of the SQL you arrived here with,
call you can use the simple:
require verify = recipient
What that will do is walk the router/transport chain in 'verify mode'.
Basically saying 'can any of you lot *deliver* this IF we accept it?'
First router to say 'yes' stops the walk and triggers acceptance. If
NONE do, the traffic is rejected.
You can flag a router as 'verify_only' or 'no_verify'.
Simple, efficient, and built-in.
If the traffic source is NOT from one of your own logged-in and
authenticated user community AND that router happens to be the
remote_smtp router, you have an open relay.
Fix that, or buy a few cases of Astroglyde.
So, SQL quite aside, you'll want to study authentication and
router/transport examples.
JM2CW, but even in a heavily-pgSQL-driven model, we hard-code the local
domains we support. They change far less often than the users or their
preferences do.
I'd recomend working with small flat-files instead of SQL until you have
done enough testing to be comfortable with how Exim works.
Not to put too fine a point on it, but flat-files, db or cdb make far
more sense than SQL for Exim unless you need to do something especially
'preverted'.
HTH,
Bill
>
> On Mon, Nov 10, 2008 at 12:28 PM, W B Hacker <wbh@???> wrote:
>> 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
>>
>> --
>> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
>> ## Exim details at http://www.exim.org/
>> ## Please use the Wiki with this list - http://wiki.exim.org/
>>
>> --
>> This message has been scanned for
>> viruses and dangerous content by
>> Accurate Anti-Spam Technologies
>> and is believed to be clean.
>>
>>
>
