From: Robert Brooks (robbwtg.cw.com)
Date: Thu Jan 25 2007 - 06:23:43 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Wietse,

I'm curious if you have any thoughts on the best solution.

The complete thread is here:
 
http://sourceforge.net/mailarchive/forum.php?thread_id=31527470&forum_id=3289

Does a policy server need a bunch of forked instances to keep up with
postfix?

Regards,

Rob

-------- Original Message --------
Subject: Re: [AMaViS-user] amavis and postfix policy
Date: Wed, 24 Jan 2007 17:10:04 +0000
From: Robert Brooks <robbwtg.cw.com>
To: amavis-userlists.sourceforge.net
References: <45B78289.5070104wtg.cw.com>
<200701241729.11408.Mark.Martinec+amavisijs.si>

Mark Martinec wrote:

> The Postfix policy protocol support is complete, but there is almost
> no semantics in-there. Similarly the support for Postfix tcp lookup
> maps is there. I did both mostly as a proof-of-concept, because
> most of the code is common with AM.PDP protocol support and was
> not difficult to add what was missing.
>
> See sub process_tcp_lookup_request for tcp lookups support
> (policy bank on the interface must specify protocol=>'TCP-LOOKUP'),
>
> and process_policy_request with postfix_policy, which can (syntactically)
> handle both the AM.PDP as well as the Postfix policy delegation support.
> The Postfix request is distinguished from AM.PDP request by the
> presence of the attribute: request=smtpd_access_policy'
>
> The problem with both is that these are pre-queue requests,
> with all the problems this drags along: amavisd would need to
> handle numerous sessions comparable to the number of smtpd services,
> which is normally by an order of magnitude larger than post-queue
> content filtering sessions. Heavy-weight calls to SA are mostly
> out of the question for any setup larger than a home or small office
> site. ...Which is the reason why I never pushed this beyond
> proof-of-concept. Experimentation may be interesting nevertheless.

Mark,

many thanks for this. I'd not thought about the problems with
performance. However it is precisely because this is prequeue that I am
interested.

I'm keen to avoid accepting email which is not going to be delivered.
I'd rather the server which has the message is responsible for bouncing
than us creating back-scatter or silently failing to deliver.

Also ultimately I'd like users to be able to chose who they do and don't
accept email from. Just because something is blacklisted doesn't
necessarily mean it's spam (or that all users wish this address to be
blacklisted). There can be personal reasons for blacklisting or
commercial emailers that aren't diligent with unsubscription requests.

As you probably know Horde (via sam) and a few others apps beside
support writing to an amavis preference database so this seemed like a
good place for a solution which might work for others too.

I've talked to the postfix-users list about per-user mysql lookups and
they don't seem keen, which I can understand (see
http://archives.neohapsis.com/archives/postfix/2007-01/0992.html)

I've also talked to the horde project don't seem keen to write a policy
daemon (see http://bugs.horde.org/ticket/?id=4904) and I can understand
that too.

I'm also sure the world can do without me writing a sloppy coded and
poorly performing policy daemon (and adding another to the growing list).

I assume when you say there are no semantics you mean it's going to be
hard to get AM.PDP to give the answers to Postfix I am looking for?

Do you have any other thoughts as to a solution that would work for me
and for others or maybe I should just let this go for now.

Regards,

Rob

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]