Policy Server Protocol - Request for (small) Enhancement(s)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Policy Server Protocol - Request for (small) Enhancement(s)

Ronald F. Guilmette-2

I've been writing a modest little policy server.  It's nothing to write
home about yet, but I hope to turn it into something really useful and
then distribute it freely.

But in order to realize my dreams, I need a couple of small clarifications
about the policy server protocol, and also, I'm afraid to say, I may have
one or two modest enhancement requests for the protocol.

First, the clarifications...

The SMTPD_POLICY_README document describes the "recipient" attribute of
the protocol thusly:

  * The "recipient" attribute is available only in the "RCPT TO" stage, and in
    the "DATA" and "END-OF-MESSAGE" stages when Postfix accepted only one
    recipient for the current message.

I'm not at all sure that I'm interpreting that correctly.  Does the quali-
fication "...when Postfix accepted only one recipient for the current message"
apply to _all_ instances in which the "recipient" parameter is supplied to
the policy server by Postfix?  Or does it only apply to those cases where
Postfix is exchanging information with the policy server ``in the "DATA" and
"END-OF-MESSAGE" stages''?

That's my first question.

Second question: Regardless of the set of "stages" in which the "recipient"
parameter is only supplied to the policy server when it is the singular
allowed recipient, why is it that Postfix can't/doesn't supply the entire
list of all of the (multiple) allowed recipients?  Is there some special
problem that I'm not aware of that prevents Postfix from handing the policy
server the whole and entire list of permitted recipients?  (I'm just trying
to understand things a bit better here.)

Now on to the enhancement request(s)...

Obviously, the policy server protocol is all about blocking undesirable
e-mails.  It occurs to me that it would be Very Nice to be able to make
use of the protocol in a way that allows for per-actual-local-recipient
individualized tailoring/adjustment/configuring.  Perhaps I have failed
to understand the actual semantics of the current protocol... and I feel
sure that someone will tell me if I have... but it seems to be that there
may be at least two potential difficulties that might thwart individualized
per-actual-local-recipient customization of the behavior of a common system-
wide policy server, i.e.:

1)  It appears that the "recipient" parameter, when available, may perhaps
be the actual original envelope recipient address, i.e. before alias expansion
and other Postfix address rewriting.  I understand that there might be some
problems created if Postfix were to try to also pass a post-rewriting
recipient "address", via the protocol, to the policy server (e.g. the
results of rewriting may be whole list of things, and also may not even
be an "address" anymore) but regardless of such problems, I think that in
many situations and environment, it would be most helpful for the policy
server to have access to a post-rewrite recipient address.  (In my own case,
I have virtually no addresses here locally that get rewritten into either
lists or file or pipes, but I _do_ have about eighteen zillion aliases...
all beginning with "rfg-"... which are all aliased to the local recipient
address "rfg".  I'd love to be able to able to have a policy server that
knows about the rewritten forms of all those aliases, and that could just
go and look in, say, ~rfg/.postfix_policy_settings to find out how incoming
e-mail addressed to any/all of those aliases should be filtered.)

2)  Consistant with the general goal (hope? dream?) of being able to tailor
policy server behavior on a per-actual-local-recipient basis, it would also
be Nice if Postfix conducted a separate transaction with the policy server
for each individual RCPT TO.  That way, if the current message is addressed
to, say, ten different local users, and if five of those have elected to reject
mail from the relevant sender address, then the policy server could, in
effect, instruct Postfix to issue 5xx responses for the just those five
RCPT TOs, while still issuing 2xx responses for the other five recipients.


Thanks in advance to Wietse for a fine product, for answers to my questions
(unless Ralf or Victor beats you to it), and of course, for any consideration
you may give to my enhancement requests.

Finally, I'd just like to state the obvious... When it comes to e-mail,
filtering is _the_ big issue.  And when it comes to filtering, per-user
customization is an extraordinarily important feature... maybe even a
deal maker/breaker... in a lot of environments.  Yes, it's probably
possible to do just about anything if one goes the Milter route, or if
one elects instead to make filtering decisions after reception (i.e.
during local delivery) but it seems to me that neither of those options
is nearly as attractive as using Postfix's policy server protocol.  Now,
if the protocol would just support per-user filtering customizations, then
I feel sure that I (and any number of other people) could develope some
really exciting and interesting individually-customizable policy servers.


Regards,
rfg


P.S.  My apologies if the above ideas have already been advanced.  If so,
I plead ignorance of that.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Cami-2
Ronald F. Guilmette wrote:

