Re: trivial-rewrite regular expression substitution

2008-10-01 Thread David DeFranco
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 <[EMAIL PROTECTED]> wrote: > David DeFranco: > > These are application generated messages and the format of the recipient > > address is very specific. The user p

Re: trivial-rewrite regular expression substitution

2008-10-01 Thread Wietse Venema
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: > > [EMAIL PROTECTED] smtp:[server1]:10025 > > befo

Re: trivial-rewrite regular expression substitution

2008-10-01 Thread 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: [EMAIL PROTECTED] smtp:[server1]:10025 before I realized the regex/transp

Re: trivial-rewrite regular expression substitution

2008-10-01 Thread Wietse Venema
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: >

Re: trivial-rewrite regular expression substitution

2008-10-01 Thread Victor Duchovni
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 ki

Re: trivial-rewrite regular expression substitution

2008-10-01 Thread 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 thi

Re: trivial-rewrite regular expression substitution

2008-10-01 Thread Wietse Venema
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 local

Re: trivial-rewrite regular expression substitution

2008-10-01 Thread Wietse Venema
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 secu

Re: trivial-rewrite regular expression substitution

2008-09-30 Thread 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 server is an internal mail router and only one recipient domain would be subject to this transport. Just out of curiosity, what kind of sec

Re: trivial-rewrite regular expression substitution

2008-09-30 Thread Victor Duchovni
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 expressio

trivial-rewrite regular expression substitution

2008-09-30 Thread 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