Subject: Re: Sieve notify options and escaping

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Apr 2007 20:16:18 +0100

Aaron Stone wrote:

>On Mon, Mar 26, 2007, Alexey Melnikov <[email-masked]> said:  
>
>>Aaron, Dave has forwarded me your message:
>>    
>>
>Ok, moving back on list since we're more than one side-comment out.
>  
>
>>Dave Cridland wrote:
>>    
>>
>>>Dave,
>>>
>>>Barry and I discussed the need for some text to say what this means:
>>>
>>>   notify :options "body=${summary}" "mailto:foo@bar" 
>>>
>>>Because when you expand ${summary} is pretty important wrt escaping.
>>>Barry said that he'd add some text to handle this. I forgot to mention
>>>it in the jabber room for the official notes.
>>>      
>>>
>>Is this specific to Mailto notification method? Note that there is no 
>>text in notify base saying that options are to be converted to URI 
>>parameters.    
>>
>Same issues arise from this:  mailto "mailto:foo@bar?body=${summary}"
>
>What if ${summary} expands to "safebody&evil=evilbody"? We'll need some
>text to handle this situation I think.
>
If you suggest some, I will include it ;-).

>The issue applies to all
>mechanisms, I'm sure we could just as easily have additional xmpp url
>arguments or options.
>
>Do we have the option for "lazy evaluation" of variable expansion? If the
>expansion takes place inside the action, we have no trouble. If it takes
>place prior to calling the action, we need escaping.
>  
>
>>Also, do we actually want to register the "body" option?    
>>
>Sure, I don't see why not...
>  
>
Personally I dislike this, as this will most likely require a new IANA 
registry.
So far we were able to punt on this, as we didn't have any options.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Apr 2007 20:20:19 +0100

Aaron Stone wrote:

>On Tue, 2007-03-27 at 14:03 +0200, Kjetil Torgrim Homme wrote:
>  
>
>>On Mon, 2007-03-26 at 17:53 +0000, Aaron Stone wrote:
>>    
>>
>>[variables] says:
>>3.  Interpretation of strings
>>   [...]
>>   Tests or actions in future extensions may need to access the
>>   unexpanded version of the string argument and, e.g., do the expansion
>>   after setting variables in its namespace.  The design of the
>>   implementation should allow this.
>>
>>so the door is kept open, but the extension needs to be explicit about
>>it.  notice that a separate namespace should be used for such "dynamic"
>>or "internal" variables, in other words it should be ${notify.summary},
>>not just ${summary}.  for normal variables without a namespace, the
>>behaviour is:
>>
>>   The expanded string MUST use the variable values which are current
>>   when control reaches the statement the string is part of.
>>    
>>
>So a user can supply a variable that expands into valid options or url
>syntax. I do think we have to prevent this.
>  
>
New ":urlencode" modifier to the set action?

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 10 Apr 2007 18:35:53 +0200

> New ":urlencode" modifier to the set action?

what document should add such a modifier?

I'd like to note that it is possible to do this securely, although it's
not convenient.  e.g.

   if string :matches "${var}" "*&*" {
       set "var" "${1}%26${2}";

no, scratch that, we don't have recursion or other looping, so it won't
work for values containing two ampersands.  it would be tempting to add
a replace action:

  replace "var" "&" "%26";

we could allow MATCH-TYPE for more advanced replacements, e.g.

  replace :matches "var" "\\?" "${1}";

would replace a backslash followed by an arbitrary character by that
arbitrary character.

I don't have a real use case for this, so please feel free to disregard
the suggestion.

getting back to the issue at hand, I think it would be better to extend
the size of the notify namespace.  we could have

${notify.quote.subject}  (turn «hey "you"» into «"hey \"you\""»)
${notify.urlencode.subject}  (turn above string into «hey%20"you"»)
${notify.plain.subject}  (verbatim value)

we could also turn the order around, e.g.

${notify.subject.plain}
${notify.subject.urlencode}

which allows us to choose one of them as a "default" when the user
writes just ${notify.subject}.

-- 
Kjetil T.