About 3 - why not? I propose a new untaint/filter function in ADDITION to what already exist, so people can choose what fits the situation best.
Sometimes, you know beforehand what email adress to expect on recipient, then a lookup is fine and you can accept any characters.
Sometimes, you "mint" email adresses based on a external factor (think Email-2-SMS or mailinator.com like service, or even include IP adresses in localpart - for example for a local network messaging system) - then you need to be able to allow any email adress that follows a specific set of strict rules - to prevent dangerous data to compromise the server.
What I propose with the filters.
Also notice - my proposed filters will never fail, it will only delete dangerous characters, meaning it will "neuter" bad data, not reject it.
And if the system administrators want to reject bad data instead of "neuter it" - he have to compare the unfiltered data to filtered data, and reject if they don't match, else return the filtered variant (which is equal to the unfiltered if no bad characters were found)
Meaning any legit filtered characters will not break internationalization.
Also such a filter, as I said, can be very useful for non-taint filtering too - for example filtering out bad characters from subjects or headers, even if tainted data is accepted there, there is still reasons to filter things like that to prevent certain email clients to crash.
-----Ursprungligt meddelande-----
Från: Andrew C Aitchison via Exim-users <exim-users@???>
Skickat: den 12 november 2020 16:04
Till: exim-users@???
Ämne: Re: [exim] tainted data issues
On Thu, 12 Nov 2020, Mike Tubby via Exim-users wrote:
> Here's a proposal for a compromise in an attempt to satisfy these,
> competing, requirements with a phased approach:
>
> 1. Publish a roadmap for Exim - likely things to arrive in 4.95, 4.96,
> 4.97 ... and that there will be an Exim 5.0 out in roughly XX months.Â
> This doesn't have to be stuck to - its forward looking not a 'promise'
> but can include item (5) below.
>
> 2. Keep the tainted data model as it is now
>
> 3. Don't give the user's new untaint methods that fix one thing and
> potentially break another, e.g. internationalisation
>
> 4. Document tainted data more fully:
>
> * what tainted data is
> * what can go wrong if you trust it when you shouldn't
> * why you need to change
> * examples of configurations and recommendations
>
> Ensure the documentation includes the road-signs to the right way to
> do things to avoid cargo-cult
>
> 5. Add a new config variable:
>
> taint_mode = warn | enforce
>
> which is initially defaults to 'warn' and which bleaches to
> mainlog/paniclog or even stdout on start warning:
>
> a) of the perils of tainted data;
> b) tells the user this this feature is going to be removed in
> a future release
> c) points to the documentation (3)
> Eg:
> Exim: Configuration uses tainted data which is currently
> allowed may be dangerous. This will be removed in a future release.
> For info see https://exim.org/tainted_data.html
>
> At some later release (4.96, 4.97 ?) switch from the default of
> 'warn' to the default of 'enforce', effectively allowing the user to
> swim against the tide by switching back to 'warn' if they must.
>
> Implement the taint_mode with a sun-set, i.e planned removal at Exim 5.0.
>
> 6. Implement Jeremy's relatively light weight:
>
> ${if tainted{my_suspect_expansion} {expand_this}
> {expand_that}}
>
> Which he said would be simple to code and test and allow some
> workarounds to be implemented for some use cases.
>
> 7. Publicity.
Generally good. Thanks Mike.
Some points:
A/ I believe that one reason we have got into this position is that "suspect" data is currently being used in many ways that the main developers had not imagined.
*** This means that other people are in a better position then Jeremy etc.
*** to write (at least one pass of) the new documentation.
B/ Given that the likes of Ubuntu are now shipping v4.94, would it not be reasonable to default to
taint_mode = enforce
- anyone who is up to date already has this, so that is least surprise ?
If 4.95 bleats unless taint_mode is explicitly set to something, we will get some free publicity, and the user will know to set taint_mode = warn until they have addresses the issue.
The later release (4.96, 4.97 ?) will then merely need to bleat if taint_mode is set to "warn".
(I am tempted to suggest that this should be a persistent bleat, like the
Warning: No server certificate defined; will use a selfsigned one.
Suggested action: either install a certificate or change tls_advertise_hosts option
message.)
C/ I see 6. ${if tainted{ as primarily a debugging feature; once {expand_this} and {expand_that} are pinned down for an installation, I believe that {my_suspect_expansion} will usually turn out to be a constant.
--
Andrew C. Aitchison Kendal, UK
andrew@???
--
## 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/
