After talking to Cullen Lisa thinks that one or two of the following
changes should address Cullen's DISCUSS (I assume that the text I've
suggested earlier should be included in some form into 3028bis anyway,
this is in addition to this):
1). Limit applicability of SIEVE, e.g. to deployments where
administrators can disable accounts abusing scripts.
2). Add text with helpful guidance about script analysis or forking
detection.
3). Add requirements for use of mail headers to more reliably detect
forking.
=======
So here is some background on the three choices and are my comments on
them (strictly as an individual contributor).
1). This is really no brainer. Any deployed mail system should have a
way to disable accounts. I would suggest adding the following:
Sieve implementations MUST provide facilities to allow administrators
to disable accounts abusing scripts.
Cullen, does this satisfy you?
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.
3). [I hope that the following is not too cryptic for people to
understand. If it is, I can try to provide a more detailed explanation
later.] Lisa has suggested in a private email a new header field
(Mail-Fork-Estimation) that can be used to convey the estimated total
number of redirects that happened so far as estimated at the previous
hop. The value of this header is multiplied by the number of redirects
that happens at the current hop and if it is bigger than 100, the
message is going to be dropped at the next hop. So this is similar to
counting Received headers, but compensates for multiple redirects.
While I think this might be a neat research idea and should be published
as a draft, I have a problem with mandating this in 3028bis:
1). If this is mandated in 3028bis, this would take some time to deploy.
This would also render *all* existing implementations non-compliant,
which is not a good thing. While I can see that this might help in the
future, I don't think it is necessary and 2 other approaches (script
analysis and abuse detection+script disabling) already work quite
reasonably
2). This proposal changes how redirect has to be implemented by many
implementations. Currently for some implementations a redirect can be a
fire-and-forget operation (after adding it to logs). The actual message
submission is performed asynchronously. Your proposal will require that
all redirects for all users (a single message can be destined to
multiple recipients and all of them can have Sieve scripts) are to be
performed by an MTA at one moment, because all of them will have to have
the same Mail-Fork-Estimation header field. In Sieve WG we have many
different implementations and we were trying vary carefully not to put
unnecessary requirements on implementations.
====
To summarize: I personally disagree that # 3 is a solution suitable for
3028bis. I agree that some combination of 1 and 2 is reasonable. I would
need some help to come up with text covering # 2.
Regards,
Alexey