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

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

## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to