Ned Freed wrote:
>> 2). Ned wrote in a separate email about # 2:
>
>> > Script analysis is one of those tri-state things. It can conclude
>> that:
>> >
>> > (1) A script is harmless.
>> > (2) A script is harmful.
>> > (3) The script cannot be analyzed.
>> >
>> > Now, in practice the _overwhelming_ majority of actual scripts will
>> fall into
>> > one of the first two categories. This is especially true when
>> scripts are
>> > created by a GUI - GUIs tools tend to construct straightforward
>> scripts without
>> > any of the complexities that hinder analysis.
>> >
>> > And even when the conclusion is (3), that actually tells you
>> something. A
>> > really sophisticated system might even note the presence of a highly
>> > complicated script and watch even more carefully for abuse.
>> >
>> > Heck, even a very naive analysis can be useful. For example, to the
>> extent
>> > redirect offers capabilities beyond those of a .forward file, they
>> only arise
>> > when the address redirect sends the message to can be controlled by
>> the message
>> > itself. For that you really need Sieve variables (and hence this is
>> out of
>> > scope for the Sieve base specification). So one very simple thing
>> you can do is
>> > look for the use of variables and the presence of ${} constructs in
>> redirects.
>> > A setup that allows users to configure arbitrary sieves might want
>> to check for
>> > this combination and either disallow or flag it in some way.
>
>> I don't think the discussion about looking for variables in the redirect
>> address belongs to the 3028bis, because 3028bis itself has no variables.
>> Apart from that something along the lines of Ned's text can be included.
>
> Agreed. I can work on a cut down version if you want.
Yes please.
With all the back and forth on this I'm afraid I've lost track of the
current set of proposed revisions. If you could send them to me I'll see
about adding these points to them without getting into the issues Sieve
variables raises.
Ned