On 2016-10-17 at 22:53 +0100, Mike Tubby wrote:
> Couldn't we have - per perhaps shouldn't we have - a "safe domain name"
> function in Exim that could be used for this and elsewhere where an
> untrusted domain name enters - it would:
Exim is a volunteer open source project. Patches are welcome, as are
new contributors. If this is the itch for you to scratch to get
involved, then take a look at src/expand.c
> * remove white space (tab, space, etc)
> * remove non-printing chars
> * remove 'quoting' and 'escaping'
Any security function should _whitelist_, not blacklist.
This is the advantage of hashing or base64-encoding: it moves the
character-set of files in the local filesystem to be guaranteed safe,
easily scriptable without having to worry about extra `$` signs or
backticks or other malarkey from remote data.
This is a pattern used in various secure designs. I was asked for the
safest approach, so I gave the safest. If instead you want an approach
which is "probably pretty safe, but still looks a bit like the original
name for most cases" then you can use escaping mechanisms and hope that
no corner cases were missed (empty string but present `$tls_sni` and so
forth).
> aren't computers are supposed to be doing the work for us...?
They do. I provided an answer which matches the approach for handling
user-data which I've seen at some big sites. Don't ever trust user-data
as safe for a filename on local disk.
Really, this goes in as a step in your configuration build process when
building the set of files to be deployed to the mail-server. A
filename transform step is simple (as is having some symlinks for
user-friendliness if you have humans regularly logging in to look around).
