[Top] [All Lists]

Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2

2007-09-23 07:01:19

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.