At 17:21 11/08/2002 +0200, Wulff D. Heiss wrote:
:(
there should be an entry point before this
because we have a mixture of forwards, scripts and so on and would like to
execute spam assassin before this is parsed...
and: i don't want to change 140 usersnamually, as userid and emailaddress
is not the same:(
I am in the process of replacing the 'users' table with a view which sets
this up based on a flag. The idea will be that all redirections etc will be
handled by PostgreSQL/Postfix before it gets to dbmail.
So DBMail will have a very simple single level mapping - one entry in the
DBMail aliases table will point to a single user. The basic structure is:
-- Table: barnet_maildrops
CREATE TABLE "maildrops" (
"id" int8,
"maildrop" varchar(100),
"user_idnr" int8,
"filter_spam" bool
);
CREATE VIEW "aliases" AS SELECT
a.id AS alias_idnr,
a.maildrop AS alias,
CASE WHEN a.filter_spam THEN
'!/path/spamc -u ' || u.userid
|| '| /path/dbmail-smtp -u '
|| u.userid
ELSE
text(a.user_idnr)
END AS deliver_to,
'0'::Bigint as client_idnr
FROM maildrops a,
users u
WHERE (u.user_idnr = a.user_idnr);
This obviously means that we can't use dbmail-adduser to maintain the
aliases table, but that's OK. If we really wanted to we could write a
PostgreSQL rewrite rule to handle this, but it's not really worth the effort.
The advantage of this is that we can turn spam-filtering on/off easily; the
disadvantage is that we have placed heavy restrictions on the DBMail
aliases. But that seems OK since postfix can do everything DBMail can in
this regard (or so I believe?).
Further, if we want to add more filters in the future, or change the
filter, we just need to update the view.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
