> On Jan 4, 2020, at 11:57 AM, Bill Cole
> wrote:
>
> On 3 Jan 2020, at 17:45, Philip Prindeville wrote:
> [...]
>
>> One other question that occurs to me: why would we even need > http-equiv=“Content-Type” …> if we already have a Content-Type: header?
>
> There should be no need.
>
> With
Lyle Evans wrote:
Expect to see a lot more of these due to
https://github.com/0x4447/0x4447_product_s3_email/blob/master/README.md
That looks more like Doing It Right(TM), by way of using Amazon's
outbound relay hosts.
Doing It Wrong(TM) is sending direct-to-MX from your VPS without
overrid
On 1/3/2020 11:02 AM, Kris Deugau wrote:
Philip Prindeville wrote:
I’m getting the following Spam.
http://www.redfish-solutions.com/misc/bluechew.eml
Received: from phylobago.mysecuritycamera.org
(ec2-34-210-5-63.us-west-2.compute.amazonaws.com [34.210.5.63])
I have a local rule adding a c
On 3 Jan 2020, at 8:02, Kris Deugau wrote:
I have a local rule adding a couple of points for anything coming
direct-to-MX from any Amazon compute node, period.
⋮
Reality has intruded and there are in fact static IP assignments in
the .compute.amazonaws.com tree (as well as ISP customers of our
On Sat, 4 Jan 2020 11:06:41 -0800 (PST)
John Hardin wrote:
> >>> Seems to work either way!
> >>
> >> Either should match, but without the /m it should only match once.
> >>
> >> I just tried it and
> >>
> >> meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
> >>
> >> doesn't work without t
On Sat, 4 Jan 2020, John Hardin wrote:
On Fri, 3 Jan 2020, RW wrote:
On Fri, 3 Jan 2020 15:29:40 -0700
Philip Prindeville wrote:
On Jan 3, 2020, at 11:34 AM, RW wrote:
On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:
Try this instead, to actually match the header(s):
header
On Fri, 3 Jan 2020, RW wrote:
On Fri, 3 Jan 2020 15:29:40 -0700
Philip Prindeville wrote:
On Jan 3, 2020, at 11:34 AM, RW wrote:
On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:
Try this instead, to actually match the header(s):
header __L_RECEIVED_SPF Received-SPF =~ /
On 3 Jan 2020, at 17:45, Philip Prindeville wrote:
[...]
One other question that occurs to me: why would we even need http-equiv=“Content-Type” …> if we already have a Content-Type:
header?
There should be no need.
With that said, it could be *helpful* if a MUA were to save out the
text/html
On Fri, 3 Jan 2020, Philip Prindeville wrote:
On Jan 3, 2020, at 11:34 AM, RW wrote:
On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:
On Fri, 3 Jan 2020, Pedro David Marco wrote:
header __L_RECEIVED_SPFexists:Received-SPF
tflags __L_RECEIVED_SPFmultiple maxhits
On Fri, 3 Jan 2020 16:21:21 -0700
Philip Prindeville wrote:
> rawbody __L_UNNEEDED_META_CT /^ /m
>
> meta T_BLOCK_MISC47 __L_UNNEEDED_META_CT
> describe T_BLOCK_MISC47 Why do this when a
> Content-Type: header works? score T_BLOCK_MISC47 20.0
>
> And that se
On Fri, 3 Jan 2020 15:29:40 -0700
Philip Prindeville wrote:
> > On Jan 3, 2020, at 11:34 AM, RW wrote:
> >
> > On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
> > John Hardin wrote:
> >> Try this instead, to actually match the header(s):
> >>
> >> header __L_RECEIVED_SPF Received-SPF =~ /^./
> On Jan 3, 2020, at 3:45 PM, Philip Prindeville
> wrote:
>
>
>
>> On Jan 2, 2020, at 4:08 PM, Philip Prindeville
>> wrote:
>>
>> I’m getting the following Spam.
>>
>> http://www.redfish-solutions.com/misc/bluechew.eml
>>
>> And this is notable for having:
>>
>>
>>
>> GUID1
>> GUID2
> On Jan 2, 2020, at 4:08 PM, Philip Prindeville
> wrote:
>
> I’m getting the following Spam.
>
> http://www.redfish-solutions.com/misc/bluechew.eml
>
> And this is notable for having:
>
>
>
> GUID1
> GUID2
> GUID3
> GUID4
> …
>
One other question that occurs to me: why would we even n
> On Jan 3, 2020, at 11:34 AM, RW wrote:
>
> On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
> John Hardin wrote:
>
>> On Fri, 3 Jan 2020, Pedro David Marco wrote:
>>
>>> header __L_RECEIVED_SPFexists:Received-SPF
>>> tflags __L_RECEIVED_SPFmultiple maxhits=20
>>>
>>> meta L_RECEIVE
On Fri, 3 Jan 2020 10:09:21 -0800 (PST)
John Hardin wrote:
> On Fri, 3 Jan 2020, Pedro David Marco wrote:
>
> > header __L_RECEIVED_SPF exists:Received-SPF
> > tflags __L_RECEIVED_SPF multiple maxhits=20
> >
> > meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
> > describe L_
On Fri, 3 Jan 2020, Pedro David Marco wrote:
header __L_RECEIVED_SPF exists:Received-SPF
tflags __L_RECEIVED_SPF multiple maxhits=20
meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)
describe L_RECEIVED_SPF Crazy numbers of Received-SFP headers
score L_RECEIVED_SPF
Hi Philipe...
try this:
full __L_RECEIVED_SPF /^Received-SPF: \w/mtflags __L_RECEIVED_SPF
multiple maxhits=11
meta L_RECEIVED_SPF (__L_RECEIVED_SPF >= 10)describe L_RECEIVED_SPF
Crazy numbers of Received-SFP headersscore L_RECEIVED_SPF 4
-Pedro.
Philip Prindeville wrote:
I’m getting the following Spam.
http://www.redfish-solutions.com/misc/bluechew.eml
Received: from phylobago.mysecuritycamera.org
(ec2-34-210-5-63.us-west-2.compute.amazonaws.com [34.210.5.63])
I have a local rule adding a couple of points for anything coming
direc
On Thu, 2020-01-02 at 16:08 -0700, Philip Prindeville wrote:
> I’m getting the following Spam.
>
> http://www.redfish-solutions.com/misc/bluechew.eml
>
> And this is notable for having:
>
>
>
> GUID1
> GUID2
> GUID3
> GUID4
> …
>
I've also been getting a number of these, and someone else on
I’m getting the following Spam.
http://www.redfish-solutions.com/misc/bluechew.eml
And this is notable for having:
GUID1
GUID2
GUID3
GUID4
…
so it should be easy enough to detect.
A GUID looks like:
[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{3}-[0-9a-f]{3}-[0-9a-f]{12}
The 2nd type of Spam I’m seei
20 matches
Mail list logo
