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
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
Hi,
I’ve recently gotten emails (a lot of them, as it happened) with the following
subject line:
Subject: H¡gh level of r¡sk. Your account has been hacked. Change yøur passwørd.
and I’ve seen other similar emails in the past using simple mechanical
substitutions (Greek alpha for ‘a’, Cyrillic
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
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->{'de
You can move the md5 generation into the SQL server. Of course,
you'd want to be mindful of the communications channel between
SpamAssassin and the SQL server.
I was thinking that the database/whatever would be populated by feeding
in lists of dsto=len passwords, since they seem to be more or l
