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

Re: trivial-rewrite regular expression substitution

Expand Messages
  • 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 1 of 11 , Oct 1, 2008
    • 0 Attachment
      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 2 of 11 , Oct 1, 2008
      • 0 Attachment
        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 3 of 11 , Oct 1, 2008
        • 0 Attachment
          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 4 of 11 , Oct 1, 2008
          • 0 Attachment
            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 5 of 11 , Oct 1, 2008
            • 0 Attachment
              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 6 of 11 , Oct 1, 2008
              • 0 Attachment
                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 7 of 11 , Oct 1, 2008
                • 0 Attachment
                  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 8 of 11 , Oct 1, 2008
                  • 0 Attachment
                    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.