Marc Perkel wrote:
> If you have domains you are filtering just add this as your highers numbered
> MX record.
As long as this isn't for any valid domains. Don't add the honeypot
to a valid domain's MX because valid senders may get trapped
otherwise. For example if I were to add your tarpit to m
Am 19.06.2015 um 22:39 schrieb Benny Pedersen:
Reindl Harald skrev den 2015-06-19 15:56:
curenntly you need a few greps to dig from the MID to the postfix-id
envelope=_SENDERDOMAIN_, from=_AUTHORDOMAIN_
syslog to SQL and you can xref all the info you need
that's a workaround and not a sol
On Jun 19, 2015, at 6:02 PM, Philip Prindeville
wrote:
> Given how many vulnerabilities CentOS 5 has, why would you want to keep
> running that?
Because, while "I wish I could upgrade ... various circumstances prevent that
right now."
It is fully patched, FWIW.
--- Amir
thumbed via iPhone
On 06/10/2015 04:34 AM, Amir Caspi wrote:
On Jun 10, 2015, at 12:32 AM, Matus UHLAR - fantomas wrote:
FEATURE(`block_bad_helo')
define(`confALLOW_BOGUS_HELO', `False')
Argh, unfortunately, that feature is only on sendmail 8.14 and higher, which
means RHEL/CentOS 6 or higher. For those of
for convenience, postfix & SA TLD-blocking snippets together:
in postfix
/etc/postfix/main.cf
...
smtpd_sender_restrictions =
...
+ check_sender_access pcre:/etc/postfix/reject_TLDs.pcre
permit_mynetworks
Ditto here. Along with a handful of other junk domains like the colors (.red,
.blue, etc.) and a couple of country codes. Some I kill at the MTA, some I
just poison pill with spam scores.
...Kevin
--
Kevin Miller
Network/email Administrator, CBJ MIS Dept.
155 South Seward Street
Juneau, Alaska
On Jun 19, 2015, at 3:28 PM, David Jones wrote:
>> From: Philip Prindeville
>> Sent: Friday, June 19, 2015 3:53 PM
>> To: David Jones
>> Cc: users@spamassassin.apache.org
>> Subject: Re: Must-Have Plugins?
>
>> On Jun 19, 2015, at 2:35 PM, David Jones wrote:
>
>>>
But I’m on a LOT of h
>From: Philip Prindeville
>Sent: Friday, June 19, 2015 3:53 PM
>To: David Jones
>Cc: users@spamassassin.apache.org
>Subject: Re: Must-Have Plugins?
>On Jun 19, 2015, at 2:35 PM, David Jones wrote:
>>
>>> But I’m on a LOT of high volume mailing lists (like mozilla-general and
>>> netdev) that g
>From: Marc Perkel
>Sent: Friday, June 19, 2015 3:41 PM
>To: users@spamassassin.apache.org
>Subject: Help me waste spammers resources
>I found a great trick for wasting spammer's resources and getting them
>blacklisted that I'd like to share will all of you.
>On my main spam filtering servers I
On Jun 19, 2015, at 2:35 PM, David Jones wrote:
>
>> But I’m on a LOT of high volume mailing lists (like mozilla-general and
>> netdev) that get heavily spammed.
>
> Filtering mailing lists is a slightly different ballgame than filtering
> regular email. Some of the items listed above
> don
I found a great trick for wasting spammer's resources and getting them
blacklisted that I'd like to share will all of you.
On my main spam filtering servers I advertise authenticated login even
though I don't actually have any authenticated users. Anyone who tries
to authenticate is a spammer.
Reindl Harald skrev den 2015-06-19 15:56:
curenntly you need a few greps to dig from the MID to the postfix-id
envelope=_SENDERDOMAIN_, from=_AUTHORDOMAIN_
syslog to SQL and you can xref all the info you need
that's a workaround and not a solution, there's a reason why the
spamfirewall is t
>>> From: Philip Prindeville
>>
>>> On Jun 9, 2015, at 12:29 PM, John Hardin wrote:
>>
On Tue, 9 Jun 2015, David Jones wrote:
> Some of the best and easiest things you can enable to block spam are
> outside of SpamAssassin at your MTA (sendmail, postfix, etc.).
> - Enab
On Jun 19, 2015, at 1:01 PM, David Jones wrote:
>> From: Philip Prindeville
>
>> On Jun 9, 2015, at 12:29 PM, John Hardin wrote:
>
>>> On Tue, 9 Jun 2015, David Jones wrote:
>>>
Some of the best and easiest things you can enable to block spam are
outside of SpamAssassin at your MT
On Fri, 19 Jun 2015 12:51:28 -0600
Philip Prindeville wrote:
[stuff]
> With this, we avoid ever accepting about 98% of the SPAM that we’d
> otherwise receive.
Really? 98%? I find that surprising. We get quite a lot of spam
from gmail, hotmail, yahoo etc. that would pass all of your tests.
R
>From: Philip Prindeville
>On Jun 9, 2015, at 12:29 PM, John Hardin wrote:
>> On Tue, 9 Jun 2015, David Jones wrote:
>>
>>> Some of the best and easiest things you can enable to block spam are
>>> outside of SpamAssassin at your MTA (sendmail, postfix, etc.).
>>
>>> - Enable greylisting. This
On Jun 9, 2015, at 12:29 PM, John Hardin wrote:
> On Tue, 9 Jun 2015, David Jones wrote:
>
>> Some of the best and easiest things you can enable to block spam are
>> outside of SpamAssassin at your MTA (sendmail, postfix, etc.).
>
>> - Enable greylisting. This is just about the only way you c
On 19/06/15 18:46, Axb wrote:
On 19.06.2015 19:42, Philip Prindeville wrote:
No offense to lepers, but is .science to be avoided? I’ve had email
this week from about 17 different .science domain names, and 13 were
blocked because of ZenBL and the rest turned out to be SPAM anyway.
I’m thinki
Greetings,
spamd is using 100% CPU on my RaspberryPi 2 B, even though there is no
email coming in. Each process only runs 10 seconds or so, but then a new
one starts. (I have m set to 1)
I tried some of the tips on the site, ran sa-compile and disabled most
plugins, but that didn't help much(at
* Philip Prindeville :
> No offense to lepers, but is .science to be avoided? I’ve had email this
> week from about 17 different .science domain names, and 13 were blocked
> because of ZenBL and the rest turned out to be SPAM anyway.
>
> I’m thinking that I should just refuse connections from a
On 19.06.2015 19:42, Philip Prindeville wrote:
No offense to lepers, but is .science to be avoided? I’ve had email this week
from about 17 different .science domain names, and 13 were blocked because of
ZenBL and the rest turned out to be SPAM anyway.
I’m thinking that I should just refuse co
No offense to lepers, but is .science to be avoided? I’ve had email this week
from about 17 different .science domain names, and 13 were blocked because of
ZenBL and the rest turned out to be SPAM anyway.
I’m thinking that I should just refuse connections from any host whose rDNS is
.science…
amavisd seems to be involved in this issue; not sure whether it's the 'culprit'
or the 'victim'.
A 'ham' mail received through postfix+amavisd+spamassassin arrives with headers
...
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Level:
X-Spam-Status: No, score
> > UNPARSEABLE_RELAY still hits. I've not yet determined what the actual
> > problem with the parsing is.
>
> It's a shortcoming/bug in the SpamAssassin ad-hoc parser.
>
> Please open a Bugzilla ticket and provide a sample of
> your Received header field (which is perfectly valid
> according to
On 19/06/15 16:57, Steve Freegard wrote:
spamd will already log the envfrom= line provided it has this
information passed through from whatever calls it. I send it over via a
X-Envelope-From: (see 'envelope_sender_header' in man
Mail::SpamAssassin::Conf).
Actually - I'm talking rubbish; I ju
On 19/06/15 15:50, Kevin A. McGrail wrote:
On 6/19/2015 10:43 AM, Reindl Harald wrote:
if you only have one user=sa-milter then you're screwed
and how does a "user=rcpt" give you any useful information to grep for
the sender of the mail in the case above?
We need to agree to disagree because
PGNd wrote:
The LHLO/LMTP header still is added at the backend, and
UNPARSEABLE_RELAY still hits. I've not yet determined what the actual
problem with the parsing is.
It's a shortcoming/bug in the SpamAssassin ad-hoc parser.
Please open a Bugzilla ticket and provide a sample of
your Received
On 19.06.2015 17:04, Reindl Harald wrote:
Am 19.06.2015 um 16:55 schrieb Axb:
again: "Your system design limits you"
my glue allows me to log all that in SQL and Xref it
boah we talk about spam-assassin logging and not the glue and my first
post at all on this list was about spamass-milter w
Am 19.06.2015 um 16:55 schrieb Axb:
again: "Your system design limits you"
my glue allows me to log all that in SQL and Xref it
boah we talk about spam-assassin logging and not the glue and my first
post at all on this list was about spamass-milter with a warm "creep
away that's not a SA pr
Am 19.06.2015 um 16:50 schrieb Kevin A. McGrail:
On 6/19/2015 10:43 AM, Reindl Harald wrote:
if you only have one user=sa-milter then you're screwed
and how does a "user=rcpt" give you any useful information to grep for
the sender of the mail in the case above?
We need to agree to disagree
On 19.06.2015 16:43, Reindl Harald wrote:
Am 19.06.2015 um 16:34 schrieb Axb:
On 19.06.2015 16:24, Reindl Harald wrote:
Am 19.06.2015 um 16:19 schrieb Axb:
Postfix/MTA/Glue Session IDs, etc... having the data in a DB also
allows all kinds of stats.
nonsense, there is *nothing* to xfer the
On 6/19/2015 10:43 AM, Reindl Harald wrote:
if you only have one user=sa-milter then you're screwed
and how does a "user=rcpt" give you any useful information to grep for
the sender of the mail in the case above?
We need to agree to disagree because you don't need to convince people
that your
Am 19.06.2015 um 16:34 schrieb Axb:
On 19.06.2015 16:24, Reindl Harald wrote:
Am 19.06.2015 um 16:19 schrieb Axb:
Postfix/MTA/Glue Session IDs, etc... having the data in a DB also
allows all kinds of stats.
nonsense, there is *nothing* to xfer the other log entries and the
timestamp is for
Am 19.06.2015 um 16:31 schrieb PGNd:
Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly
prevents it from triggering the shortcircuit.
However, it still fires -- incorrectly & intermittently, albeit now with a "-1"
score attached.
The LHLO/LMTP header still is adde
On 19.06.2015 16:24, Reindl Harald wrote:
Am 19.06.2015 um 16:19 schrieb Axb:
On 19.06.2015 16:01, Reindl Harald wrote:
Am 19.06.2015 um 15:56 schrieb Reindl Harald:
envelope=_SENDERDOMAIN_, from=_AUTHORDOMAIN_
syslog to SQL and you can xref all the info you need
that's a workaround and
Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly
prevents it from triggering the shortcircuit.
However, it still fires -- incorrectly & intermittently, albeit now with a "-1"
score attached.
The LHLO/LMTP header still is added at the backend, and UNPARSEABLE_RELAY s
Am 19.06.2015 um 16:19 schrieb Axb:
On 19.06.2015 16:01, Reindl Harald wrote:
Am 19.06.2015 um 15:56 schrieb Reindl Harald:
envelope=_SENDERDOMAIN_, from=_AUTHORDOMAIN_
syslog to SQL and you can xref all the info you need
that's a workaround and not a solution, there's a reason why the
sp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19-06-15 16:19, Axb wrote:
> On 19.06.2015 16:01, Reindl Harald wrote:
>>
>> Am 19.06.2015 um 15:56 schrieb Reindl Harald:
> envelope=_SENDERDOMAIN_, from=_AUTHORDOMAIN_
syslog to SQL and you can xref all the info you need
>>>
>>>
On 19.06.2015 16:01, Reindl Harald wrote:
Am 19.06.2015 um 15:56 schrieb Reindl Harald:
envelope=_SENDERDOMAIN_, from=_AUTHORDOMAIN_
syslog to SQL and you can xref all the info you need
that's a workaround and not a solution, there's a reason why the
spamfirewall is the *only* machine not l
Am 19.06.2015 um 15:56 schrieb Reindl Harald:
envelope=_SENDERDOMAIN_, from=_AUTHORDOMAIN_
syslog to SQL and you can xref all the info you need
that's a workaround and not a solution, there's a reason why the
spamfirewall is the *only* machine not logging to mysql because you
really don't wa
Am 19.06.2015 um 15:50 schrieb Axb:
On 19.06.2015 15:34, Reindl Harald wrote:
Am 19.06.2015 um 15:08 schrieb Rajesh M:
i am using qmailtoaster on centos6.6 64 bit
is there a way to have detailed logging for spamassassin
which includes the sender and the recepient and the scan result
+1
te
On 19.06.2015 15:34, Reindl Harald wrote:
Am 19.06.2015 um 15:08 schrieb Rajesh M:
i am using qmailtoaster on centos6.6 64 bit
is there a way to have detailed logging for spamassassin
which includes the sender and the recepient and the scan result
+1
template based like for headers would be
Am 19.06.2015 um 15:08 schrieb Rajesh M:
i am using qmailtoaster on centos6.6 64 bit
is there a way to have detailed logging for spamassassin
which includes the sender and the recepient and the scan result
+1
template based like for headers would be much more helpful in the logs
than in the
> Are the 196.28.80.29, 196.28.80.61, and 196.28.66.13 in your
> trusted X.X.X.X/29 ? If they are, then hitting ALL_TRUSTED is expected.
No, the X.X.X.X/29 is a different server -- one of my own, not in a 186. block,
and definitely not in ZA.
> > Jun 18 22:38:19.967 [19747] dbg: check:
> > tes
hi
i am using qmailtoaster on centos6.6 64 bit
is there a way to have detailed logging for spamassassin
which includes the sender and the recepient and the scan result.
my current logs are as such which does not show the
Jun 19 18:31:45 ns1 spamd[48983]: spamd: connection from localhost [127.0
PGNd wrote:
I'm running
postfix 3.0.1
amavisd-new-2.10.1 (20141025)
SpamAssassin version 3.4.1
on linux/64.
amavisd/spamassasin is invoked as a postfix prequeue proxy filter.
Spam is getting scanned and scored. Usually correctly.
Intermittenly, I get an email that get
>/local.cf
> internal_networks 127.0.0.0/8 10.2.2.0/24 10.1.1.0/24 X.X.X.X/29
> trusted_networks 10.2.2.0/24 10.1.1.0/24 X.X.X.X/29
>etc, the msg's received-from headers are _not_ all on my internal networks,
What are the X.X.X.X/29 above? It can
On 19.06.2015 09:14, Olivier CALVANO wrote:
Hi
i want create a rules for filters :
i want add 100 in score at all email that have:
"Invoice" or "Facture" in core
AND
a .DOC file attachment
it's possible ?
yes, it's possible
Requires a header rule for the Subject string and a mimeheader ru
Hi
i want create a rules for filters :
i want add 100 in score at all email that have:
"Invoice" or "Facture" in core
AND
a .DOC file attachment
it's possible ?
thanks
Olivieir
49 matches
Mail list logo
