Ask Bjørn Hansen wrote:
As John said, the databytes configuration should do what you are
asking. It'll reject the message right away if the sender uses the
extension that specifies the size in MAIL FROM and if not then it'll
stop buffering the data after the configured number of bytes has been
As John said, the databytes configuration should do what you are
asking. It'll reject the message right away if the sender uses the
extension that specifies the size in MAIL FROM and if not then it'll
stop buffering the data after the configured number of bytes has been
received (and then reject
On Jul 11, 2008, at 3:00, Jared Johnson wrote:
Hi,
I've noticed that our qpsmtpd-based product is not handling
extremely large messages particularly well. This was brought on by
a flood of delay notices for a 495MB message sent outbound through a
server not under our control. There are
On 2008-07-11 05:00:06 -0500, Jared Johnson wrote:
> I've noticed that our qpsmtpd-based product is not handling extremely
> large messages particularly well. This was brought on by a flood of
> delay notices for a 495MB message sent outbound through a server not
> under our control. There are a
Jared Johnson wrote:
it occurs to me that the most appropriate thing would be to drop a
connection and stop listening when we have received what we consider
to be too much data after the DATA command.
That would be a major violation of the applicable RFC, and as such I
don't think it would be
Hi,
I've noticed that our qpsmtpd-based product is not handling extremely large
messages particularly well. This was brought on by a flood of delay notices
for a 495MB message sent outbound through a server not under our control.
There are a number of fixes in the pipeline, but it occurs to m
