Loading ...
Sorry, an error occurred while loading the content.
 

postfix ETRN

Expand Messages
  • Andre Hübner
    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
    Message 1 of 7 , Jan 30, 2008
      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.

      Can someone help me?
      Thanks Andre
    • mouss
      ... how about showing the content of the file and the error in the log?
      Message 2 of 7 , Jan 30, 2008
        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.
        >

        how about showing the content of the file and the error in the log?

        > Can someone help me?
        > Thanks Andre
      • Victor Duchovni
        ... 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
        Message 3 of 7 , Jan 30, 2008
          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.

          --
          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:majordomo@...?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.
        • Wietse Venema
          ... 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,
          Message 4 of 7 , Jan 30, 2008
            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
          • Andre Huebner
            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
            Message 5 of 7 , Feb 1, 2008
              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" <wietse@...>
              To: <postfix-users@...>
              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
              >
              >
            • Victor Duchovni
              ... This is why Postfix has a policy extension mechanism, when you run out of rope, there s more. ... The problem is that no small improvement is ever enough,
              Message 6 of 7 , Feb 1, 2008
                On Fri, Feb 01, 2008 at 07:50:18PM +0100, Andre Huebner wrote:

                > i wrote now my own policy-server in php. it is already working, but still
                > ander development.

                This is why Postfix has a policy extension mechanism, when you run out
                of rope, there's more.

                > But i think modern software should provide more own controlmethods for
                > problems like this...

                The problem is that no small improvement is ever enough, nothing short
                of a full interpreter inside the SMTP server is ever really sufficient.

                Postfix currently provides simple, widely applicable, and often sufficient
                mechanisms in the SMTP server. The rest is done via policy services
                and milters.

                It is possible, for example, to build a new "pysmtpd" server for
                Postfix that includes a Python interpreter, and and replace the current
                restriction checks by calls into the interpreter. Then we'd also need a
                "plsmtpd" for the Perl lovers and a "tclsmtpd" for Tcl fans. Finally,
                we can invent our own scripting language that nobody knows...

                This should it make clear that the path to a fully expressive built-in
                policy engine is difficult.

                Perhaps gluing-in an interpreter can be done in a generic way, and people
                can choose which one to glue-in, with optional contributed modules that
                provide Python, Perl, Tcl, ... (as with SASL Cyrus vs. Dovecot AUTH).

                Finally, some might object to the security implications of that much rope.

                --
                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:majordomo@...?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.
              • Wietse Venema
                ... Either the client IP adress or client hostname would do the job. If someone subverts the DNS (or IP) then they can do much worse things that asking Postfix
                Message 7 of 7 , Feb 1, 2008
                  Andre Huebner:
                  > 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?

                  Either the client IP adress or client hostname would do the job.
                  If someone subverts the DNS (or IP) then they can do much worse
                  things that asking Postfix to schedule mail delivery.

                  > 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...

                  Postfix provides basic features, the rest goes with plugins.

                  With PHP it should be possible to write a multi-threaded policy
                  server. With simple queries like yours, one process should be able
                  to service a lot of smtpd processes.

                  Wietse
                Your message has been successfully submitted and would be delivered to recipients shortly.