Mailing List Archive

On Tue, May 05, 2020 at 12:51:36PM -0400, Rick Cooper wrote:
> We received a couple emails yesterday that barely got caught and when I
> looked at them they should have hit big time. As I looked it would appear
> the body parts are encoded quoted-printable utf-7. Apparently SA doesn't
> handle utf-7?
>
> I added $self->{'decoded'} = Encode::decode("UTF-7", $self->{'decoded'});
> just before the decoded body is returned in Node.pm and the body rules hit
> again including some quick tests I put together.
>
> Is ignoring utf-7 intentional or is this a new spammer tactic? The actual
> email messages are rendered perfectly through outlook and our webmail
> application.

If I remember right, normalize_charset 1 will handle this just fine.
Atleast in trunk/4.0.

In any case, UTF-7 mails can be blocked on sight, no one uses it
legimately..

Henrik K wrote:
> On Tue, May 05, 2020 at 12:51:36PM -0400, Rick Cooper wrote:
>> We received a couple emails yesterday that barely got caught and
>> when I looked at them they should have hit big time. As I looked it
>> would appear the body parts are encoded quoted-printable utf-7.
>> Apparently SA doesn't handle utf-7?
>>
>> I added $self->{'decoded'} = Encode::decode("UTF-7",
>> $self->{'decoded'}); just before the decoded body is returned in
>> Node.pm and the body rules hit again including some quick tests I
>> put together.
>>
>> Is ignoring utf-7 intentional or is this a new spammer tactic? The
>> actual email messages are rendered perfectly through outlook and our
>> webmail application.
>
> If I remember right, normalize_charset 1 will handle this just fine.
> Atleast in trunk/4.0.
>
> In any case, UTF-7 mails can be blocked on sight, no one uses it
> legimately..

Bingo, that does it, And yes I added a check for utf-7 to exim and add a
header that causes emails to be quarantined and marked so users cannot
releaseor view them on their own.

Thanks

Rick

On 5 May 2020, at 13:05, Henrik K wrote:

> In any case, UTF-7 mails can be blocked on sight, no one uses it
> legimately..

I wish that were true.

Apparently Evolution supports UTF-7 and can be set to use it with the
user being unaware of it. Last year I had an extended exchange with
someone who was in that situation and was sending mail with broken PGP
signatures as a result: the signatures were not getting encoded.

This was someone whose mail I encountered on 2 different mailing lists
dealing with email technical issues, so it wasn't just a random newbie
error.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Hi Rick

Will you be willing to share your Exim and SA rules / code?
So that the community can benefit from your finding and work.

Regards
Brent Clark

On 2020/05/05 20:00, Rick Cooper wrote:
> Henrik K wrote:
>> On Tue, May 05, 2020 at 12:51:36PM -0400, Rick Cooper wrote:
>>> We received a couple emails yesterday that barely got caught and
>>> when I looked at them they should have hit big time. As I looked it
>>> would appear the body parts are encoded quoted-printable utf-7.
>>> Apparently SA doesn't handle utf-7?
>>>
>>> I added $self->{'decoded'} = Encode::decode("UTF-7",
>>> $self->{'decoded'}); just before the decoded body is returned in
>>> Node.pm and the body rules hit again including some quick tests I
>>> put together.
>>>
>>> Is ignoring utf-7 intentional or is this a new spammer tactic? The
>>> actual email messages are rendered perfectly through outlook and our
>>> webmail application.
>>
>> If I remember right, normalize_charset 1 will handle this just fine.
>> Atleast in trunk/4.0.
>>
>> In any case, UTF-7 mails can be blocked on sight, no one uses it
>> legimately..
>
> Bingo, that does it, And yes I added a check for utf-7 to exim and add a
> header that causes emails to be quarantined and marked so users cannot
> releaseor view them on their own.
>
> Thanks
>
> Rick
>

Brent Clark wrote:
> Hi Rick
>
> Will you be willing to share your Exim and SA rules / code?
> So that the community can benefit from your finding and work.
>

Pretty standard exim acl
The DataWhitelisted portion is calculated from several other items so that
would be up to you if you even wanted to whitelist anything. The
AddSuspectHeader is a flag used in various parts of the delivery as is the
message that is added as a header as well. If the Suspicious headers is
added to an email the end user cannot release it from quarantine on their
own and the portion of the message they can see has been sanitized, disarmed
(html, scripting and links disarmed and obfuscated).

warn log_message = [DATA] FOUND UTF-7 CONTENT-TYPE :
${sg{$h_Content-Type:}{\N\n.*\N}{}}
condition = ${if !eq {yes}
{${lc:$acl_m_DataWhiteListed}}}
condition = ${if
def:h_Content-Type:}
condition = ${if
match{${lc:$h_Content-Type:}}{\Ntext\/html; charset=utf-7\N}}
set acl_c_AddSuspectHeader = yes
set acl_c_SuspectMsg =
${sg{$acl_c_SuspectMsg}{\NNONE(\s{0,}:)?\N}{}}:UTF-7 BODY HIDING SOMETHING


