SIEVE: handling of lineending in fields

[Ingo Thierack]

On 25.07.2017 13:54, Stephan Bosch wrote:
>
>
> Op 22-7-2017 om 18:02 schreef Ingo Thierack:
>> Hello,
>>
>> migrated von the mailserver from centos to alpine linux. Most parts are
>> run well.
>>
>> dovecot 2.2.31
>> sieve: 0.4.19
>>
>> But i fight with on behavior.
>>
>> I have an sieve script which pipes a few fields to an external script
>> which send this data to an telegram-bot.
>>
>> the part of the sieve-script.
>>
>> if header :matches "Subject" "*" {
>>      set "subject" "${1}";
>> }
>> if header :matches "from" "*" {
>>      set "from" "${1}";
>> }
>> if header :matches "to" "*" {
>>      set "to" "${1}";
>> }
>>
>> foreverypart
>> {
>>      if header :mime :type :is "Content-Type" "text"
>>      {
>>           extracttext :first 30 "msgcontent";
>>           break;
>>      }
>> }
>>
>> pipe :copy :try "notify.sh" [ "", "(${from})#${to}#${subject}",
>> "\"${msgcontent}\"" ];
>>
>> What i get now is an error about looks like encoding of the linefeeds.
>>
>> default: line 107: error: specified :args item `"test 4??"' is invalid.
>>
>> Here is sent a mail which contains in subject "test 4".
>>
>> or
>> default: line 107: error: specified :args item `"?? ?? ??? ??? Oracle
>> Magazine "' is invalid.
>>
>> Here is sent a mail which contains in subject "test 4".
>>
>> On centos this was never an problem. With alpine-linux this process is
>> complete broken.
>>
>> Any hints, where to look and maybee fix thie behavior? Mybe its ab
>> problem with the libmusl which used in alpine.
>
> This is nothing new:
>
> https://github.com/dovecot/pigeonhole/blob/master/doc/rfc/spec-bosch-sieve-extprograms.txt#L149
>
> https://github.com/dovecot/pigeonhole/blob/master/src/plugins/sieve-extprograms/sieve-extprograms-common.c#L191
> (code is at least 4 years old)
>
> I could add an option to allow newlines, but I am not sure that is a
> good idea per se.
>
> Regards,
>
> Stephan.

What kind of problems are expected, if CR and LF are allowed? Maybe
there are other control chars which are also problematic. Think every
char below 0x20 could be. Should not be in a normal mail, but who knows....

As of now, I have the code part, I'll try to create for my
installation/package a patch, which allows CR/LF, or if i see here an
problem replace it by an space.

So no general change necessary i think.


Regards,

Ingo




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20170725/87a21ee1/attachment.sig>