On 12/31/2010 12:25 PM, Thomas Leuxner wrote:
> I have a global sieve rule in place to filter mailing-lists. This has
> worked well so far. Recently however one subscriber on a list seems
> to create strange character set encodings in the 'From' and 'To'
> headers. This leads to unprocessed/unfiltered mails (no errors
> thrown). Is this a configuration or Pigeonhole issue (latest HG
> used)?
>
I executed the following to investigate this issue:
###
sieve-test -t - -Tlevel=matching ~/frop.sieve ~/frop.eml
## Started executing script 'frop'
3: address test
3: starting `:is' match with `i;ascii-casemap' comparator:
3: extracting `To' headers from message
3: parsing address header value `""[email protected]""
<[email protected]>'
3: extracting `all' part from non-address value
`""[email protected]"" <[email protected]>'
3: matching value `""[email protected]""
<[email protected]>'
3: with key `[email protected]' => 0
3: with key `[email protected]' => 0
3: with key `[email protected]' => 0
3: extracting `CC' headers from message
3: finishing match with result: not matched
3: jump if result is false
3: jumping to line 5
## Finished executing script 'frop'
Performed actions:
(none)
Implicit keep:
* store message in folder: INBOX
sieve-test(stephan): Info: final result: success
###
Apparently, the MIME-encoded part of those address headers includes
double quotes, duplicating the ones surrounding the encoded part
already. As can be seen from the above trace, this decodes into an
invalid address representation, causing Pigeonhole to handle it as
opaque text.
If those quotes are really supposed to be part of the 'phrase' part of
the e-mail address, I think those should have been escaped somehow. I
don't think that encoding can be an alternative for that. Timo, any
thoughts?
Regards,
Stephan.
