#431489 Provide option to set timeout.

Package:
maildrop
Source:
maildrop
Description:
mail delivery agent with filtering abilities (set-GID=mail)
Submitter:
Reuben Thomas
Date:
2025-08-22 15:09:02 UTC
Severity:
wishlist
Tags:
#431489#5
Date:
2007-07-02 22:39:56 UTC
From:
To:
maildrop has a global timeout that seems to be intended to stop
non-terminating or excessively long-running filters. However, it also
stops arbitrarily long messages being fetched on my system, because
the mail fetcher pipes the message directly into maildrop. Hence, if
the message takes too long to fetch, maildrop times out. It seems to
me that maildrop needs some idea of how much CPU time it has used (or
some other way of telling it has been running a filter), not merely
how long it has waited.
#431489#10
Date:
2012-06-02 12:26:11 UTC
From:
To:
severity 431489 wishlist
retitle  431489 Provide option to set timeout.
thanks

Hi,

As documented in maildrop(1) manpage:

 WATCHDOG TIMER
   maildrop has a watchdog timer that attempts to abort runaway filtering.
   If filtering is not complete within a predefined time interval (defined
   by the system administrator, usually five minutes), maildrop
   terminates.

Thus, this time out is an upstream design feature.

As I see it, if this value is only set as constant via compilation
constant now.  If you come up with a patch to set it via commandline
option, this can be solved.  So I retitke and mark this as a wishlist
feature request.  patch welcome :-)

Osamu
#431489#21
Date:
2025-07-10 23:21:11 UTC
From:
To:
Reuben,

I recently took over maintenance of the maildrop package.  Can you confirm if
this but still exists in the current versio of maildrop (3.1.8-2)?
#431489#24
Date:
2025-07-10 23:21:11 UTC
From:
To:
Reuben,

I recently took over maintenance of the maildrop package.  Can you confirm if
this but still exists in the current versio of maildrop (3.1.8-2)?
#431489#29
Date:
2025-07-11 11:28:32 UTC
From:
To:
I had a look at the source, and the problem appears to remain.
#431489#34
Date:
2025-07-11 11:28:32 UTC
From:
To:
I had a look at the source, and the problem appears to remain.
#431489#37
Date:
2025-07-11 11:28:32 UTC
From:
To:
I had a look at the source, and the problem appears to remain.
#431489#42
Date:
2025-07-11 17:33:41 UTC
From:
To:
Reuben,

Thank you for taking the time to look at the source.

This sounds like an upstream feature request.  I have a hard time imagining
how a 5 minute timeout would cause problems for the processing of an
individual email, but if you can provide a compelling use case I would
recommend you file an upstream feature request.  If you decide to do so,
please post a link to it in this bug report.
#431489#47
Date:
2025-07-11 20:56:49 UTC
From:
To:

It's very easy to imagine, at least 18 years ago, when dialup internet
access was more common than today, "broadband" started at 128kbps, and yet
emails with attachments could still be several megabytes!
#431489#52
Date:
2025-07-11 21:21:08 UTC
From:
To:
On Friday, July 11, 2025 1:56:49 PM Mountain Standard Time Reuben Thomas wrote:

I could see that being the case 18 years ago, but I have a hard time imagining
it now.  In any case, upstream is who you need to convince.
#431489#57
Date:
2025-08-22 15:07:21 UTC
From:
To:
I am going to close this bug report as it doesn’t appear to be a problem in
the modern world.  If anyone is still experiencing this issue, I would
recommend you raise it as an upstream feature request.