>
> 1)  It appears that the "recipient" parameter, when available, may perhaps
> be the actual original envelope recipient address, i.e. before alias expansion
> and other Postfix address rewriting.  I understand that there might be some
> problems created if Postfix were to try to also pass a post-rewriting
> recipient "address", via the protocol, to the policy server (e.g. the
> results of rewriting may be whole list of things, and also may not even
> be an "address" anymore) but regardless of such problems, I think that in
> many situations and environment, it would be most helpful for the policy
> server to have access to a post-rewrite recipient address.  (In my own case,
> I have virtually no addresses here locally that get rewritten into either
> lists or file or pipes, but I _do_ have about eighteen zillion aliases...
> all beginning with "rfg-"... which are all aliased to the local recipient
> address "rfg".  I'd love to be able to able to have a policy server that
> knows about the rewritten forms of all those aliases, and that could just
> go and look in, say, ~rfg/.postfix_policy_settings to find out how incoming
> e-mail addressed to any/all of those aliases should be filtered.)

Why don't you let your Policy Server do that? Store all that
data inside MySQL and then your policy server can do exactly
what you want it to.

> 2)  Consistant with the general goal (hope? dream?) of being able to tailor
> policy server behavior on a per-actual-local-recipient basis, it would also
> be Nice if Postfix conducted a separate transaction with the policy server
> for each individual RCPT TO.

This is already the current / default behaviour.

Cami
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

mouss-2
In reply to this post by Ronald F. Guilmette-2
Ronald F. Guilmette wrote:

> I've been writing a modest little policy server.  It's nothing to write
> home about yet, but I hope to turn it into something really useful and
> then distribute it freely.
>
> But in order to realize my dreams, I need a couple of small clarifications
> about the policy server protocol, and also, I'm afraid to say, I may have
> one or two modest enhancement requests for the protocol.
>
> First, the clarifications...
>
> The SMTPD_POLICY_README document describes the "recipient" attribute of
> the protocol thusly:
>
>   * The "recipient" attribute is available only in the "RCPT TO" stage, and in
>     the "DATA" and "END-OF-MESSAGE" stages when Postfix accepted only one
>     recipient for the current message.
>
> I'm not at all sure that I'm interpreting that correctly.  Does the quali-
> fication "...when Postfix accepted only one recipient for the current message"
> apply to _all_ instances in which the "recipient" parameter is supplied to
> the policy server by Postfix?  Or does it only apply to those cases where
> Postfix is exchanging information with the policy server ``in the "DATA" and
> "END-OF-MESSAGE" stages''?
>
>  


- the recipient attribute is available in the RCPT TO stage
- the recipient atrbute is also available in DATA and END-OF-MESSAGE
stages provided the message is addressed to a single recipient.


> That's my first question.
>
> Second question: Regardless of the set of "stages" in which the "recipient"
> parameter is only supplied to the policy server when it is the singular
> allowed recipient, why is it that Postfix can't/doesn't supply the entire
> list of all of the (multiple) allowed recipients?  Is there some special
> problem that I'm not aware of that prevents Postfix from handing the policy
> server the whole and entire list of permitted recipients?  (I'm just trying
> to understand things a bit better here.)
>  

there are a couple of problems:
- how to separate the addresses? would postfix send each recipient in an
attribute? ... etc
- what if the message is addressed to 100 recipients? ... etc

anyway, this has been discussed here before. please search the archives.

> Now on to the enhancement request(s)...
>
> Obviously, the policy server protocol is all about blocking undesirable
> e-mails.  It occurs to me that it would be Very Nice to be able to make
> use of the protocol in a way that allows for per-actual-local-recipient
> individualized tailoring/adjustment/configuring.  Perhaps I have failed
> to understand the actual semantics of the current protocol... and I feel
> sure that someone will tell me if I have... but it seems to be that there
> may be at least two potential difficulties that might thwart individualized
> per-actual-local-recipient customization of the behavior of a common system-
> wide policy server, i.e.:
>
> 1)  It appears that the "recipient" parameter, when available, may perhaps
> be the actual original envelope recipient address, i.e. before alias expansion
> and other Postfix address rewriting.  I understand that there might be some
> problems created if Postfix were to try to also pass a post-rewriting
> recipient "address", via the protocol, to the policy server (e.g. the
> results of rewriting may be whole list of things, and also may not even
> be an "address" anymore) but regardless of such problems, I think that in
> many situations and environment, it would be most helpful for the policy
> server to have access to a post-rewrite recipient address.  (In my own case,
> I have virtually no addresses here locally that get rewritten into either
> lists or file or pipes, but I _do_ have about eighteen zillion aliases...
> all beginning with "rfg-"... which are all aliased to the local recipient
> address "rfg".  I'd love to be able to able to have a policy server that
> knows about the rewritten forms of all those aliases, and that could just
> go and look in, say, ~rfg/.postfix_policy_settings to find out how incoming
> e-mail addressed to any/all of those aliases should be filtered.)
>  


