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