Mailman 3 July 2002 - Mailman-Developers

Re: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering
by J C Lawrence 31 Jul '02

31 Jul '02

On Tue, 30 Jul 2002 22:46:45 -0700 J C Lawrence <J> wrote: > On Tue, 30 Jul 2002 22:30:12 -0700 J C Lawrence <J> wrote: >> I'm writing this now as the discussed configuration appears to work >> and I'd rather document it now while its still fresh in my mind then >> later when its not. If any big bugs or required changes surface I'll >> post on those later to the mailman-developers list. > Its now section 6.7 in the mailman user FAQ: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.007.htp If you want to play with a list set up this way I still have my list installation running. Give me a shout and I'll send over the addresses etc. Abusers will of course get blacklisted. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: Opening up a few can o' worms here...
by Ka-Ping Yee 30 Jul '02

30 Jul '02

Barry wrote: > Do you want to attempt to obscure the > address (e.g. "barry--at--python--dot--org") Chuq wrote: > Anything you programmatically obscure will be programmatically > de-obscured. I don't think this is entirely true. This is probably true if you invent ways of rearranging text that is still readable as an e-mail address, but one possible good solution is to use an image instead. If you generate an image containing the entire e-mail address, it can be made extremely hard to read, even with state-of-the-art OCR. And it raises the bar so high that it will be a long time before spammers bother to even try OCR -- it's much too easy to harvest addresses in other, simpler ways. Just to give you an idea of what tricks are possible: a GIF can contain many different colour table entries that map to almost the same colour; the background can be patterned; the text can be distorted or blurred; the text can be drawn shadowed or embossed; the text can be broken into multiple frames of a GIF animation; etc. etc. Many of these things can be done subtly enough that the text is still trivial for anyone to read, yet it becomes phenomenally difficult for a machine to decode -- to the point where the spammer's best bet is to take a video capture of the screen, print it out, run it through a scanner, and run a fancy OCR program on the result. -- ?!ng

8 17

Re: [Mailman-Developers] Cute TMDA use
by Donal Hunt 30 Jul '02

30 Jul '02

