[AMaViS-user] local_domains_map and SQL lookups

[Mark Martinec]

Jyri,

> I'm, bit confused, why it's unusual to use SQL for lookups?

What do you mean by that? It is not unusual. Perhaps you are referring
to my statement where I meant that providing local domain names statically
in @local_domains_maps is unusual (but not wrong) when having the rest
in SQL:

> > It is a bit unusual to use SQL lookups but keep the 'local' attribut
> > in a static lookup table. The usual approach when using SQL
> > is to have one record for each local domain. No other fields (besides
> > a key) are necessary, absent (or NULL) fields let a lookup continue
> > with statical settings.


> The reason why we are using SQL lookups is that we need dynamic updating
> and managing of white/black lists. That's the main reason. And yes we have
> "catch all" entry in SQL.

Sure, that is common.

> So basically you are saying that static maps will be overridden by SQL
> lookups

Right.

> which are processed right after parsing statical maps, ok clear,

Actually the implementation does a SQL lookup first, and if the answer
is not available there, continues with the list of statical lookups.
The first definite match stops the search.

> and for fixing this we should either remove "catch-all" entry or add all
> official domains to SQL and basically make static map redundant.

Removing a catch-all record is not necessary, as long as it does
not claim that it is local. So, if you *do* have a field 'local' in SQL,
make sure the catchall record has this field at false. If you do *not*
have a field 'local' in SQL, then the default should be fine.

> This rose few questions:
> 1. What's the consequence of removing "catch-all" entry?

Nothing sinister. You loose ability to control settings through SQL
for any recipient not matching any SQL record. Their settings
will be provided by your static configuration.

> 2. Do we have to define valid policies for "official domains" or amavis
> will fall back to static policy definitions in case it can't find valid
> one from SQL?

It will fall back to static value for each setting individually if no record
in SQL matches, or if an SQL field for that setting is NULL.  So, it is not
necessary to provide records for each of your local domains, although
it is convenient to do so, as this will automatically and dynamically
let them be recognized as local domains.

If you need SQL mainly for white/blacklisting, I'd just leave out
most if not all fields in table policy and thus let them fall back to
static settings. I'd have one 'users' record for each local domain,
referencing a dummy 'policy' with no fields (or all/most fields at NULL).
You need records for recipients which need their white/listing anyway,
so why not provide a record for each domain as well.

  Mark