[Top] [All Lists]

Re: [sieve] Working group last call on draft-ietf-sieve-include

2011-09-30 14:40:47

Robert Burrell Donkin wrote:

On Mon, Sep 26, 2011 at 10:06 PM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Hi Robert,

Robert Burrell Donkin wrote:
On Sat, Sep 24, 2011 at 4:08 PM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Aaron Stone wrote:
In the case of a MUST, it means that a valid includes implementation
imposes a script naming restriction. If a site isn't using
managesieve, would that site really need to accept the name
If you don't make it a MUST, then nobody can be relied upon the rule.
I'm a little unclear why allowing people to rely on this rule should
be seen as good thing...

1. Can anyone think of a use case that could be satisfied best by an
author intentionally including a restricted script name?

This question looks entirely backwards to me.

ManageSieve script names are quite permissive: basically various control
characters are disallowed. IMHO, disallowing control characters in script
names is a good thing.

(I'd like to avoid second guessing the design choices made in RFC5804)

I just wanted to understand what benefit (if any) changing SHOULD to
MUST has for script authors.

I don't see any point of having requirement on script authors (humans). However I believe knowing exact syntax and limitations has benefits for agents that generate and validate scripts.

I assume this silence means there is no benefit.

SHOULD is pointless for syntactic restrictions, because no agent can rely that it will be complied with.

2. Allowing implementors to rely on this rule may create a false sense
of security, and so may encourage them to neglect proper checks on
names before accessing their backing store. What are the positive
benefits that outweigh this risk?
Quite the opposite: if the rule is a MUST, then implementations can validate
names and reject invalid ones.

Any reasonable, security-conscious implementation will reject
malicious names whether this action is allowed by the specification or
not. A well written, security-conscious specification would
acknowledge this behaviour and permit it.

A reasonable implementation supporting a related standard (whether
RFC5804 or some other future standard) will reject and allow script
names for reasons of compatibility  whether this action is allowed by
the specification or not.  A durable specification would acknowledge
this behaviour and permit it.

If you are arguing that these things are obvious and thus must not be document, then I strongly disagree.

Therefore, I believe that authoring tools should strictly validate to
ensure wide portability but that servers should be allowed more
freedom for reasons of security and compatibility. So, I think that
perhaps something like [1] would be an improvement.


"Be conservative in what you do, be liberal in what you accept from
others." - Jon Postel

  Implementations MUST restrict script
  names according to MANAGESIEVE [RFC5804], Section 1.6.  The script
  name argument MUST be a constant string as defined in VARIABLES
  [RFC5229], Section 3;

Before resource resolution, implementations MUST validate script

This MUST is insufficient to have two interoperable implementations, because it doesn't suggest how this can be achieved. Unless the text below is really trying to explain how this can be done.

The rest of your proposed text seems Ok.

Before attempting to access the resolved resource, if an
invalid name is detected implementations MUST terminate execution by
raising an error. A name is invalid when:

* name resolution could compromise the security of the backing storage; or
* the name is incompatible with one or more standard supported by the

After resource resolution, implementations MUST verify the rights of
the script owner to access this resource. If access is not permitted,
implementations MUST terminate execution by raising a runtime-error.

Creators of script authoring tools SHOULD validate script names to
ensure portability and MUST restrict script names
 * to constant strings as defined in VARIABLES [RFC5229], Section 3;
 * to MANAGESIEVE [RFC5804], Section 1.6.

sieve mailing list