[24744] in SIPB bug reports
Re: spam-inc bug
daemon@ATHENA.MIT.EDU (chad brown)
Tue Mar 22 10:48:03 2005
From y@MIT.EDU Tue Mar 22 15:48:03 2005
Return-Path: <y@MIT.EDU>
Delivered-To: bug-sipb-mtg@CHARON.mit.edu
Received: (qmail 16494 invoked from network); 22 Mar 2005 15:48:03 -0000
Received: from biscayne-one-station.mit.edu (18.7.7.80)
by charon.mit.edu with SMTP; 22 Mar 2005 15:48:03 -0000
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j2MFlc5F008311
for <bug-sipb@mit.edu>; Tue, 22 Mar 2005 10:47:38 -0500 (EST)
Received: from [192.168.1.101] (209-94-133-129.c3-0.bkl-ubr2.sbo-bkl.ma.cable.rcn.com [209.94.133.129])
(authenticated bits=0)
(User authenticated as yandros@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.12.4/8.12.4) with ESMTP id j2MFlV0Z015155
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
for <bug-sipb@MIT.EDU>; Tue, 22 Mar 2005 10:47:31 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <200503221515.j2MFFDkv014820@multics.mit.edu>
References: <200503221515.j2MFFDkv014820@multics.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5f560f0e1176b1835ee4630c928c8e41@mit.edu>
Content-Transfer-Encoding: 7bit
From: chad brown <y@MIT.EDU>
Subject: Re: spam-inc bug
Date: Tue, 22 Mar 2005 10:47:27 -0500
To: bug-sipb@mit.edu
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: -4.9
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
MH commands refuse to do permanent operations on 999 or more messages
as a matter of policy. It's intended to be a safety net. The only way
that I recall to bypass this restriction is to recompile mh.
If this is a concern, the script will have to check and loop. In my
own scripts, back in the day, I just always handled these operations in
chunks of 666 messages (safety be damned!).
*chad
On 22 Mar, 2005, at 10:15, Abbe Cohen Dvornik wrote:
>
> If the spam-inc script (/mit/sipb/arch/sun4x_59/bin/spam-inc) finds
> more than 998 messages, the refile +spamfolder in the script will
> fail, and the spam and non-spam will both remain in the inbox.
>
> This is because refile and rmm cannot handle more than 998 messages
> (don't ask me why.)
>
> I wasn't paying too much attention when this happened, but it looked
> to me like all of the output from the script looked perfectly normal,
> so I didn't even realize it until noticing that 90% of my new mail was
> spam and was flagged as spam. In manually refiling it with pick, I
> got the "more than 998 messages" error message for refile and realized
> that it was probably the suspect.
>
> I haven't looked over the script other than verifying that it is using
> refile, but someone might want to investigate.
>
> --Abbe
