> 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
On 6/1/2017 7:31 PM, John Hardin wrote:
Interesting. I wonder how that affects RFC-2822 (et. al.) headers, and
specifically, the X-Spam-* headers that SA emits?
RFC 6648 is a best practice and "deprecates the convention for newly
defined parameters with textual (as opposed to numerical) names
Ignore them. Focus on RFC compliant headers and reject anything that fails.
Sent from ProtonMail Mobile
On Thu, Jun 1, 2017 at 12:14 AM, Loren Wilton wrote: I
see I have received several new spam messages today from what looks (to
me) like a new tool. Admittedly these three were all caught as
On Thu, 1 Jun 2017, A. Schulze wrote:
John Hardin:
any header that begins with "X-" is permitted.
permitted - yes
but I'm aware may user assisiate X- header still as private header.
This is no longer true since 2012: https://tools.ietf.org/html/rfc6648
just to mention that...
Andreas
In
On Thu, 1 Jun 2017, Loren Wilton wrote:
Hopeless-Forming-Philistinizes: jobs
Lossy-Cabdriver: 2368db81dcf1
Alba-Leanness-Elections: 38376DB11A
Merrimac-Grams-Participating: B354488539E
Giving-Remarkably-Incriminate: drawl
Dustin-Ransoming: 18
Person-Decathlon-Arnold: dfcfce7ba985
Majori
Nice to see you're around Loren.
Been a looong time since we did stuff like
headerSARE_MSGID_RATWARE2 MESSAGEID =~
/\<\d{10,15}\.\d{18,40}\@[a-z]+\>/ # no /i!
describe SARE_MSGID_RATWARE2 Message-Id is
score SARE_MSGID_RATWARE2 0.639
#hist SARE_MSGI
On 1 Jun 2017, at 8:28, Loren Wilton wrote:
If he is intending to hide tracking info in the headers, it seems
pointless unless he is also writing an MTA of some sort that will see
the headers. But maybe he didn't think that far, and it was his intent
to hide tracking info. Still, it seems a li
If I were to guess, adding such headers is done to confuse tools that
compute hashes based on headers or use bayes filtering on the entire
mail, since it adds innocent words to the mail without showing them
to most end-users.
It doesn't confuse either Bayes or any hash I'm aware of.
Just as a
On Thu, 1 Jun 2017 01:59:44 +0200 (CEST)
Kim Roar Foldøy Hauge wrote:
> If I were to guess, adding such headers is done to confuse tools that
> compute hashes based on headers or use bayes filtering on the entire
> mail, since it adds innocent words to the mail without showing them
> to most end-
John Hardin:
any header that begins with "X-" is permitted.
permitted - yes
but I'm aware may user assisiate X- header still as private header.
This is no longer true since 2012: https://tools.ietf.org/html/rfc6648
just to mention that...
Andreas
Hopeless-Forming-Philistinizes: jobs
Lossy-Cabdriver: 2368db81dcf1
Alba-Leanness-Elections: 38376DB11A
Merrimac-Grams-Participating: B354488539E
Giving-Remarkably-Incriminate: drawl
Dustin-Ransoming: 18
Person-Decathlon-Arnold: dfcfce7ba985
Majority-Gambles: 4f856
Buttock-Milky-Dogged: 8E626A
Kim Roar Foldøy Hauge skrev den 2017-06-01 01:59:
If I were to guess, adding such headers is done to confuse tools that
compute hashes based on headers or use bayes filtering on the entire
mail, since it adds innocent words to the mail without showing them to
most end-users.
bayes plugin:
#
On 2017-05-31 16:59, Kim Roar Foldøy Hauge wrote:
On Wed, 31 May 2017, John Hardin wrote:
On Thu, 1 Jun 2017, Benny Pedersen wrote:
John Hardin skrev den 2017-06-01 00:29:
> That sort of thing has happened before, and there are rules to *try*
> to catch nonsense headers in my sandbox,
On Wed, 31 May 2017, John Hardin wrote:
On Thu, 1 Jun 2017, Benny Pedersen wrote:
John Hardin skrev den 2017-06-01 00:29:
> That sort of thing has happened before, and there are rules to *try*
> to catch nonsense headers in my sandbox, but IIRC they never worked
> well enough in massch
On Thu, 1 Jun 2017, Benny Pedersen wrote:
John Hardin skrev den 2017-06-01 00:29:
That sort of thing has happened before, and there are rules to *try*
to catch nonsense headers in my sandbox, but IIRC they never worked
well enough in masscheck to actually get published.
would it be possib
John Hardin skrev den 2017-06-01 00:29:
That sort of thing has happened before, and there are rules to *try*
to catch nonsense headers in my sandbox, but IIRC they never worked
well enough in masscheck to actually get published.
would it be possible to make list of non nonsense headers, and co
On Wed, 31 May 2017, Loren Wilton wrote:
I see I have received several new spam messages today from what looks (to me)
like a new tool. Admittedly these three were all caught as spam, but some of
them were close and went over the edge on some local rules I have. The new
tool is putting
I see I have received several new spam messages today from what looks (to
me) like a new tool. Admittedly these three were all caught as spam, but
some of them were close and went over the edge on some local rules I have.
The new tool is putting absolutely absurd random headers in the spam
On November 9, 2014 2:12:16 AM John Hardin wrote:
Yep. .sig flamewar. Sigh.
Thats why i use no sig at all, please dont copy me :)
On Nov 8, 2014, at 5:54 PM, Reindl Harald wrote:
> Am 09.11.2014 um 01:48 schrieb Dave Pooser:
>> On 11/8/14, 5:57 PM, "Reindl Harald" wrote:
>>
>>> what is that garbage worth for?
>>
>> It's from a book by Terry Pratchett. Are we really so hard up for things to
>> talk about that we're going
On Sun, 9 Nov 2014, Reindl Harald wrote:
Am 09.11.2014 um 01:48 schrieb Dave Pooser:
On 11/8/14, 5:57 PM, "Reindl Harald" wrote:
> what is that garbage worth for?
It's from a book by Terry Pratchett. Are we really so hard up for things
to talk about that we're going to have a .sig flamew
Am 09.11.2014 um 01:48 schrieb Dave Pooser:
On 11/8/14, 5:57 PM, "Reindl Harald" wrote:
what is that garbage worth for?
It's from a book by Terry Pratchett. Are we really so hard up for things
to talk about that we're going to have a .sig flamewar now?
it's not a matter of "hard"
it's a m
On 11/8/14, 5:57 PM, "Reindl Harald" wrote:
>what is that garbage worth for?
It's from a book by Terry Pratchett. Are we really so hard up for things
to talk about that we're going to have a .sig flamewar now?
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
Programming: The profession of pr
Am 09.11.2014 um 00:51 schrieb LuKreme:
On Nov 7, 2014, at 10:03 AM, Benny Pedersen wrote:
What mua clients shows invalid mimetypes ?
Most all of them
"thank you" for your "fortune footer" in the name of everybody trying to
train ham messages for bayes..
what is that garbage worth
On Nov 7, 2014, at 10:03 AM, Benny Pedersen wrote:
>
> What mua clients shows invalid mimetypes ?
Most all of them.
--
He'd never asked for an exciting life. What he really liked, what he
sought on every occasion, was boredom. The trouble was that boredom
tended to explode in your face. Just w
On November 7, 2014 6:06:40 PM "David F. Skoll" wrote:
> What mua clients shows invalid mimetypes ?
Microsoft, thank you... if the attachment name ends in ".htm" or ".html" it
is treated as HTML regardless of MIME type.
Microsoft could fix this in a monthly bugfix update for dangerous softwar
On Fri, 07 Nov 2014 18:03:32 +0100
Benny Pedersen wrote:
> What mua clients shows invalid mimetypes ?
Microsoft, thank you... if the attachment name ends in ".htm" or ".html" it
is treated as HTML regardless of MIME type.
Actually, most MUAs do this. There are an unbelievable number of MIME
ge
On November 7, 2014 5:41:30 PM "David F. Skoll" wrote:
I've seen a couple of hundred phishing emails come in that all had an
attachment of type "application/html" which is (of course) bogus.
What mua clients shows invalid mimetypes ?
On 11/07/2014 05:41 PM, David F. Skoll wrote:
Hi,
I've seen a couple of hundred phishing emails come in that all had an
attachment of type "application/html" which is (of course) bogus.
I've put in a rule to block these and will see how it goes.
I've put an example up at http://pastebin.com/M3d
Hi,
I've seen a couple of hundred phishing emails come in that all had an
attachment of type "application/html" which is (of course) bogus.
I've put in a rule to block these and will see how it goes.
I've put an example up at http://pastebin.com/M3dRp4dD
with only slight editing to hide the actua
On Mon, 12 Aug 2013, Kris Deugau wrote:
Amir 'CG' Caspi wrote:
My main feeling is that if anyone is
sending HTML email with LOTS of stuff commented out, that email is
almost certainly spam. Ham HTML email would probably be done with more
care.
*snigger* Take a look at the raw source from a
Amir 'CG' Caspi wrote:
> My main feeling is that if anyone is
> sending HTML email with LOTS of stuff commented out, that email is
> almost certainly spam. Ham HTML email would probably be done with more
> care.
*snigger* Take a look at the raw source from a message sent with
Outlook (especiall
At 8:23 PM -0700 08/11/2013, John Hardin wrote:
However, I may be taking too-conservative a stance here. It's
possible that, while HTML comments can appear in ham, *long* HTML
comments won't, and the fact that we're looking for long blocks of
comment text is enough safety.
That's why feeling.
On Sun, 11 Aug 2013, Amir 'CG' Caspi wrote:
At 7:20 PM -0700 08/11/2013, John Hardin wrote:
Yuck. Can you pastbin spamples, if you still have them?
Here's one that comes to mind:
http://pastebin.com/zVEH2h02
That's going to be problematic as the comment isn't gibberish, it's a
bunch of pr
At 7:20 PM -0700 08/11/2013, John Hardin wrote:
The unbounded matches you're using probably caused the RE engine to
get stuck backing off and retrying.
That's what I figured. That's why I changed things to the current
version, which is "bounded" by the end-tag of the comment. My
current ver
On Sun, 11 Aug 2013, Amir 'CG' Caspi wrote:
At 6:56 PM -0700 08/11/2013, John Hardin wrote:
I'm also going to make FP-avoidance changes that should also help.
Care to share? =)
Everything is publicly visible in my sandbox:
http://svn.apache.org/viewvc/spamassassin/trunk/rulesrc/sandbox/jhar
On Sun, 11 Aug 2013, Amir 'CG' Caspi wrote:
At 9:31 PM -0400 08/11/2013, Alex wrote:
Are you using sqlgrey? If not, it's incredible and you should try it.
I have not implemented any sort of greylisting yet. I can't use sqlgrey
because I don't use postfix... my server runs sendmail. I'm sur
At 6:56 PM -0700 08/11/2013, John Hardin wrote:
I'm also going to make FP-avoidance changes that should also help.
Care to share? =)
Just make sure that the rule does not match the --> comment-end token
I tried doing that and it caused SA to hang... couldn't figure out
why the regex wasn't
On Sun, 11 Aug 2013, Amir 'CG' Caspi wrote:
At 2:22 AM -0600 08/11/2013, Amir 'CG' Caspi wrote:
My regex is valid and appropriate for those comments... I tested it at
regexpal.com, which shows that all three comments match just fine (all
three get highlighted).
So... why is SA hitting only o
At 9:31 PM -0400 08/11/2013, Alex wrote:
Can you post this rule again so we can investigate?
# HTML comment gibberish
# Looks for sequence of 100 or more "words" (alphanum + punct
separated by whitespace) within HTML comment
rawbody HTML_COMMENT_GIBBERISH //im
describe HTML_COMMENT_GIBBERISH
Hi,
> Further confusion. Received another of these types of spam today:
>
> http://pastebin.com/YywcFkui
>
> My new HTML_COMMENT_GIBBERISH rule didn't hit on this one at all. Running
Can you post this rule again so we can investigate?
How do you find the SPAMMY_URI_PATTERNS rule is performing?
At 2:22 AM -0600 08/11/2013, Amir 'CG' Caspi wrote:
My regex is valid and appropriate for those comments... I tested it
at regexpal.com, which shows that all three comments match just fine
(all three get highlighted).
So... why is SA hitting only on the final comment, and ignoring the first tw
On Aug 11, 2013, at 9:10 AM, Benny Pedersen wrote:
> i created MSG_ID_INSTAFILE_BIZ and HTML_ERROR_TAGS_X_HTML , but even without
> this rules its spam
It is NOW, it was not when it was originally processed, as you can see from the
SA headers included in the pastebin. If you read the messages
Amir 'CG' Caspi skrev den 2013-08-11 10:22:
http://pastebin.com/VCtvzjzV
Content analysis details: (10.9 points, 5.0 required)
pts rule name description
--
--
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good repu
At 1:41 PM -0600 08/10/2013, Amir 'CG' Caspi wrote:
(The HTML comment gibberish rule would be a big step here, since
that's one of the few things that would distinguish this from ham...
unlikely that a real person would embed tens of KB of comment
gibberish.)
OK, I'm trying to test an HTML co
On Sat, 10 Aug 2013, Amir 'CG' Caspi wrote:
At 2:17 PM -0700 08/10/2013, John Hardin wrote:
Perhaps it's time to bring FuzzyOCR up-to-date...?
Is this something I need to manually update or something that needs updating
in the SA distribution?
FuzzyOCR was a SA plugin a few years back. It
At 2:17 PM -0700 08/10/2013, John Hardin wrote:
Perhaps it's time to bring FuzzyOCR up-to-date...?
Is this something I need to manually update or something that needs
updating in the SA distribution?
Thanks.
--- Amir
On Sat, 10 Aug 2013, Amir 'CG' Caspi wrote:
It looks like both this and the previous type of spam are bypassing Bayes by
embedding images and using no rendered text. Well, not NO text, but very
little, mostly a "successful delivery" message and the unsub/report links.
That is, Bayes sees abso
At 10:41 AM -0700 08/09/2013, John Hardin wrote:
Can you provide a spample or two?
Looks like a similar spam method has come out in recent weeks (since
Jul 30, it seems) that uses slightly different footers... example is
here:
http://pastebin.com/QCmSPzwG
Although running SA on this spam _
At 10:41 AM -0700 08/09/2013, John Hardin wrote:
Can you provide a spample or two?
Sure.
http://pastebin.com/VfSCB7fw
http://pastebin.com/VCtvzjzV
Note the "outl" and "outi" links near the very bottom. The actual
domains used in these URIs vary... they used to be .pw, but recently
most have
On Fri, August 9, 2013 1:01 pm, RW wrote:
> BAYES works on rendered text it doesn't see the HTML.
Hmmm. It doesn't see HTML comments, which would appear in rendered HTML
source even though they are "invisible?" OK, in that case, I have NO idea
why the spam isn't hitting Bayes, because it looks p
On Fri, 9 Aug 2013 11:19:08 -0600
Amir 'CG' Caspi wrote:
> A number of my users have been receiving spam formatted in a
> very specific way which seems to very often miss Bayes... I don't
> know why, whether it's because of the HTML gibberish flooding Bayes
> with useless tokens (to reduc
On Fri, 9 Aug 2013, Amir 'CG' Caspi wrote:
A number of my users have been receiving spam formatted in a very
specific way which seems to very often miss Bayes...
Can you provide a spample or two?
I recommend this rule be added to the general distribution.
They can be added but unless such
Hi all,
A number of my users have been receiving spam formatted in a
very specific way which seems to very often miss Bayes... I don't
know why, whether it's because of the HTML gibberish flooding Bayes
with useless tokens (to reduce the relative strength of the spammy
tokens), or if it's ju
On 7/20/2013 1:35 AM, Andrea wrote:
Hi all.
Since a few days ago I'm being buried under spam messages that slip
through my amavis/SA setup.
The messages all look alike: plaintext with random junk + URL in the body.
Pastebin with a few examples here: http://g2z.me/ed64d
I've tried running a sa
On Sun, 2013-07-21 at 16:33 +0200, Andrea wrote:
>
> On 7/20/13 9:20 AM, "Christian Recktenwald" wrote:
>
> >On Sat, Jul 20, 2013 at 07:35:23AM +0200, Andrea wrote:
> >> Hi all.
> >>
> >> Since a few days ago I'm being buried under spam messages that slip
> >>through
> >> my amavis/SA setup.
>
On 7/20/13 9:20 AM, "Christian Recktenwald" wrote:
>On Sat, Jul 20, 2013 at 07:35:23AM +0200, Andrea wrote:
>> Hi all.
>>
>> Since a few days ago I'm being buried under spam messages that slip
>>through
>> my amavis/SA setup.
>> The messages all look alike: plaintext with random junk + URL in
On Jul 19, 2013, at 10:35 PM, Andrea wrote:
> Hi all.
>
> Since a few days ago I'm being buried under spam messages that slip through
> my amavis/SA setup.
> The messages all look alike: plaintext with random junk + URL in the body.
> Pastebin with a few examples here: http://g2z.me/ed64d
>
>
Hi all.
Since a few days ago I'm being buried under spam messages that slip through
my amavis/SA setup.
The messages all look alike: plaintext with random junk + URL in the body.
Pastebin with a few examples here: http://g2z.me/ed64d
I've tried running a sa-update but I don't have enough samples
Good morning *,
Am 2009-08-04 13:51:24, schrieb Jason L Tibbitts III:
> > "DS" == Dan Schaefer writes:
>
> DS> I'm glad to see this SPAM traffic has come to a halt. At least on my
> DS> mail server...
>
> Yes, I haven't seen any of those spams since the morning of the 31st.
> My servers wer
> "DS" == Dan Schaefer writes:
DS> I'm glad to see this SPAM traffic has come to a halt. At least on my
DS> mail server...
Yes, I haven't seen any of those spams since the morning of the 31st.
My servers were rejecting them like mad right up until that point in
time (10:30CDT), and then noth
Hi Dan and *,
Am 2009-08-04 14:37:46, schrieb Dan Schaefer:
> I'm glad to see this SPAM traffic has come to a halt. At least on my
> mail server...
They have seen, the out spamassassin is working verry efficient. I get
only one or two spams per day... which are catched by SA of course.
Than
I'm glad to see this SPAM traffic has come to a halt. At least on my
mail server...
--
Dan Schaefer
Web Developer/Systems Analyst
Performance Administration Corp.
(apologies for top posting, but the email software here does not really do
quoting in a way that works out well otherwise)
If your mail contains SpamAssassin headers then it was (obviously) processed
through SpamAssassin. Just because you have BL checks in your MTA does not
necessarily mean th
On Thu, 23 Jul 2009, Dan Schaefer wrote:
> > Are you quite sure that an upstream copy of SA, e.g. in your ISP
> > or at a sender site that scans for outgoing spam, hasn't already
> > added X-* headers to the message?
>
> No. Is that even possible to track down?
There would probably b
On Thu, 2009-07-23 at 12:25 -0400, Dan Schaefer wrote:
> > Are you quite sure that an upstream copy of SA, e.g. in your ISP or at a
> > sender site that scans for outgoing spam, hasn't already added X-*
> > headers to the message?
> >
> >
> > Martin
> >
> >
> No. Is that even possible to track d
On Thu, 23 Jul 2009, Dan Schaefer wrote:
Are you quite sure that an upstream copy of SA, e.g. in your ISP or at
a sender site that scans for outgoing spam, hasn't already added X-*
headers to the message?
No. Is that even possible to track down?
There would probably be an X-Spam-Checker-V
Are you quite sure that an upstream copy of SA, e.g. in your ISP or at
a sender site that scans for outgoing spam, hasn't already added X-*
headers to the message?
No. Is that even possible to track down?
There would probably be an X-Spam-Checker-Version header in your
inbound mail strea
Are you quite sure that an upstream copy of SA, e.g. in your ISP or at a
sender site that scans for outgoing spam, hasn't already added X-*
headers to the message?
Martin
No. Is that even possible to track down?
--
Dan Schaefer
Web Developer/Systems Analyst
Performance Administration Cor
Dan Schaefer wrote:
>
> If this is the case, then why does my email have the X-* headers in
> it? I have nothing in my postfix header_checks to discard the BL
> rules. Does anyone have a detailed flow chart of SA/postfix setup and
> describes blacklisting? Or even a webpage describing the proces
On Wed, 22 Jul 2009, Dan Schaefer wrote:
For those of you that manage these rules,
URI_OBFU_X9_WS, URI_OBFU_WWW, AE_MEDS38, AE_MEDS39 did not mark this
email as spam
http://pastebin.com/m40f7cff4
The URI is not obfuscated, therefore it triggered the URIBL tests
properly (and scored 3 additio
Dan Schaefer wrote:
It means that if you were using BL at MTA level your SA might never
have seen the message at all.
No your rule would not be "overlooked" 'because the site is in a
blacklist' *unless* you were using the BL in your MTA and rejected
the transaction from a blacklisted IP add
It means that if you were using BL at MTA level your SA might never have seen
the message at all.
No your rule would not be "overlooked" 'because the site is in a blacklist'
*unless* you were using the BL in your MTA and rejected the transaction from a
blacklisted IP address and, thus, never
>For those of you that manage these rules,
>URI_OBFU_X9_WS, URI_OBFU_WWW, AE_MEDS38, AE_MEDS39 did not mark this
email as spam
I'm up to AE_MED45, so I wouldn't expect AE_MEDS38 and 39 to be
hitting anything currently.
>http://pastebin.com/m40f7cff4
This is not an obfuscated domain. You
On Thu, 2009-07-23 at 07:34 +0100, rich...@buzzhost.co.uk wrote:
> It's catching on :-)
this new obfuscation is already caught by AE_MED45, but I can foresee a
variant that might not match...
How about:
body__MED_OB
/\bw{2,3}(?:[[:punct:][:space:]]{1,5}|[[:space:][:punct:]]{1,3}dot[[
It means that if you were using BL at MTA level your SA might never have seen
the message at all.
No your rule would not be "overlooked" 'because the site is in a blacklist'
*unless* you were using the BL in your MTA and rejected the transaction from a
blacklisted IP address and, thus, never su
>From: Dan Schaefer [mailto:d...@performanceadmin.com]
>For those of you that manage these rules,
>URI_OBFU_X9_WS, URI_OBFU_WWW, AE_MEDS38, AE_MEDS39 did not mark this email as
>spam
I'm up to AE_MED45, so I wouldn't expect AE_MEDS38 and 39 to be hitting
anything currently.
>http://pastebin.co
On Wed, July 22, 2009 21:56, Dan Schaefer wrote:
> Does this mean that if I have a custom rule to search for exactly the
> "via" site, my rule will be overlooked because the site is in a blacklist?
what problem ?
--
xpoint
Benny Pedersen wrote:
On Wed, July 22, 2009 21:39, Dan Schaefer wrote:
For those of you that manage these rules,
URI_OBFU_X9_WS, URI_OBFU_WWW, AE_MEDS38, AE_MEDS39 did not mark this email as
spam
http://pastebin.com/m40f7cff4
reject it with rbl testing in mta, and its found in blackli
On Wed, July 22, 2009 21:39, Dan Schaefer wrote:
> For those of you that manage these rules,
> URI_OBFU_X9_WS, URI_OBFU_WWW, AE_MEDS38, AE_MEDS39 did not mark this email as
> spam
> http://pastebin.com/m40f7cff4
reject it with rbl testing in mta, and its found in blacklist, reason it not
found
For those of you that manage these rules,
URI_OBFU_X9_WS, URI_OBFU_WWW, AE_MEDS38, AE_MEDS39 did not mark this email as
spam
http://pastebin.com/m40f7cff4
--
Dan Schaefer
Web Developer/Systems Analyst
Performance Administration Corp.
1 - 100 of 370 matches
Mail list logo
