On 10 Jun 2016, at 3:40, Merijn van den Kroonenberg wrote:
On 9 Jun 2016, at 0:53, Henrik K wrote:
Garbage text/plain is known problem..
text/html too. From GMail.
Last week I had a *perfectly legitimate* message with a 151KB logical
single line of HTML (QP encoded of course) freeze up a se
On 9 Jun 2016, at 1:40, Olivier wrote:
Mark London writes:
On 6/8/2016 1:20 PM, John Hardin wrote:
On Wed, 8 Jun 2016, Mark London wrote:
Hi - We received an email with several large postscript
attachments,
and the content type was "text/plain". This caused our
spamassassin
Sorry to ju
On Fri, 2016-06-10 at 18:26 -0400, Bill Cole wrote:
> It will be interesting to see the stats on scantimes this week to see
> if my tightening up on sloppy rules has an impact. I expect it will,
> since I now have a concrete theory to explain that long tail out to 2
> minutes, which before now I've
Merijn van den Kroonenberg wrote on 10/06/16 10:17 PM:
> What does this mean, can still a single operation take more than this
> time_limit?
There is a fundamental difficulty in perl that the built-in timer alarm
facility cannot always interrupt the built-in regular expression matching
facility. T
On 10 Jun 2016, at 6:17, Merijn van den Kroonenberg wrote:
[...]
From the manual:
This is a best-effort advisory setting, processing will not be
abruptly
aborted at an arbitrary point in processing when the time limit is
exceeded, but only on reaching one of locations in the program flow
equi
>
>
> Am 10.06.2016 um 04:49 schrieb Bill Cole:
>> On 9 Jun 2016, at 0:53, Henrik K wrote:
>>
>>> Garbage text/plain is known problem..
>>
>> text/html too. From GMail.
>>
>> Last week I had a *perfectly legitimate* message with a 151KB logical
>> single line of HTML (QP encoded of course) freeze u
Am 10.06.2016 um 04:49 schrieb Bill Cole:
On 9 Jun 2016, at 0:53, Henrik K wrote:
Garbage text/plain is known problem..
text/html too. From GMail.
Last week I had a *perfectly legitimate* message with a 151KB logical
single line of HTML (QP encoded of course) freeze up a server scaled for
> On 9 Jun 2016, at 0:53, Henrik K wrote:
>
>> Garbage text/plain is known problem..
>
> text/html too. From GMail.
>
> Last week I had a *perfectly legitimate* message with a 151KB logical
> single line of HTML (QP encoded of course) freeze up a server scaled for
> 10k users.
> [snip]
Are there p
On 9 Jun 2016, at 0:53, Henrik K wrote:
Garbage text/plain is known problem..
text/html too. From GMail.
Last week I had a *perfectly legitimate* message with a 151KB logical
single line of HTML (QP encoded of course) freeze up a server scaled for
10k users. It did it slowly over a day, bec
Mark London writes:
> On 6/8/2016 1:20 PM, John Hardin wrote:
>> On Wed, 8 Jun 2016, Mark London wrote:
>>> Hi - We received an email with several large postscript attachments,
>>> and the content type was "text/plain". This caused our
>>> spamassassin
Sorry to jump in, but should SA trust t
On Thu, Jun 09, 2016 at 12:16:11AM -0400, Mark London wrote:
> On 6/8/2016 1:20 PM, John Hardin wrote:
> >On Wed, 8 Jun 2016, Mark London wrote:
> >>Hi - We received an email with several large postscript
> >>attachments, and the content type was "text/plain". This
> >>caused our spamassassin s
On 6/8/2016 1:20 PM, John Hardin wrote:
On Wed, 8 Jun 2016, Mark London wrote:
Hi - We received an email with several large postscript attachments,
and the content type was "text/plain". This caused our spamassassin
server to use up 100% CPU, parsing the attachments as text. I
temporarily
On 6/8/2016 1:20 PM, John Hardin wrote:
On Wed, 8 Jun 2016, Mark London wrote:
Hi - We received an email with several large postscript attachments,
and the content type was "text/plain". This caused our spamassassin
server to use up 100% CPU, parsing the attachments as text. I
temporaril
On Wed, 8 Jun 2016, Mark London wrote:
Hi - We received an email with several large postscript attachments, and the
content type was "text/plain". This caused our spamassassin server to use
up 100% CPU, parsing the attachments as text. I temporarily disabled spam
scanning to allow the mes
Hi - We received an email with several large postscript attachments,
and the content type was "text/plain". This caused our spamassassin
server to use up 100% CPU, parsing the attachments as text. I
temporarily disabled spam scanning to allow the message to go through.
How can I prevent
15 matches
Mail list logo
