There are dozend of reasons why this can happen.
Most common is 'PenaltyExpiration'.
If there is a good mail transfered by an IP, the IP score is deleted to
prevent false positives. Where good means - no doubed, like 'contentOnly',
RWL, SPF, DKIM
Thomas.
Von:"Dirk Kulmsee"
An:
Hi Thomas,
if there was a good message causing this, then I should see the IP in
question in my log before the drop. But there is not a single line.The score
is high, nothing happens, the score is low.
This happened again today and I grep'ed the log for e.g. 118.71.251
(leaving out the last byte
The PBBlack record is removed after 'PenaltyExpiration' minutes of the
record creation (NOT the last update).
Thomas
Von:"Dirk Kulmsee"
An: "'ASSP development mailing list'"
Datum: 03.10.2016 10:19
Betreff:Re: [Assp-test] PB-IP-Score suddenly dropping
Hi Thomas,
if th
Hi Thomas,
I've put 16275 on one of my servers this morning. I'm seeing the no running
workers error every 10-20 minutes causing ASSP to shut down. I've sat there
with the worker status page open and I'm not seeing any workers getting
stuck that coincide with this problem. In fact when the error i
Hi Thomas,
thanks for explaining this behaviour. Let's see if I get this right...
Let's assume an IP reveals constant misbehaviour adding a PB-IP-Score of 60
every hour. It started off at 0 so after 6 hours (default PenaltyExpiration)
the score would be 360 and rising, but *surprise* after Penelty
>Wouldn't it be better to have a "gliding" score, i.e. with every
nice idea - thrown away in 2008 for the PBBlack
for some temporary hashes (domainIP ... outgoing mail limiter ) it is
done this way
assume the IP has been connected 100 times - we'll get something like
time1 value1 time2 valu
Hi all,
fixed in assp 2.5.4 build 16277:
changed:
- for all SSL/TLS connection a 'read ahead' mechanism is implemented to
speed up mail processing
for small SSL-frame size (< 8kB) - at least by ten times
added:
- 'neverQueueSize','Never internaly Queue Mails larger than this Size'
Default
>action: header (Content-Disposition -attr)
2.5.4 16277 will no longer use this output to state the worker
please post the line produced with the current build
"action: header (Content-Disposition -attr)" may be stated by a virus or
attachment check, done in the body check of assp.pl or the ASS
Hi Thomas,
I've got 16277 running straight away. Oddly I've not been able to get
connected to the GUI on either server since upgrading I just get timeouts.
I'm not entirely convinced this build is working properly for me. I'm
seeing only one email every few minutes rather than the constant output
Hi Thomas,
After upgrading to this build ASSP was only listening on my internal
private subnet and was not accepting connections from the outside world.
I've had to go straight back down to 16275.
On Mon, Oct 3, 2016 at 1:44 PM, Thomas Eckardt
wrote:
> Hi all,
>
> fixed in assp 2.5.4 build 162
Okay, I'm back to standard logging on ClamAV then
Thanks
On Mon, Oct 3, 2016 at 2:55 AM, Thomas Eckardt
wrote:
> >1) Is verbose logging slowing things
>
> The MainThread goes slower than more is logged
>
> >1) and causing the daemon to be unreachable
>
> No.
>
> >1) is this happening with st
I'm sure, there is no change in build 16277 than can cause this.
Thomas
Von:cw
An: ASSP development mailing list
Datum: 03.10.2016 15:39
Betreff:Re: [Assp-test] fixes in assp 2.5.4 build 16277
Hi Thomas,
After upgrading to this build ASSP was only listening on my intern
Hi Thomas,
I don't know what is going on. I've dropped back to 16275 and external
email starts working again but it is extremely slow. I can't get to the GUI
and output to the maillog is slow.
I've even dropped back to 16270 and it is still the same. Are there any
caches or database entries that
I've been watching what the process is doing. It seems to be writing to the
logfiles, or failing to. I have this:
write(63, "2016-10-03 15:41:31 [Worker_7] <"..., 102) = 102
This repeats 999 times until:
write(63, "2016-10-03 15:41:39 [Worker_7] <"..., 101) = 101
There is no line with a matchin
Hi Thomas,
Cracked it. It turns out it is all down to debugging. I remembered I turned
that on at the same time as upgrading the version. I've turned that off
again and both ASSP instances are back up to full speed. Phew.
Not sure why debugging had such a major impact, it never has before and
I'v
15 matches
Mail list logo