On Fri, 09 Oct 2015 14:22:18 +0200
Mark Martinec wrote:
> The problem with this message is that it declares encoding
> as UTF-16, i.e. not explicitly stating endianness like
> UTF-16BE or UTF-16LE, and there is no BOM mark at the
> beginning of each textual part, so endianness cannot be
> determi
On Fri, 9 Oct 2015, AK wrote:
On 20/09/15 03:07, Dave Funk wrote:
Notes:
1) Due to SA pre-processing collapsing body into one long line, cannot
match on '^' repeatedly, need to look for '\n' as line break indicator.
Find start of a line and then following repeats of ".\n"
Dave,
I've bee
On 10/9/2015 12:07 AM, AK wrote:
On 20/09/15 03:07, Dave Funk wrote:
Notes:
1) Due to SA pre-processing collapsing body into one long line,
cannot match on '^' repeatedly, need to look for '\n' as line break
indicator.
Find start of a line and then following repeats of ".\n"
Dave,
I've be
On Fri, 9 Oct 2015 14:47:53 +0200
Reindl Harald wrote:
> > In the provided message the actual endianness is LE, and
> > BOM is missing, so decoding as UTF-16BE fails and the
> > rule does not hit. Garbage-in, garbage-out.
> >
> > If you manually edit the sample and replace UTF-16
> > with UTF-16L
Am 09.10.2015 um 14:22 schrieb Mark Martinec:
Reindl Harald wrote:
no custom body rules hit like they do for ISO/UTF8 :-(
What is your normalize_charsets setting?
enabled, that's what i meant with "like they do for ISO/UTF8" and
adding "dear potencial partner" to CUST_BODY_17 did not chang
Reindl Harald wrote:
no custom body rules hit like they do for ISO/UTF8 :-(
What is your normalize_charsets setting?
enabled, that's what i meant with "like they do for ISO/UTF8" and
adding "dear potencial partner" to CUST_BODY_17 did not change the
score
see attached sample and rule below
Am 09.10.2015 um 08:10 schrieb John Wilcock:
Le 08/10/2015 17:34, Reindl Harald a écrit :
Content-Type: text/plain; charset=utf-16
Content-Transfer-Encoding: base64
no custom body rules hit like they do for ISO/UTF8 :-(
What is your normalize_charsets setting?
enabled, that's what i meant
