Mailman 3 November 2006 - Mailman-Developers

The age old question - virtual domains
by Michael Kabot 02 Dec '06

02 Dec '06

Hi, I've searched quite a bit and found that virtual domains is still not supported in the current version of Mailmain (2.1.9). It sounds like it is around the corner in v2.2, whenever that is. I've also tried to use some of the "patches" that others have pointed to without success. I have a short term need for virtual domains in Mailman and believe I have a quick fix that I could use some brief expertise in implementing, thus why I am emailing this group. Here is my configuration - Dedicated Servers at GoDaddy.com - Fedora Core 4 (2.6.17 kernel) - Mailman 2.1.5 - Python 2.4.3 - Plesk 8.1 - Qmail 1.03 Here is my idea - create all mailman lists in the format <virtual domain name>-<list name> - This can be done right through Plesk - setup a mail alias for the virtual domain with the name <listname> that forwards to the <virtual domain name>-<list name>@<virtual domain name> email address - Again, this can be done right through Plesk - Setup a regexp for the mailman list that looks for the <virtual domain name>-<list name> format - Presto, virtual domains working in mailman ! I will not be using ANY of the email admin functions, i.e. -request, -subscribe, -unsubscribe, etc.. I've got this all working well. The ONLY issue that I can see is that I need to have mailman munge two email addresses... - In the mail that is forwarded to the list members, the Reply-To and "on behalf of" of the person who sent the email needs to be put back in. Based on the forwarding, it is showing up as <virtual domain name>-<list name> - In that same email, change the <virtual domain name>-<list name>-bounces email to just <list name>-bounces. Can someone help me with two things 1. I need a pointer to where in the code to do the munge above. 2. Any gotcha's you can think of to this idea? Thanks in advance, Michael Kabot President - SOAR Scouting Online Affordable & Reliable mkabot(a)soarol.com 585-388-0211 www.soarol.com <http://www.soarol.com/>

2 1

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8100] trunk/mailman/Mailman/MTA/Postfix.py
by Barry Warsaw 28 Nov '06

28 Nov '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 23, 2006, at 7:32 AM, tkikuchi(a)users.sourceforge.net wrote: > Revision: 8100 > http://svn.sourceforge.net/mailman/?rev=8100&view=rev > Author: tkikuchi > Date: 2006-11-23 04:32:56 -0800 (Thu, 23 Nov 2006) > > Log Message: > ----------- > Some cleanups of code. > - if config.USE_LMTP immediately after ALIASFILE add/remove; we need > to keep alias settings because postfix rejects as unknown if > not present. I haven't tried this diff yet, but are you sure that you need the alias settings if you've got a transport_maps setting? I thought that I tested using fully qualified alias names in the transport map and not needing alias file entries unless you wanted site-wide or across-all-domain aliases, e.g. noreply@. I'll have to test this again, but it would be great that if you're using LMTP via transport maps, you don't also need alias file settings. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWXppXEjvBPtnXfVAQKtSQP+LZJj+k/tRGznbOUP93I6ShSgHIbWoyy7 O9Bf6Y8a4gw4ru31MDDfNeYU3/0PRr+LLEqD5oAD1iTNPwojdUOSwOuzNkvAwyZy MIyIkH8LRX/Xj91ye8+JHqdin9ZV3Wh5j0DjXPTM5iBihK7rYrk+7qkyYsgOBm7j Qt9OAUitS0s= =kEaT -----END PGP SIGNATURE-----

2 3

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8090] trunk/mailman/Mailman
by Barry Warsaw 17 Nov '06

