[Dovecot] sieve 0.1.14: vacation encodes Subject twice
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-- Roland Rosenfeld - Content Delivery - NED - Technik NetCologne Gesellschaft für Telekommunikation mbH - HRB 25580, AG Köln Am Coloneum 9 50829 Köln Tel.: +49-221-2222-373 Fax: +49-221-2222-7373 Geschäftsführer: Werner Hanf, Karl-Heinz Zankel
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
Christian Rohmann wrote:
Hey folks,
allow me to bump this notice about a possible plain bug in the sieve filter conversion.
Oh, sorry, this one got a bit backlogged.
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.
Yes, that seems to be the intended behavior.
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.
Timo and I first introduced header encoding in that last version. Before that, no attempt to encode the header was made at all.
Timo, are you going to change this in Dovecot or should I implement the non-ASCII-only check in Sieve?
Regards,
Stephan
On 7.1.2010, at 11.40, Stephan Bosch wrote:
Timo, are you going to change this in Dovecot or should I implement the non-ASCII-only check in Sieve?
I don't think my function should do such checks. It might be wanted in some situations that ASCII-only text gets encoded.
Timo Sirainen wrote:
On 7.1.2010, at 11.40, Stephan Bosch wrote:
Timo, are you going to change this in Dovecot or should I implement the non-ASCII-only check in Sieve?
I don't think my function should do such checks. It might be wanted in some situations that ASCII-only text gets encoded.
Ok, I'll give this one a look later today.
Regards,
Stephan.
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.
Fixed:
http://hg.rename-it.nl/dovecot-1.2-sieve/rev/219a6f0d6bf6
Regards,
Stephan.
On Fri, 08 Jan 2010, Stephan Bosch wrote:
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.
Fixed:
Great job, many thanks. Works now like a charm.
Tschoeeee
Roland-- Roland Rosenfeld - Content Delivery - NED - Technik NetCologne Gesellschaft für Telekommunikation mbH - HRB 25580, AG Köln Am Coloneum 9 50829 Köln Tel.: +49-221-2222-373 Fax: +49-221-2222-7373 Geschäftsführer: Werner Hanf, Karl-Heinz Zankel
participants (4)
-
Christian Rohmann
-
Roland Rosenfeld
-
Stephan Bosch
-
Timo Sirainen