Mark Martinec wrote:
What is missing is your semantics code: check what information
came in, and prepare a suitable response.
ok, we shall begin. I do code a little perl, I shall pass it back with a
brown bag :)
You may disable whole code sections in amavisd
which you won't be needing:
Hi,
I noticed there's bits of code in amavis to allow it to act as a
tcp_access map for postfix, but I'm not sure if this is complete.
I was wondering if there's any chance that this might be developed to
allow amavis to act as a policy server for postfix.
In particular, I'd like to be able
Rob,
I noticed there's bits of code in amavis to allow it to act as a
tcp_access map for postfix, but I'm not sure if this is complete.
I was wondering if there's any chance that this might be developed to
allow amavis to act as a policy server for postfix.
In particular, I'd like to be
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
Dear Robert et al,
Robert Brooks wrote:
[..]
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.
Me too, I'm interested to have some of the tests done pre-queue.
I'm keen to avoid
Rob,
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?
The current code is very simple:
sub postfix_policy($$$) {
my($conn,$msginfo,$attr_ref) = @_;
my(@response);
if ($attr_ref-{'request'} ne
