Hey folks,
allow me to bump this notice about a possible plain bug in the sieve filter conversion.
Regards
Christian
On 12/30/2009 01:37 PM, Roland Rosenfeld wrote:
Hi!
I noticed the following problem in dovecot-1.2-sieve-0.1.14: The following vacation causes trouble with the Subject line:
if not exists ["List-Id", "List-Post"] { vacation :days 7 :addresses ["test@netcologne.de"] :subject "=?utf-8?b?w4TDlsOc?= sadasd" "Bin gerade nicht hier."; }
As you can see, the Subject is already MIME encoded according to RFC2047.
Starting with sieve 0.1.14 the subject is now encoded by sieve again, so I get the following in my vacation mail:
Subject: =?utf-8?q?=3D=3Futf-8=3Fb=3Fw4TDlsOc=3F=3D?= sadasd
As you can see, the RFC2047 encoding is RFC2047 encoded, which results in an unreadable subject.
According to RFC5230 section 4.3 this shouldn't happen:
The ":subject" parameter specifies a subject line to attach to any vacation response that is generated. UTF-8 characters can be used in the string argument; implementations MUST convert the string to [RFC2047] encoded words if and only if non-ASCII characters are present. Implementations MUST generate an appropriate default subject line as specified below if no :subject parameter is specified.
If I understand this right, sieve should do the RFC2047 encoding only if the string is non-ASCII. But the RFC2047 encoded string is already ASCII, so it should not be encoded a second time.
I just compared this with sieve 0.1.13, which behaves different: It does not encode the Subject header at all. As long as the managesieve client (in our situation Horde/IMP) encodes the subject, everything works correct, while we run into trouble with 0.1.14.
I think that there needs to some mechanism in sieve that checks whether the subject contains non-ASCII and does the encoding only in this case.
I just checked out, that 0.1.14 does not encode a non RFC2047 encoded 7bit subject, while a 7bit subject starting with =?utf-8?... is encoded twice.
Tschoeeee
Roland