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