On 11/30/01 11:18 PM, "Barry A. Warsaw" <[EMAIL PROTECTED]> wrote:
> B> I'm not so sure if doing an estimated average of messages sent > B> is the right thing. > > Me neither. It /seems/ reasonable... It is, but it's lots of work. How about something simpler: Timestamp the FIRST bounce on each day. Then, track bounces for N days (N being configurable per list). If you're allowing a user to bounce for 3 days, then if you have a bounce for day N, and day N-3, then you have a match and the user is disabled. At some time longer than N days, bounce timestamps are deleted, since they're no longer valid. You can set a default value for the 'typical' list as the default. I tend to think that any moderately busy list (say, more than 2-3 messages a day) would be handle by N=3 to N=5, depending on whether you want to avoid the possibility of long-weekend-daemon breakage or not. Then add in the "soft bounce = .5 bounce", and soft bounces would extend N. And digests, do they need to be handled differently? I tend to think so. For digests, to be careful, I'd probably start them at soft-bounce, and if their bounces ARE soft, go to .25 bounce... Trying to count messages and then figure out some percentage of them as having bounced, and etc -- I think from my experience it's overkill. You get almost all of that by keeping track of "we have records of bouncing over this period of time....". You might occasionally nail a person who's system is bouncing every 8th message or some godawful thing, but IMHO, that person ought to thank you for helping them find that out... For announce, moderated and or things like e-newsletters, with very low volumes, an admin would have to decide what N should be, and likely, set it longer. You might want to keep track of them for 14 days, and if you've bounced at least twice in that time (once 14 days ago, once today), that constitutes a legitimate bounce. For something like an e-newsletter, N might even be 45 or 60 days: imagine a once-a-month beast where you want at least two bounces to prove it's dead. Hmm. That brings up a glitch in my design. If you have < 1 posting a day, that first posting has to be within some "window" around that N days, you can't depend on it being exactly N days away. So you really need some kind of way of saying "Bounces N days apart, with at least M bounces in that time, and the first bounce within Q days" -- 60 days, 3 or more recorded bounces, first bounce within 5 days of "N". Make sense? It's still a much simpler accounting system than we currently have, or one that requires tracking what the list does, and trying to guess what bounces should do from that. Let the admin define the policy, which boils down to "how long", "minimum # of bounces in then" and "granularity" (for lack of a better word) > If I understand your approach correctly, the problem is that bounces > may be clumped and may not be correlated in time with the postings > that causes them. This is correct. There are some sites (not as prevalant as it once was) that only send back bounces and admin mail during "off" hours. Since most of them seemed to be european, of course, it meant their bounces showed up in MY prime time, but that's not their problem.... (grin). You can't depend on bounces returning in any kind of "reliable" stream. > I'm more concerned with the user who fills up his disk and doesn't > notice it for a week because they're on vacation. I'd like Mailman to > be robust against this, and I think the average non-deliveries over a > couple of weeks, with consignment to probation probably catches most > of this use case. The above handles that, especially if you throw in the "soft bounce" factoring... You can set "N" to a week, or ten days, if you don't mind having more bounces flowing in and out of the system. But users who need to minimize throughput or are more willing to be strict can cut it shorter. (one other thought, which some mailers do. When bounces START, switch them to digest mode. It cuts the overhead on all sides, and allows them a cahnce to fix things before disabling, without all those bounces and etc rolling around... ) _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