if you want the policy server to do per recipient actions, then code
that in the policy server.

if you want postfix to do per recipient actions, then use
check_recipient_access. note that you can use pcre or regexp:

/^rfg\-.*@example\com$/         some_restriction_class


> 2)  Consistant with the general goal (hope? dream?) of being able to tailor
> policy server behavior on a per-actual-local-recipient basis, it would also
> be Nice if Postfix conducted a separate transaction with the policy server
> for each individual RCPT TO.  That way, if the current message is addressed
> to, say, ten different local users, and if five of those have elected to reject
> mail from the relevant sender address, then the policy server could, in
> effect, instruct Postfix to issue 5xx responses for the just those five
> RCPT TOs, while still issuing 2xx responses for the other five recipients.
>
>
>  

smtpd_recipient_restrictions is executed once for each recipient. so
just call the policy service in your smtpd_recipient_restrictions.

> Thanks in advance to Wietse for a fine product, for answers to my questions
> (unless Ralf or Victor beats you to it), and of course, for any consideration
> you may give to my enhancement requests.
>
> Finally, I'd just like to state the obvious... When it comes to e-mail,
> filtering is _the_ big issue.  And when it comes to filtering, per-user
> customization is an extraordinarily important feature... maybe even a
> deal maker/breaker... in a lot of environments.  Yes, it's probably
> possible to do just about anything if one goes the Milter route, or if
> one elects instead to make filtering decisions after reception (i.e.
> during local delivery) but it seems to me that neither of those options
> is nearly as attractive as using Postfix's policy server protocol.  Now,
> if the protocol would just support per-user filtering customizations, then
> I feel sure that I (and any number of other people) could develope some
> really exciting and interesting individually-customizable policy servers.
>
>
> Regards,
> rfg
>
>
> P.S.  My apologies if the above ideas have already been advanced.  If so,
> I plead ignorance of that.
>  

Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

d.hill
In reply to this post by Ronald F. Guilmette-2
On Fri, 16 May 2008 at 02:26 -0700, [hidden email] confabulated:

> Obviously, the policy server protocol is all about blocking undesirable
> e-mails.

