On Tue, Mar 03, 2020 at 04:46:11AM +, s...@skolma.com wrote:
> Boudewijn,
> Thank you for your reply, and clarification.
>
> The man pages for SPAMD and SPAMDB do not directly state this relationship /
> behavior, and therefore I had made the assumption that spamd would capt
Boudewijn,
Thank you for your reply, and clarification.
The man pages for SPAMD and SPAMDB do not directly state this relationship /
behavior, and therefore I had made the assumption that spamd would capture and
feed all entries into the spamdb, in all operational modes.
..hopefully i have
Op Thu, 27 Feb 2020 00:19:59 +0100 schreef :
Questions:
Does the spamDB play a role at all in pure Black listing mode ?
No, that DB is used for bookkeeping and decision-making. In blacklist-only
mode, there is none of that.
Does the spamDB only get created/configured when running in Normal
Hi misc,
Questions:
Does the spamDB play a role at all in pure Black listing mode ?
Does the spamDB only get created/configured when running in Normal/Grey mode ?
Does is require Manual creation ?
Issue:
When Attempting to review SPAMDB entries i get an error:
spamdb: cannot open /var/db/spamd
Op Fri, 21 Dec 2018 17:10:46 +0100 schreef Gilles Chehade
:
spamdb | grep -E '^(GREY|WHITE)\|' | cut -d\| -f1,2
--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
hello misc@,
If you are comfortable with sharing your spamdb output with me, it would
be very helpful in confirming or not some theories I have.
I do not need the sender/recipient parts, only the first two fields that
disclose if the connection is in GREY or WHITE list and IP address of MX
, in case it affects, we are using the software raid.
>
> hth others googling for spamd.
>
> > El 10/9/2015, a las 15:41, Peter N. M. Hansteen <pe...@bsdly.net>
> > escribió:
> >
> >> On Thu, Sep 10, 2015 at 03:04:26PM +0200, Fran. J Ballesteros
>
<pe...@bsdly.net> escribió:
>
>> On Thu, Sep 10, 2015 at 03:04:26PM +0200, Fran. J Ballesteros wrote:
>>
>> with 5.7 our spamdb becomes corrupt after a while. Are we the only ones with
>> this problem? Anyone else using it?
>
> using spamd with related tools includin
On Thu, Sep 10, 2015 at 03:04:26PM +0200, Fran. J Ballesteros wrote:
> with 5.7 our spamdb becomes corrupt after a while. Are we the only ones with
> this problem? Anyone else using it?
using spamd with related tools including spamdb through the 5.7 cycle and past,
yes.
seeing
hi
with 5.7 our spamdb becomes corrupt after a while. Are we the only ones with
this problem? Anyone else using it?
:)
here is the script:
ip_range=$1
for i in `spamdb | grep $ip_range | grep WHITE | awk -F | '{print $2}'`;
do
echo $i
/usr/sbin/spamdb -d $i
/usr/sbin/spamdb -a -t $i
echo $i /etc/mail/blacksheep.txt
done
/usr/libexec/spamd-setup
maybe someone give me some hints for improvement
if
the delivery attempt is successful (which it shouldnt in the first place
because I trapped the ip and put it in my blacklist). This seems like an
odd behaviour to me, its not the end of the world but it feels kinda
wrong :)
here is the script:
ip_range=$1
for i in `spamdb | grep $ip_range
:
$ spamdb | grep $ip
WHITE|$ip|...
GREY|$ip|...
$ spamdb -d $ip
$ spamdb | grep $ip
GREY|$ip|...
$ sleep 60
$ spamdb | grep $ip
WHITE|$ip|...
GREY|$ip|...
As a side note, your awk bit can be replaced by a `cut -d \| -f 2'.
--patrick
here is the script:
ip_range=$1
for i in `spamdb | grep
of the script the ip should be trapped and in
my opinion the grey mail shouldnt white list the ip again. I just saw
this behaviour 2 times with the same ip because they sent the mail to 3
different mailaddresses.
To see this with an IP that has been WHITE-listed, but still in
the GREY, do:
$ spamdb
Hi there,
just a simple question, is there a way to seperate the spamdb logs into
logs for white-, grey- and blacklist entries?
It would make the lookup make much easier when something goes wrong :)
regards
--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
G+H Webservice GbR
Bennett:
On Wed, Jul 01, 2015 at 11:01:18AM +0200, Markus Rosjat wrote:
Hi there,
just a simple question, is there a way to seperate the spamdb logs into logs
for white-, grey- and blacklist entries?
It would make the lookup make much easier when something goes wrong :)
I just use:
alias G
On Wed, Jul 01, 2015 at 11:01:18AM +0200, Markus Rosjat wrote:
Hi there,
just a simple question, is there a way to seperate the spamdb logs into logs
for white-, grey- and blacklist entries?
It would make the lookup make much easier when something goes wrong :)
I just use:
alias G='spamdb
+10:52PM0:00.00 grep
-i spamd (ksh)
#
You might also try running:
$ spamdb | fgrep 66.111.4.25
Here is the output:
$ spamdb | fgrep 66.111.4.25
WHITE|66.111.4.25|||1430096342|1430098533|1433208963|4|0
GREY|66.111.4.25|out1-smtp.messagingengine.com
:
[priv] (greylist) (spamd)
_spamd 14894 0.0 0.0 9656 1020 ?? I 10:28PM0:00.00 spamd:
(/var/db/spamd update) (spamd)
root 30162 0.0 0.0 636 4 p7 R+10:52PM0:00.00 grep
-i spamd (ksh)
#
You might also try running:
$ spamdb | fgrep 66.111.4.25
Here
)
root 30162 0.0 0.0 636 4 p7 R+10:52PM0:00.00 grep
-i spamd (ksh)
#
You might also try running:
$ spamdb | fgrep 66.111.4.25
Here is the output:
$ spamdb | fgrep 66.111.4.25
WHITE|66.111.4.25|||1430096342|1430098533|1433208963|4|0
GREY|66.111.4.25|out1
might have caused it?
Error 22 is EINVAL. I'm not sure how that can happen in this case
though. Have you tried restating spamd?
You might also try running:
$ spamdb | fgrep 66.111.4.25
to see if that entry is really in the database and if so see if
spamdb -d can remove it.
- todd
spamd[7233]: can't delete 66.111.4.25
out1-smtp.messagingengine.com adam.w...@koparo.com
adam.w...@tintagel.pl from spamd db (Error 0)
You might also try running:
$ spamdb | fgrep 66.111.4.25
Here is the output:
$ spamdb | fgrep 66.111.4.25
WHITE|66.111.4.25|||1430096342|1430098533|1433208963
(Error 22)
... and so on
They keep repeating every minute.
Current spamdb entry as of 19:58:58 in the timestamp
# spamdb
WHITE|66.111.4.25|||1430096342|1430098533|1433208963|4|0
GREY|209.85.218.48|mail-oi0-f48.google.com|netpr...@gmail.com|mulan...@tintagel.pl|1430145364|1430159764|1430159764|1|0
I've finally started using spamd on a new mail server, and am seeing
some results that I don't understand. (I'm also using smtpd(8) now, so
this is all new software to me...)
1 - spamdb(8) shows nothing but WHITE-listed entries
2 - but spamd(8) (running with -v -G 2:4:864) logs almost every
to me...)
That is exciting. spamd and smtpd are excellent imho.
I recommend you continue to read the man pages until you have
a better understanding of how they work.
1 - spamdb(8) shows nothing but WHITE-listed entries
2 - but spamd(8) (running with -v -G 2:4:864) logs almost every one of
those
backfilled with operational experience.
spamdb(8) indicates 4 different entry types.
BLACK is not an entry type.
Oops. I see that now. Then how do I see what IPs are blacklisted
without becoming a human version of spamd-setup(8)?
I would recommend using the default spamd values.
Easy enough
Oops. I see that now. Then how do I see what IPs are blacklisted
without becoming a human version of spamd-setup(8)?
If running spamd in default mode ...
1. spamdb(8), TRAPPED entries.
2. The spamd.conf(5) file is read by spamd-setup(8) to configure
blacklists for spamd(8).
I am not aware
the following command:
spamdb -d 207.126.144.121
Unfortunately it does not remove the entry as it is still there. Any
ideas what could be wrong?
An IP address can only be used as a key for WHITE and TRAPPED entries. The
spamdb(8) utility was not designed to remove GREY entries, but if you are
clever, you
tried the following command:
spamdb -d 207.126.144.121
Unfortunately it does not remove the entry as it is still there. Any ideas
what could be wrong?
Regards,
M.L.
I don't think anything is wrong. It will be removed but might not show
straight away. man 8 spamdb explains very
to allow mail
coming in from this mail server.
Regards,
M.L.
From: Boudewijn Dijkstra
sp4mtr4p.boudew...@indes.com
To: misc misc@openbsd.org
Sent: Wednesday,
August 14, 2013 12:39 PM
Subject: Re: remove entry from spamdb greylist
Op
Tue, 13 Aug 2013 17:49:51 +0200
this IP my PF spamd whitelist. The final goal being simply to allow mail
coming in from this mail server.
spamdb -a 207.126.144.121 should set it to state WHITE, and the GREY entry
(which will be overridden by the WHITE) will expire sooner or later.
If it doesn't behave that way, I'd think
If that PF table is spamd-white, then it will get reset when you run
spamd-setup(8) or reboot. Maybe a better way is to manually add this IP to
the spamdb whitelist:
spamdb -a 207.126.144.121
In this case the grey entry will be ignored and stay in the database until
it expires.
Or, even
Dear Peter,
Thanks for your input too! Actually yesterday I have also tried afterwards to
do a spamdb -a and as I didn't see any immediate effect (IP still listed
under GREY), I simply assumed that it didn't work. From your mail I understand
that it stays for a while as GREY until it expires
Hello,
I am using spamd in greylisting mode and would like to delete the following
entry:
GREY|207.126.144.121|eu1sys200aog106.obsmtp.com|no_reply@sender|recipient@domain|1376398715|1376400232|1376413115|4|0
I tried the following command:
spamdb -d 207.126.144.121
Unfortunately it does
Hi!
Sorry.
Emilio Lucena
--- spamdb.c.orig Sat May 17 07:48:06 2008
+++ spamdb.cMon Jul 18 08:04:29 2011
@@ -39,10 +39,10 @@
#define SPAMTRAP 2
intdblist(DB *);
-intdbupdate(DB *, char *, int, int);
+intdbupdate(DB *, char *, int, int, time_t);
int
Hi,
I've been using OpenBSD spamd for a while now and I find it
really great.
One feature I wanted to try was the ability to trap and
whitelist hosts for different periods of time, depending
on the host's behaviour. As you well know, there are some
really bad guys out there.
So I wrote this
I'm not personally interested in this, but your mailer broke the diff.
Fix and resend if you want serious feedback on this.
/Alexander
On 07/30/11 14:51, Emilio Lucena wrote:
Hi,
I've been using OpenBSD spamd for a while now and I find it
really great.
One feature I wanted to try was the
Op Tue, 23 Nov 2010 18:05:14 +0100 schreef Peter Fraser p...@thinkage.ca:
Somehow I have an bad entry in my /var/db/spamdb the entry in question
is a follows.
GREY|kadorken.thspamdb -t -a
itroll.03092...@thinkage.chinkage.on.ca|spamdb -t
-a kgdykesb...@thinkage.on.ca|spamdb -t
That worked thanks
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Boudewijn Dijkstra
Sent: Wednesday, November 24, 2010 6:08 AM
To: OpenBSD misc
Subject: Re: A bad entry in the spamdb kills pfctl
Op Tue, 23 Nov 2010 18:05:14 +0100 schreef
Somehow I have an bad entry in my /var/db/spamdb the entry in question is a
follows.
GREY|kadorken.thspamdb -t -a itroll.03092...@thinkage.chinkage.on.ca|spamdb -t
-a kgdykesb...@thinkage.on.ca|spamdb -t -a kgdykesb...@thinkage.on.ca|spamdb
-t -a kgdykescxspamdb|1160168514|0|0|1|-2
I have
On Tue, Nov 23, 2010 at 05:05:14PM +, Peter Fraser wrote:
Somehow I have an bad entry in my /var/db/spamdb the entry in question is a
follows.
GREY|kadorken.thspamdb -t -a itroll.03092...@thinkage.chinkage.on.ca|spamdb -t
-a kgdykesb...@thinkage.on.ca|spamdb -t -a kgdykesb
One question here. Shouldn't the spamdb -t -a w.x.y.z when adding a trap
manually in the spamd database also removed any grey listing for the
same IP's?
What happened is of in the same 4 hours window I manually add an IP to
the trap, but I also see source for that IP in the greg listing
On Mon, Aug 23, 2010 at 5:07 PM, Daniel Ouellet dan...@presscom.net wrote:
One question here. Shouldn't the spamdb -t -a w.x.y.z when adding a trap
manually in the spamd database also removed any grey listing for the same
IP's?
What happened is of in the same 4 hours window I manually add
Traplists do not go into tables. (for this exact reason) only the
whitelisted
hosts go into tables guys.
Bob
* Peter N. M. Hansteen pe...@bsdly.net [2009-07-28 15:31]:
Renaud Allard ren...@allard.it writes:
It happened to me also with servers with huge white/black lists. If
Renaud Allard ren...@allard.it writes:
It happened to me also with servers with huge white/black lists. If
it's happening for new connections, ensure that pf is configured with
enough maximum table entries (set limit table-entries).
That's interesting. Hitting table size limits would explain
On 7/24/09 3:03 PM, Peter N. M. Hansteen wrote:
setting up a new spamd plus various content filtering at a client site
we were kind of baffled to see that apparently manually setting an
address to TRAPPED with spamdb, ie
spamdb -a -t 211.49.57.32
for some reason seems porous, in that messages
...@bsdly.net [2009-07-24 07:10]:
setting up a new spamd plus various content filtering at a client site
we were kind of baffled to see that apparently manually setting an
address to TRAPPED with spamdb, ie
spamdb -a -t 211.49.57.32
for some reason seems porous, in that messages received from that IP
setting up a new spamd plus various content filtering at a client site
we were kind of baffled to see that apparently manually setting an
address to TRAPPED with spamdb, ie
spamdb -a -t 211.49.57.32
for some reason seems porous, in that messages received from that IP
address still hits
On Fri, Jul 24, 2009 at 03:03:51PM +0200, Peter N. M. Hansteen wrote:
setting up a new spamd plus various content filtering at a client site
we were kind of baffled to see that apparently manually setting an
address to TRAPPED with spamdb, ie
spamdb -a -t 211.49.57.32
for some reason
Hi.
...working on with spamd.
# uname -a
OpenBSD mx.chics.ru 4.4 GENERIC#0 i386
Today I see some annoying spammer from 200.162.44.162. He was
greylisted but then go thought it.
# spamdb |fgrep '200.162.44.162'
GREY|200.162.44.162|mail.plusoft.com.br|v...@chinatown.ru|o...@email|1231915016
I have difficulties in understanding why a minority of IP's of a huge
set of WHITE entries of our spamdb do not have a 'pass' date set:
# spamdb | grep 128.1x8.50.xxx
WHITE|128.1x8.50.xxx|||1218625388|0|1221750240|1|1
spamdb(8) says: time the entry passed from being GREY to being WHITE.
Since
. lists: spamd-greytrap
Along with its spamdb entry:
TRAPPED|10.10.10.10|1214679171
However, after including the offending email address and stopping and
restarting spamd; and removing the greytrapped/blacklisted host from
spamdb like so
$ sudo spamdb -T -d 10.10.10.10
I continue to get the same
]: 10.10.10.10: disconnected after 386 seconds. lists:
spamd-greytrap
Along with its spamdb entry:
TRAPPED|10.10.10.10|1214679171
However, after including the offending email address and stopping and
restarting spamd; and removing the greytrapped/blacklisted host from
spamdb like so
Hi,
Is it normal to have white and grey entries from the same
IP address showing up in the output of spamdb?
Should the GREY entries not be deleted once the IP address
is whitelisted?
GREY|217.130.91.233|qanr.comunitel.net|from-email|to-email|
1205058895|1205060468|1205073295|6|0
WHITE
On Sun, Mar 09, 2008 at 09:17:51AM -0500, Jose Fragoso wrote:
Hi,
Is it normal to have white and grey entries from the same
IP address showing up in the output of spamdb?
Should the GREY entries not be deleted once the IP address
is whitelisted?
GREY|217.130.91.233|qanr.comunitel.net
On 2008-03-09, Jose Fragoso [EMAIL PROTECTED] wrote:
Is it normal to have white and grey entries from the same
IP address showing up in the output of spamdb?
Yes
Should the GREY entries not be deleted once the IP address
is whitelisted?
No
Hi,
reading about spamd having changed the database format (recently?), how
do I best achieve replicating and merging the spamdb database(s) across
a number of machines, maintaining consistent white- and greylisting
entries?
Or is this not yet supported (the docs suggest so)?
Best,
--Toni++
Toni Mueller wrote:
Hi,
reading about spamd having changed the database format (recently?), how
do I best achieve replicating and merging the spamdb database(s) across
a number of machines, maintaining consistent white- and greylisting
entries?
Or is this not yet supported (the docs suggest so
unordered
entries.
My question is: Is this normal with spamd a la 4.2 or is it because I
migrated a database?
This is normal in 4.2 - the change happened post 4.0 when
spamdb stopped using DB_BTREE
Thanks Bob. I'm already using a script to sort the list to emulate the
previous
is: Is this normal with spamd a la 4.2 or is it because I
migrated a database?
This is normal in 4.2 - the change happened post 4.0 when
spamdb stopped using DB_BTREE
-Bob
was the output of spamdb.
Back on 4.0 all the entries came out (sort of) sorted.
All the SPAMTRAP entries last but sorted on the trap address field.
All the GREY, WHITE or TRAPPED entries first sorted on the IP field
(but sorted
alphabetically i.e. 101.x.y.z precedes 99.x.y.z)
All that was fine because I
!!
But Machine B (the passive brother which gets synced through
spamd-sync) behaves as it should!?
spamdb (A):
WHITE|10.100.64.199|||1193231843|1193232057|1196342528|3|1
spamdb (B):
WHITE|10.100.64.199|||1193231843|1193232057|1193239279|3|1
pf.conf:
no rdr inet proto tcp from spamd
!
It has taken the default 36 days ahead instead of our 2 hour (testvalue)
from spamd_flags!!
But Machine B (the passive brother which gets synced through
spamd-sync) behaves as it should!?
spamdb (A):
WHITE|10.100.64.199|||1193231843|1193232057|1196342528|3|1
spamdb (B):
WHITE|10.100.64.199
On Wed, 26 Sep 2007 17:02:50 +0300
Liviu Daia [EMAIL PROTECTED] wrote:
Why should it? The second copy is sent in a separate run, that's
the whole point. The only thing the bot has to figure out is how long
to wait until the second run. A smart one would send a second copy
after 10
--- Bob Beck [EMAIL PROTECTED] wrote:
[snip]
greylisting does what it does. It delays the initial email
for 30 minutes or more. what you do with that 30 minutes will decide
on how effective it is for you.
In that 30 minutes)
[snip]
4) optionally, if you check the greylist
* Juan Miscaro [EMAIL PROTECTED] [2007-09-27 11:36]:
--- Bob Beck [EMAIL PROTECTED] wrote:
[snip]
greylisting does what it does. It delays the initial email
for 30 minutes or more. what you do with that 30 minutes will decide
on how effective it is for you.
In that 30
Bob Beck wrote:
There is a quasi standard perl script which I have posted and is
available
frequently referenced in the archives of this list, and has already been
mentioned
twice in this thread. it is not standard with OpenBSD because pieces of it
must be customized to be site
Chris Smith wrote:
On Tuesday 25 September 2007, Craig Skinner wrote:
If you are using postfix:
/etc/postfix/main.cf:
..
..
smtpd_recipient_restrictions =
reject_non_fqdn_hostname
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
RW wrote:
What I was getting looked like backscatter and smelled like backscatter
it is just that some of the IPs sending it didn't check out as MTAs.
i.e. they were not listed MXs for the domain they came from AND the
domain was not likely someone with separate outbound senders.
They all
Craig Skinner [EMAIL PROTECTED] writes:
'bots getting smart eh? Bugger! If that is the trend, greylisting
starts to lose its value as spammers adapt to the RFCs.
If they adapt to greylisting and start following relevant RFCs, we've
succeeded in making spamming more expensive. I don't see that
On 26 September 2007, Craig Skinner [EMAIL PROTECTED] wrote:
RW wrote:
What I was getting looked like backscatter and smelled like backscatter
it is just that some of the IPs sending it didn't check out as MTAs.
i.e. they were not listed MXs for the domain they came from AND the
domain
On Wed, 26 Sep 2007, Liviu Daia wrote:
Greylisting is trivial to bypass, with or without a queue: just send
the same messages twice. Some spammers have figured that out long ago.
Ever wondered why sometimes you receive 2 or 3 copies of the same spam,
from the same IP, with the same
On 26 September 2007, Damien Miller [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007, Liviu Daia wrote:
Greylisting is trivial to bypass, with or without a queue: just
send the same messages twice. Some spammers have figured that out
long ago. Ever wondered why sometimes you receive 2 or
Liviu Daia wrote:
How does spamd distinguish between a legitimate retry and a
re-injection of the same message with the same Message-Id, sender etc.?
It doesn't.
Just what you described would probably be within the default 25 mins
grey period. Another delivery attempt would be needed
On Wed, 26 Sep 2007, Liviu Daia wrote:
On 26 September 2007, Damien Miller [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007, Liviu Daia wrote:
Greylisting is trivial to bypass, with or without a queue: just
send the same messages twice. Some spammers have figured that out
long ago.
On 26 September 2007, Craig Skinner [EMAIL PROTECTED] wrote:
Liviu Daia wrote:
How does spamd distinguish between a legitimate retry and a
re-injection of the same message with the same Message-Id, sender
etc.?
It doesn't.
Just what you described would probably be within the
On Wed, 2007-09-26 at 17:02 +0300, Liviu Daia wrote:
Another delivery attempt would be needed after this time to pass
spamd.
Moral: randomize the greylisting time...
Between which min/max valuse? Keep in mind that this corresponds to the
(minimum) delay introduced in delivering a good
Liviu Daia wrote:
Why should it? The second copy is sent in a separate run, that's
the whole point. The only thing the bot has to figure out is how long
to wait until the second run. A smart one would send a second copy
after 10 minutes, and a third one after, say, 35 minutes.
OK, but
On 26 September 2007, Luca Corti [EMAIL PROTECTED] wrote:
On Wed, 2007-09-26 at 17:02 +0300, Liviu Daia wrote:
Another delivery attempt would be needed after this time to pass
spamd.
Moral: randomize the greylisting time...
Between which min/max valuse? Keep in mind that this
On 26 September 2007, Liviu Daia [EMAIL PROTECTED] wrote:
On 26 September 2007, Luca Corti [EMAIL PROTECTED] wrote:
On Wed, 2007-09-26 at 17:02 +0300, Liviu Daia wrote:
Another delivery attempt would be needed after this time to pass
spamd.
Moral: randomize the greylisting
Liviu Daia [EMAIL PROTECTED] writes:
Why should it? The second copy is sent in a separate run, that's
the whole point. The only thing the bot has to figure out is how long
to wait until the second run. A smart one would send a second copy
after 10 minutes, and a third one after, say,
Liviu Daia wrote:
That's up to you. The minimum should be large enough to keep away
naive bots, as it does now. The maximum should be as large as you
can afford without being too anti-social. :) Some crap will still pass
through anyway.
The maximum should also leave plenty of time
On Wed, 26 Sep 2007, Liviu Daia wrote:
On 26 September 2007, Craig Skinner [EMAIL PROTECTED] wrote:
Liviu Daia wrote:
How does spamd distinguish between a legitimate retry and a
re-injection of the same message with the same Message-Id, sender
etc.?
It doesn't.
Just what you
On 2007/09/26 11:03, Dave Anderson wrote:
Or take advantage of the (by default) 25 minute window to use other
means to detect that this address is sending spam. Perhaps spamd should
be extended to look for excessive attempts to send messages from an
address during that period?
google:
Dave Anderson [EMAIL PROTECTED] writes:
Or take advantage of the (by default) 25 minute window to use other
means to detect that this address is sending spam. Perhaps spamd should
be extended to look for excessive attempts to send messages from an
address during that period? (How often do
On Wed, 2007-09-26 at 17:38 +0300, Liviu Daia wrote:
That's up to you. The minimum should be large enough to keep away
naive bots, as it does now. The maximum should be as large as you
can afford without being too anti-social. :) Some crap will still pass
through anyway.
Sometimes is
On Wed, 2007-09-26 at 16:01 +0100, Craig Skinner wrote:
The defaults work very well:
See: http://www.ualberta.ca/~beck/nycbug06/spamd/mgp1.html
Hear: http://www.fetissov.org/public/nycbsdcon06/2.4.mp3
Maybe this also has to do with amount and type of traffic you get.
Small shops are
On 26 September 2007, Peter N. M. Hansteen [EMAIL PROTECTED] wrote:
Liviu Daia [EMAIL PROTECTED] writes:
Why should it? The second copy is sent in a separate run,
that's the whole point. The only thing the bot has to figure out
is how long to wait until the second run. A smart one
Oh, I'm not saying it doesn't work. What I'm saying is, greylisting
is trivial to bypass, and some spammers have figured that out.
Amazingly, most of them still haven't, which is why it still works in a
significant number of cases.
greylisting does what it does. It delays the
On Wed, 26 Sep 2007, Liviu Daia wrote:
Same, 28 minutes later:
Sep 25 18:42:52 ns1 postfix-localhost/smtpd[13055]: 72BCD142A7:
client=unknown[212.239.40.101]
Sep 25 18:42:53 ns1 postfix/cleanup[21622]: 72BCD142A7: message-id=[EMAIL
PROTECTED]
Sep 25 18:42:53 ns1 postfix/qmgr[1554]:
On 26 September 2007, Jeremy C. Reed [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007, Liviu Daia wrote:
Same, 28 minutes later:
Sep 25 18:42:52 ns1 postfix-localhost/smtpd[13055]: 72BCD142A7:
client=unknown[212.239.40.101]
Sep 25 18:42:53 ns1 postfix/cleanup[21622]: 72BCD142A7:
On 26 September 2007, Bob Beck [EMAIL PROTECTED] wrote:
Oh, I'm not saying it doesn't work. What I'm saying is,
greylisting is trivial to bypass, and some spammers have figured
that out. Amazingly, most of them still haven't, which is why it
still works in a significant number of
Oh, I'm not saying it doesn't work. What I'm saying is, greylisting
is trivial to bypass, and some spammers have figured that out.
Amazingly, most of them still haven't, which is why it still works in a
significant number of cases.
Just to give an additional data point here: I work for
Hi!
On Wed, Sep 26, 2007 at 02:03:03PM -0700, Rob wrote:
[...]
While watching the connection logs, I've noticed that a large majority
of spammers get the first spamd response (250 Hello, spam sender.
Pleased to be wasting your time.) and immediately disconnect. This
suggests to me that rather
Hannah,
On 9/26/07, Hannah Schroeter [EMAIL PROTECTED] wrote:
Hi!
On Wed, Sep 26, 2007 at 02:03:03PM -0700, Rob wrote:
[...]
While watching the connection logs, I've noticed that a large majority
of spammers get the first spamd response (250 Hello, spam sender.
Pleased to be wasting your
Rob [EMAIL PROTECTED] writes:
I would guess the latter too, except that they tend to wait the full
default 10 seconds until the first 250 response. I'm looking forward
to increasing the stutter time to something on the order of 60 seconds
and watching to see what happens then.
I have reports
On Wed, 26 Sep 2007 17:26:22 +0200, Peter N. M. Hansteen wrote:
Or take advantage of the (by default) 25 minute window to use other
means to detect that this address is sending spam. Perhaps spamd should
be extended to look for excessive attempts to send messages from an
address during that
On 9/23/07, Peter N. M. Hansteen [EMAIL PROTECTED] wrote:
patrick keshishian [EMAIL PROTECTED] writes:
I'm running spamdb in greylist mode, but these servers were
getting white-listed very quickly.
Then it sounds almost like you were running with a too short passtime,
but then that's easy
patrick keshishian [EMAIL PROTECTED] writes:
When you speak of misconfigured mail servers bouncing spam,
what exactly is a proper configured mail server supposed to
do with spam directed at non-existing user @their-host-name?
The real question in there is, what does a properly configured mail
patrick keshishian wrote:
I'm very certain right now, this flood is due to a spammer
using these fake addresses @my-domain-name to spam these mail
server (all around the world -- Japan, South America, US,
Germany, Ireland, etc...) and I'm getting the brunt of it in
the form of these bounced
1 - 100 of 176 matches
Mail list logo
