[Mailman-Developers] Re: add to FAQ? - mailman full raw archive mboxes not anti-spammed
thanks :) - done: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.034.htp (but now i've got my email spammably posted to the RCS :( ) On Wed, 18 Feb 2004, Terri Oda wrote: > I don't think the explanation of how to do this belongs in the user > manual, which is the only documentation I've written currently (and I This page of the user manual has the title: http://www.list.org/mailman-member/node40.html > 11.2 What does Mailman do to help protect me from unsolicited bulk > email (spam)? My guess in version 2.1.4 is that the file archtocnombox.html has to be chosen sometime during installation if the user wishes to use it. Doesn't this mean it should be in the user manual under this question? Or is it too technical a question? Maybe a developer should add some comment to the INSTALL file or a README.* ? grep archtocnmbox mailman-2.1.4/* gives no hint at all. boud ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] Re: add to FAQ? - mailman full raw archive mboxes not anti-spammed
I don't think the explanation of how to do this belongs in the user manual, which is the only documentation I've written currently (and I assume why you specifically CC'ed me on this message), but the FAQ is a good place for now since the other manuals for 2.1 haven't been completed. If you haven't seen it already, the user-addable FAQ is available at http://www.python.org/cgi-bin/faqw-mm.py Please do put the info there if it isn't already, since I'm sure this'll be handy for other people. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] Re: add to FAQ? - mailman full raw archive mboxes not anti-spammed
On Thu, 19 Feb 2004, boud wrote: > e.g. > http://mail.python.org/pipermail/mailman-announce/ has no *.mbox/*.mbox > In fact, > http://mail.python.org/pipermail/mailman-announce.mbox/ > exists but nothing in it is accessible. In fact the mbox file *does* exist and is accessible if you look in the obvious place: (add in "mailman-announce.mbox" after ".mbox/") i won't write the URL directly because i don't want to point google to it. So 2.1.4 is not as safe from spiders/harversters as it could be. boud ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] add to FAQ? - mailman full raw archive mboxes not anti-spammed
hi mailman people, terri, i looked for information regarding archtocnombox.html relating to the problem of a full raw mbox archive being non-antispammed, but couldn't find any discussion. It's clear somebody has thought about it, since the file exists. Are there any plans (or any options already present) to have the full raw mbox archive, but corrected for "@" -> " at " (maybe other obvious corrections too), to be made available like the raw spammable version is available if the archtocnombox.html template is not chosen? It seems to me that this should be made an obvious option - or else that the default should be that the full raw archive .mbox is *not* available. At least, could info on this be added to the FAQ somewhere, so that people can easily find out what has already been done? E.g. > 11.2 What does Mailman do to help protect me from unsolicited bulk > email (spam)? http://www.list.org/mailman-member/node40.html i've added a comment on barry warsaw's wiki pages: http://zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanProblems and below is my own analysis. thanks boud (convert from sympa to mailman ;) PS: Sorry if this should be to mailman-users rather than mailman-developers, but it seems to me like a developers' issue. -- SPAM PROBLEM: HYPOTHESIS SOLUTION 2.1.4 HACK SOLUTION 2.0.11 (AND PROBABLY 2.1.1) (1) remove link to *.mbox in /var/lib/mailman/Mailman/Archiver/HyperArch.py (2) remove compiled versions HyperArch.py[oc] (3) test on an archive (e.g. imc-pl-tech ;) (4) make the *.mbox/*.mbox files inaccessible (since google links remain) (5) think about newlist s (maybe nothing needs doing) SPAM PROBLEM: i think this is a known spam problem - by default, it looks like the archive files linked under "download the full raw archive" like the following etc are NOT antispammed: http://lists.mydomain.org/mailman/public/mylist.mbox/mylist.mbox It seems to be present in 2.0.11 and 2.1.1 HYPOTHESIS -- IMHO the reason why this is probably not easy to solve is that this is where mail is automatically saved when it's received. If this is filtered by " at " -> "@" then it means that overall there are typically 4 copies of the entire mailbox (e.g. html version, monthly archives, true mailbox with @ hidden from external access, and " at " version for web access). i couldn't find if this has been discussed, but it looks like there's a simple solution in 2.1.4. SOLUTION 2.1.4 -- It looks like the solution in mailman-2.1.4 is to offer different templates: mailman-2.1.4/templates/en/archtoc.html mailman-2.1.4/templates/en/archtocentry.html mailman-2.1.4/templates/en/archtocnombox.html -> this one has no mbox e.g. http://mail.python.org/pipermail/mailman-announce/ has no *.mbox/*.mbox In fact, http://mail.python.org/pipermail/mailman-announce.mbox/ exists but nothing in it is accessible. HACK SOLUTION 2.0.11 (AND PROBABLY 2.1.1) In 2.0.11, the line pointing to the .mbox is in /var/lib/mailman/Mailman/Archiver/HyperArch.py (for Debian anyway ;) You can get more information about this list or you can download the full raw archive (%(size)s). solution: (1) remove the link to the full .mbox in /var/lib/mailman/Mailman/Archiver/HyperArch.py To do this, replace You can get more information about this list or you can download the full raw archive (%(size)s). by You can get more information about this list. (2) remove compiled versions (in my case the .pyc gets automatically recompiled) rm /var/lib/mailman/Mailman/Archiver/HyperArch.py[co] (3) test this cd /var/lib/mailman/archives/public/ /usr/lib/mailman/bin/arch mylist Then check out: http://lists.mydomain.org/pipermail/mylist/ Hopefully there will be no link to the .mbox and even direct access will be impossible. (4) make the .mbox files inaccessible - since google links will still hang around for some time chmod go-rw /var/lib/mailman/archives/private/*.mbox/*.mbox (5) probably nothing needed when running newlist for new lists. Making new lists will, by default, write *.mbox/*.mbox which are web accessible, but nobody is going to link to them (unless paranoid, deliberately wants to subject indymedia users to spam, ...) anti-spam solidarity boud -- ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Mailman 2.1.4 migration
On Wednesday 18 February 2004 18:42, Kory Wheatley wrote: > We have Mailman 2.1.4 currently running on a Linux Red Hat 8 box called [...] > My plan was to install a clean version of mailman 2.1.4 on lx5.isu.edu, > then move the mailing lists from mm.isu.edu over to lx5.isu.edu (the > directories that I would move over would be /home/mailman/lists and > /home/mailman/archives) and hopefully nobody would notice that there was > a change done. Other things you should take care of - you must copy or recreate alias/virtual maps for postfix (see genaliases) - while the change to your DNS is propagating though Internet caches, messages will go partly to mm and partly to lx5. This means list archives on lx5 could have some hole and people could experience some temporary glitch (e.g. confirmations requested on mm but the response received on lx5). Try to keep refresh time to a short value during the switch, and/or shut down postfix on mm so that messages will be kept queued until sent to lx5. -- http://thisurlenablesemailtogetthroughoverzealousspamfilters.org ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] Mailman 2.1.4 migration
We have Mailman 2.1.4 currently running on a Linux Red Hat 8 box called mm.isu.edu, the mta is "postfix", and our mailing list addresses are [EMAIL PROTECTED] We would like to move or migrate our current mailman mailing lists over to a existing linux red hat box that is called lx5.isu.edu, but we would like to keep our mailing lists addresses the same, example, [EMAIL PROTECTED] not as [EMAIL PROTECTED] I know to do this we would need to put a CNAME in DNS pointing lx5.isu.edu to mm.isu.edu, we would also need to created a virtual server to have the web server still be mm.isu.edu . My plan was to install a clean version of mailman 2.1.4 on lx5.isu.edu, then move the mailing lists from mm.isu.edu over to lx5.isu.edu (the directories that I would move over would be /home/mailman/lists and /home/mailman/archives) and hopefully nobody would notice that there was a change done. Basically, I'm trying to duplicate what I have on mm.isu.edu to lx5.isu.edu and then remove the old mm.isu.edu. I'm I missing any steps or is this possible? -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 # Everything must point to him. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] Another Chinese Problem
Dear All Experts, Thanks to Jason R. Mastaler's kind suggestion and my Mailman can process emails with Chinese subject. However, the Chinese characters in "Today's Topics" in the digests all changed to "", it seems Mailman processes the characters in ASCII format. The individual emails in MIME format works fine. Any suggestion?? Thanks in advance! Regards, Patrick -- Patrick Lam Sze Fan Computer Officer II Medical Information Technology, Faculty of Medicine, The Chinese University of Hong Kong Tel:21455213 Fax:26352521 -- ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] pycon sprint for MM3 db backend
Barry, Kevin, Fred, and others, I'm interested in joining those working on mailman during the PyCon2004 sprint. I too am interested in seeing a db backend on mailman. I'm fairly familiar with mysql, but will be willing to write(in parallel) other backends for postgres, or db2. I can take at least one of Monday or Tuesday off from work to do this, as well as some time on the weekend. So, where can I find Mailman3 code? maki ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Is the config.pck.last logic correct?
On Sun, 2004-02-08 at 14:10, Les Niles wrote: > On Sun, 08 Feb 2004 13:59:06 -0500 Barry Warsaw <[EMAIL PROTECTED]> wrote: > > >Have you tried setting SYNC_AFTER_WRITE=Yes in your mm_cfg.py file? > > > >-Barry > > No, not yet. I'd like to get a sense from folks as to whether I should turn on SYNC_AFTER_WRITE for MM 2.1.5. If so, should I keep the configuration variable or just hard-code enable it? Note that with the pending.pck and requests.pck rewrite I recently implemented, I'm always fsync'ing the files. > That's one of the mitigation steps the lack of which > demonstrates why I should be kept away from computers. But whether > the writes succeed or fail or trash the file, I couldn't see how > both config.pck and config.pck.last got corrupted. If it's some > subtle bug in the program's logic, that might be worth fixing, but > if it's just some serious nastiness on the part of the filesystem > then nevermind. The only way I can see this happening is if the system calls succeed, but that the data gets corrupted before its flushed out to disk. So the writes and closes of the tmp files never raise exceptions, the rename dance is done, and then you're left with a corrupt .last file. If for some reason this is happening, turning on fsync should expose the problem because presumably, that call won't succeed unless the data is flushed to disk. Try setting SYNC_AFTER_WRITE to Yes and restarting Mailman. -Barry ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
