use different mysql databases for header_checks

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

use different mysql databases for header_checks

Tavolodo Bela
Hello,

I'd like to create a mysql lookup table for header_checks.
I think the following should do the trick:

header_checks = mysql:/etc/posfix/header_checks.cf

header_checks.cf might look like:
user = someone
password = some_password
dbname = customer_database
query = some query here

However, I'm stuck with specifying the database. My task is to let
the dbname be the local part of the rcpt to envelope address:

eg. "dbname = user1" for user1@mydomain

The used environment can guarantee that there's only one single
recipient specified for one smtp transaction.

Is it possible to setup such configuration?

Bela
Reply | Threaded
Open this post in threaded view
|

Re: use different mysql databases for header_checks

John Fawcett
On 01/05/2018 09:51 AM, Tavolodo Bela wrote:
Hello,

I'd like to create a mysql lookup table for header_checks.
I think the following should do the trick:

header_checks = mysql:/etc/posfix/header_checks.cf

header_checks.cf might look like:
user = someone
password = some_password
dbname = customer_database
query = some query here

However, I'm stuck with specifying the database. My task is to let
the dbname be the local part of the rcpt to envelope address:

eg. "dbname = user1" for user1@mydomain

The used environment can guarantee that there's only one single
recipient specified for one smtp transaction.

Is it possible to setup such configuration?

Bela

Bela

there is no support in the mysql table type to use a variable database name. The dbname must be a literal value specifying the database to connect to, it will be the same for all users.

As far as I know header_checks are supported with pcre and regex table types. In general I don't believe it makes sense to use other table types which will not produce matches against the header lines (except maybe for some very narrow use cases).

John