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/transport_maps restriction I had something like:
/(server[0-9])\.([0-9]{5})\.([a-z]+)@process.company\.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:
/[EMAIL PROTECTED]/ smtp:[server1]:10025
/[EMAIL PROTECTED]/ 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 <[EMAIL PROTECTED]> 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
>
