[Dovecot] Sieve and locale (Japanese), string length

[Stephan Bosch]

Jorgen Lundman wrote:
> 
> Damn I apologise for the noise now, but I did manage to run into one 
> problem:
> 
> Subject: 日本語らららららららららららららららららららららららららららら 
> らららら ららららららららららららららららららららら
> 
> Subject: 
> =?UTF-8?B?5pel5pys6Kqe44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ?=
>  =?UTF-8?B?44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ?= 

>  =?UTF-8?B?44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ?=  
>  =?UTF-8?B?44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ44KJ?=
[...]
> 
> So it seems the longest word test is 16 UTF8 chars (or 48 bytes?). So as 
> long as we use small words, it should be ok.
> 
> Out of curiousity, can we increase this limit?
Well, this looks very much like a bug to me. And, conveniently, it does 
not look like a bug in Sieve :o). By adding a small debug line i found 
that the Dovecot function mail_get_headers_utf8() returns the following 
for the above string:

日本語ららららららららららら らららららららららららららららら ららららら 
ららららららららららら らららららららららら

Note the additional spaces between the characters. This is due to the 75 
character limit for RFC2822 header lines, meaning that (as seen above) 
the RFC2047 encoding is broken into multiple parts.

Timo: As far as I understand RFC2047, the (<CRLF>)<SPC> sequence between 
the RFC2047 encoded words is not supposed to be added as a space. I 
admit that it is not a very well-specified RFC. The examples mention 
something about encoding space inside the encoded words if a joining 
space is required.

Regards,

Stephan