From: Andre Huebner (andre.huebnergmx.de)
Date: Fri Feb 01 2008 - 12:50:18 CST

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

hmm...
i wrote now my own policy-server in php. it is already working, but still
ander development.
Using check_policy_service i can compare data provided by postfix with my
own legal combination
of etrn-domain, client-ip and client name. after checking postfix gets back
action=permit or action=reject.
so it is possible to say client x with IP y can only get mails for domain z
Should be enough comparison to make it bulletproof?
If you understand the concept and know a little bit about php/perl etc. is
pretty easy.
But i think modern software should provide more own controlmethods for
problems like this...

Thank you
Andre

----- Original Message -----
From: "Wietse Venema" <wietseporcupine.org>
To: <postfix-userspostfix.org>
Sent: Wednesday, January 30, 2008 9:26 PM
Subject: Re: postfix ETRN

> Victor Duchovni:
>> On Wed, Jan 30, 2008 at 04:05:43PM +0100, Andre H?bner wrote:
>>
>> > Hi List,
>> >
>> > i try to set up etrn on my machine. Most of this is working.
>> > I used this tutorial: http://www.postfix.org/ETRN_README.html
>> > Now i have the problem to limit requests of etrn-domain x to client y
>> >
>> > I cannot find correct restrictions for smtpd_etrn_restrictions
>> > Either every client can request etrn or no one can. (or Server
>> > configuration error ;) )
>> > I did a try with:
>> >
>> > smtpd_etrn_restrictions =
>> > check_etrn_access hash:/etc/postfix/etrn-access
>> > reject
>> >
>> > in /etc/postfix/etrn-access i combined etrn-domain and ip of client who
>> > should be able to request but i have no idea about the correct format.
>>
>> See http://www.postfix.org/RESTRICTION_CLASS_README.html. This does
>> not scale to lots of domains, as each will need a different client
>> access table. If you have a lot of domains, you need a policy service
>> that makes database queries based on the client ip, domain name pair.
>> Postfix itself does not have multi-key table support.
>
> In the specific case of access maps, it could be faked by string
> concatenation of (helo + etrn) but this may push things over the
> limit.
>
> For example, imagine that all check_xxx_access were re-implemented
> in terms of a single check_access primitive that takes as first
> argument a search key type, and as second argument a lookup table.
>
> check_client_access maptype:mapname -> check_access client
> maptype:mapname
> check_etrn_access maptype:mapname -> check_access etrn maptype:mapname
>
> "check_xxx_access" would become aliases for "check_access xxx",
> for xxx in { client, helo, sender, recipient, data, end-of-data,
> etrn }.
>
> If one could then specify composite search key types instead of
> just "client" or "etrn", one would be able to say:
>
> check_access client|etrn maptype:mapname
>
> Besides main.cf ugliness there is Postfix code ugliness, because
> everyone will expect that parent domain searches and subnetwork
> searches will continue work as they do now. With composite search
> key types that can become nasty. We already had this problem with
> check_client_access where the search key has two parts, the name
> and the address.
>
> Anyway, back to PHP now.
>
> Wietse
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.16/1251 - Release Date:
> 30.01.2008 09:29
>
>

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