Re: [Mailman-Users] Muti-Mailman install
For users who have their mail go through procmail the problem can be fixed by a rule like the following. But in light of Brads letter, I feel it is necessary to add a disclaimer saying that if this setting gets you killed or fired, I cannot be held responsible! :p :0 fw * [EMAIL PROTECTED]|^List-id: .*mailman- users.python.org | formail -i Reply-To: mailman-users@python.org A more fancy solution could extract the list address from the list- post header (and target all list letters w/o a reply-to). I use an anonymous remailer so personally wouldn’t work for me, plus when people reply to me and cc the list, there are no list headers in that message, even though it is a list message (one of the reasons “reply to poster” sucks). Btw: does anyone know any of these many MUAs that Brad speak of? I can’t help but wonder how users of these can participate in list conversation with Mailman’s default setting, given their inability to control where their letters are sent to. On 19 Jun 2008, at 23:23, Brad Knowles wrote: Charles Marcus wrote: Whats the big deal anyway? If you want lists configured to reply to the list, just set it that way. What difference does it make what the default is? The point is that there are lots of MUAs out there that are broken, and if you screw with the Reply-To: header, they are completely and totally unable to change who the reply is sent to. This is how private information gets exposed on public lists, with consequences ranging from just being personally embarassing, to getting you fired, to actually being life-threatening in some cases. Do you really want to be responsible for something that could get someone killed? -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Reply to list instead of poster (was: Muti-Mailman install)
On 19 Jun 2008, at 08:38, adsarebad-at-. wrote: [...] Also it seems clicking reply on a msg here does a off list reply. So all my previous reply`s were done off list. It is the default for new Mailman installs and the admin UI even has: Where are replies to list messages directed? Poster is strongly recommended for most mailing lists I never understood why they have this recommendation or even default setting and it has always bothered me when lists I subscribe to does not change away from the default (fortunately majority of lists _do_ change it). The problem is actually twofold: 1. I routinely forget to reply to the list, and 2. I get private replies which I _think_ are meant for the list, but I feel bad about following up to the list incase the poster really wanted it to be private (plus list members lose half the conversation when only the list is cc’ed on every second letter). So what exactly is the reason for this recommendation (and default)? And where do we lobby for a change? :) -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Reply to list instead of poster (was: Muti-Mailmaninstall)
On 19 Jun 2008, at 15:53, Mark Sapiro wrote: [...] You have said in another thread that these links contribute to excessive verbosity of the labels, but they often link to useful supplemental information. I don’t dispute that. I am sure there are lots of useful info there, but it drowns in the excessive verbosity. Take the reply-to UI in question: Reply-To: header munging Should any existing Reply-To: header found in the original message be stripped? If so, this will be done (o) No ( ) Yes regardless of whether an explict Reply-To: header is added by Mailman or not. (Edit first_strip_reply_to) Where are replies to list messages directed? Poster is strongly recommended (o) Poster ( ) This list for most mailing lists. (Details for ( ) Explicit address reply_goes_to_list) Explicit Reply-To: header. (Details for [ ] reply_to_address) That’s almost 100 words and the link that explains why the Poster option is recommended bears the mundane title of “(Details for reply_goes_to_list)” and is part of a label which is really 3 sentences. Here is how I would change all of the above: List replies go to: (o) Poster (recommended, more info) ( ) The list [x] Strip existing Reply-To header ( ) Other: [ ] The grouping should make it clear how the settings relate to each other, so no need for long explanations about the explicit Reply-To address etc.¹ Less text means better chance the user will read/grasp it. I only added one “more info” link and put it right next to the ‘recommended’ text, so it should be clear from context that it will elaborate on why this is the recommended setting. ¹ The third setting is dependent on list replies going to the list and while it indicates that the first setting can be used even for replies sent to poster, that does IMHO not make much sense. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
On 18 Jun 2008, at 20:32, Terri Oda wrote: [...] I've opened up a new page on the wiki to get more of a process going: http://wiki.list.org/display/DEV/Web+Interface This is great, but how should we use it? :) I think the easiest is simply to go through all settings, decide what is needed/not needed. Then group the relevant stuff, and then do categorization. This should probably just be done by 1-3 people and then submitted as a proposal. But how easy is it to actually improve the web UI? It was said in another letter that it is generated from various source fragments, so is there the necessary abstraction in Mailman to allow the web UI to be improved? If it is feasible to redo the UI for 2.x then I’ll gladly submit some more complete suggestions. [...] 4. Labels are too verbose, contributing with noise to the overall view, and the “Details for «the_mailman_option_name»” under each label does not help in this regard. I've got mixed feelings about this. The labels do contribute to noise, but they also provide the ability for me to tell people change the setting with name $foo *or* describe the description if I'm not near a computer to check the stuff myself. The longer labels also make it easier for people looking at the interface the first time to figure out what things do at a glance instead of having to click each details button to find the one they want. My main problem with the verbose (right-aligned) labels is that it makes skimming very difficult. A few days ago I created a list where I wanted to allow posts from non- members and I spent at least 10 minutes skimming page after page for this setting. Eventually I found it under “Privacy Options… → [Sender Filters]” with this label: Action to take for postings from non-members for which no explicit action is defined (Details for generic_nonmember_action) The first six words of that label has no value with respect to telling what it is. For optimal skimming, the first few words should have words that are unique to the option. I also am not sure about the importance of stressing that this is for the case where there is no explicit action defined (sort of goes without saying). So here I would propose something like: Non-members have their posts: ( ) Accepted (o) Held (for the list admin to approve) ( ) Rejected (they receive a bounce) ( ) Discarded (no bounce is sent back) I also added info about each choice hopefully making the previous “more info” link unnecessary. Another example of the long verbose labels are (in same category): List of non-member addresses whose postings should be automatically accepted. (Details for accept_these_nonmembers) In my mind a simple label of “white-listed non-members” would suffice. And back to the point about skimming, there are actually four settings which all start with “List of non-member addresses whose”, meaning that when skimming, this is 20 words I have to read which say nothing about the actual option. For the above, it is actually the last word (of first sentence) which makes all the difference compared e.g. to this setting on same page: List of non-member addresses whose postings should be automatically rejected. (Details for discard_these_nonmembers) So we have two paragraphs of 15 words each which in the first sentence only differ in the last word. So while I agree with you in theory, I don’t think this verbosity holds the value you assign it ;) -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] How to enable VERP?
On 17 Jun 2008, at 18:47, Mark Sapiro wrote: [...] If you want Mailman to VERP all deliveries, just set VERP_DELIVERY_INTERVAL = 1 and don't worry about personalization. Thanks, I ended up with just this one and it works. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Queue problems
On 17 Jun 2008, at 18:53, Mark Sapiro wrote: Brad Knowles wrote: On 6/17/08, Allan Odgaard wrote: I transferred a lot of list members from a previous list. A dozen of these has left errors like the following in `logs/smtp-failures`: delivery to address failed with code 450: 4.1.2 address: Recipient address rejected: Domain not found You're doing DNS validation on your outbound mail. Don't do that. Pay attention to the stuff in section 6 of the FAQ, especially including 6.6, 6.8, 6.12, etc Also, fix your MTA configuration so it returns a 5xx status, not a 450 for a non-existant domain. To the best of my knowledge, this can not be “fixed” (for Postfix). If Postfix is unable to obtain DNS settings for a domain, it will treat it as a temporary error, and will return 450, regardless of settings (and to me this seems correct, as not being able to obtain DNS settings is likely because something is down). If on the other hand it _does_ find a name server for the domain and there is no MX record, _then_ can it be treated as a permanent error. If others should run into this problem `reject_unknown_recipient_domain` was the setting I had to disable in Postfix’s `smtpd_recipient_restrictions`. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] List archive threading (pipermail)
On 17 Jun 2008, at 06:01, Brad Knowles wrote: On 6/17/08, Allan Odgaard wrote: I copied a list's mbox to a new server and regenerated the archive. Unfortunately threading is not rendered satisfyingly, here are the two Mailman/pipermail versions: Your threading got broken somehow, but I can't tell you how. This would need further investigation. One thing that strikes me is to ask whether you copied the cooked text archives or the raw mbox archives, before regeneration? Raw mbox file. And new letters sent to the list also show up with wrong indent in the web archive. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Muti-Mailman install
On 18 Jun 2008, at 10:04, adsarebad-at-. wrote: I have searched all over for how to do true virtual list with mailman and finely decided to run multiple mailman installs side by side. Have you seen http://www.gurulabs.com/downloads/postfix-to-mailman-2.1.py ? It was included with my Mailman install. This does not require system- wide aliases for the various lists (so you should set MTA = None). I don’t think it will verify that the domain is the proper one (for mails sent to each list), but it should be simple to duplicate the service as mailman-list-a, b, c and setup the different ones to be used as transport for the different list domains (via transport_maps in postfix/main.cf), that way, Postfix will help do the validation. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Encoding problems
On 18 Jun 2008, at 02:49, Mark Sapiro wrote:
[...]
Into `/etc/python2.5/sitecustomize.py`. This is despite proper setup
of `LC_CTYPE` on the system. Seems to me Mailman should use the
encoding of the current locale, not this site-wide Python default
encoding (settable by root only).
I am aware of this issue, but I think the place to fix it is Python,
not Mailman.
I don’t think Mailman should use `sys.getdefaultencoding()`. See http://wiki.python.org/moin/DefaultEncoding
. I think instead `locale.getdefaultlocale()` should be used for the
CLI commands.
## Mailing List
The mailing list letters are correct _except_ that the body now
contains this:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
And yes, each letter sent to the list is converted into base64.
Again, this is the Python email library. If you prefer
quoted-printable, set the language's charset to iso-8859-1.
But I occasionally use stuff that cannot be represented in latin-1…
(like this line)
Anyway, point taken, Python MIME library is at fault and I will direct
my concern to the maintainers of this.
Though I don’t understand why Mailman has to re-encode all letters to
the list encoding. Hopefully it will only do so when the list encoding
can actually represent the letter!?!
[...]
Did you restart Mailman after removing
add_language('en', 'English', 'utf-8')
from mm_cfg.py? If so, and you're still getting utf-8 encoded list
mail, the incoming posts are probably utf-8 encoded.
I must have not restarted at the proper time while testing, cause now
I can get it work, i.e. messages now arrive without being base64.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Muti-Mailman install
On 18 Jun 2008, at 17:51, Brad Knowles wrote: Allan Odgaard wrote: I don’t think it will verify that the domain is the proper one (for mails sent to each list), but it should be simple to duplicate the service as mailman-list-a, b, c and setup the different ones to be used as transport for the different list domains (via transport_maps in postfix/main.cf), that way, Postfix will help do the validation. Doesn't work for the purpose of the OP. This method doesn't allow you to have the same list name for different lists under different domains. Running multiple copies of Mailman *will* allow you to do that, but it takes a lot more care-and-feeding, and is a pain to set up. By “it should be simple to duplicate the service […]” I meant duplicate it so that mailman-list-a calls mailman-install-a, etc. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] List archive threading (pipermail)
On 18 Jun 2008, at 17:45, Mark Sapiro wrote: Allan Odgaard wrote: Raw mbox file. And new letters sent to the list also show up with wrong indent in the web archive. I'm only guessing, but I think there must have been some issue with the mbox file that caused the archive database file to be messed up. Does a new list work OK? A new list show the same problem. What does bin/cleanarch say about the mbox file? Did bin/arch report anything odd? I don’t recall so. But since this happens both for new letters to this list, and for a completely new list I created a few days ago, I don’t think the problem is the mbox. I’ll see if I can get access to another Mailman version and generate the archive from there. If I didn’t state already, this is Mailman 2.1.9 under Ubuntu (installed via aptitude). -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Queue problems
On 18 Jun 2008, at 17:49, Brad Knowles wrote: [...] It is not necessary to recommend to others that they disable this feature on their copy of postfix. Instead, you should be recommending to them exactly what I recommended to you, which was to run a second copy of postfix with all checks disabled and have Mailman deliver to that second copy of postfix. Wow… just wow… I didn’t recommend anything, I reported my findings pointing to the setting which was problematic in this context. I figured people running into it will appreciate having the full info available before they decide what solution to pick. Personally I prefer just disabling the check rather than run a new copy of Postfix, but each to his own. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Encoding problems
On 18 Jun 2008, at 16:09, Mark Sapiro wrote: [...] The process of adding the list header and/or footer to the message attempts to add these to a text/plain body by coercing the body and the header/footer to unicode, concatenating them and then coercing back to the original body charset. If the last step doesn't work, it will try to coerce to the charset of the list's preferred language. My list header/footer is pure ASCII. So there should never be a problem going back to the original body encoding. So should I consider it a bug that setting list encoding to utf-8 will (in my experience) _always_ produce (base 64 encoded) utf-8 letters, when both header/footer and letter itself sent to list is ASCII? Here is what I did to test: Set list encoding to utf-8 (in mm_cfg.py). Created a new list (called Test) and subscribed to it. Even the welcome letter contained: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: =?utf-8?q?Welcome_to_the_=22Test=22_mailing_list?= Notice here the subject was sent as utf-8 even though it is pure ASCII, the body was likewise encoded. I then sent one letter to this list, subject set to Test and body likewise. I ensured that the produced letter was sent with encoding set to ASCII. The letter I received as a subscriber was one giant block of base64 encoded text with charset set to utf-8. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Web UI request
On 18 Jun 2008, at 17:41, Terri Oda wrote: [...] the more user input we get, the better! Another thread said that “the web UI is scheduled for overhaul”. Is anyone assigned to this? Is it an open process? Can we follow it somewhere? I think the admin UI suffers from: 1. Too many options. 2. Weak categorization. 3. Typographically bad, e.g. no visual cues about significance, related options, etc. and right-aligned labels make it difficult to skim down through a page. 4. Labels are too verbose, contributing with noise to the overall view, and the “Details for «the_mailman_option_name»” under each label does not help in this regard. I believe the current UI is generated from the Defaults.py, which is a contributing factor to some of the above. Is the plan to keep generating the UI, or would it be OK to actually design a UI? Switching to a designed one means more work when adding new options that require UI, but considering that the current UI has been the same for as long as I can remember, it’s not exactly a moving target. Also, having the lists themselves stored as pickled objects make it problematic to leave stuff out of the web UI, but I would strongly suggest that the lists switch to using a plain text format. Anyway, for the overhauled web UI, I will gladly participate in the process, if I am welcomed, but I think it might be a little controversial because I probably want to cut all the options I consider unnecessary, for example does an admin really need a web UI for setting whether or not digest users are allowed to switch to immediate mail delivery? etc. I think a first step would be to find out what options actually are necessary in the web UI (and presently there are some stuff not available that I would like to have there, for example the list URLs really should be visible in the web UI). Next step would then be to categorize this stuff sensibly, and after that, we can look at mockups. But as indicated above, at least step 1 should probably not be done “by committee” because you want to be harsh and not include some arcane option that one guy argue is really very useful to him :) If the pickled lists were instead plain text, that would be much easier, because then it could be a very clearly stated goal that the web UI is for the stuff most of us want most of the time, and for the more exotic stuff, there is the list config file. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] list messages lost to Hotmail subscribers lost
On 19 Jun 2008, at 01:33, Mark Sapiro wrote: [...] The problem that I had initially and that you are apparently having now is that at some point, they accept your mail and then silently discard it. That hasn't happened to me again since the mitigation period, but I'm never relaxed about it. It happens to me as well. I.e. they silently accept mail and then just drop it. I am at the point where I just don’t accept any email address managed by Hotmail. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Encoding problems
On 19 Jun 2008, at 00:24, Mark Sapiro wrote: So should I consider it a bug that setting list encoding to utf-8 will (in my experience) _always_ produce (base 64 encoded) utf-8 letters, when both header/footer and letter itself sent to list is ASCII? You may consider it a bug if you wish. It is intentional (but still perhaps wrong) that the message is coerced to the character set of the list's preferred language when msg_header and/or msg_footer are added. I meant in the sense that I should report it / submit a patch, given that what I saw was contrary to what you said the behavior should be. Though given your correction, I assume I should not submit a patch for this, if it actually is how it is supposed to work. The base64 encoding for a utf-8 message is a separate issue and is done by the Python email library. Here is what I did to test: Set list encoding to utf-8 (in mm_cfg.py). Created a new list (called Test) and subscribed to it. Even the welcome letter contained: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: =?utf-8?q?Welcome_to_the_=22Test=22_mailing_list?= This is a 'virgin' message from Mailman which will always be in the charset of the list's or user's preferred language, so no surprise here. But encoding an ASCII subject? Though maybe this is also the Python MIME library? I will do some tests with the lib. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Muti-Mailman install
On 18 Jun 2008, at 20:59, adsarebad-at-. wrote: Have you seen http://www.gurulabs.com/downloads/postfix-to-mailman-2.1.py ? [...] I think I may have ran into that file in my travels, can`t remember for sure through because I ran into so many. Is that the one where I need to have [EMAIL PROTECTED] I was hoping to be able to use [EMAIL PROTECTED] At least the advantage of this solution is that you set the transport for an entire domain to be this script, and then don’t need to have the Mailman email addresses explicitly stated in your Postfix config. If you want to have both regular and Mailman addresses for the same domain, then I am afraid you will have to explicitly have the Mailman addresses in your Postfix config. Just, they should go in the appropriate section (addresses for virtual domains instead of aliases). I am unsure what you actually wanted help with in your original letter, i.e. was it a convenient way to do “newlist” after you setup the multiple Mailman installs? Was it routing the different addresses to the proper installs? etc. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] List archive threading (pipermail)
On 18 Jun 2008, at 22:46, Mark Sapiro wrote: [...] I have never before seen a report like this. Since it occurs for a new list, there is apparently something wrong with the Mailman installation itself. If it were a problem with the Ubuntu package, I think it would have been seen elsewhere, so I think it's likely specific to your installation, but I have no idea what might cause it. I installed same version of Mailman locally (OS X) and generated the archive there, from the same mbox, and here it shows up fine. So definitely there is something on the server causing the problem. I tried reverting mm_cfg.py to the default version, but that did not fix anything. Looks like I’ll have to go through the pipermail source to solve this… -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] List archive threading (pipermail)
On 19 Jun 2008, at 07:00, Allan Odgaard wrote: On 18 Jun 2008, at 22:46, Mark Sapiro wrote: [...] I have never before seen a report like this. Since it occurs for a new list, there is apparently something wrong with the Mailman installation itself. If it were a problem with the Ubuntu package, I think it would have been seen elsewhere, so I think it's likely specific to your installation, but I have no idea what might cause it. I installed same version of Mailman locally (OS X) and generated the archive there, from the same mbox, and here it shows up fine. [...] Doing a diff on the generated archives, the only problem with the bad one is that it has the UL and /UL’s placed wrong. It tends to be very eager with UL so everything gets down to third level… -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Problems with the who command (migrating lists FAQ)
I followed the FAQ¹ and sent a `who «password»` to my old list (where I am administrator). This scheme had the following problems: 1. All user settings are lost (digest, no email, etc.). 2. It does not return subscribers with concealed identity (hide). 3. User names with accents came through mangled. I expected #1 but not #2 (as I can see these users in the web UI with my admin passwords). To solve #3 I had to set my old list to Serbian. This changed encoding from us-ascii to utf-8 and caused the user names to be emailed without the mangling. I suggest updating the FAQ and/or improve the `who` command to return concealed users to the list administrator. Would also be nice if the mass subscribe could optionally take per user settings and `who` would return these. ¹ http://www.python.org/cgi-bin/faqw-mm.py?req=all#3.4 Using Mailman 2.1.9 (Ubuntu installation). -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] List archive threading (pipermail)
I copied a list’s mbox to a new server and regenerated the archive. Unfortunately threading is not rendered satisfyingly, here are the two Mailman/pipermail versions: Old: http://lists.textdrive.com/pipermail/textmate/2008-January/thread.html New: http://lists.macromates.com/textmate/2008-January/thread.html The new one is using wrong indent levels for letters. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Encoding problems
Some of my subscribers have accents and similar in their name and I
had to do the following post install to have Mailman properly work
with these:
## CLI
In order to get `list_members -f «list»` to properly output non-ASCII
user names I had to put the following:
import sys
sys.setdefaultencoding('utf-8')
Into `/etc/python2.5/sitecustomize.py`. This is despite proper setup
of `LC_CTYPE` on the system. Seems to me Mailman should use the
encoding of the current locale, not this site-wide Python default
encoding (settable by root only).
## Web
For the web page forms to accept non-ASCII I had to put this:
add_language('en', 'English', 'utf-8')
Into `/etc/mailman/mm_cfg.py`. I think utf-8 should be the default
because even on an English list, you can use non-ASCII punctuation,
glyphs, and many European subscribers will have non-ASCII in their
names.
## Mailing List
The mailing list letters are correct _except_ that the body now
contains this:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
And yes, each letter sent to the list is converted into base64.
I tried disabling the above utf-8 changes, but it did not seem to fix
it. But it might be that the list language (containing utf-8) was
copied at list creation time, so I will effectively have to recreate
the list (or write Python code) to change this?
Using Mailman 2.1.9 (Ubuntu installation).
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Queue problems
I transferred a lot of list members from a previous list. A dozen of these has left errors like the following in `logs/smtp-failures`: delivery to «address» failed with code 450: 4.1.2 «address»: Recipient address rejected: Domain not found This is interpreted as a temporary failure so Mailman will put the letter into `qfiles/retry`. Every 15th minute the retry qrunner will move all the retry letters back into `qfiles/out`. My queue had gathered around 70 emails and had 10 recipients or so with this error, so it took more than half an hour to get through all of the queue (only to start over). Since the queue is FIFO _without_ lowering the priority for retries, it meant that normal subscribers saw a long delay before their letter was delivered to other list subscribers. I unsubscribed all addresses that were listed in `logs/smtp-failures` and then I had to manually delete letters from the qfiles. But now I see another subscriber has a similar problem and is causing letters to pile up in qfiles affecting delivery to healthy recipients. Seems to me that there is a flaw in this system (having retries pile up and starve regular delivery). Using Mailman 2.1.9 (Ubuntu installation). -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Spaces inserted in subjects
On a new list I had this set in `mm_cfg.py` at creation time: OLD_STYLE_PREFIXING = No This caused extra spaces between the tag inserted and the subject for letters sent to the list. I suspected that this option was the problem, but I was unable to disable it again (seems to be another one of those options only settable at list creation time), so I had to traverse the source and eventually found the problem in `CookHeaders.py` where it does: u' '.join([prefix, recolon, subject]) But for new letters `recolon` will be the empty string. Using Mailman 2.1.9 (Ubuntu installation). -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] How to enable VERP?
When I look at the letters I receive from my list they do not have my subscription address in the `Return-Path` header, so I suspect VERP is disabled. I have placed the following in `/etc/mailman/mm_cfg:` VERP_PERSONALIZED_DELIVERIES = Yes VERP_CONFIRMATIONS = Yes But I also see options about list personalization. Do I need to also enable that stuff? -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
