On 10/25/06 1:11 AM, "Peter J. Holzer" <[EMAIL PROTECTED]> wrote:
> On 2006-10-24 20:44:04 -0500, Peter Eisch wrote: >> On 10/24/06 8:23 PM, "Ask Bjørn Hansen" <[EMAIL PROTECTED]> wrote: >>>> I propose in the TODO the ability to clock the time it takes for >>>> spamd to scan an email. A month or so ago there was a thread about >>>> this and I forgot I had such a mechanism in my spamassassin plugin. >>>> Rather than pollute this patch with its already suspect sprintf and >>>> sed. I can submit that as a subsequent patch. >>> >>> I don't get it. Is "spamd is overwhelmed" a sign the mail was spam? >>> Or are you talking about handling timeouts from spamd with a 451 >>> response to the smtp client? > > But you would have to issue the 451 before passing the mail to spamd. > Otherwise you'll just exacerbate the problem by scanning lots of mails > where the result won't ever be used. > I came at the problem from users getting multiple copies of email. After tracking the problem it was clear that client had gone away at some point during the scan. The queuing unfortunately still took place. While one spamd spun out of control, other incoming would get delivered multiple times. The sending MTA would simply retry later. If spamd chewed for an hour on an email and eventually returned, the mail was queued to the recipient. The resulting 250 Queued would be written to a dead socket. The recipient would then receive that email multiple times. These were typically larger email but small enough to be scanned. It would be best there were a way to "ping" the sending MTA to ensure that if you continue on to queue the message that it will be there to receive the confirmation that the message was queued. Then all the traps of timing could obviously go away. If there is a way to do that (even an inkling?) I would pursue that and dump the timing of processing other than for statistical purposes. > >> I've seen emails crafted that spin spamd off only to return 4 minutes >> later. When I've seen this happen, new versions of spamassassin soon >> appear with emails citing http://secunia.com/advisories/20430/ as a >> reference. (as an example) > > ITYM http://secunia.com/advisories/15704/ (20430 is a code injection > issue). > Correct, thank you. peter
