Prev: allowing/authorized pipelining & high volume email
Next: disable bounce notification
From: Joshua Pettett on 26 May 2010 12:42
I have a policy server that needs to be able to make policy decisions after a
before-queue content filter. The problem is that the client IP address
reported by the second smtpd instance to the policy server is that of the
proxy (i.e. localhost), rather than of the sending server. Would it make
sense to add the values provided by XFORWARD to the list of attributes passed
to the policy server? For example:

--- smtpd_check.c.orig 2010-03-06 19:35:24.000000000 -0500
+++ smtpd_check.c 2010-05-26 11:57:41.000000000 -0400
@@ -3417,6 +3417,10 @@
ATTR_TYPE_STR, MAIL_ATTR_ACT_PROTO_NAME, state->protocol,
ATTR_TYPE_STR, MAIL_ATTR_ACT_CLIENT_ADDR, state->addr,
ATTR_TYPE_STR, MAIL_ATTR_ACT_CLIENT_NAME, state->name,
+ ATTR_TYPE_STR, MAIL_ATTR_LOG_CLIENT_ADDR, FORWARD_ADDR(state),
+ ATTR_TYPE_STR, MAIL_ATTR_LOG_CLIENT_NAME, FORWARD_NAME(state),
+ ATTR_TYPE_STR, MAIL_ATTR_LOG_HELO_NAME, state->helo_name ?
FORWARD_HELO(state) : "",
+ ATTR_TYPE_STR, MAIL_ATTR_LOG_PROTO_NAME, FORWARD_PROTO(state),
ATTR_TYPE_STR, MAIL_ATTR_ACT_REVERSE_CLIENT_NAME,
state->reverse_name,
ATTR_TYPE_STR, MAIL_ATTR_ACT_HELO_NAME,

--
Joshua Pettett

From: Victor Duchovni on 26 May 2010 13:05
On Wed, May 26, 2010 at 12:42:17PM -0400, Joshua Pettett wrote:

> I have a policy server that needs to be able to make policy decisions after a
> before-queue content filter. The problem is that the client IP address
> reported by the second smtpd instance to the policy server is that of the
> proxy (i.e. localhost), rather than of the sending server. Would it make
> sense to add the values provided by XFORWARD to the list of attributes passed
> to the policy server? For example:

Why is the policy service behind the content filter? Policy services
only see envelope information, and don't see content. Especially if
you want the real client IP, it sure sounds like your policy service
is in the wrong place...

--
Viktor.

From: Joshua Pettett on 26 May 2010 13:14
On Wednesday 26 May 2010, Victor Duchovni wrote:
> On Wed, May 26, 2010 at 12:42:17PM -0400, Joshua Pettett wrote:
> > I have a policy server that needs to be able to make policy decisions
> > after a before-queue content filter. The problem is that the client IP
> > address reported by the second smtpd instance to the policy server is
> > that of the proxy (i.e. localhost), rather than of the sending server.
> > Would it make sense to add the values provided by XFORWARD to the list of
> > attributes passed to the policy server? For example:
>
> Why is the policy service behind the content filter?

Because I'm performing client-reputation-based greylisting/rejecting that
takes into account SpamAssassin score.

--
Joshua Pettett

From: Victor Duchovni on 26 May 2010 13:33
On Wed, May 26, 2010 at 01:14:08PM -0400, Joshua Pettett wrote:

> On Wednesday 26 May 2010, Victor Duchovni wrote:
> > On Wed, May 26, 2010 at 12:42:17PM -0400, Joshua Pettett wrote:
> > > I have a policy server that needs to be able to make policy decisions
> > > after a before-queue content filter. The problem is that the client IP
> > > address reported by the second smtpd instance to the policy server is
> > > that of the proxy (i.e. localhost), rather than of the sending server.
> > > Would it make sense to add the values provided by XFORWARD to the list of
> > > attributes passed to the policy server? For example:
> >
> > Why is the policy service behind the content filter?
>
> Because I'm performing client-reputation-based greylisting/rejecting that
> takes into account SpamAssassin score.

Embed SA into amavisd-new or similar, and then you don't need a separate
policy service.

--
Viktor.

 | 
Pages: 1
Prev: allowing/authorized pipelining & high volume email
Next: disable bounce notification