That hasn't become obvious to me. We have two filter servers that run two
Postfix instances. One for inbound and one for outbound. On the outbound
instances, I have policyd (http://www.policyd.org) throttling our
customer's sending ability.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Stefan Förster-4
* D Hill <[hidden email]> wrote:
> On Fri, 16 May 2008 at 02:26 -0700, [hidden email] confabulated:
>
>> Obviously, the policy server protocol is all about blocking undesirable
>> e-mails.
>
> That hasn't become obvious to me. We have two filter servers that run two
> Postfix instances. One for inbound and one for outbound. On the outbound
> instances, I have policyd (http://www.policyd.org) throttling our
> customer's sending ability.

I've found that using a policy server to delegate messages above a
certain size to a dedicated transport can be a very useful tool, too,
given that your network connection is limited in terms of bandwith and
you don't want to get your active queue congested with large mails
which take forever to transmit, but don't time out.


Ciao
Stefan
--
Stefan Förster     http://www.incertum.net/     Public Key: 0xBBE2A9E9
FdI #298: MSIE - Der MSIE ist dazu da, den Zugriff von außen (mittels
ActiveX-Komponenten) zu erleichtern bzw. überhaupt erst zu ermöglichen.
(Rocco Rutte)
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Ronald F. Guilmette-2
In reply to this post by mouss-2

In message <[hidden email]>, you wrote:

>Ronald F. Guilmette wrote:
>- the recipient attribute is available in the RCPT TO stage
>- the recipient atrbute is also available in DATA and END-OF-MESSAGE
>stages provided the message is addressed to a single recipient.

OK.  That clarifies the behavior entirely.  Thank you.

>> Second question: Regardless of the set of "stages" in which the "recipient"
>> parameter is only supplied to the policy server when it is the singular
>> allowed recipient, why is it that Postfix can't/doesn't supply the entire
>> list of all of the (multiple) allowed recipients?  Is there some special
>> problem that I'm not aware of that prevents Postfix from handing the policy
>> server the whole and entire list of permitted recipients?  (I'm just trying
>> to understand things a bit better here.)
>>  
>
>there are a couple of problems:
>- how to separate the addresses? would postfix send each recipient in an
>attribute? ... etc

Yes.  That would work.

>- what if the message is addressed to 100 recipients? ... etc

I'm not following you.  What special problem(s) would that cause?

>anyway, this has been discussed here before. please search the archives.

OK.  I'll ry to hunt down the info.  Thanks.

>if you want the policy server to do per recipient actions, then code
>that in the policy server.
>...
>smtpd_recipient_restrictions is executed once for each recipient. so
>just call the policy service in your smtpd_recipient_restrictions.

Ah!  OK.  This was something that I obviously didn't quite understand,
or remember.  (I _did_ build a small policy server before... different
from the new one that I'm working on now.  But that was quite awhile
ago, so there are obviously some details about the interactions between
Postfix and the policy server that I forgot.  Thanks for refreshing
my memory.)


Regards,
rfg
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Ronald F. Guilmette-2
In reply to this post by d.hill

In message <[hidden email]>,
D Hill <[hidden email]> wrote:

>On Fri, 16 May 2008 at 02:26 -0700, [hidden email] confabulated:
>
>> Obviously, the policy server protocol is all about blocking undesirable
>> e-mails.
>
>That hasn't become obvious to me. We have two filter servers that run two
>Postfix instances. One for inbound and one for outbound. On the outbound
>instances, I have policyd (http://www.policyd.org) throttling our
>customer's sending ability.

OK then, "blocking _and_ throttling".

It's all still about "controlling" the flow of (potentially) undesirable
e-mails.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Noel Jones-2
In reply to this post by Ronald F. Guilmette-2
Ronald F. Guilmette wrote:
>>> Second question: Regardless of the set of "stages" in which the "recipient"
>>> parameter is only supplied to the policy server when it is the singular
>>> allowed recipient, why is it that Postfix can't/doesn't supply the entire
>>> list of all of the (multiple) allowed recipients?  Is there some special
>>> problem that I'm not aware of that prevents Postfix from handing the policy
>>> server the whole and entire list of permitted recipients?  (I'm just trying
>>> to understand things a bit better here.)

I believe the major issue is that multiple recipients are
simply not meaningful in this context.  Once the client gets
to DATA, individual recipients can no longer be
rejected/accepted; you have to either accept or reject the
whole message.

The current protocol definition states "When the same
attribute name is sent more than once, the server may keep the
first value or the last attribute value" so sending multiple
"recipient=foo" lines isn't acceptable.
User interface issues (and user expectations) further cloud
the issue.  If you send all recipients as one value, what
should be used as a delimiter?  will it break existing software?

For now, in those cases where you want to see the entire
recipient list you need to build that list with a policy
server called from smtpd_recipient_restrictions that keeps state.

--
Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Victor Duchovni
On Fri, May 16, 2008 at 03:49:52PM -0500, Noel Jones wrote:

> I believe the major issue is that multiple recipients are
> simply not meaningful in this context.  Once the client gets
> to DATA, individual recipients can no longer be
> rejected/accepted; you have to either accept or reject the
> whole message.

Postfix is designed to run in bounded memory, so the SMTP server
does not remember the full recipient list, only the last recipient
is kept in memory, but is not used with DATA checks if the count > 1.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Wietse Venema
In reply to this post by Ronald F. Guilmette-2
Ronald F. Guilmette:

>
> In message <[hidden email]>,
> D Hill <[hidden email]> wrote:
>
> >On Fri, 16 May 2008 at 02:26 -0700, [hidden email] confabulated:
> >
> >> Obviously, the policy server protocol is all about blocking undesirable
> >> e-mails.
> >
> >That hasn't become obvious to me. We have two filter servers that run two
> >Postfix instances. One for inbound and one for outbound. On the outbound
> >instances, I have policyd (http://www.policyd.org) throttling our
> >customer's sending ability.
>
> OK then, "blocking _and_ throttling".
>
> It's all still about "controlling" the flow of (potentially) undesirable
> e-mails.

No it could also be used for counting purposes, so that one does
not have to parse logfiles.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Ronald F. Guilmette-2
In reply to this post by Noel Jones-2

In message <[hidden email]>, you wrote:

>Ronald F. Guilmette wrote:
>>>> Second question: Regardless of the set of "stages" in which the "recipient
>"
>>>> parameter is only supplied to the policy server when it is the singular
>>>> allowed recipient, why is it that Postfix can't/doesn't supply the entire
>>>> list of all of the (multiple) allowed recipients?  Is there some special
>>>> problem that I'm not aware of that prevents Postfix from handing the polic
>y
>>>> server the whole and entire list of permitted recipients?  (I'm just tryin
>g
>>>> to understand things a bit better here.)
>
>I believe the major issue is that multiple recipients are
>simply not meaningful in this context.  Once the client gets
>to DATA, individual recipients can no longer be
>rejected/accepted; you have to either accept or reject the
>whole message.

Thank you.

I didn't understand (or didn't remember) that the protocol causes a
separate transaction with the external policy server for each separate
RCPT TO.  Now that I know/remember that, it all makes perfect sense.

>For now, in those cases where you want to see the entire
>recipient list you need to build that list with a policy
>server called from smtpd_recipient_restrictions that keeps state.

Yes.

The good news is that I don't actually need to do that.

I just needed to be sure that I _can_ get each on of the recipient
addresses in turn.  And apparently I can.  So that's perfect.

The only actual issue that still concerns me is the one regarding the
pre- versus post-rewritten recipient addresses.  It's useful to have
the pre-rewritten ones, but for what I'm doing it would be more useful
to have access to the post-rewritten ones.

I suppose that my policy sever could, in theory, convert pre-rewritten
recipient addresses into post-rewritten ones _if_ it could get access,
selectively, to _just_ the address rewriting functionality of the
local(8) delivery agent, but I don't know how to do that.


Regards,
rfg
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Victor Duchovni
On Sun, May 18, 2008 at 11:15:44AM -0700, Ronald F. Guilmette wrote:

> I suppose that my policy sever could, in theory, convert pre-rewritten
> recipient addresses into post-rewritten ones _if_ it could get access,
> selectively, to _just_ the address rewriting functionality of the
> local(8) delivery agent, but I don't know how to do that.

Nor does anything in Postfix (other than of course the local(8) delivery
agent itself). The smtpd(8) server just uses local_recipient_maps for
validation. For number of reasons (including security) aliases and
.forward expansion is not possible anywhere else.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Ronald F. Guilmette-2

In message <[hidden email]>, you wrote:

>On Sun, May 18, 2008 at 11:15:44AM -0700, Ronald F. Guilmette wrote:
>
>> I suppose that my policy sever could, in theory, convert pre-rewritten
>> recipient addresses into post-rewritten ones _if_ it could get access,
>> selectively, to _just_ the address rewriting functionality of the
>> local(8) delivery agent, but I don't know how to do that.
>
>Nor does anything in Postfix (other than of course the local(8) delivery
>agent itself). The smtpd(8) server just uses local_recipient_maps for
>validation. For number of reasons (including security) aliases and
>.forward expansion is not possible anywhere else.

I'm not at all sure that I understand what the security implications
would be of exporting the address rewriting functionality to some
particular administrator-enabled external tool.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Bill Anderson-2
In reply to this post by Wietse Venema

On May 17, 2008, at 4:07 AM, Wietse Venema wrote:

> Ronald F. Guilmette:
>>
>> In message <[hidden email]
>> >,
>> D Hill <[hidden email]> wrote:
>>
>>> On Fri, 16 May 2008 at 02:26 -0700, [hidden email]  
>>> confabulated:
>>>
>>>> Obviously, the policy server protocol is all about blocking  
>>>> undesirable
>>>> e-mails.
>>>
>>> That hasn't become obvious to me. We have two filter servers that  
>>> run two
>>> Postfix instances. One for inbound and one for outbound. On the  
>>> outbound
>>> instances, I have policyd (http://www.policyd.org) throttling our
>>> customer's sending ability.
>>
>> OK then, "blocking _and_ throttling".
>>
>> It's all still about "controlling" the flow of (potentially)  
>> undesirable
>> e-mails.
>
> No it could also be used for counting purposes, so that one does
> not have to parse logfiles.

Absolutely! And for message tracking in real time purposes. Now if  
only we had a way to get headers in the End-of-Data stage via the  
daemon so we didn't have to go read a queue file, it'd be glorious! :^D
  Yes I know that's unlikely but a man can still dream.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Bill Anderson-2
In reply to this post by Victor Duchovni

On May 18, 2008, at 8:55 PM, Victor Duchovni wrote:

> On Sun, May 18, 2008 at 11:15:44AM -0700, Ronald F. Guilmette wrote:
>
>> I suppose that my policy sever could, in theory, convert pre-
>> rewritten
>> recipient addresses into post-rewritten ones _if_ it could get  
>> access,
>> selectively, to _just_ the address rewriting functionality of the
>> local(8) delivery agent, but I don't know how to do that.
>
> Nor does anything in Postfix (other than of course the local(8)  
> delivery
> agent itself). The smtpd(8) server just uses local_recipient_maps for
> validation. For number of reasons (including security) aliases and
> .forward expansion is not possible anywhere else.

Depending on the language used, it could be considered a hack, but  
having the policy daemon call postmap -q to get the result seems  
effective in some cases to me. Not ideal but depending on the request,  
effective.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Victor Duchovni
On Mon, May 19, 2008 at 10:20:43PM -0600, Bill Anderson wrote:

>
> On May 18, 2008, at 8:55 PM, Victor Duchovni wrote:
>
> >On Sun, May 18, 2008 at 11:15:44AM -0700, Ronald F. Guilmette wrote:
> >
> >>I suppose that my policy sever could, in theory, convert pre-
> >>rewritten
> >>recipient addresses into post-rewritten ones _if_ it could get  
> >>access,
> >>selectively, to _just_ the address rewriting functionality of the
> >>local(8) delivery agent, but I don't know how to do that.
> >
> >Nor does anything in Postfix (other than of course the local(8)  
> >delivery
> >agent itself). The smtpd(8) server just uses local_recipient_maps for
> >validation. For number of reasons (including security) aliases and
> >.forward expansion is not possible anywhere else.
>
> Depending on the language used, it could be considered a hack, but  
> having the policy daemon call postmap -q to get the result seems  
> effective in some cases to me. Not ideal but depending on the request,  
> effective.

Not reliable (the queue file may be incomplete), and unsupported, far
better to run a pre-queue proxy filter.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Bill Anderson-2

On May 19, 2008, at 10:28 PM, Victor Duchovni wrote:

> On Mon, May 19, 2008 at 10:20:43PM -0600, Bill Anderson wrote:
>
>>
>> On May 18, 2008, at 8:55 PM, Victor Duchovni wrote:
>>
>>> On Sun, May 18, 2008 at 11:15:44AM -0700, Ronald F. Guilmette wrote:
>>>
>>>> I suppose that my policy sever could, in theory, convert pre-
>>>> rewritten
>>>> recipient addresses into post-rewritten ones _if_ it could get
>>>> access,
>>>> selectively, to _just_ the address rewriting functionality of the
>>>> local(8) delivery agent, but I don't know how to do that.
>>>
>>> Nor does anything in Postfix (other than of course the local(8)
>>> delivery
>>> agent itself). The smtpd(8) server just uses local_recipient_maps  
>>> for
>>> validation. For number of reasons (including security) aliases and
>>> .forward expansion is not possible anywhere else.
>>
>> Depending on the language used, it could be considered a hack, but
>> having the policy daemon call postmap -q to get the result seems
>> effective in some cases to me. Not ideal but depending on the  
>> request,
>> effective.
>
> Not reliable (the queue file may be incomplete), and unsupported, far
> better to run a pre-queue proxy filter.
>


Not sure what the queuefile has to do with this, Victor. Take a  
recipient address and see what postmap -q would return for it during  
the RCPT TO policy request. No queue file involved. Indeed at the  
recipient file the queuefile *would* be incomplete or even nonexistent.
Reply | Threaded
Open this post in threaded view
|

Re: Policy Server Protocol - Request for (small) Enhancement(s)

Victor Duchovni
On Fri, May 23, 2008 at 03:27:54PM -0600, Bill Anderson wrote:

> >>Depending on the language used, it could be considered a hack, but
> >>having the policy daemon call postmap -q to get the result seems
> >>effective in some cases to me. Not ideal but depending on the  
> >>request, effective.
> >
> >Not reliable (the queue file may be incomplete), and unsupported, far
> >better to run a pre-queue proxy filter.
>
> Not sure what the queuefile has to do with this, Victor. Take a  
> recipient address and see what postmap -q would return for it during  
> the RCPT TO policy request. No queue file involved. Indeed at the  
> recipient file the queuefile *would* be incomplete or even nonexistent.

Oops, sorry, I thought you meant "postcat -q". Never mind.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.