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

trivial-rewrite regular expression substitution

Expand Messages
  • David DeFranco
    According to the man page I can t do regular expression substitution in transport maps with Postfix 2.3 or later. The trivial-rewrite(8) server disallows
    Message 1 of 11 , Sep 30, 2008
      According to the man page I can't do regular expression substitution in transport maps with Postfix 2.3 or later.
      The trivial-rewrite(8) server disallows regular expression
      substitution  of  $1  etc.  in  regular  expression lookup
      tables, because that could open a security  hole  (Postfix
      version 2.3 and later).
      Is there a way to override this setting or am I stuck running Postfix 2.2?


      Thank you,
      David




    • Victor Duchovni
      ... Are you using regexp keys to resolve to a *fixed* transport:nexthop or regexp keys with sub-patterns to resolve to a dynamic transport:nexthop? The latter
      Message 2 of 11 , Sep 30, 2008
        On Tue, Sep 30, 2008 at 09:27:59PM -0600, David DeFranco wrote:

        > According to the man page I can't do regular expression substitution in
        > transport maps with Postfix 2.3 or later.
        >
        > The trivial-rewrite(8) server disallows regular expression
        > substitution of $1 etc. in regular expression lookup
        > tables, because that could open a security hole (Postfix
        > version 2.3 and later).
        >
        > Is there a way to override this setting or am I stuck running Postfix 2.2?

        Are you using regexp keys to resolve to a *fixed* transport:nexthop or
        regexp keys with sub-patterns to resolve to a dynamic transport:nexthop?

        The latter is not safe, and is far too likely to lead to security issues.
        So if you really need substitutions, you are out of luck.

        --
        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.
      • David DeFranco
        I need data that s in the user part of the address to determine the nexthop. Obviously doing this dynamically is easier that maintaining a huge map file. My
        Message 3 of 11 , Sep 30, 2008
          I need data that's in the user part of the address to determine the nexthop.  Obviously doing this dynamically is easier that maintaining a huge map file.

          My server is an internal mail router and only one recipient domain would be subject to this transport.

          Just out of curiosity, what kind of security hole are we talking about?



          On Tue, Sep 30, 2008 at 9:31 PM, Victor Duchovni <Victor.Duchovni@...> wrote:
          On Tue, Sep 30, 2008 at 09:27:59PM -0600, David DeFranco wrote:

          > According to the man page I can't do regular expression substitution in
          > transport maps with Postfix 2.3 or later.
          >
          > The trivial-rewrite(8) server disallows regular expression
          > substitution  of  $1  etc.  in  regular  expression lookup
          > tables, because that could open a security  hole  (Postfix
          > version 2.3 and later).
          >
          > Is there a way to override this setting or am I stuck running Postfix 2.2?

          Are you using regexp keys to resolve to a *fixed* transport:nexthop or
          regexp keys with sub-patterns to resolve to a dynamic transport:nexthop?

          The latter is not safe, and is far too likely to lead to security issues.
          So if you really need substitutions, you are out of luck.

          --
                 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
          ... Of course it s equally dangerous with earlier Postfix releases. ... I recommend that you stop using regexp substitutions in transport maps. Wietse
          Message 4 of 11 , Oct 1, 2008
            David DeFranco:
            > According to the man page I can't do regular expression substitution in
            > transport maps with Postfix 2.3 or later.
            >
            > The trivial-rewrite(8) server disallows regular expression
            > substitution of $1 etc. in regular expression lookup
            > tables, because that could open a security hole (Postfix
            > version 2.3 and later).

            Of course it's equally dangerous with earlier Postfix releases.

            > Is there a way to override this setting or am I stuck running Postfix 2.2?

            I recommend that you stop using regexp substitutions in transport maps.

            Wietse
          • Wietse Venema
            ... With regexp substitution, this would give giving random users control over destination host names, host addresses, and TCP ports. Instead of using (regexp)
            Message 5 of 11 , Oct 1, 2008
              David DeFranco:
              > I need data that's in the user part of the address to determine the
              > nexthop.

              With regexp substitution, this would give giving random users
              control over destination host names, host addresses, and TCP ports.

              Instead of using (regexp) to grab the nexthop from the recipient
              localpart or domain part, specify the string explicitly.

              /......(regexp)....../ ......$1......

              /......whatever....../ ......whatever......

              Repeat this for each such domain.

              Wietse
            • David DeFranco
              Thanks for the answers. This is an internal mail server for system generated mail, and I m re-writing the address before determining the transport so there s
              Message 6 of 11 , Oct 1, 2008
                Thanks for the answers.

                This is an internal mail server for system generated mail, and I'm re-writing the address before determining the transport so there's sanity checking already in place.  I would never consider this kind of setup on a user/internet relay server.  Heck, I wouldn't consider this solution in the first place, but it's legacy ( currently on sendmailx ) and I have to make it work.  I wanted to avoid using an explicit map file because it could be complex and has to be updated manually.

                Is there another way to programmatically determine the next-hop?

                Thanks again




                On Wed, Oct 1, 2008 at 6:15 AM, Wietse Venema <wietse@...> wrote:
                David DeFranco:
                > I need data that's in the user part of the address to determine the
                > nexthop.

                With regexp substitution, this would give giving random users
                control over destination host names, host addresses, and TCP ports.

                Instead of using (regexp) to grab the nexthop from the recipient
                localpart or domain part, specify the string explicitly.

                /......(regexp)....../  ......$1......

                /......whatever....../  ......whatever......

                Repeat this for each such domain.

                       Wietse

              • Victor Duchovni
                ... Use (regexp) virtual alias mapping to rewrite recipients to suitably selected artificial domains that map statically to the right transport. In the
                Message 7 of 11 , Oct 1, 2008
                  On Wed, Oct 01, 2008 at 01:38:36PM -0600, David DeFranco wrote:

                  > Thanks for the answers.
                  >
                  > This is an internal mail server for system generated mail, and I'm
                  > re-writing the address before determining the transport so there's sanity
                  > checking already in place. I would never consider this kind of setup on a
                  > user/internet relay server. Heck, I wouldn't consider this solution in the
                  > first place, but it's legacy ( currently on sendmailx ) and I have to make
                  > it work. I wanted to avoid using an explicit map file because it could be
                  > complex and has to be updated manually.
                  >
                  > Is there another way to programmatically determine the next-hop?

                  Use (regexp) virtual alias mapping to rewrite recipients to suitably
                  selected artificial domains that map statically to the right transport.
                  In the transport, use smtp_generic_maps to undo the virtual mapping,
                  so the destination sees an unmodified recipient address.

                  virtual(5):
                  user1@... -> user=example.com@...
                  user2@... -> user=example.com@...

                  transport(5):
                  host1.nexthop.invalid mysmtp:[host1-gateway]
                  host2.nexthop.invalid mysmtp:[host2-gateway]


                  master.cf
                  mysmtp ... smtp
                  -o smtp_generic_maps=$mysmtp_generic_maps

                  main.cf:
                  mysmtp_generic_maps = pcre:/etc/postfix/undo_adhoc_routing.pcre
                  virtual_alias_maps = pcre:/etc/postfix/do_adhoc_routing.pcre

                  Beware of loops! Do not let the PCRE LHS pattern match the RHS output!

                  --
                  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
                  ... How many entries would a map have, and why would the map have to change? Is the problem that recipients have their real domain name embedded in the address
                  Message 8 of 11 , Oct 1, 2008
                    Wietse:
                    > > Instead of using (regexp) to grab the nexthop from the recipient
                    > > localpart or domain part, specify the string explicitly.
                    > >
                    > > /......(regexp)....../ ......$1......
                    > >
                    > > /......whatever....../ ......whatever......
                    > >
                    > > Repeat this for each such domain.

                    David DeFranco:
                    > Thanks for the answers.
                    >
                    > This is an internal mail server for system generated mail, and I'm
                    > re-writing the address before determining the transport so there's sanity
                    > checking already in place. I would never consider this kind of setup on a
                    > user/internet relay server. Heck, I wouldn't consider this solution in the
                    > first place, but it's legacy ( currently on sendmailx ) and I have to make
                    > it work. I wanted to avoid using an explicit map file because it could be
                    > complex and has to be updated manually.
                    >
                    > Is there another way to programmatically determine the next-hop?

                    How many entries would a map have, and why would the map have to
                    change?

                    Is the problem that recipients have their real domain name
                    embedded in the address local-part? If that is the case
                    there may be better solutions than using a transport map.

                    I am trying to look for alternatives to your preferred solution,
                    and that requires that I know more about the problem.

                    Wietse
                  • David DeFranco
                    These are application generated messages and the format of the recipient address is very specific. The user part of the address contains a specific server and
                    Message 9 of 11 , Oct 1, 2008
                      These are application generated messages and the format of the recipient address is very specific.  The user part of the address contains a specific server and port the message needs to be sent to.  Something like:

                      server1.10025.username@...          smtp:[server1]:10025

                      before I realized the regex/transport_maps restriction I had something like:

                      /(server[0-9])\.([0-9]{5})\.([a-z]+)@...\.com/          smtp:[$1]:$2

                      I'm not sure of the entire history behind this solution but apparently they didn't want these servers to listen on 25.  I don't know if different ports handle mail differently, I can only assume so.  This mapping is currently done dynamically, and I'm in the process of finding out how many servers and port combinations there are.  My fear is that there are hundreds of combinations ( which wouldn't be horrible to manage statically, just inelegant ) and that new combinations are brought up ad hoc.

                      Victor, thanks for the solution, that's good stuff.  I should have told you about the port requirement sooner. I think it would be a lot simpler to use regexp matching:

                      /server1\.10025\.[a-z]+@process.company.com/          smtp:[server1]:10025
                      /server1\.20025\.[a-z]+@process.company.com/          smtp:[server1]:20025

                      etc.  I would still prefer a programmatic way to do this so the messaging team doesn't have to be involved every time the application team adds a server or changes a port.


                      On Wed, Oct 1, 2008 at 2:35 PM, Wietse Venema <wietse@...> wrote:
                      Wietse:
                      > > Instead of using (regexp) to grab the nexthop from the recipient
                      > > localpart or domain part, specify the string explicitly.
                      > >
                      > > /......(regexp)....../  ......$1......
                      > >
                      > > /......whatever....../  ......whatever......
                      > >
                      > > Repeat this for each such domain.

                      David DeFranco:
                      > Thanks for the answers.
                      >
                      > This is an internal mail server for system generated mail, and I'm
                      > re-writing the address before determining the transport so there's sanity
                      > checking already in place.  I would never consider this kind of setup on a
                      > user/internet relay server.  Heck, I wouldn't consider this solution in the
                      > first place, but it's legacy ( currently on sendmailx ) and I have to make
                      > it work.  I wanted to avoid using an explicit map file because it could be
                      > complex and has to be updated manually.
                      >
                      > Is there another way to programmatically determine the next-hop?

                      How many entries would a map have, and why would the map have to
                      change?

                      Is the problem that recipients have their real domain name
                      embedded in the address local-part? If that is the case
                      there may be better solutions than using a transport map.

                      I am trying to look for alternatives to your preferred solution,
                      and that requires that I know more about the problem.

                             Wietse

                    • Wietse Venema
                      ... Argh. Using regexp-based transport maps in a closed environment for this should be safe for some definition of safe . Unfortunately there is no source
                      Message 10 of 11 , Oct 1, 2008
                        David DeFranco:
                        > These are application generated messages and the format of the recipient
                        > address is very specific. The user part of the address contains a specific
                        > server and port the message needs to be sent to. Something like:
                        >
                        > server1.10025.username@... smtp:[server1]:10025
                        >
                        > before I realized the regex/transport_maps restriction I had something like:
                        >
                        > /(server[0-9])\.([0-9]{5})\.([a-z]+)@...\.com/
                        > smtp:[$1]:$2
                        >
                        > I'm not sure of the entire history behind this solution but apparently they
                        > didn't want these servers to listen on 25. I don't know if different ports
                        > handle mail differently, I can only assume so. This mapping is currently
                        > done dynamically, and I'm in the process of finding out how many servers and
                        > port combinations there are. My fear is that there are hundreds of
                        > combinations ( which wouldn't be horrible to manage statically, just
                        > inelegant ) and that new combinations are brought up ad hoc.

                        Argh. Using regexp-based transport maps in a closed environment
                        for this should be "safe" for some definition of "safe".

                        Unfortunately there is no source code in place that allows you to
                        toggle the one-bit flag that says "no regexp substitution allowed
                        here". Sendmail has "don't blame Sendmail" options for such cases.

                        Until then you may want to stick with Postfix 2.2. There is nothing
                        bad with it except for the non-standard link(2) semantics of
                        Solaris/Linux/Irix, resulting in privilege escalation if you have
                        a world-writable system mailbox directory.

                        Wietse
                      • David DeFranco
                        No mailboxes on these servers so no worries there. Thanks for all your time and help.
                        Message 11 of 11 , Oct 1, 2008
                          No mailboxes on these servers so no worries there. 

                          Thanks for all your time and help.


                          On Wed, Oct 1, 2008 at 5:19 PM, Wietse Venema <wietse@...> wrote:
                          David DeFranco:
                          > These are application generated messages and the format of the recipient
                          > address is very specific.  The user part of the address contains a specific
                          > server and port the message needs to be sent to.  Something like:
                          >
                          > server1.10025.username@...          smtp:[server1]:10025
                          >
                          > before I realized the regex/transport_maps restriction I had something like:
                          >
                          > /(server[0-9])\.([0-9]{5})\.([a-z]+)@...\.com/
                          > smtp:[$1]:$2
                          >
                          > I'm not sure of the entire history behind this solution but apparently they
                          > didn't want these servers to listen on 25.  I don't know if different ports
                          > handle mail differently, I can only assume so.  This mapping is currently
                          > done dynamically, and I'm in the process of finding out how many servers and
                          > port combinations there are.  My fear is that there are hundreds of
                          > combinations ( which wouldn't be horrible to manage statically, just
                          > inelegant ) and that new combinations are brought up ad hoc.

                          Argh. Using regexp-based transport maps in a closed environment
                          for this should be "safe" for some definition of "safe".

                          Unfortunately there is no source code in place that allows you to
                          toggle the one-bit flag that says "no regexp substitution allowed
                          here". Sendmail has "don't blame Sendmail" options for such cases.

                          Until then you may want to stick with Postfix 2.2. There is nothing
                          bad with it except for the non-standard link(2) semantics of
                          Solaris/Linux/Irix, resulting in privilege escalation if you have
                          a world-writable system mailbox directory.

                                 Wietse

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