Re: Sieve gets in infinite loop

Re: Sieve gets in infinite loop

[Reiner Steib]

On Thu, Nov 19 2009, Jason Rumney wrote:

> Gnus v5.13
> GNU Emacs 23.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.3)
>  of 2009-11-18 on wanchan.jasonrumney.net
>
> Attempting to upload my sieve script to a Dovecot server results in an
> infinite loop in sieve-manage-network-open.
>
> The cause is the test for the OK line in sieve-manage-parse-capability-1:
>
>   (when (re-search-forward (concat "^OK" sieve-manage-server-eol) nil t)
>     (setq sieve-manage-state 'nonauth)))
>
> My server sends the following non-matching line:
>
>    OK "Dovecot ready."

I know next to nothing about sieve, but AFAICS, you (and your server)
are right.  Feel free to adjust sieve-manage-parse-capability-1 as
needed.

,----[ http://tools.ietf.org/html/draft-ietf-sieve-managesieve-09 ]
| 1.3.  Syntax
| 
|    [...]
| 
|    Each command consists of an atom (the command name) followed by zero
|    or more strings and numbers terminated by CRLF.
| 
|    All client queries are replied to with either an OK, NO, or BYE
|    response.  Each response may be followed by a response code (see
|    Section 1.4) and by a string consisting of human readable text in the
|    local language (as returned by the LANGUAGE capability, see
|    Section 1.8), encoded in [UTF-8].  The contents of the string SHOULD
|    be shown to the user and implementations MUST NOT attempt to parse
|    the message for meaning.
| 
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Sieve gets in infinite loop

[Jason Rumney]

Reiner Steib wrote:
> On Thu, Nov 19 2009, Jason Rumney wrote:
>
>   
>> My server sends the following non-matching line:
>>
>>    OK "Dovecot ready."
>>     
>
> I know next to nothing about sieve, but AFAICS, you (and your server)
> are right.  Feel free to adjust sieve-manage-parse-capability-1 as
> needed.
>   

The following simple patch works for me, but I don't understand why the 
eol needed to be on the regexp in the first place, so I may be missing 
something.

=== modified file 'lisp/gnus/sieve-manage.el'
--- lisp/gnus/sieve-manage.el    2009-01-09 03:01:50 +0000
+++ lisp/gnus/sieve-manage.el    2010-01-08 14:53:46 +0000
@@ -636,7 +636,7 @@
           sieve-manage-capability))
     (push (list str) sieve-manage-capability))
       (forward-line)))
-  (when (re-search-forward (concat "^OK" sieve-manage-server-eol) nil t)
+  (when (re-search-forward "^OK" nil t)
     (setq sieve-manage-state 'nonauth)))
 
 (defalias 'sieve-manage-parse-greeting-1 'sieve-manage-parse-capability-1)



-- 
Jason

Re: Sieve gets in infinite loop

[Simon Josefsson]

Jason Rumney <jasonr@gnu.org> writes:

> Reiner Steib wrote:
>> On Thu, Nov 19 2009, Jason Rumney wrote:
>>
>>   
>>> My server sends the following non-matching line:
>>>
>>>    OK "Dovecot ready."
>>>     
>>
>> I know next to nothing about sieve, but AFAICS, you (and your server)
>> are right.  Feel free to adjust sieve-manage-parse-capability-1 as
>> needed.
>>   
>
> The following simple patch works for me, but I don't understand why
> the eol needed to be on the regexp in the first place, so I may be
> missing something.
>
> === modified file 'lisp/gnus/sieve-manage.el'
> --- lisp/gnus/sieve-manage.el    2009-01-09 03:01:50 +0000
> +++ lisp/gnus/sieve-manage.el    2010-01-08 14:53:46 +0000
> @@ -636,7 +636,7 @@
>           sieve-manage-capability))
>     (push (list str) sieve-manage-capability))
>       (forward-line)))
> -  (when (re-search-forward (concat "^OK" sieve-manage-server-eol) nil t)
> +  (when (re-search-forward "^OK" nil t)
>     (setq sieve-manage-state 'nonauth)))
>
> (defalias 'sieve-manage-parse-greeting-1 'sieve-manage-parse-capability-1)

According to http://tools.ietf.org/html/draft-ietf-sieve-managesieve-09
the response line can contain an optional string:

    response-nobye        = ("NO" / "BYE") [SP "(" resp-code ")"]
                            [SP string] CRLF
                            ;; The string contains human readable text
                            ;; encoded as UTF-8.

So how about

-  (when (re-search-forward (concat "^OK" sieve-manage-server-eol) nil t)
+  (when (re-search-forward (concat "^OK.*" sieve-manage-server-eol) nil t)

instead?  Not perfect, but hopefully would solve your problem and still
match EOL stuff.

/Simon

Re: Sieve gets in infinite loop

[Jason Rumney]

Simon Josefsson wrote:
> According to http://tools.ietf.org/html/draft-ietf-sieve-managesieve-09
> the response line can contain an optional string:
>
>     response-nobye        = ("NO" / "BYE") [SP "(" resp-code ")"]
>                             [SP string] CRLF
>                             ;; The string contains human readable text
>                             ;; encoded as UTF-8.
>
>   
I guess you meant to paste the response-ok definition there, but they 
are basically the same.

> So how about
>
> -  (when (re-search-forward (concat "^OK" sieve-manage-server-eol) nil t)
> +  (when (re-search-forward (concat "^OK.*" sieve-manage-server-eol) nil t)
>
> instead?  Not perfect, but hopefully would solve your problem and still
> match EOL stuff.
>   

So the gnus developers are OK about ignoring this statement in section 
1.3 of the RFC?

   The contents of the string SHOULD be shown to the user and
   implementations MUST NOT attempt to parse the message for meaning.

Following it would mean parsing the response properly, but I'm not sure it is worth it for this case.

Re: Sieve gets in infinite loop

[Simon Josefsson]

Jason Rumney <jasonr@gnu.org> writes:

> Simon Josefsson wrote:
>> According to http://tools.ietf.org/html/draft-ietf-sieve-managesieve-09
>> the response line can contain an optional string:
>>
>>     response-nobye        = ("NO" / "BYE") [SP "(" resp-code ")"]
>>                             [SP string] CRLF
>>                             ;; The string contains human readable text
>>                             ;; encoded as UTF-8.
>>
>>   
> I guess you meant to paste the response-ok definition there, but they
> are basically the same.

Ah, right.

>> So how about
>>
>> -  (when (re-search-forward (concat "^OK" sieve-manage-server-eol) nil t)
>> +  (when (re-search-forward (concat "^OK.*" sieve-manage-server-eol) nil t)
>>
>> instead?  Not perfect, but hopefully would solve your problem and still
>> match EOL stuff.
>>   
>
> So the gnus developers are OK about ignoring this statement in section
> 1.3 of the RFC?

It's not an RFC yet.

>   The contents of the string SHOULD be shown to the user and
>   implementations MUST NOT attempt to parse the message for meaning.
>
> Following it would mean parsing the response properly, but I'm not
> sure it is worth it for this case.

Better patches are welcome.

/Simon