I've had a lot of requests recently for information about Mailman
hosting. As a general rule I don't like to recommend any particular
hosting company. But if you do provide Mailman hosting facilities,
please make sure you've added yourself to the PythonHosting wiki:
http://www.python.org/cgi-bin/moinmoin/PythonHosting
I usually point people here for more information, so please make sure
you're on that list. Now to check the FAQ and see if it points here...
-Barry
Hello.
I'm one of the guy managing the mailman package for mandrake-linux. I've
currently trying to make setup a bit more standard and FHS compliant. I need
developpers help however, first to make sure my changes won't cause trouble,
second as I think some of these change should get merged upstream, as they
would benefit more people.
The first issue is file location. We are trying to achieve FHS compliance, so
i had to move things a bit.
I'm using the --with-var-prefix configure option to have variable files
in /var/lib/mailman and non-variables files in /usr/lib/mailman. That is
supported by mailman install.
Then i move logs from /var/lib/mailman/logs to /var/log/mailman through a
symlink.
The config file location, however, is still puzzling me. Having a
configuration file (mm_cfg.py) under /usr is non-standard, as /usr is
supposed to be read-only. Moreover, it is a pain for us packagers, as we have
to include everything but this file as normal files, then tag it as config
file. I'd really think it should be moved in /etc instead, either by me using
a symlink, but much better by an upstream change.
The second issue are perms. The default install make everything owned by the
uid/gid determined at configure stage (mail/mail for me), and make all
directories setgid, even for non-variables files, which is quite really a
non-standard practice. So i tried to clean it a bit.
I made everything under /usr/lib/mailman owned by root.root, with standard
perms (644 for files, 755 for directories) except the binaries
in /usr/lib/mailman/cgi-bin and usr/lib/mailman/mail which are setgid, and
owned by mail group. I tested, it seems to work.
I also made top-level directory for variable files (/var/lib/mailman) owned by
root/root with standard 755 perms, but i didn't tried yet further perm
modifications there, as mailman need write permissions in subdirectories.
You can have a look at the spec file in CVS if you want details
(http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/mailman/mailman.spec).
Your comments on my changes are welcome, as well as what could get integrated
into mailman.
--
Those who hesitate under fire usually do not end up KIA, MIA or WIA
-- Murphy's Military Laws n°101
Hi Mailman developers,
we at freexp.de are setting up Mailman and INN and are trying to get the
Mail<->News facility to work. We are neither familiar with Mailman nor
with Python, just being poor old Pascal programmers. ;)
I have been in touch with Brad Knowles before and he advised me to ask
here.
We have three mailing lists and three corresponding newsgroups, which
shall be gated bidirectional. It even works but what is puzzling us is
that in Mail->News direction Mailman always creates an own MsgID. This
screws up threading by references: If a newsgroup user replies to a
posting that has been gated from the mailing list to the newsgroup, then
- from the perspective of the mailing list users - his references point
to a "wrong" MsgID when they receive this followup posting being gated
from the newsgroup to the mailing list.
I found the respective code in Queue/NewsRunner.py and also read the
explanation why Mailmain is creating own MsgIDs (I'll come back to this
later on). I changed the code as follows:
----------8<----------
# Our Message-ID format is <mailman.secs.pid.listname@hostname>
msgid = msg['message-id']
hackmsgid = True
if msgid:
hackmsgid = False
# mo = mcre.search(msgid)
# if mo:
# lname, hname = mo.group('listname', 'hostname')
# if lname == mlist.internal_name() and hname == mlist.host_name:
# hackmsgid = False
if hackmsgid:
del msg['message-id']
msg['Message-ID'] = Utils.unique_message_id(mlist)
----------8<----------
It is not really clear to me how Python can know where a conditional
statement such as "if msgid:" ends (just by the indention?), but this
piece seems to work: The MsgID is now being left untouched.
This is question #1: Is this code OK? I'm also not sure if the variable
'msgid' contains a boolean or a string...?
Now to the more important issues:
I understand that there are two main reasons why Mailman wants to create
an own MsgID upon gating Mail->News, one of them being to avoid loops.
Even after I changed the code as above, I still can't see a loop. I
first thought Mailman might check the MsgID of a posting upon deciding
whether it should be gated from the newsgroup to the mailing list, but
this is obviously not the case. I've had a look into cron/gate_news.py
but couldn't figure out exactly how Mailman is taking that decision.
This is question #2: How does Mailman know if the mailing list has
already seen a posting or not?
Anyway, the second and more important reason for creating own MsgIDs
seems to be the issue of an XPost to two (or more) Usenet-gated mailing
lists.
This is indeed a problem and I understand the background. Thus we'd
like to tweak Mailman in a way that it does the following:
1. Say we have the mailing lists ml-1, ml-2 and ml-3 and the
corresponding newsgroups ng-1, ng-2 and ng-3. Now a mail comes in,
being addressed to ml-1 and ml-2 (which thus should be gated to ng-1
and ng-2).
In fact, two physical mails will come in, and obviously Mailman does
now create two physical postings, one addressed to ng-1, the other
one addressed to ng-2. This in fact creates the problem of duplicate
MsgIDs.
But what Mailman should do is to create *one* physical posting,
x-posted to ng-1 and ng-2 ("Newsgroups: ng-1,ng-2"). This would mean
that upon dealing with the mail to ml-1 it would have to check if the
addresses in the To: and Cc: headers contain more than one of "our"
mailing lists and if these mailing lists are being gated to "our"
Newsgroups. If so, then an x-posting as described shall be created.
When Mailman now has to deal with the second mail to ml-2 (with the
same MsgID) it shall *not* create another posting anymore.
Can this be accomplished (and if yes, how)?
2. Of course, if a mail does not have a MsgID at all, then Mailman
should still create its own MsgID.
Any hint will be appreciated (and again, please consider that we are
newbees with regards to Mailman and Python). Even if we would have to
hardcode some strings (of mailing lists and/or newsgroups) this would be
a better solution than no solution.
Michael
I have released Mailman 2.1.4, a bug fix release that also contains
support for four new languages: Catalan, Croatian, Romanian, and
Slovenian. This release also contains a fix for a cross-site
scripting vulnerability in the 'admin' cgi script (see
CAN-2003-0965). There is also an expanded ability to filter message
headers, nominally to provide better support when Mailman is used in
conjunction with upstream spam and virus filters.
The full source tarball has been made available from the usual sites.
Sorry, there is no patch available yet, but you should be able to
install Mailman 2.1.4 over your existing 2.1.x installation. See
http://sourceforge.net/project/showfiles.php?group_id=103
for links to the downloadable files. After installing, be sure you
restart your Mailman daemon by doing a "mailmanctl restart".
IMPORTANT: You will want to re-run configure before doing a make install.
See also:
http://www.list.orghttp://mailman.sf.nethttp://www.gnu.org/software/mailman
Enjoy, and have a Happy New Year.
-Barry
-------------------- snip snip --------------------
2.1.4 (31-Dec-2003)
- Close some cross-site scripting vulnerabilities in the admin pages
(CAN-2003-0965).
- New languages: Catalan, Croatian, Romanian, Slovenian.
- New mm_cfg.py/Defaults.py variable PUBLIC_MBOX which allows the site
administrator to disable public access to all the raw list mbox files
(this is not a per-list configuration).
- Expanded header filter rules under Privacy -> Spam Filters. Now you can
specify regular expression matches against any header, with specific
actions tied to those matches.
- Rework the SMTP error handling in SMTPDirect.py to avoid scoring bounces
for all recipients when a permanent error code is returned by the mail
server (e.g. because of content restrictions).
- Promoted SYNC_AFTER_WRITE to a Default.py/mm_cfg.py variable and
make it control syncing on the config.pck file. Also, we always flush
and sync message files.
- Reduce archive bloat by not storing the HTML body of Article objects in
the Pipermail database. A new script bin/rb-archfix was added to clean
up older archives.
- Proper RFC quoting for List-ID descriptions.
- PKGDIR can be passed to the make command in order to specify a different
directory to unpack the distutils packages in misc. (SF bug 784700).
- Improved logging of the origin of subscription requests.
- Bugs and patches: 832748 (unsubscribe_policy ignored for unsub button on
member login page), 846681 (bounce disabled cookie was always out of
date), 835870 (check VIRTUAL_HOST_OVERVIEW on through the web list
creation), 835036 (global address change when the new address is already
a member of one of the lists), 833384 (incorrect admin password on a
hold message confirmation attachment would discard the message), 835012
(fix permission on empty archive index), 816410 (confirmation page
consistency), 834486 (catch empty charsets in the scrubber), 777444 (set
the process's supplemental groups if possible), 860135 (ignore
DiscardMessage exceptions during digest scrubbing), 828811 (reduce
process size for list and admin overviews), 864674/864676 (problems
accessing private archives and rosters with admin password), 865661
(Tokio Kikuchi's i18n patches), 862906 (unicode prefix leak in admindb),
841445 (setting new_member_options via config_list), n/a (fixed email
command 'set delivery')
http://www.british-genealogy.com/mailman/listinfo/s-arnold
As a list owner of the above list can you tell me why my own list is
rejecting my mail.
It seems your mailman thing says I do not exist?
no one will answer my emails from this UK web site.
Do I have to delete all my members as well am myself?
I do not know what ty do.
Jill Morley
list owner
s-arnold list
On Wed, 2003-12-31 at 10:20, pheinlein(a)users.sourceforge.net wrote:
> Update of /cvsroot/mailman/mailman/messages/de/LC_MESSAGES
> In directory sc8-pr-cvs1:/tmp/cvs-serv5338/messages/de/LC_MESSAGES
>
> Modified Files:
> mailman.po
> Log Message:
>
> Last quick fix for 2.1.4
Peer, you really need to make these changes on the Release_2_1-maint
branch tag. These changes are on the trunk and will /not/ make it into
2.1.4 unless you also commit them to the branch!
I'm also going to log into irc.freenode.net #mailman now in case anybody
wants to chat about stuff.
-Barry
I'm going to be cutting the 2.1.4 release at noon EST, which is
approximately three hours from now. If there are any last minute i18n
updates, please get them in now. No other changes are allowed.
After 12noon EST, no other i18n updates will be allowed either.
Thanks and happy new year to all (including those of you already
partying :).
-Barry
Hi Barry,
I made a mistake on this patch.
Hye-Shik Chang's cjkcodecs site has moved from sourceforge to
http://cjkpython.i18n.org/
He has updated his codecs to 1.0.2, so please download and update the
package and change the package description in Makefile.in accordingly.
http://download.berlios.de/cjkpython/cjkcodecs-1.0.2.tar.gz
Sorry for the inconvenience.
bwarsaw(a)users.sourceforge.net wrote:
> Update of /cvsroot/mailman/mailman/misc
> In directory sc8-pr-cvs1:/tmp/cvs-serv24964/misc
>
> Modified Files:
> Tag: Release_2_1-maint
> .cvsignore Makefile.in paths.py.in
> Added Files:
> Tag: Release_2_1-maint
> CJKCodecs-1.0.tar.gz
> Removed Files:
> Tag: Release_2_1-maint
> JapaneseCodecs-1.4.9.tar.gz KoreanCodecs-2.0.5.tar.gz
> Log Message:
> TK's patch # 865661 chunk which replaces JapaneseCodecs-1.4.9 and
> KoreanCodecs-2.0.5 with CJKCodecs-1.0.
>
>
> --- NEW FILE: CJKCodecs-1.0.tar.gz ---
> (This appears to be a binary file; contents omitted.)
>
> Index: .cvsignore
> ===================================================================
> RCS file: /cvsroot/mailman/mailman/misc/.cvsignore,v
> retrieving revision 2.2
> retrieving revision 2.2.2.1
> diff -u -d -r2.2 -r2.2.2.1
> --- .cvsignore 17 Aug 2001 23:19:22 -0000 2.2
> +++ .cvsignore 26 Dec 2003 21:46:09 -0000 2.2.2.1
> @@ -1,3 +1,5 @@
> Makefile
> paths.py
> mailman
> +CJKCodecs-1.0
> +email-2.5.4
>
> Index: Makefile.in
> ===================================================================
> RCS file: /cvsroot/mailman/mailman/misc/Makefile.in,v
> retrieving revision 2.33.2.3
> retrieving revision 2.33.2.4
> diff -u -d -r2.33.2.3 -r2.33.2.4
> --- Makefile.in 1 Dec 2003 00:12:30 -0000 2.33.2.3
> +++ Makefile.in 26 Dec 2003 21:46:09 -0000 2.33.2.4
> @@ -53,10 +53,9 @@
> PKGDIR= $(srcdir)
>
> EMAILPKG= email-2.5.4
> -JACODECSPKG= JapaneseCodecs-1.4.9
> -KOCODECSPKG= KoreanCodecs-2.0.5
> +CJKCODECSPKG= CJKCodecs-1.0
>
> -PACKAGES= $(EMAILPKG) $(JACODECSPKG) $(KOCODECSPKG)
> +PACKAGES= $(EMAILPKG) $(CJKCODECSPKG)
>
> # Modes for directories and executables created by the install
> # process. Default to group-writable directories but
>
> Index: paths.py.in
> ===================================================================
> RCS file: /cvsroot/mailman/mailman/misc/paths.py.in,v
> retrieving revision 2.6
> retrieving revision 2.6.2.1
> diff -u -d -r2.6 -r2.6.2.1
> --- paths.py.in 21 Oct 2002 19:52:05 -0000 2.6
> +++ paths.py.in 26 Dec 2003 21:46:09 -0000 2.6.2.1
> @@ -1,19 +1,19 @@
> # -*- python -*-
>
> -# Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
> +# Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
> #
> # This program is free software; you can redistribute it and/or
> # modify it under the terms of the GNU General Public License
> # as published by the Free Software Foundation; either version 2
> # of the License, or (at your option) any later version.
> -#
> +#
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> # GNU General Public License for more details.
> -#
> +#
> # You should have received a copy of the GNU General Public License
> -# along with this program; if not, write to the Free Software
> +# along with this program; if not, write to the Free Software
> # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>
> # This file becomes paths.py which is installed in may directories. By
> @@ -49,12 +49,8 @@
> sys.path.append(sitedir)
>
>
> -# In a normal interactive Python environment, the japanese.pth and korean.pth
> -# files would be imported automatically. But because we inhibit the importing
> -# of the site module, we need to be explicit about importing these codecs.
> -import japanese
> -# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
> -# codecs installed, however leave the first import in there in case an upgrade
> -# changes this.
> -import korean
> -import korean.aliases
> +# We explicitly import CJKCodecs here since we inhibit the importing of the
> +# site module. As of CJKCodecs-1.0, you have to do the second import. We may
> +# have to re-activate the first line if an upgrade changes this.
> +#import cjkcodecs
> +import cjkcodecs.aliases
>
> --- JapaneseCodecs-1.4.9.tar.gz DELETED ---
>
> --- KoreanCodecs-2.0.5.tar.gz DELETED ---
>
>
>
> _______________________________________________
> Mailman-checkins mailing list
> Mailman-checkins(a)python.org
> Unsubscribe: http://mail.python.org/mailman/options/mailman-checkins/tkikuchi%40is.kochi…
>
>
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
Hi,
I hope I can get some insights into this problem.
I've been using Mailman in our university to administer a number of lists,
and the web interface has worked well so far for us. However, in the recent
weeks we have learned a spammer has subscribed many of our email accounts
to his own mailman system (on a server outside the US), and has disabled
the web interface. This means no one can get a reminder of their passwords
to unsubscribe via email (since when an administrator subscribes users no
password is sent).
As it is now, Mailman is being used to keep those accounts "captive" and
bombard them with unsolicited email. So the purpose of my email is twofold:
** Development:
- I strongly believe now email commands should also include a password
reminder/recovery feature, so that in cases like ours users can still get
their passwords and unsubscribe via email. Currently a password can only be
recovered via the web interface (which a spammer can disable).
- I also think when the administrator enrolls users, the passwords should
be sent as a default, with no possibility of disabling this feature. This
would cut down on misuse of Mailman as the one described above.
** Management:
- This is a generic question to all managers: if
- a Mailman list does not offer a web interface to recover a password to
unsubscribe,
- the manager does not reply to unsubscription messages,
- the bounce utility has been disabled (so sending fake "Returned mail"
messages does not trigger unsubscription),
- the monthly password reminder has been disabled,
- the Mailman server is outside the US (so reporting to the FCC is useless),
- and the list is being used to bombard subscribers who did not subscribe
themselves...
...how else could unsubscription be achieved in Mailman? I know that users
could put filters, but I'd like for the messages to stop instead of having
to put patches here and there on each user's machine...
Thanks in advance for any pointers/ideas/suggestion you may have.
Roberto Perez
rgpg(a)technologist.com
Larry Price wrote:
> That is not evidence, that is an appeal to authority.
>
> If you wish to present evidence, you would need to drop a tarball
> containing.
>
> a. a relatively complex test algorithm and data set
> b. implementations thereof in ${language}
> c. a test script which executes and times each implementation
>
> You would then need to have a large sample of testers run the tests on a
> wide variety of platforms, and then do a linear regression of the
> results to see if speed varied independently of the underlying platform.
>
> and yet it would still not matter.
You name the reasons why I will not produce the 'convincing
evidence' Richard Barret is interested in. I do however believe
ESR is called authority rightly and assume he is has sufficient
knowledge of and communication with experts in the languages he
writes about so his opinion adds to my experience that python is
slow. Some complex things are hard to prove so I thought you
might be interested in the opinion of a neural network trained in
the subject.
> with few exceptions the problems that people use python to solve are not
> ones where
> speed is paramount, but rather ones where understanding what's happening
> and being able to change it quickly is.
>
>
>
>
> On Tuesday, December 16, 2003, at 02:44 PM, Bernhard Kuemel wrote:
>
>> Richard Barrett wrote:
>>
>>> On 25 Nov 2003, at 20:06, Bernhard Kuemel wrote:
>>>
>>>> Maybe. However, I don't like python as on our old P60 server it
>>>> burned up so much CPU time (15 s/min).
>>>
>>> It would be interesting to see you present convincing evidence that
>>> Python runs slower than Perl which you seem happy to rely on.
>>
>>
>> Eric Steven Raymond says in "The Art of Unix Programming"
>> (http://www.faqs.org/docs/artu/index.html) on
>> http://www.faqs.org/docs/artu/ch14s04.html :
>>
>> "Python cannot compete with C or C++ on raw execution speed (though
>> using a mixed-language strategy on today's fast processors probably
>> makes that relatively unimportant). In fact it's generally thought to
>> be the least efficient and slowest of the major scripting languages, a
>> price it pays for runtime type polymorphism. By.
>> eware of rejecting Python on these grounds, however; most applications
>> do not actually need better performance than Python offers, and even
>> those that appear to are generally limited by external latencies such
>> as network or disk waits that entirely swamp the effects of Python's
>> interpretive overhead. Also, by way of compensation, Python is
>> exceptionally easy to combine with C, so performance-critical Python
>> modules can be readily translated into that language for substantial
>> speed gains."
>>
>> Bernhard
>>
>> --
>> Webspace; Low end Serverhousing ab 15 e, etc.: http://www.bksys.at
>> Linux Admin/Programmierer: http://bksys.at/bernhard/services.html
>>
>>
>> _______________________________________________
>> Mailman-Developers mailing list
>> Mailman-Developers(a)python.org
>> http://mail.python.org/mailman/listinfo/mailman-developers
>>
>>
> --
> "You are the eventuality of an anomaly , which despite my sincerest
> efforts I have been unable to eliminate from what is otherwise a harmony
> of mathematical precision. " -The Architect
> "Microsoft has resolved this issue. We have put processes in place to
> ensure there is no recurrence of this eventuality." -Microsoft
>
--
Webspace; Low end Serverhousing ab 15 e, etc.: http://www.bksys.at
Linux Admin/Programmierer: http://bksys.at/bernhard/services.html
