Re: [exim] Alternative to the -D option

On 2011-10-10 at 20:51 +1000, Russell Stuart wrote:
> virus checking). I now realise the WHITELISTED_D_MACROS thing was a
> debian hack introduced for this reason.

No, it was a "Phil Pennock hack", introduced because I insisted that
people were using macros in sane ways and, by very carefully limiting
the character set allowed to appear in a macro, we could limit the
damage and provide people time to migrate carefully instead of having to
slash & burn.

I'm a sysadmin, I like migration strategies other than "redo all your
configs at upgrade time, only ever roll forward". I like giving others
that freedom too. :)

Rather than throw away a lot of work right now in a hurry, I suggest
building Exim using the whitelist for the macros you have, and work with
us on exim-users to try to find ways to deal with the remaining issues.
Some of those ways might involve code changes for new facilities.

Someone's already suggested using a "protocol" to deal with some
problems. That's the -oMr flag.

There's a proposal/patch which adds a ${getenv:...} expansion operator
(or somesuch). That would not propagate cleanly to messages delivered
by queue-runners started from another context, but might be useful in
some conditions. Would it help with some of your current issues? I'm
mostly in favour of adding ${getenv:...}. It does have some security
impact, but the _results_ of getenv are not subject to string expansion,
as macro results are (unless fed back through ${expand:...}) so is
generally much MUCH safer.

And so on. You're using Exim responsibly in a production environment
and we want to help you to continue to do so without having to cripple
anything or remove emergency recovery methods which experience has shown
you to be necessary. _Changing_ the recovery method may be necessary,
but removing a recovery method is just asking for trouble.

-Phil