mailman-developers-request(a)python.org wrote: ------------------------------------------------------------------------ > Subject: Re: [Mailman-Developers] Cute TMDA use > Date: Mon, 29 Jul 2002 22:29:29 -0400 > From: barry(a)python.org (Barry A. Warsaw) > To: Chuq Von Rospach <chuqui(a)plaidworks.com> > CC: J C Lawrence <claw(a)kanga.nu>, <mailman-developers(a)python.org> > References: <15685.53303.972678.484832(a)anthem.wooz.org> > <B96B225E.4ACED%chuqui(a)plaidworks.com> > > Ah wait, I see what you're suggesting. A confirmed non-member > wouldn't get added to accept_these_nonmembers, but their message would > not show up in the admindb until they've confirmed. > > The messages would be in a sort of limbo until them, with > timeout/auto-discards if they don't confirm after a certain amount of > time. Once they've confirmed, we'll do the normal non-member action > (although it would make little sense to go through this rigamarole if > we're simply discarding or rejecting non-member postings). > > Maybe the admindb should have a button that would let them see all > held message, including non-confirmed ones? Perhaps that's a YAGNI. > > Have I got that right? I'll think on it and try to decide whether > it's worth adding to 2.1 or not. > > -Barry > > ------------------------------------------------------------------------ The above would be great!! We currently have a problem with students (university environment) sending "spam" to hundreds of lists so they can find a room mate!! We've stopped it by reducing the number of lists a person can post to at the same time. However, the side effect is that the list admin (one for all the student lists) gets mailed hundreds of times because there is one pending message for each list!!! So we wrote a script to clear the pending messages log. :) The above would be fierce handy as the list admin wouldn't get mailed about unconfirmed emails until they were confirmed... And if someone got 200+ confirmation mails it's unlikely the messages would ever be seen by the list admin. "This would be a good thing"(tm). :) The central userbase (if it included the admins too) would mean admins would get one email about all the pending messages for their lists and perhaps one webpage for confirming/rejecting (ie multiple list all on the same page / login) would be excellent too. Anyway... that's further down the road - let's keep our eye on the 2.1 ball!! Donal DCU

4 5

Adding exception to html-stripping in the archive
by Laurence Berland 30 Jul '02

30 Jul '02

All, I posted this earlier, but it was sort of buried in an email about not necessarily related things. Here's what I'm trying to do: I've already written code that filters the messages on their way to the archiver, substituting based on regular expressions. It does this in the Queue/ArchRunner.py file, in just about the last spot before the actual archiver gets called. It can't go in the archiver, because it needs to be able to read the mlist variable for configuration and such. I need to be able to use a regular expression to substitute in a snippet of html code. This could be used for several things, but my intention is to use it to add an img tag. Is there a way to configurably get around the html-sanitizing done by the archiver in some non-kludge way? TIA, Laurence

1 0

Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 11:47:07 -0600 Jason R Mastaler <Jason> wrote: > J C Lawrence <claw(a)kanga.nu> writes: >> Note: SF is likely going to have severe performance problems with the >> current flatfile list implementation. Odds are that they're going to >> want a persistent SQL-backed implementation due to their size. > What flatfile list implementation are you referring to? I failed to noticed the cdb/dbm/etc list code. Ooops. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] Re: Opening up a few can o' worms here...
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 10:22:39 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > On 7/30/02 10:14 AM, "J C Lawrence" <claw(a)kanga.nu> wrote: >> Building the archives (even if not the list) with dated or sender >> addresses TMDA-style starts seeming quite attractive. > Actually, we're putting everything behind a CGI that'll enforce our > policies. That way, if the policies change, only the CGI has to be > modified, not the archives. And we don't have to modify the archives > -- which is problematic if you take stuff out that later you decide > ought to be there. An unmodified archive is a lot easier to deal > with. Yeah, I get the same end by a MVC abstraction in my (currently) PHP template processing code. The raw PHP file generated by MHonArc is, well, raw. The external globally shared code that does the actual render to HTML etc can re-wrap/re-present etc as desired. (Which is really just making a false distinction between PHP pages using shared code and a CGI). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
by J C Lawrence 30 Jul '02

30 Jul '02

On Mon, 29 Jul 2002 20:06:49 -0700 (PDT) Dan Mick <dmick(a)utopia.West.Sun.COM> wrote: > Probably missing something again. But I'm on very few lists that > share a server, so I'd expect the normal behavior of "one confirm per > list per alien address" behavior anyway (I think the only multilist > server I communicate with is python.org). SourceForge is the other canonical case. Note: SF is likely going to have severe performance problems with the current flatfile list implementation. Odds are that they're going to want a persistent SQL-backed implementation due to their size. :nudges Marc. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

2 1

Re: [Mailman-Developers] Re: Opening up a few can o' worms here...
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 09:57:47 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > (this is one reason why, for instance, we are reinventing our archive > system to remove the passwords we're currently using to keep the bots > out. Because that's a system that doesn't really solve the problem, > any more than a "do not enter" sign on an unlocked door stops a > burglar. It only stops stupid burglars.) Building the archives (even if not the list) with dated or sender addresses TMDA-style starts seeming quite attractive. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

2 1

Re: [Mailman-Developers] Cute TMDA use
by Donal Hunt 30 Jul '02

30 Jul '02

Dan Mick wrote: > > > The above would be great!! We currently have a problem with students > > (university environment) sending "spam" to hundreds of lists so they can > > find a room mate!! > > ...And note that this is an argument for list-specific (i.e. non-global) > whitelists, as "just because you can post to the alt.magic.i-have-no-life > list doesn't give you the right to post to wedding-planners, just because > they happen to share disk space on the same host cluster". Most definately. Donal DCU

1 0

Re: [Mailman-Developers] Off topic: a cautionary tale.
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 08:34:50 -0400 (EDT) Dale Newfield <Dale(a)Newfield.org> wrote: > I've thought for a while that phpMyAdmin was making a mistake with GET > links for all those actions--they should be POST buttons, and spiders > would not be able to do this. It is making a mistake. W3C specs state that only POSTs may have side effects, not GETs. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0