Policy delegation after alias expansion

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Policy delegation after alias expansion

Reinaldo Gil Lima de Carvalho

Is possible call a policy daemon after alias expansion?


--
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net

"While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works" (myself)

Reply | Threaded
Open this post in threaded view
|

Re: Policy delegation after alias expansion

Jeroen Geilman
On 11/14/2012 11:45 PM, Reinaldo de Carvalho wrote:
>
> Is possible call a policy daemon after alias expansion?

Policy checks happen in the context of smtp reception (before
end-of-data); alias expansion happens once the message has been accepted
(after end-of-data) and just before it is queued.

The only way to reverse this state of events is to re-inject the mail
into a separate smtpd(8) listener, with different policy settings (and
no_address_mappings).

--
J.

Reply | Threaded
Open this post in threaded view
|

Re: Policy delegation after alias expansion

Wietse Venema
In reply to this post by Reinaldo Gil Lima de Carvalho
Reinaldo de Carvalho:
> Is possible call a policy daemon after alias expansion?

local_recipient_maps and reject_unverified_recipient will verify
that the alias exist, but won't look at the result of expansion.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Policy delegation after alias expansion

Reinaldo Gil Lima de Carvalho
On Wed, Nov 14, 2012 at 9:15 PM, Wietse Venema <[hidden email]> wrote:
Reinaldo de Carvalho:
> Is possible call a policy daemon after alias expansion?

local_recipient_maps and reject_unverified_recipient will verify
that the alias exist, but won't look at the result of expansion.


Then I need make the alias expansion in the policy daemon to check quota availability on my cyrus cluster (returning temp error keeping message on sender queue).

And I need add support to many backends like ldap, mysql, postgresql, etc. Would be great if postfix could do this and take postfix tables lookup proficiency.

:~(


--
Reinaldo Gil Lima de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net

"While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works" (myself)

Reply | Threaded
Open this post in threaded view
|

Re: Policy delegation after alias expansion

Wietse Venema
Reinaldo Gil Lima de Carvalho:

> On Wed, Nov 14, 2012 at 9:15 PM, Wietse Venema <[hidden email]> wrote:
>
> > Reinaldo de Carvalho:
> > > Is possible call a policy daemon after alias expansion?
> >
> > local_recipient_maps and reject_unverified_recipient will verify
> > that the alias exist, but won't look at the result of expansion.
> >
> >
> Then I need make the alias expansion in the policy daemon to check quota
> availability on my cyrus cluster (returning temp error keeping message on
> sender queue).
>
> And I need add support to many backends like ldap, mysql, postgresql,
> etc. Would
> be great if postfix could do this and take postfix tables lookup
> proficiency.

I suggest that you try to solve the quota problem with an access map.

Aliases can nest, redirect via .forward files, and so on. Figuring
all that out can use up a lot of resources  Your suggestion has
great potential for DOS attacks, where very cheap RCPT TO commands
at the SMTP port can bring a server to its knees.

The Postfix solution would be a variation on the address verify
cache, where delivery agents maintain a success/failure database
for certain actions, and where the SMTP server can be configured
to query that database.  But this is harder than address verification
- now, Postfix must also be able to recognize WHY a down-stream
(LMTP) server is rejecting mail.

        Wietse