17 Nov '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 8, 2006, at 8:14 PM, tkikuchi(a)users.sourceforge.net wrote: > Revision: 8090 > http://svn.sourceforge.net/mailman/?rev=8090&view=rev > Author: tkikuchi > Date: 2006-11-08 17:13:59 -0800 (Wed, 08 Nov 2006) > > Log Message: > ----------- > MailList.py ... GetScriptURL() absolute again because we need it > for email > notifications. > wsgi_app.py ... URI normalization by stripping trailing slash. We > need > Special care for 'private'. > Strip dot only components in the PATH_INFO for sanitization. Hi Tokio, I'm not so sure about this change. It breaks the ability to access the web page urls by both the wsgi path and the apache ScriptAlias path at the same time. I've tried to make sure that worked because it's pretty useful for debugging. I'm trying to keep the principle that all internal web page urls are relative, which is why we currently try to figure out the prefix to the script and then reproduce that in the cookie path (see SecurityManager.py). I've also been thinking about trying to get rid of mlist.web_page_url (I don't much like hard coding that in the list's data). I understand that we'll need absolute paths in the email notifications, and I've read the note about not exposing wsgi_app interface to the internet. I'm not sure I agree with the latter though, and besides, I'd like us to be as flexible as possible for wsgi integration. I think we should try to find some other way to do the email notification urls and keep GetScriptURL() returning relative paths. E.g. when I try to use r8090 via the Apache ScriptAlias path, I end up getting three slashes between the host and the 'mailman' prefix. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRVaCEXEjvBPtnXfVAQIOIQP8DTdlILSlUli9+WgSdskfl2+i44ON3gvx 0uoEZZ1lPon6NgJFg5Y3BCAr7YLAXsrj4pyXrhAxxLomgnjt6eM9BKdIWkSmZMl9 smQ/En31Xs5tKd69jtekaiMNMy4kMx0Yo53ci0E7yp6tVkpIh05Vg0wAB/wQr71Y 6etMJUeeJ78= =gFtd -----END PGP SIGNATURE-----

2 4

LDAP auth
by Anne Ramey 15 Nov '06

15 Nov '06

Forgive me if this has already been discussed, but I couldn't find it in the archives. I'm interested in replacing the logon screen for the list with one that asks for the email address and password for the user, checks if they are an owner or moderator, then if so, checks to see if they can bind successfully to the given ldap, and if so, logs them in with their owner or moderator permissions. Has anyone implemented or worked on anything like this? -- Anne

2 1

Crypto-sign to post
by Nathaniel Gray 13 Nov '06

13 Nov '06

Hi Mailmen & Mailwomen, I'm an open-source butterfly, flitting from project to project. I ask questions here, contribute patches there, and report bugs elsewhere. As you can probably imagine, subscribe-to-post seriously annoys me. I can't tell you how many times I've done the "subscribe, disable delivery, ask for CC on replies" mambo, and it's getting to the point where I just won't bother unless I've got a serious issue. The thing is, I don't blame the list maintainers for enabling subscribe-to-post -- it's just the only easily accessible solution to the spam crisis at this point -- but I would really like to see them have a better option. Since Mailman has already taken over the world you guys are in a great position to give it to them! I brought this up on the Cairo mailing list recently <http://lists.freedesktop.org/archives/cairo/2006-November/008345.html> and Carl Worth brought up the idea of a simple option to accept any post that's cryptographically signed, regardless of subscriber status. I liked this idea for several reasons. 1. I've never seen signed spam 2. Most mail programs have some way to sign mails 2. When spammers do start signing spam it allows a straightforward transition to a real web-of-trust style model. After a bit of searching I found RFE 893870 <https://sourceforge.net/tracker/?func=detail&atid=350103&aid=893870&group_i…>, which seems to have been dismissed on a technicality. Are there serious technical or philosophical problems with the idea, or is this just a matter of finding somebody with the time and talent to do an implementation? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

10 22

courier-to-mailman.py
by Lindsay Haisley 03 Nov '06

03 Nov '06

I'm attaching a current version of courier-to-mailman.py for possible inclusion in mailman's contrib directory in the source tree. I recently updated it a tad to properly handle confirmation address cookies in newer versions of mailman, and the script is in use, quite happily, on a production system. This script is based on Bruce Perens' qmail-to-mailman.py, but it's specific to the Courier MTA <http://www.courier-mta.org/> and the code and the install instructions (in the file comments) have been modified accordingly. Additional changes to the configure script would be necessary to do the proper token replacements at build time. It ought to be noted that qmail-to-mailman.py probably won't work as-is at this point, since it allows neither for the current format of VERP addresses in bounce messages nor for the use of confirmation addresses with cookies. The flip side is that although qmail has been largely unsupported for some time, the script provides a useful example of how to do this stuff creatively. -- Lindsay Haisley | "Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate | <http://pubkeys.fmp.com> http://www.fmp.com | dandelions" | | (Pamela Jones) |

1 0