> Regards
> Brent Clark
>
> On 2020/05/05 20:00, Rick Cooper wrote:
>> Henrik K wrote:
>>> On Tue, May 05, 2020 at 12:51:36PM -0400, Rick Cooper wrote:
>>>> We received a couple emails yesterday that barely got caught and
>>>> when I looked at them they should have hit big time. As I looked it
>>>> would appear the body parts are encoded quoted-printable utf-7.
>>>> Apparently SA doesn't handle utf-7?
>>>>
>>>> I added $self->{'decoded'} = Encode::decode("UTF-7",
>>>> $self->{'decoded'}); just before the decoded body is returned in
>>>> Node.pm and the body rules hit again including some quick tests I
>>>> put together.
>>>>
>>>> Is ignoring utf-7 intentional or is this a new spammer tactic? The
>>>> actual email messages are rendered perfectly through outlook and
>>>> our webmail application.
>>>
>>> If I remember right, normalize_charset 1 will handle this just
>>> fine. Atleast in trunk/4.0.
>>>
>>> In any case, UTF-7 mails can be blocked on sight, no one uses it
>>> legimately..
>>
>> Bingo, that does it, And yes I added a check for utf-7 to exim and
>> add a header that causes emails to be quarantined and marked so
>> users cannot releaseor view them on their own.
>>
>> Thanks
>>
>> Rick

Thanks so much Rick

Much appreciated.

Regards
Brent Clark

On 2020/05/07 19:41, Rick Cooper wrote:
> Brent Clark wrote:
>> Hi Rick
>>
>> Will you be willing to share your Exim and SA rules / code?
>> So that the community can benefit from your finding and work.
>>
>
> Pretty standard exim acl
> The DataWhitelisted portion is calculated from several other items so that
> would be up to you if you even wanted to whitelist anything. The
> AddSuspectHeader is a flag used in various parts of the delivery as is the
> message that is added as a header as well. If the Suspicious headers is
> added to an email the end user cannot release it from quarantine on their
> own and the portion of the message they can see has been sanitized, disarmed
> (html, scripting and links disarmed and obfuscated).
>
> warn log_message = [DATA] FOUND UTF-7 CONTENT-TYPE :
> ${sg{$h_Content-Type:}{\N\n.*\N}{}}
> condition = ${if !eq {yes}
> {${lc:$acl_m_DataWhiteListed}}}
> condition = ${if
> def:h_Content-Type:}
> condition = ${if
> match{${lc:$h_Content-Type:}}{\Ntext\/html; charset=utf-7\N}}
> set acl_c_AddSuspectHeader = yes
> set acl_c_SuspectMsg =
> ${sg{$acl_c_SuspectMsg}{\NNONE(\s{0,}:)?\N}{}}:UTF-7 BODY HIDING SOMETHING
>
>
>> Regards
>> Brent Clark
>>
>> On 2020/05/05 20:00, Rick Cooper wrote:
>>> Henrik K wrote:
>>>> On Tue, May 05, 2020 at 12:51:36PM -0400, Rick Cooper wrote:
>>>>> We received a couple emails yesterday that barely got caught and
>>>>> when I looked at them they should have hit big time. As I looked it
>>>>> would appear the body parts are encoded quoted-printable utf-7.
>>>>> Apparently SA doesn't handle utf-7?
>>>>>
>>>>> I added $self->{'decoded'} = Encode::decode("UTF-7",
>>>>> $self->{'decoded'}); just before the decoded body is returned in
>>>>> Node.pm and the body rules hit again including some quick tests I
>>>>> put together.
>>>>>
>>>>> Is ignoring utf-7 intentional or is this a new spammer tactic? The
>>>>> actual email messages are rendered perfectly through outlook and
>>>>> our webmail application.
>>>>
>>>> If I remember right, normalize_charset 1 will handle this just
>>>> fine. Atleast in trunk/4.0.
>>>>
>>>> In any case, UTF-7 mails can be blocked on sight, no one uses it
>>>> legimately..
>>>
>>> Bingo, that does it, And yes I added a check for utf-7 to exim and
>>> add a header that causes emails to be quarantined and marked so
>>> users cannot releaseor view them on their own.
>>>
>>> Thanks
>>>
>>> Rick
>

On 5 May 2020, Bill Cole outgrape:

> Apparently Evolution supports UTF-7 and can be set to use it with the
> user being unaware of it.

Probably user error -- UTF-7 is right below UTF-8 in the list of
encodings supported by the composer, so it's easy to aim for UTF-8, hit
UTF-7 and whoops...

On 12 Jun 2020, at 08:01, Nix <nix@esperi.org.uk> wrote:
> On 5 May 2020, Bill Cole outgrape:
>> Apparently Evolution supports UTF-7 and can be set to use it with the user being unaware of it.
>
> Probably user error -- UTF-7 is right below UTF-8 in the list of encodings supported by the composer, so it's easy to aim for UTF-8, hit UTF-7 and whoops…

I don’t use Evolution, but I have heard complaints of it “falling back” to UTF-7 instead of UTF-8 in some cases.

The solution seems to be to make sure it is set specifically to UTF-8 and not to something like LATIN-1.

On Fri, 12 Jun 2020 15:01:11 +0100
Nix wrote:

> On 5 May 2020, Bill Cole outgrape:
>
> > Apparently Evolution supports UTF-7 and can be set to use it with
> > the user being unaware of it.
>
> Probably user error -- UTF-7 is right below UTF-8 in the list of
> encodings supported by the composer, so it's easy to aim for UTF-8,
> hit UTF-7 and whoops...

Personally I don't think it matters much as far as SpamAssassin is
concerned. I've never received a legitimate email in UTF-7, if I saw it
in spam I'd be happy to give it a hefty score.

If it turns out that Evolution has a particularly problem it can be
excluded easily enough with:

User-Agent =~ /^Evolution\b/