Hello,
Currently I'm creating an unofficial site of GNU Mailman. It's not
done yet, but the goal is to make the current official site more
accessible and usable. The content is almost the same.
The unofficial site (since Google Page Creator doesn't support
folders, images are not shown and linked docs are not available):
http://gnu.mailman.googlepages.com/index.html
You can download the source tarball here (with linked docs):
Source Tarball (size: 1.1mb)
http://gnu.mailman.googlepages.com/Mailman-Site-Redesign.tar.gz
This site tries to solve the problems that I listed in the following document:
What's wrong with the current Mailman official site?
http://gnu.mailman.googlepages.com/wrong.txt
I'd love to have your feedback. Also, I listed several questions in
the document above, so I'd appreciate if any of you could answer or
comment on them (Some questions are not about the official site per
se).
Best,
- Satoshi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm moving this discussion to mailman-developers.
On Mar 30, 2008, at 2:39 PM, Alster wrote:
>
> I have been repeatedly tempted to sum up options of setting up
> encrypted
> mailing lists, with or without using GNU Mailman.
>
> As such, only these options listed in my previous summary remain:
>
> * mailman-ssls, a Mailman-Patch which has recently been updated for
> Mailman 2.1.9 compatibility:
> http://non-gnu.uvt.nl/mailman-ssls/
>
> * firma, a standalone encrypted mailinglist server (written in bash):
> http://codecoop.org/projects/firma/
>
>
> Additionally, there are these options which had not been part of the
> last overview:
>
> * MMReencrypt, another Mailman patch
> https://sourceforge.net/projects/mmreencrypt/
> no longer maintained
>
> * Schleuder, a standalone 'crypto mailinglist'
> http://codecoop.org/projects/schleuder/
> still maintained (according to their versioning system), but last
> release dates back to 2006
I don't have time right now to look at these, however I would really
like to support some form of encrypted mailing lists for Mailman 3, if
not also 2.2. It isn't possible to add this feature to Mailman 2.1.
If you're interested in working on this, it would be good to capture
some requirements and use cases in the wiki. If you wanted to do a
survey of the approaches and implementations that have gone before,
that would also help. Ideally, some folks would be motivated enough
to start developing some branches in Bazaar so that we can take a
look, with an eye toward supporting the feature officially in a future
release.
Feel free to discuss further on this mailing list.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkf+l2EACgkQ2YZpQepbvXFFBQCdFY+07fgyROIVGUVInd1+Zhph
HBkAnjuh78SV2DzvEtchN0CAFLeoXkjE
=iaw1
-----END PGP SIGNATURE-----
Ever wanted to help out with Mailman but didn't know how? Here's
your chance!
I've been trying to make the wiki into the one-stop-shop for Mailman
documentation, and as part of that process, I made a script that
moved the Mailman FAQ entries into the wiki.
http://wiki.list.org/display/DOC/Frequently+Asked+Questions
You'll see that there's around 200 entries in there now, organized
into sections as they were originally in the FAQ Wizard:
http://www.python.org/cgi-bin/faqw-mm.py
I need some people who've got a few minutes to help out with cleaning
up the wiki FAQ entries. You don't need to know the answers -- I
just need some volunteers who can fix some links and maybe do some
organization. I don't need any huge time commitment, just sign up
for a wiki account and do an entry or two when you've got some spare
time.
Most of the pages just need someone to convert the FAQ Wizard links
to internal wiki links (eg: in http://wiki.list.org/x/PIA9), maybe
fix some other formatting (eg: look at http://wiki.list.org/x/p4A9
and how the preformatted stuff is inexplicably in three blocks rather
than one). It's an easy job, it's just that at 200 pages, I could
use some help!
If you have any questions or need any help getting started, please
let me know!
Terri
Hi all,
the plans in
http://wiki.list.org/display/DEV/TemplatingNotes
and
http://wiki.list.org/display/DEV/StyledPages
sound great, but mean a lot of work.
For example there is options.py with functions for rendering output named
options_page and loginpage.
options_page supports the old template mechanism using options.html
However loginpage has hard-coded tables including "BGCOLOR" and such ugly things.
I don't know if someone is still working on the new template mechanism and I couldn't find any changes on options.py either.
(What I think is fundamentally necessary for a complete template mechanism.)
(I looked in http://bazaar.launchpad.net/~mailman-coders/mailman/2.2/files and http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/files)
So my plan is:
For a customer I want to customize more than the standard pages (for example the function loginpage from options.py).
I will use the old template system (like in function options_page in options.py), using new template names like <SCRIPT>_<FUNCTION>.html
As I think this is useful for others it could maybe be merged in mailman.
So what do you think, is it a waste of time because code for the old template mechanism will never get merged?
I'm looking forward to your suggestions.
bye,
Frank
--
Frank Schubert
Systemadministration
EsPresto AG
Breite Str. 30-31
10178 Berlin/Germany
Tel: +49.(0)30.90 226.750
Fax: +49.(0)30.90 226.760
f.schubert(a)espresto.com
HRB 77554 AG - Berlin-Charlottenburg
Vorstand: Alexander Biersack, Maya Biersack, Peter Biersack
Vorsitzender des Aufsichtsrats: Oli Kai Paulus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Actually, this note really applies to just restarting mailman a Mailman
2.1.9 installation, with or without upgrading to Mailman 2.1.10. But in
installations that just 'run' without intervention, this restart may not
occur until an upgrade.
There is an error in Mailman 2.1.9. In the introduction of the backup
and recovery of queue entries, we neglected to remove the backup queue
entry for an unparseable message. Thus, if you sometimes receive
unparseable messages which are ignored, you may have an accumulation of
.bak files in qfiles/in from these messages. When you restart Mailman,
these will all be reprocessed, resulting in a flood of error log entries.
There is no real harm done, but it would be a good idea when upgrading
to stop Mailman and remove any qfiles/in/*.bak files.
- --
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIDgCwVVuXXpU7hpMRAlOyAJ4/VpFnCL9JHoEBSl4PmZIBowTbigCgjjRr
Bh8FoeuGZDAXonphAnvqwMA=
=qt1K
-----END PGP SIGNATURE-----
Hi,
I have an intern coming to work for a couple of months in the summer.
Neither of us will be python experts, but part of the point is to learn,
right?
I'd like him to work on some aspects of Mailman 3.
I plan to get LMTP working to my taste, by (a) rejecting messages for
non-existent lists at RCTP time, and (b) rejecting messages from unwanted
sender addresses at RCPT time. I Think (a) will be easy to achieve, and (b)
only slightly more challenging.
So, I'm after ideas for what to do next. I'm vaguely thinking about (c)
integration (which will probably begin from working up a specification for
exactly what that means), and possibly (d) user interface design for end
users and list admins.
Any suggestions for (c) and (d) or alternative areas that need some focus
would be useful.
Also, can you give me pointers to a good place to learn about doctest,
please?
Finally, is there any overview documentation for developers new to the
Mailman architecture?
--
Ian Eiloart
IT Services, University of Sussex
x3148
I'm doing some work in mm2.2 and wanted to add some python package
dependencies like routes, lxml, and simplejason. How do I go about
declaring these dependencies so that the dependent packages will be
installed for the end user who wants to run mm2.2?
Can someone point me in the direction of the stuff that I need to read?
....maki....
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Quoting Barry Warsaw <barry(a)list.org>:
> On Apr 13, 2008, at 5:35 PM, Maki Kato wrote:
[stuff deleted]
>> - Documentation. I'm hoping the xHTML representation will have
>> a way of being able to serve reasonable documentation. So one
>> could point their browser to the REST interface and start browsing
>> to learn how the server is implemented. We may want to distribute
>> a static set of HTML pages that has documentation and test(dummy)
>> data.
>
> Leonard Richardson is very hot on WADL. Will we be able to generate
> that automatically or does that not have a place in the architecture
> you're thinking about?
I went to read up some more on WADL and ran into this:
http://bitworking.org/news/193/Do-we-need-WADL
I don't have any plans(yet) on auto generating the WADL, or did you
mean auto generating the documentation from the WADL file? Are there
tools that do that? I didn't find any such.
Currently I'm returning human readable text containing something like
documentation when you request the xHTML representation. I've seen
this done before and figured it was a pretty good idea. It is of no
use of course if you want to auto generate a client, as you would from
a description file.
Anyone else have any opinions or experiences with WADL?
....maki....
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Hello there,
I don't really know how to start this topic, I'm fairly new to Mailman
and I don't speak anything but the most basic Python, but I am unsure
whether the function "def chunkify(recips, chunksize):" which is
defined in "Mailman/Handlers/SMTPDirect.py" might not have an adverse
effect on mail delivery performance.
The problem is: At the moment, I'm looking at a specific setup without
knowing anything about the "historical" development of "chunkify".
There is a comment which mentions an initial suggestion made by Chuq
Von Rospach and further improvements made by Barry Warsaw.
Unfortunately, I was unable to find these original discussion, and
frankly, without knowing why "chunkify" is implemented the way it is,
I don't think I'm qualified to discuss my concern (which involves VERP
delivery using a specific MTAs VERP implementation and a highly I/O
saturated mail server) on this list.
What I found out from the archives is that "chunkfiy" has two
purposes:
1. Make sure that not more than mm_cfg.SMTP_MAX_RCPTS are passed to
the MTA in a single transaction.
2. To improve delivery performance by grouping destinations which will
prevent messages which are addressed to dead/congested destinations
blocking delivery of messages to working destinations.
Is this assumption of mine basically correct? If it is and if I didn't
miss any important parts, I would like to point out a specific
scenario in which the way "chunkify" is implemented and the way in
which it is called based on delivery style (verp, bulk) and the
setting of mm_cfg.SMTP_MAX_RCPTS might actually worsen overall mail
delivery performance.
If I am totally wrong and "chunkfiy" serves a totally different
purpose, please feel free to ignore this posting.
Cheers
Stefan