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
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
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
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.
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
>
>
> 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
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
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,
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,
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
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
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
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
14 matches
Mail list logo