On Mon, 3 Dec 2018 21:15:20 -0700
Grant Taylor wrote:
> As far as I know, (other than LONG deprecated source routing) the @
> character is a reserved special character and can't be used used as
> part of the local part.
Syntactically, it can be used as long as it's properly quoted or
escaped.
No longer just embedded =9D characters.
From: =?utf-8?B?bmlnaHRt0LByZQ==?=
To:
Subject: You are my victim.
Date: Tue, 4 Dec 2018 15:56:36 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="a0d0993ce53319101c19af03d5311b0976b26b"
X-Scanned-By: MIMEDefang 2.79 on
FYI, I have just seen email from an O 365 system with no "To:" header. "To"
has not been a required header for a long time, but still I was not aware
of any legitimate software that sends without it. Use of an empty list like
"To: Undisclosed recipients:;" must be a lost art.
This might affect
The __UNICODE_OBFU_ZW rule is not being triggered on this email. Maybe
it needs updating? - Mark
On 12/5/2018 11:19 AM, Mark London wrote:
No longer just embedded =9D characters.
From: =?utf-8?B?bmlnaHRt0LByZQ==?=
To:
Subject: You are my victim.
Date: Tue, 4 Dec 2018 15:56:36 -0800
On 12/05/2018 02:45 PM, John Hardin wrote:
I've added a "too many [ascii][unicode][ascii]" rule based on that but I
suspect it will be pretty FP-prone and will be pretty large if we want
to avoid whack-a-mole syndrome. For this, normalize + bayes is probably
the best bet.
Is it possible to
On 12/05/2018 03:27 PM, John Hardin wrote:
Take a look at replace_rules in the repo (both standard and sandboxes).
Thank you for the reference. replace_rules look very intriguing.
Link - Mail::SpamAssassin::Plugin::ReplaceTags - tags for SpamAssassin rules
-
On Wed, 5 Dec 2018, Bill Cole wrote:
On 5 Dec 2018, at 16:45, John Hardin wrote:
Those aren't zero-width, those are just standard Unicode obfuscations of
regular ASCII text.
Not precisely. In this case they seem to all be Cyrillic characters which
happen to look like Latin characters that
On Wed, 5 Dec 2018, Grant Taylor wrote:
On 12/05/2018 02:45 PM, John Hardin wrote:
I've added a "too many [ascii][unicode][ascii]" rule based on that but I
suspect it will be pretty FP-prone and will be pretty large if we want to
avoid whack-a-mole syndrome. For this, normalize + bayes is
On 5 Dec 2018, at 16:45, John Hardin wrote:
Those aren't zero-width, those are just standard Unicode obfuscations
of regular ASCII text.
Not precisely. In this case they seem to all be Cyrillic characters
which happen to look like Latin characters that have ASCII encodings.
It's not
On Wed, 5 Dec 2018, Mark London wrote:
No longer just embedded =9D characters.
From: =?utf-8?B?bmlnaHRt0LByZQ==?=
To:
Subject: You are my victim.
Date: Tue, 4 Dec 2018 15:56:36 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="a0d0993ce53319101c19af03d5311b0976b26b"
On 12/5/2018 4:50 PM, Grant Taylor wrote:
> On 12/05/2018 02:45 PM, John Hardin wrote:
>> I've added a "too many [ascii][unicode][ascii]" rule based on that
>> but I suspect it will be pretty FP-prone and will be pretty large if
>> we want to avoid whack-a-mole syndrome. For this, normalize +
On Wed, 5 Dec 2018, Grant Taylor wrote:
On 12/05/2018 03:27 PM, John Hardin wrote:
Take a look at replace_rules in the repo (both standard and sandboxes).
Thank you for the reference. replace_rules look very intriguing.
Link - Mail::SpamAssassin::Plugin::ReplaceTags - tags for SpamAssassin
On 12/5/18 5:43 PM, John Hardin wrote:
Potentially, but it's hard to use something like that in regular rule
REs. That sort of smarts would probably need to be in a plugin.
Maybe (from my naive point of view) if not probably (from your more
experienced point of view).
I would think that it
On 12/5/18 7:55 PM, Bill Cole wrote:
Yes. There is no automatic 'shortcircuiting' of rules.
Okay.
You say "automatic". Is there a "non-automatic" way? :-)
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
On 5 Dec 2018, at 20:37, Grant Taylor wrote:
> On 12/5/18 5:43 PM, John Hardin wrote:
>> Potentially, but it's hard to use something like that in regular rule REs.
>> That sort of smarts would probably need to be in a plugin.
>
> Maybe (from my naive point of view) if not probably (from your
On 5 Dec 2018, at 22:29, Grant Taylor wrote:
> On 12/5/18 7:55 PM, Bill Cole wrote:
>> Yes. There is no automatic 'shortcircuiting' of rules.
>
> Okay.
>
> You say "automatic". Is there a "non-automatic" way? :-)
perldoc Mail::SpamAssassin::Plugin::Shortcircuit
--
Bill Cole
signature.asc
On 5 Dec 2018, at 11:45, Mark London wrote:
The __UNICODE_OBFU_ZW rule is not being triggered on this email. Maybe
it needs updating? - Mark
FWIW, I just added a "MIXED_ES" rule to my sandbox which does catch on
anything with a suspiciously large number of characters that are
visually like
On 12/05/2018 06:17 AM, RW wrote:
Syntactically, it can be used as long as it's properly quoted or
escaped. The use of such addresses is discouraged under SMTP, but only
with a "SHOULD NOT".
I wonder how many user interfaces will balk at the (Source) Route
Addressing. I mean, if they can't
On Wed, 5 Dec 2018, Mark London wrote:
The __UNICODE_OBFU_ZW rule is not being triggered on this email. Maybe it
needs updating? - Mark
Will do, I don't have a zero response time as much as I wish I did... :)
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
19 matches
Mail list logo
