Re: [Mailman-Developers] Put admin_member_chunksize in GUI

2006-01-28 Thread Mark Sapiro
Tokio Kikuchi wrote: >No reason, maybe. But, I just don't want to add a new language catalog >entry and re-generate whole .po files for 2.2 now. :-( Actually, that's probably just as well. I started looking at it and the obvious place to put it is on the membership list page, but that isn't qui

Re: [Mailman-Developers] Put admin_member_chunksize in GUI

2006-01-28 Thread Tokio Kikuchi
Mark Sapiro wrote: > Is there any reason to not put admin_member_chunksize in the GUI? > > It doesn't do the job requested in > , > but it helps. > > Is there a fear that some unsuspecting list owner will se

[Mailman-Developers] Put admin_member_chunksize in GUI

2006-01-28 Thread Mark Sapiro
Is there any reason to not put admin_member_chunksize in the GUI? It doesn't do the job requested in , but it helps. Is there a fear that some unsuspecting list owner will set it too big? -- Mark Sapiro <[

Re: [Mailman-Developers] Scrubber mungs quoted-printable revisited.

2006-01-28 Thread Tokio Kikuchi
Hi Mark, Mark Sapiro wrote: > Recently, I looked in more detail at the actual set_payload() method in > the email library and I have at least a vague understanding of the > problem. The problem and my understanding are reported at >

Re: [Mailman-Developers] [ mailman-Bugs-1416853 ] Jan 14 change toHandlers/SpamDetect.pyisincomplete

2006-01-28 Thread Mark Sapiro
Mark Sapiro wrote: > >Perhaps we could test if msg.get_sender() == mlist.GetOwnerEmail(), and >discard in that case only, but I'd want a somewhat different test in >case the sender's domain were not identical - something like > >if msg.get_sender().split('@')[0] == \ > mlist.GetOw

Re: [Mailman-Developers] [ mailman-Bugs-1416853 ] Jan 14 change toHandlers/SpamDetect.pyisincomplete

2006-01-28 Thread Mark Sapiro
Dan Astoorian wrote: > >Personally, I'm of the opinion that it's wrong ever to use a reject rule >for spam filtering in the first place, since so much spam has forged >sender information anyway, but debating that is well beyond the scope of >how this bug should be fixed. I think we all agree that