[Mailman-Developers] escape characters for boilerplate messages not working
I'm am having trouble putting together a Welcome Message. Using the escape characters for ", &, < and > do not seem to working. I'm getting very odd results whether I try to use the escape characters or not. Not using them results with the escape characters appearing in the delivered message (ie. "&" yields "&"), and using them results in this weird doubling thing (eg." &" yields "&"). Any ideas?? Further, how can I change the text that Mailman automatically appends to the Welcome Message?? Can I set it so that it appends nothing?? For you developers, why doesn't it just use plain text, simply treating text as text?? It is for generating email, not a webpage. RTFM Notice: I have looked through all of the available documents at http://www.gnu.org/software/mailman/ and went through the archives for the last several months. The list and archives at http://listowner.org/ do not seem to be working at this time. THANX!! ___ 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] new feature request (was: Re: setting a list for no daily reminders?)
Thanks to everyone who responded. Please forgive this crosspost to the developers group. Seeing that there is no way to do this without changing the code, and that many Mailman users are not Python programmers or do not have the permission to make such changes on the server they are using, I think it would be best if this was made an option that could be set through the web interface for each list. That way administrators could choose immediate notifications, daily summaries, or both. THANX!! :) On 11/20/04, Mark Sapiro put forth: Mark wrote: > >I am running a list set to immediately send administrative requests >(admin_immed_notify set to yes), but I am getting daily notices as >well. I don't want to receive daily notices. The immediate notices >are sufficient. Nor do I see the logic in filling my inbox with >daily notices when I'm not around or haven't had a chance to process >the immediate notices that are already sitting there. > >Is there any way to change this?? You could delete the checkdbs entry from crontab, but this would affect all lists and also would have the side effect of never clearing stale entries from hold_and_cmd_autoresponses[] (I don't think this is serious because I don't think there is ever more than one entry per user - stale entries get "reused"). The only other way and the only way to do it per list is to change the code in checkdbs. ___ 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: [Mailman-Users] new feature request (was: Re: setting a list for no daily reminders?)
On 11/22/04, Brad Knowles put forth: At 1:30 PM -0500 2004-11-22, Mark wrote: Seeing that there is no way to do this without changing the code, and that many Mailman users are not Python programmers or do not have the permission to make such changes on the server they are using, I think it would be best if this was made an option that could be set through the web interface for each list. If you want this to actually get on the list of requested feature enhancements, you should use the Mailman RFE page at <http://sourceforge.net/tracker/?group_id=103&atid=350103> to submit your request. Thanks. Done. ___ 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] Issue: Mailman integration with Postfix(zimbra)
subin-opensourcesolutions.co.in wrote: > >Now when I send the mail to listn...@domain.tld, the >subscribed users are not able to receive the group/list mail. Please >advice ! Thanks. > >I followed the below forum integration that was suggested official by >zimbra community: > >http://www.zimbra.com/forums/administrators/1380-solved-zimbra-mailman-howto.html Please see the FAQs at <http://wiki.list.org/x/OIDD> and <http://wiki.list.org/x/A4E9>. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] translation of mail templates
Peter Holzer wrote: >Hi >Aside of the actual translations being done... >Can someone confirm that german umlauts and more or less >exotic characters should work within the mail templates? Templates for web pages or pieces of web pages should have all non-ascii characters encoded as HTML entities, e.g. 'ä', 'ö', etc. Text templates for email messages, etc. can have non-ascii (exotic) characters as long as they are encoded in the character set that Mailman uses for that language. For Mailman 2.1 and German, this is iso-8859-1. Unfortunately, I'm not sure how this is working in MM3 in terms of how the various languages are registered and what the character set for German is (although most should probably be utf-8). -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] translation of mail templates
On 8/26/2012 2:12 PM, Patrick Ben Koetter wrote: > * Mark Sapiro : >> Templates for web pages or pieces of web pages should have all >> non-ascii characters encoded as HTML entities, e.g. 'ä', >> 'ö', etc. > > Seriously? Is there a particular reason we can't go UTF-8 and use 'ä', 'ö' > the way they are written natively? Yes, there is a reason. HTML entities are a standard way of representing non-ascii characters in HTML that survives miscommunication of character set information between web applications, web servers and web browsers. Mailman is developed as much as possible to work on multiple servers operated by different people with different configurations. It is possible to configure web servers to include a Content-Type: header with a charset parameter when sending a text/html response which will override the charset parameter in the Content-Type: that Mailman puts in a META tag in the HTML. (See, e.g., <http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset>). If mailman generates web pages with non-ascii, say utf-8 encoded characters and the installation's web server assigns a default character set other than utf-8, all the utf-8 encoded characters will be garbled. This will not happen if the characters are encoded as HTML entities. I know you wouldn't do such a thing, but if such a thing is possible, some Mailman installations somewhere will do it. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] "newlist" command and Mailman 3
Tom Browder wrote: > >I use "newlist" in a Perl wrapper to programmatically start and delete >mailing lists, and I would like to be able to do more >programmatically, such as: > > add moderators > set default variables > etc. > >Is there any work being done in that direction? The architecture of Mailman 3 is such that communication with the core is via a RESTful HTTP interface. The web UI for example is separate from the core and communicates with the core via this interface. Thus, you can build your own interface for communicating with the core and exercising any core functionality without changing the core itself. Clearly this RESTful HTTP interface must be secured in some way, and normally this would be by only allowing connection from localhost, but other methods could be used if you needed to communicate directly with the core from a different server. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] add_members and nomail
Scot Hacker wrote: > >Long story short, if I were to submit a patch, would it likely be accepted? Or >is there a good reason why it's not included? Probably yes. The reason it was never include upstream is that Apple has *never* shared any of its Mailman changes with the upstream GNU-Mailman project. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Logging automatic rejects of incoming posts.
When a handler raises Errors.RejectMessage to reject an incoming post, nothing is logged. I have filed <https://bugs.launchpad.net/mailman/+bug/1068837> in preparation for addressing this. My question is what to log. Currently, IncomingRunner logs automatic discards with the message 'Message discarded, msgid: %s'. This is a bit cryptic. I think it would be good to have the list name in this message, but I have never changed it as that could be disruptive. It would also be possible to log which handler raised the exception, but again, that could be disruptive. With a new message for rejects, disruption is not much of an issue as existing log analyzers would presumably not recognize the message and skip it, which is no different from no message, or report the raw message. The question is whether it is a good thing to log the error message that accompanies the exception. This can be quite verbose as the error message can be the list's member_moderation_notice or nonmember_rejection_notice, but if only the handler name is logged, it doesn't distinguish between a non-member reject and a moderated member reject. Does anyone have an opinion on this? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] add_members and nomail
On 10/20/2012 11:06 AM, Scot Hacker wrote: > > Here's a simple 2.x diff in case it's useful to anyone: > https://gist.github.com/3924229 Thanks. I'm inclined to implement this for the 2.1 branch, but my taste is to do it differently. I would prefer to have a -n|--nomail option which if specified would set the added members to nomail by admin, the default in the absence of the option being current behavior. Thus, no need for --enable-mail=. Also, If the member to be added is already a member, I wouldn't change its delivery option. Would such an implementation work for you? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] add_members and nomail
Scot Hacker wrote: > >On Oct 22, 2012, at 7:15 PM, Mark Sapiro wrote: > >> Also, If the member to be added is already a member, I wouldn't change >> its delivery option. >> > >Hmm, not sure about that part - my implementation sometimes includes duplicate >addresses, relying on the mailman import to weed them out. So I would *prefer* >to have the option changed for existing members. But if that doesn't sit well >with you, I understand - my script will just have to be smarter about it. I don't see this as a problem. If you try to add the same address twice with a --nomail option, the first add will succeed and set nomail and the second add will fail and do nothing, but the result is the address is added with nomail set. The only situation in which this makes a difference is if the address is already a member without nomail, which would only occur if it was added previously by some other process or if it was added previously and the user subsequently enabled delivery. Either way, I think the right thing is for add_members --nomail to not disable delivery for an existing member. Note, if you want to just set some or all users to nomail, see <http://www.msapiro.net/scripts/set_nomail.py>. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] New to mailman
Sandesh Agrawal wrote: > >Also can you suggest me some easier bugs to start with. Look at bugs tagged 'easy' <https://bugs.launchpad.net/mailman/+bugs?field.tag=easy>. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Wiki woes
Terri Oda wrote: >I think in the latest wiki update I seem to have lost the ability to >turn off rich text editing, Yes, that sucks. I've been muddling through, but it's a PITA. >and as a result it's nigh impossible for me >to cut and paste some types of content from one page to another. Also, >some pages are now missing content (specifically, anything marked as a >code snippet) if they're viewed without JavaScript. I hadn't noticed that one. Bummer! -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Wiki woes
Terri Oda wrote: >On 12/10/2012 12:37 PM, Barry Warsaw wrote: > >> I suppose the other option is to just get a new moin site up and not worry >> about migration, which is what I think has defeated all our previous >> volunteers. We'd have dual content for a while, maybe forever, and we'd have >> to think about what to call the two hosts, but it's doable. It might be >> easier for volunteers to manually transfer information from one wiki to the >> other than to automate that. (Some content won't be transferable directly >> anyway.) > > >That's not idea, but it's not a terrible idea given that I *think* we're >going to want to start a new Mailman 3 FAQ and have some easy way for >people to tell what version they're searching. I have a moin 1.9.5 installation running in production on my server. I would be happy to set up a Mailman wiki and give people write access to it. Unfortunately, I have another commitment for much of Saturday, but I'll try to be on #mailman in the morning and/or evening if people want to talk about this. I'm time challenged at the moment, but I might give a shot at migrating some content. This might make a good PyCon sprint project too - I'll be there. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Wiki woes
Paul Boddie wrote: > >For now, I have made the Wiki content available at the following location: > >http://mmwiki.boddie.org.uk/ > >As noted, all current page revisions will look wrong, but historical (before >Confluence 4) revisions should have been translated to a certain extent. I like it. And, I note that for a large majority of pages there have been no changes since the "Migrated to Confluence 4.0" change, so the current-1 rev of the page is good. I haven't looked at much, but the biggest problem I see is for example <http://mmwiki.boddie.org.uk/DOC/Frequently%20Asked%20Questions?action=recall&rev=5> versus <http://wiki.list.org/display/DOC/Frequently+Asked+Questions>. The issue is the FAQ in particular relies on the listing of child pages to make a hierarchical TOC, and the converted pages have lost the child pages listing. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] List etiquette - was: Mailman-Developers Digest, Vol 286, Issue 7
It helps greatly if replies to digests are given a meaningful subject and do not quote irrelevant parts of the digest. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman log access on cPanel
Many cPanel Mailman users have issues that are difficult to resolve because they don't have access to Mailman's logs. I spoke with a cPanel developer about this at PyCon, and he has created a feature request at <http://features.cpanel.net/responses/as-a-web-site-owner-i-need-access-to-a-mailman-listss-log-files-in-order-to-troubleshoot>. If you are interested in this, go to the above URL and vote for it. Voting requires registration on the site and that requires providing your name and email address and then waiting for a password to be mailed, but apparently anyone can do it. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Like to participate in GSOC 2013 (GNUMailman) - Like some ideas proposed in the list (Django, Python)
Barry Warsaw wrote: > >IIRC, Mark was using Cygwin at one point. Yes. Actually, my main Mailman 2.1 development platform is Cygwin, but I gave up on trying to run MM 3 under Cygwin. I don't recall all the issues, but there were several around file names with unacceptable characters for Windows (there's one in MM 2.1, but it's easily worked around). >The thing about Windows is that we're using several *nix-isms in process >management and possibly in other places. I have no burning desire to try to >make these Windows compatible. The real problem with running Mailman on Windows, at least for real lists, is you need a viable mail server. It seems to me that most people who might consider running Mailman on Windows do not have a machine with a fixed IP with full circle DNS and a non-generic host name and preferably an IP not in a 'home use' block. These things are needed if you want large ISPs to accept your mail. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Integration on GSoC
Marcos Chavarría Teijeiro wrote: > 4) MailMan decrypt the received message and check if the sign is correct > (with the stored public user public key). If the sign is correct, it sends > a message to every mail-list subscripter encrypted with each user public > key. As Stephen suggests in another thread at <http://mail.python.org/pipermail/mailman-developers/2013-April/022681.html>, Mailman should resign with its own private key to verify that it has accepted the incoming post and that the post was signed by a list member -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] MM 2.1 - Relative vs. absolute URLs in admin and admindb interfaces.
There is a thread in mailman-users at <http://mail.python.org/pipermail/mailman-users/2013-April/074961.html>. In short the user's difficulty is her world facing host name doesn't work inside her LAN so from inside, she accesses the web interface via IP address or some other host name. This leads to the issue that some links and form actions in the web admin and admindb interfaces are absolute using the list's web_page_url which has the host name that doesn't work inside the LAN. Granted, this can be addressed in the network or the work station's /etc/hosts file, but the question arises as to whether these URLs need to be absolute, particularly because they're already in the minority. I was going to call this a MM 2.1 bug and fix it but then I came across this 10 year old comment from Barry at <https://bugs.launchpad.net/mailman/+bug/265838>. We had lots of problems when non-absolute urls where used, although I don't remember the exact details of the problems. Eventually we'll probably make all urls absolute and get rid of this argument to GetScriptURL(). So my question is would there be issues if the URL in the form action and the leter/digit links on the web admin Membership List page or those in the admindb interface were relative instead of absolute and what might those issues be? Does anyone know? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] error installing the mailman web UI
Avik Pal wrote: >ya thanx sneha and sreyanth, hopfully other community members will be able >to help me out of this situation. The actual exception in your original post was a timeout trying to open an internet connection to retrieve some package. Are you behind some firewall or is there some other problem preventing you from connecting to PyPI or wherever it's going? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
On 4/15/2013 4:32 AM, Pratik Sarkar wrote: > Can someone please give me a link of the existing mailman spam filter > techniques.? SpamBayes integration <https://code.launchpad.net/~smontanaro/mailman/SpamBayes> Spamassassin integration <https://bugs.launchpad.net/mailman/+bug/266588> -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A feature I'd like to emphasize for GSoC ...
On 4/16/2013 2:19 AM, Patrick Ben Koetter wrote: > > Let me add some inconvenience: Log contains privacy related information. I'd > expect a log view/research interface to limit output to what the person/role > may look at and no more. This is an excellent point. It can be very useful for list admins or domain admins to view logs for various purposes, but multi-user shared hosting services (think cPanel) will be very reluctant to let these people see logs unless what they can see is restricted to their own list/domain. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] anti-spam filter
On 4/18/2013 1:32 PM, Patrick Ben Koetter wrote: > * Terri Oda : >> >> I hope that no one was seriously considering that level of >> hardcoding. What we are almost certainly talking about is setting >> up a handler (I think Stephen estimated this to be around 10 lines >> of code). > > And that handler would be - excuse my ignorance I don't program - a Python > function to handle a Python program? Could the handler pass a message over to > e.g. SpamAssassin (Perl) or openDKIM (c code) or any other non Python program > without the need to add any additional (Python) code? In 10 lines? Maybe. If SpamAssassin is spamd, the Python socket module is part of the standard library. OpenDKIM includes a milter interface. There are Python milter shims available Perhaps your point is that this is more than 10 lines of code which is probably true, but interfacing to some specific spam filter plugin architecture from a Mailman chain rule module does not seem to me to be a big project. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Build a mailman3 development virtualmachine with Vagrant and Chef
Xu Wang wrote: >I'm not sure I have the permission to edit the wiki page. If anyone with >the permission and know how, please feel free to add the link. As it says at the upper left of the wiki home (dashboard) page "to add or edit content you must sign up and log in, and you must also request write permission for your user name by sending a note to the Mailman Steering Committee. (sorry it's the only way to control wiki spam)." You now have permission. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface.
On 05/09/2013 09:47 AM, Daniel Kahn Gillmor wrote: > > so something like: > > href="mailto:l...@example.org?In-Reply-To=%3c3469a91.d10a...@example.com%3E";>Reply > to this message Go to <http://mail.python.org/pipermail/mailman-developers/2013-May/023054.html> and look at the mailto: link under 'dkg at fifthhorseman.net'. > While this doesn't solve the problem for everyone (i'm sure there are > MUAs that don't accept this header when generating mail from a mailto: > link), it should be very easy to implement, and if mailman's default > archives were to include such a link it would spur people to fix > non-compliant MUAs. Granted, it doesn't say "Reply to this message", but it's been that way for years. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface.
On 05/09/2013 10:31 AM, Daniel Kahn Gillmor wrote: > > On 05/09/2013 01:06 PM, Mark Sapiro wrote: >> Go to >> <http://mail.python.org/pipermail/mailman-developers/2013-May/023054.html> >> and look at the mailto: link under 'dkg at fifthhorseman.net'. > > wow, great! I have never looked at this link before because i always > assumed it was a link to e-mail the original sender of the message. It can be that. If the global setting ARCHIVER_OBSCURES_EMAILADDRS is True (the default) the text will be of the form 'user at example.com' and the link will address the list. If ARCHIVER_OBSCURES_EMAILADDRS is False, the text will be of the form 'userexample.com' and the link will address the user, but in either case, the In-Reply-To= and Subject= fragments will be included. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6
On 05/26/2013 06:33 PM, Graham Leggett wrote: > Hi all, > > Has anyone managed to get the mailman true virtual hosting patch for 2.1 working on Redhat Enterprise 6 as described at https://wiki.koumbit.net/VirtualMailman? I'm not sure how that compares to what I'm familiar with. I have a branch at <https://code.launchpad.net/~msapiro/mailman/vhost> based on the work of Hans Ulrich Niedermann and predecessors. (See the FAQ at <http://wiki.list.org/x/jIA9> and the post at <http://mail.python.org/pipermail/mailman-developers/2006-March/018629.html>.) Coincidently, this branch was just merged with the head of the 2.1 branch. I do not use this branch. My disclaimer is "Please don't ask me to fix all the problems with this branch. I don't guarantee that anything will work. I ported the patches and fixed a few reported problems as a service to those who wish to use it. I don't use it and am not enthusiastic about maintaining it. If you use this branch and encounter problems and report those problems to mailman-us...@python.org, I may fix them, but only if they are easy to fix." In general, I will try to fix reported problems if the fixes are not too involved. > I have to apply the patch manually as it the patch fails in a few places, however once applied the patch doesn't seem to work as it did on RHEL5. Mails are sent, but the list ends up being called list-example@example.com, which will break the list for end users. This is highly reminiscent of cPanel except their list names are list_example@example.com and they accept mail to l...@example.com for list_example@example.com by (in their case) teaching the Exim router about this convention. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6
On 05/27/2013 07:57 AM, Graham Leggett wrote: > > Hopefully this fix doesn't fall into the too involved category. This sanity > check was failing even when the emailhost and domain were the same: Fix accepted and committed to the branch at <https://code.launchpad.net/~msapiro/mailman/vhost>. Thank you. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6
On 05/28/2013 04:48 AM, Graham Leggett wrote:
>
> Here is another small issue, when VIRTUAL_HOST_OVERVIEW was switched off to
> allow all virtual lists to appear on the same host, the host_name of the list
> wasn't passed in the URL. The attached patch fixes this.
>
> diff -u -r mailman-2.1.12/Mailman/MailList.py
> mailman-2.1.12-patched/Mailman/MailList.py
> --- mailman-2.1.12/Mailman/MailList.py 2013-05-28 10:39:09.333154778 +
> +++ mailman-2.1.12-patched/Mailman/MailList.py 2013-05-28 10:40:57.874209489
> +
> @@ -252,6 +252,9 @@
> def GetScriptURL(self, scriptname, absolute=0):
> # Using "local_part" here works for both site wide lists on
> # the default url host and for vhost lists on the vhost url host.
> +if not mm_cfg.VIRTUAL_HOST_OVERVIEW:
> +return Utils.ScriptURL(scriptname, self.web_page_url, absolute)
> + \
> + '/' + self.local_part + '@' + self.host_name
> return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \
> '/' + self.local_part
>
Actually, that patch is not what's required. The comment is wrong.
@hostname is required for all vhosts lists regardless of the host name
in the URL or the setting of VIRTUAL_HOST_OVERVIEW.
A correct patch is attached.
As for the patch below, I see what you're trying to do, but I'm nervous
about untended consequences of creating lists in domains not in
VIRTUAL_HOSTS. I think the patch should be OK, but as I say, I'm nervous
about it.
I will definitely commit the attached patch, and I'll think about the
other. Do you have any motivation for it other than just not wanting to
bother with adding add_virtualhost() to mm_cfg.py?
> diff -u -r mailman-2.1.12/bin/newlist mailman-2.1.12-patched/bin/newlist
> --- mailman-2.1.12/bin/newlist 2013-05-28 10:39:09.339158852 +
> +++ mailman-2.1.12-patched/bin/newlist 2013-05-28 10:21:04.730131451 +
> @@ -165,7 +165,7 @@
> emailhost = domain
> elif emailhost != domain:
> usage(1, C_('You cannot use an email host different from the
> domain part of the list name.'))
> -if not mm_cfg.VIRTUAL_HOSTS.has_key(urlhost):
> +if mm_cfg.VIRTUAL_HOST_OVERVIEW and not
> mm_cfg.VIRTUAL_HOSTS.has_key(urlhost):
> _urlhost = repr(urlhost)
> _emailhost = repr(emailhost)
> usage(1, C_('The Mailman config file lacks a line mapping
> urlhost to emailhost:\n add_virtualhost(%(_urlhost)s,\n
> %(_emailhost)s)'))
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--- ../vhost/Mailman/MailList.py2013-05-25 16:00:50.930182026 -0700
+++ Mailman/MailList.py 2013-05-28 16:26:36.696692828 -0700
@@ -250,10 +250,10 @@
return "%s%s@%s" % (acct, self.umbrella_member_suffix, host)
def GetScriptURL(self, scriptname, absolute=0):
-# Using "local_part" here works for both site wide lists on
-# the default url host and for vhost lists on the vhost url host.
-return Utils.ScriptURL(scriptname, self.web_page_url, absolute) + \
- '/' + self.local_part
+return '%s/%s' % (
+Utils.ScriptURL(scriptname, self.web_page_url, absolute),
+self.internal_name()
+)
def GetOptionsURL(self, user, obscure=0, absolute=0):
url = self.GetScriptURL('options', absolute)
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] true virtual hosting patch for 2.1 on RHEL6
On 06/01/2013 06:08 AM, Graham Leggett wrote: > On 29 May 2013, at 1:50 AM, Mark Sapiro wrote: > >> Actually, that patch is not what's required. The comment is wrong. >> @hostname is required for all vhosts lists regardless of the host name >> in the URL or the setting of VIRTUAL_HOST_OVERVIEW. >> >> A correct patch is attached. > > I will give this a try and confirm. I have committed this to my branch at <http://launchpad.net/~msapiro/mailman/vhost/>. >> As for the patch below, I see what you're trying to do, but I'm nervous >> about untended consequences of creating lists in domains not in >> VIRTUAL_HOSTS. I think the patch should be OK, but as I say, I'm nervous >> about it. After giving it more thought, I committed that one too plus a merge of the latest head of the 2.1 branch. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 06/15/2013 02:45 PM, Barry Warsaw wrote: > > On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote: > >> * Inline pgp should be supported or not? > > Probably not as a first step. PGP/MIME will be easier to support so do that > first. As Stephen suggests, a survey of popular MUAs might be useful. My own > (Claws Mail) supports them both, though I'm not sure which is default. I > certainly use and prefer PGP/MIME. I think Thunderbird/EnigMail uses inline pgp by default, but PGP/MIME can be set as the default per account and is always available when composing a message. At one time EnigMail discouraged PGP/MIME as being supported by few MUAs, but that caveat appears to have been removed from the current UI. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration
On 06/15/2013 11:42 PM, Stephen J. Turnbull wrote: > > Barry Warsaw writes: > > > I know this is a little backwards, but it's probably the best match > > for the current rule/chain model. > > I have a smallish problem with this model. Specifically, for a list > with a maximum size, I think it's probably desirable to do any MIME > part stripping *before* the size test. But this doesn't fit the > chain(s) -> pipeline model AFAICS. FYI, on my production server (MM 2.1 - well actually 2.2+ ;) I reorder the GLOBAL_PIPELINE to put MIMEDel before Hold for exactly this reason. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Wiki Migration Update
On 06/17/2013 08:13 AM, Barry Warsaw wrote: > > That would be fantastic, thanks. Let's wait for Mark's feedback and then we > can start thinking about next steps. I am traveling and visiting family through the end of the month and haven't been following this too closely, but there is only one issue I'm concerned about and that's URLs to FAQ pages in archived list mail. It's not a show stopper. We had the same issue when we converted from the FAQWizard, and it didn't seem to be a big deal, but here it is. Every page (I think) in the wiki has three URLs. E.g. 1. <http://wiki.list.org/display/DOC/Frequently+Asked+Questions> 2. <http://wiki.list.org/pages/viewpage.action?pageId=3604482> 3. <http://wiki.list.org/x/AgA3> I gather that in the migration to Moin, the pages will have names/URLs like 1. but with spaces instead of pluses. This is fine, and if necessary a mapping from old to new URLs can be easily constructed. Form 2. is trickier. Confluence seems to use somewhat arbitrarily either 1. or 2. in internal links, so form 2. is sometimes seen in list posts referring to FAQ articles. Form 3. is what Confluence calls "Tiny Link: (useful for email)" and is available in the pages 'info' and (along with form 1.) in the "Link to this Page" Tool dialog. I use this all the time in list posts referring to FAQ articles. I don't know what info is available in the Confluence dump, but it would be nice to have at least the 'tiny link' and maybe the pageId info so that mappings and maybe eventually redirections can be constructed to get from the old URLs to the new pages. As I said, I don't think it's a show stopper, but it would be helpful. Regarding the article numbers appearing in section 4 only: in the FAQWizard, all the articles were numbered. When Teri converted the FAQWizard, she dropped the numbers from the page titles. This proved controversial and Duncan Drury added them back, but only in section 4. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman search function (was?? Re: Like to participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the list (Django, Python))
On 06/29/2013 07:12 PM, Chris Cargile wrote: > I'm not sure where things stand regarding search for mailman- > however, I found Ian > Hicks<http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/>' > approach (of applying the HT-Dig capabilities to enhance a MM v2.0 instance > interesting, but perhaps overkill and/or not quite right) but a good > case-in-point for ideas. It appears the archive at the above URL employs the indexing and htdig patches for Mailman 2,1 originally developed by Richard Barrett <http://www.openinfo.co.uk/mm/index.html> and now maintained by me <http://www.msapiro.net/mm/>. > I resolved my need for making 'search' on my lists practically achievable > but in terms of overall integration into the fabric of mailman code, it is > insufficient. What more do you want? > If you want to see my search implementation, check out a prototype from me > on my AWS > instance<http://ec2-54-224-162-128.compute-1.amazonaws.com/pipermail/mailman/> > . > > Please share your thoughts here or directly to me ;) Your prototype looks fine, but what's behind /cgi-bin/search.py ? Don't look for anything to be released for MM 2.1. The patches for htdig are available and other methods are referenced in the FAQ. If anything were to be released, it would be the htdig patches because that's what I use, but it's problematic because of the htdig dependency. For Mailman 3 the intent is that archivers will be "plugable", and the defaults will be <http://www.mail-archive.com> and <https://fedorahosted.org/hyperkitty/> -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman search function (was?? Re: Like to participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the list (Django, Python))
On 06/29/2013 07:33 PM, Chris Cargile wrote: > FWIW, I'd also like very much if anyone could provide a few lines recap of > the activity on the ModernArchiving topic under "initiatives and proposals" > as I feel my thoughts on searching/archiving tie into the > objectives/requirements listed there: > http://wiki.list.org/display/DEV/ModernArchiving See <https://fedorahosted.org/hyperkitty/> -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
On 07/08/2013 08:34 AM, Franck Martin wrote: > > I suspect this process has been improved in MM3, but I have not had a look at > the code. The purpose is for mailman to recognize 5.7.x bounces and not count > them against the recipient (or as soft bounce). Hard bounce is the default > for any non recognized bounce. MM3 uses flufl.bounce <https://launchpad.net/flufl.bounce> for bounce processing. The process, algorithms and heuristics are essentially identical to MM2.1 In the case of an RFC 3464 compliant DSN, MM does not look at the Status field at all. It only looks at the Action field. Actions beginning with 'fail' result in a 'permanent failure' determination. Actions beginning with 'delayed' result in a 'temporary failure' determination. All other actions result in the bounce being ignored. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Adding DMARC support for Mailman 3
On 07/08/2013 10:52 AM, Franck Martin wrote: > > I see in MM2 that regex are used to classify the bounces: > http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/files/head:/Mailman/Bouncers/ Yes and no. Bounce processing in the non-VERP case works by processing the DSN through a series of heuristic recognizers. A recognizer returns a possibly empty list of bouncing addresses or a special STOP signal. If the STOP signal is returned, it means "I recognize this, but ignore it" and processing of this bounce stops. If a non-empty list is returned, bounces are scored for those addresses and processing stops. If an empty list is returned, processing continues to the next recognizer. Several of the heuristic recognizers use regexps in the recognition process, but ideally, all DSNs would be RFC 3464 compliant and the recognizer for these looks only at the Action field to determine what to do. Of course in the real world, not all DSNs are RFC 3464 compliant, so we have a bunch of other recognizers. This is different in the VERP case in that the bouncing address is always obtained from the envelope recipient and the recognozers are only called to determine if the bounce is fatal or not. MM3 is different in that its recognizers return two sets of addresses, one for permanent and one for temporary failures. > which is described in broad terms here: > http://www.esosoft.com/support/mailinglist/mailman/bounce.html And which is not strictly correct for MM2.1 at least because in MM2.1, contrary to the documentation, there are no 'soft bounces'. Either delivery failed, even for a full mailbox, in which case we score a 'hard bounce', or it didn't (yet) in which case we score nothing. > It seems flufl has the same structure > http://bazaar.launchpad.net/~mailman-coders/flufl.bounce/trunk/files/head:/flufl/bounce/_detectors/ In essence, the structure and process are the same, but it does add the temporary failure notion. It would certainly be possible to add recognition of a DMARC policy rejection and not report it as a bounce for a recipient (or fix the bugs one by one as they are reported), although I suspect it would be some while before the dust settles and most all the non-compliant MTAs bounces are properly classified. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman 2.1.16 release.
FYI, I will be releasing 2.1.16rc1 in a few days with a target of a final release in early September. I believe the release will be very solid and stable. The main purpose of the candidate release is to expose any i18n changes so that translators can submit any updates and get them in the final release. There are a few new features, contributed programs, i18n changes and bug fixes, all of which will be announced when the candidate is released. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Announce] Mailman 2.1.16 release.
On 07/12/2013 11:13 AM, Rob Lingelbach wrote: > As a long-time user of Mailman, running a list of 2000+ subscribers, thank > you Mark for all your work. Is there any pertinent > news regarding a new major release of Mailman? Work on Mailman 3, Postorius and Hyperkitty is progressing, but at the moment I'm not aware of any firm release dates. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 2.1.16 release.
I am pleased to announce the first release candidate for Mailman 2.1.16. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has a few new features and several bug fixed as detailed in the attached README. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.16rc1 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ I anticipate that the 2.1.16 final release will be in early September. Bugs found between now and then will be fixed if possible, but I hope that most if not all changes between now and then will be i18n updates. Please send any updates to the templates and/or message catalogs in the 2.1.16rc1 release directly to me no later than 1 Sept 2013. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.16rc1 (14-Aug-2013) New Features - Setting digest_size_threshhold to zero now means no digests will be sent based on size instead of a digest being sent with every post. (LP: #558274) - There is a new mm_cfg.py setting SUBSCRIBE_FORM_SECRET which will put a dynamically generated, hidden hash in the listinfo subscribe form and check it upon submission. Setting this will prevent automated processes (bots) from successfully POSTing web subscribes without first retrieving and parsing the form from the listinfo page. The form must also be submitted no later than FORM_LIFETIME nor no earlier than SUBSCRIBE_FORM_MIN_TIME after retrieval. Note that enabling this will break any static subscribe forms on your site. See the description in Defaults.py for more info. (LP: #1082746) - add_members now has an option to add members with mail delivery disabled by admin. (LP: #1070574) - IncomingRunner now logs rejected messages to the vette log. (LP: #1068837) - The name of the mailmanctl master lock file is now congigurable via the mm_cfg.py setting MASTER_LOCK_FILE. (LP: #1082308) - list_lists now has an option to list only lists with public archives. (LP: #1082711) Contributed programs - A new import_majordomo_into_mailman.pl script has been contributed by Geoff Mayes. (LP: #1129742) - A new "sitemap" bash script has been contributed by Tomasz Chmielewski to generate a sitemap.xml file of an installation's public archives for submission to search engines. i18n - A Farsi (Persian) translation has been added thanks to Javad Hoseini and Mahyar Moghimi. - Fixed several misspelled or garbled string replacements in the Spanish message catalog. (LP: #1160138) - pt_BR message catalog has two new and an updated message per Hugo Koji Kobayashi. (LP: #1138578) - German message catalog has been updated per Ralf Hildebrandt. - Corrected typo in templates/it/private.html. Bug Fixes and other patches - Added "message_id" to the interpolation dictionary for the Article.html template. (LP: #725498) - Changed the admin GUI to report only the bad entries in a list of email addresses if any are bad. (LP: #558253) - Added logging for template errors in HyperArch.py. (LP: #558254) - Added more explanation to the bad owner address message from bin/newlist. (LP: #1200763) - Fixed a bug causing the admin web interface to fail CSRF checking if the list name contains a '+' character. (LP: #1190802) - Fixed bin/mailmanctl -s to not remove the master lock if it can't be determined to be truly stale. (LP: #1189558) - It is no longer possible to add 'invalid' addresses to the ban_list and the *_these_nonmembers filters from the check boxes on the admindb interface. (LP: #1187201) - Backported recognition for mail.ru DSNs and minor bug fixes from lp:flufl.bounce. (LP: #1074592, LP: #1079249 and #1079254) - Defended against buggy web servers that don't include an empty QUERY_STRING in the CGI environment. (LP: #1160647) - The Switchboard.finish() method now logs the text of the exception when it fails to unlink/preserve a .bak file. (LP: #1165589) - The pending (un)subscriptions waiting approval are now sorted by email address in the admindb interface as intended. (LP: #1164160) - The subscribe log entry for a bin/add_members subscribe now identifies bin/add_members as the source. (LP: #1161642) - Fixed a bug where the Subject: of the user notification of a bin/remove_members unsubscr
Re: [Mailman-Developers] Mailman 2.1.16 release.
I am pleased to announce the second release candidate for Mailman 2.1.16. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has a few new features and several bug fixed as detailed in the attached README. Differences from the first candidate are the inclusion of the admindb summary sorting options feature and the 'author is list' feature and a bug fix for lp:1203200. The Farsi translation has also been updated. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.16rc2 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ I anticipate that the 2.1.16 final release will be in early September. Bugs found between now and then will be fixed if possible, but I hope that most if not all changes between now and then will be i18n updates. Please send any updates to the templates and/or message catalogs in the 2.1.16rc2 release directly to me no later than 1 Sept 2013. Note that there is a minor glitch in the tarball in that the NEWS file dates the release as xx-Aug-2013 instead of 19-Jul-2013, but I didn't think it was worth uploading new files for that. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.16rc2 (19-Jul-2013) New Features - There is a new list attribute author_is_list to rewrite the From: header of posts replacing the posters address with that of the list for compatability with DMARC and or ADSP. There is a new mm_cfg.py setting DEFAULT_AUTHOR_IS_LIST to control the default for new lists, and the existing REMOVE_DKIM_HEADERS setting has been extended to allow removing those headers only for author_is_list = Yes lists. This feature must be enabled by setting ALLOW_AUTHOR_IS_LIST to Yes in mm_cfg.py. - There is a new DISPLAY_HELD_SUMMARY_SORT_BUTTONS setting which if set in mm_cfg.py will display a set of radio buttons in the admindb held message summary to select how the held messages are sorted and grouped for display. The exact setting determines the default grouping and sorting. See the description in Defaults.py for details. - Setting digest_size_threshhold to zero now means no digests will be sent based on size instead of a digest being sent with every post. (LP: #558274) - There is a new mm_cfg.py setting SUBSCRIBE_FORM_SECRET which will put a dynamically generated, hidden hash in the listinfo subscribe form and check it upon submission. Setting this will prevent automated processes (bots) from successfully POSTing web subscribes without first retrieving and parsing the form from the listinfo page. The form must also be submitted no later than FORM_LIFETIME nor no earlier than SUBSCRIBE_FORM_MIN_TIME after retrieval. Note that enabling this will break any static subscribe forms on your site. See the description in Defaults.py for more info. (LP: #1082746) - add_members now has an option to add members with mail delivery disabled by admin. (LP: #1070574) - IncomingRunner now logs rejected messages to the vette log. (LP: #1068837) - The name of the mailmanctl master lock file is now congigurable via the mm_cfg.py setting MASTER_LOCK_FILE. (LP: #1082308) - list_lists now has an option to list only lists with public archives. (LP: #1082711) Contributed programs - A new import_majordomo_into_mailman.pl script has been contributed by Geoff Mayes. (LP: #1129742) - A new "sitemap" bash script has been contributed by Tomasz Chmielewski to generate a sitemap.xml file of an installation's public archives for submission to search engines. i18n - A Farsi (Persian) translation has been added thanks to Javad Hoseini and Mahyar Moghimi. - Fixed several misspelled or garbled string replacements in the Spanish message catalog. (LP: #1160138) - pt_BR message catalog has two new and an updated message per Hugo Koji Kobayashi. (LP: #1138578) - German message catalog has been updated per Ralf Hildebrandt. - Corrected typo in templates/it/private.html. Bug Fixes and other patches - Fixed cron/disabled to send a fresh cookie when notifying disabled members. (LP: #1203200) - Added "message_id" to the interpolation dictionary for the Article.html template. (LP: #725498) - Changed the admin GUI to report only the bad entries in a list of email addresses if any are bad. (LP: #558253) - Added logging f
Re: [Mailman-Developers] Wiki Migration Update
On 07/26/2013 12:59 PM, Barry Warsaw wrote: > On Jul 19, 2013, at 01:15 AM, Paul Boddie wrote: > >> Once again, I've had some time to push the wiki migration along. As always, >> the results can be found here: >> >> http://mmwiki.boddie.org.uk/ >> >> I've updated the archived content to that of 16th July, so the translated >> content should reflect the existing wiki fairly accurately. > > Thanks very much for continuing to work on this Paul. I think it's looking > great and I'd love to start coming up with a plan to migrate officially. > Input from top wiki editors is key, so perhaps Mark, Terri, Steve and others > can chime in. Yes, thank you Paul. I too think it looks really good. > I can tell you though that my motivation to garden the current > wiki is pretty low, and I think I'd be more motivated to clean it up after the > Moin migration. If the other wiki editors feel the same way, then we should > seize the opportunity to get the migration started. +1 > What features are missing from Moin that would prevent us from migrating, or > make it more painful than staying with Confluence for now? I think we can do alright with a switch. I support a Moin wiki for my bike club, and I think we'll be OK. I have a bit to add below. >> But the solution above may be good enough: it just creates an account for >> each existing user and employs the same username, full name (or alias) and >> e-mail address, and sets a random password. It also obtains the URL of any >> profile picture, with these user details obtained by scraping the home page >> of each user on the existing wiki. How people then log into their accounts is >> something we can decide: e-mailing the random password is not exactly secure, >> but they could reset their account in the MoinMoin interface instead (which >> involves a reset e-mail that isn't too secure either, but it's the slightly >> better choice). The reset email shouldn't be a big issue if the user is prepared to receive and act on it. The reset token is only valid during the window from when it is sent to when it is used. > I'm happy with just asking everyone to reset their password. We can't do it > on the demo site because email is disabled currently. > > What can we do about setting up the ACLs for editing? I'm happy if we start > by enabling a small group to start with and having folks who want to edit > pages re-request enabling their editing permissions. It's fairly simple to add ACLs to pages that give one or more groups various access rights. Groups are just wiki pages with a list of the login names of the members of that group and so are administered by the members of the group that can modify that page. I think we can deal with that by making a small 'admin' group and then having people at large request permission (i.e. addition to the larger 'authors' group as they do now. There is an issue on my own Moin wiki in that people who are logged in but not members of any group can create and edit pages which don't have ACLs. At one point I was discovered by wiki spammers. I 'fixed' that by using Moin's textcha facility to effectively require a password to create an account. It could be solved more readily by not giving 'Known' users default (or any) write access. >> One thing we also discussed were the redirects that occur for "tiny URLs" >> and >> where page identifiers are employed. For example: >> >> http://mmwiki.boddie.org.uk/x/AgA3 >> http://mmwiki.boddie.org.uk/pages/viewpage.action?pageId=3604482 >> >> A mapping of page identifiers is extracted from the exported data, and this >> mapping is used to support a simple redirection script that looks up the >> appropriate page name and redirects to that page. One thing it does not yet >> do is to redirect to a specific revision, however. > > I think that's fine. I don't mind if redirects to anything other than the > latest revision is enabled. Mark might disagree. I do not disagree. I see no need to redirect those URLs to other than the current page. > I guess we won't be able to use tiny urls after the migration though, right? I think that's right, and it's unfortunate, but I can live with it (or implement a tiny url feature for Moin). >> I always provide a list of things that still need doing, so here are some >> familiar items: >> >> The way comments are presented on pages still needs improving. I may write a >> macro to include the comment pages in a nicer way and maybe even to allow >> new >> comments to be added. Meanwhile, the comment pages should no
Re: [Mailman-Developers] Wiki Migration Update
On 07/26/2013 02:25 PM, Barry Warsaw wrote: > On Jul 26, 2013, at 02:05 PM, Mark Sapiro wrote: > > If there are no objections, I'll reach out to the infrastructure team to see > what they'd need. I'll have to contact John and Matt to do any required DNS > changes. I think the rough task list would be: > > * Get python.org to assign us an IP address > * Map wiki-new.list.org to that IP > * Freeze all edits on wiki.list.org > * Have Paul do one more migration that he's happy with > * Get pdo to install that on wiki-new > * Test, test, test > * Move the DNS for wiki.list.org to the new IP > * Decommission the Confluence instance Sounds good. Re: timing, I am off line much of now through Aug 30, so for me at least, 'Test, test, test' shouldn't begin before September. > Would you and/or Paul want shell access to the new Moin instance? I don't > know if that's possible, but if you do, I'd make that part of my request to > infrastructure. It might be helpful, but the more critical things are that probably at least one of us should be in the superuser list (a configuration setting) and there should be an AdminGroup with all rights and we should be in it. Of course we can do this with shell access to the configuration file. >> There is an issue on my own Moin wiki in that people who are logged in >> but not members of any group can create and edit pages which don't have >> ACLs. At one point I was discovered by wiki spammers. I 'fixed' that by >> using Moin's textcha facility to effectively require a password to >> create an account. It could be solved more readily by not giving 'Known' >> users default (or any) write access. > > Is that possible? I think we'd definitely want to do that. Also, I guess > 'unknown' users would also not have any write access, correct? My Moin installation is dumb in this respect. I don't remember why we wanted to set it up the way we did, maybe so a user could create their own home page before being added to a group, but in this age of wiki spam it's probably not a good idea. And yes, we can be as loose or as tight as we want. The page at <https://moinmo.in/HelpOnAccessControlLists> gives the story, but the short answer is we can require a user to be logged in and a member of some specific group before they can create or modify any content. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Wiki Migration Update
On 07/26/2013 03:59 PM, Paul Boddie wrote: > > On the subject of home pages, users can create their own after creating an > account, but it is also possible to impose textchas on the registration > process itself. That is in fact what I do. I have one TextCha question, "What is the account creator password?" and the answer is given to people out of band. I also have a SuperGroup whose members are all the other groups, and (indirect) members of the SuperGroup are exempt from TextChas. This way, one needs to establish contact before registering, and once registered and added to at least one group, they can proceed with minimal hinderance. > The global ACLs may also prevent the creation of home pages > through things like the MyPages action, but I haven't really checked this. I'm pretty sure this is the case. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Wiki Migration Update
On 07/26/2013 03:38 PM, Paul Boddie wrote: > On Friday 26. July 2013 21.59.14 Barry Warsaw wrote: > >> What features are missing from Moin that would prevent us from migrating, >> or make it more painful than staying with Confluence for now? > > I think only the actual wiki editors can answer this. I imagine that the > dashboard features would be nice to have. I'm only one data point, but pretty much the only thing I use the dashboard for is seeing the recently updated pages, both to see what's going on and check for spam. I'm perfectly happy with Moin's RecentChanges page for this. [...] > I've now made some support for comments, including adding new ones. It might > be wise to add textcha integration for this, though, but I already support > ACLs and thus don't allow the posting of comments on pages where a user > cannot > write to that page, even though the comments are actually subpages. Cool on the comments support. On the ACLs, are you assuming acl_hierarchic is True or are you just duplicating the parent page's ACL? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] How to send out the whole archive of a thread to a member
On 08/12/2013 04:21 PM, Nghia Vu Truong wrote: > > Could you please give me guidances about how to send a thread's archives > to a specific member? How about just sending the URL of the first message in the thread and letting the recipient follow the 'next' links to see the rest? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Can we send message with attachment using UserNotification?
On 08/21/2013 02:02 PM, Nghia Vu Truong wrote: > Hi there, > Could you please help me with this question! > Is there anyway we can attach a document to message, sending by > UserNotification method? No. Mailman.Message.UserNotification() creates a single part, plain text message. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Send message having same "References" from archive
On 08/18/2013 09:20 AM, VuNghia Truong wrote:
>
> Suppose that I have archive file, like "list_name.mbox".
> Now, I want to get the message with same "References" field, and send them
> out.
> How could I accomplish this problem?
from Mailman import Mailbox
mid = 'the message Id you're looking for'
fp = open('/path/to/list_name.mbox')
mb = Mailbox.Mailbox(fp)
msgs = []
for msg in mb:
refs = msg.get_all('references')
for ref in refs:
if ref.find(mid) >= 0:
msgs.append(msg)
break
# At this point, msgs contains a list of email.Message.Message objects #
that contain 'the message Id you're looking for' in their References:
# Sending them is left as an exercise for the reader.
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/13/2013 08:06 AM, Barry Warsaw wrote: > > I will leave it to Mark for final decision on this, but my own opinion is that > the mm_cfg.py option should stay. cPanel already customizes their Mailman > installation, so I think they should set it to Yes when they upgrade their > systems to 2.1.16. I don't feel strongly about this either way except for the general principle of least surprise. Enabling this by default has three downsides that I see. It can render a fully i18n translated General Options page a bit ugly with one relatively large English paragraph; it gives list owners yet another bullet with which to shoot themselves in the foot, and it complicates list configuration by adding yet another decision. None of these is a deal breaker. I researched the i18n issue, and it turns out only 4 languages currently have a fully translated General Options page. One of these has already been updated and the other 3 are being addressed. Most languages already have between 1 and 3 untranslated strings on this page from prior changes so it could be argued that one more is not important. The other two considerations are relatively minor, but I still lean towards requiring overt action by the site admin to enable the feature. I wanted this brought to mailman-developers in the hope that whatever discussion ensued would lead to some consensus. I confess, I'm not at all up to speed on DMARC. Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail, but it seems to me that enabling author_is_list will almost guarantee that any incoming DKIM signatures will be broken (the From: is almost certainly included in the signed headers) which will cause problems if the outgoing mail is not signed with a valid DKIM signature. Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it. All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default. Please help me understand if I'm wrong. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/13/2013 12:18 PM, Franck Martin wrote: > > Mailman breaks DKIM as soon as you add a footer or tag in the subject line, > which a lot of lists do (including this one). Not necessarily. It depends on the DKIM signature and how much of the body is signed. Granted, you are correct in most cases, but it might be of interest to some to go to <https://mail.python.org/pipermail/mailman-developers/2007-February/> and review the "dkim-signature headers" threads. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/14/2013 11:18 PM, Franck Martin wrote: > > this is a religious discussion. Religious or not, it is controversial, and this discussion has raised valid points. Because the issue remains controversial, I will soon release 2.1.16 final with the feature disabled by default, and will consider the message encapsulation approach or other possibilities based on experience with 2.1.16 for a 2.1.17 release perhaps early next year. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/17/2013 05:28 PM, Barry Warsaw wrote: > On Sep 15, 2013, at 08:24 AM, Mark Sapiro wrote: > >> Because the issue remains controversial, I will soon release 2.1.16 >> final with the feature disabled by default, and will consider the >> message encapsulation approach or other possibilities based on >> experience with 2.1.16 for a 2.1.17 release perhaps early next year. > > This makes sense to me, although I would label the feature "provisional" or > "experimental". There just isn't any good experience here we can draw on, so > it seems reasonable to provide the knobs that will allow motivated folks to > gather such experience, but generally keep it out of the way for the majority > of users. I intend to so indicate in the NEWS about the feature. I have given some thought to the encapsulation approach and have some questions about it. My thoughts on how to do it include the following if the feature is enabled. CookHeaders saves the original Subject: before prefixing in the metadata. A new handler before ToOutgoing but after ToDigest, ToArchive and ToUsenet creates a new message From: the list with Content-Type: message/rfc822, a unique Message-ID: and Subject:, References: and In-Reply-To: copied from the current message. It then replaces the Subject: in the current message with that saved in the metadata and sets the payload of the new message to the current message. This will result in a single-part message with a payload of the content filtered original message. If content filtering hasn't removed anything, the original message's DKIM signatures if any should still be valid. The message then goes to ToOutgoing and eventually OutgoingRunner and SMTPDirect which will call Decorate and if any msg_header or msg_footer is added, these will be added as is currently done which will result in the message becoming multipart/mixed with the addition of one or two text/plain, Content-Disposition: inline parts containing the header and/or footer. The idea is the message/rfc822 part preserves as much of the original as possible so its DKIM sigs if any may still validate and to put enough into the headers of the new message so MUAs can still thread it properly and render it nicely. Also, the message is unchanged over current behavior for digests, archives and usenet. The sticky questions are what to do with the original From: and Reply-To: in the face of possible Reply-To: munging options and so on. Presumably, we want to still be able to reply to the original author, and preserve the behavior of a simple MUA 'reply' going to the original author and not the list in the absence of Reply-To: munging, and that could be accomplished by putting the original author's Reply-To: (or the original From: if no original Reply-To:) in the new message's Reply-To:, but it's not yet clear to me how to handle the munging options (maybe just ignore them ;). I could actually implement this approach for the 2.1.16 release, but that would negate the i18n work that's already been done as the descriptive string on General Options would change, so I'm more inclined to label this feature as experimental and subject to change significantly in a future release. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/17/2013 10:04 PM, Franck Martin wrote: > > 1) If you keep the From: header as it is then, we will still have the same > problems Perhaps I wasn't clear. The From: of the outer message would contain the list address. The From: of its message/rfc822 payload would be unchanged from that of the incoming message. My questions only had to do with the Reply-To: of the outer message in cases where the list was set to mung Reply-To: in some way. > 2) the purpose of the encapsulation message/rfc822 is not meant to preserve > the DKIM signature, DKIM is not meant to be verified by MUAs No, but that is a side effect, at least where content filtering has not altered the message. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/17/2013 06:21 PM, Mark Sapiro wrote: > > I could actually implement this approach for the 2.1.16 release, but > that would negate the i18n work that's already been done as the > descriptive string on General Options would change, so I'm more inclined > to label this feature as experimental and subject to change > significantly in a future release. > I have had another thought. I will look at provisionally making ALLOW_AUTHOR_IS_LIST a 3 way switch for 2.1.16 with 0 or False (No) meaning current (2.1.15) behavior, 1 or True (Yes) meaning the 2.1.16rc1 behavior and 2 meaning the encapsulated message behavior. If implementation doesn't turn into a can of worms or delay the release too long, I'll do that and encourage interested people to try it and report so we can get some practical experience with which to compare the different approaches. It will still be labeled experimental and subject to future change. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/22/2013 02:12 PM, Barry Warsaw wrote: > > OTOH, maybe we won't know for sure until it gets *a lot* more testing. But I > think it's a mistake to say "well, we just have to force MUA developers to > catch up". As we've seen with something presumably as simple as > reply-to-list, it (almost) never happens. I think what we already know for sure is that people will continue to use their favorite, brain dead MUA regardless of how well or how often we point out the better choices. I think we have some limited influence, but we are definitely not the 600 lb. gorilla in this jungle. Because of that and because of the need for better real world data, I am convinced that I need to release 2.1.16 final with the options of going with simple From: munging (as in RC2) or encapsulation and a default of neither. To that end, I will work on getting it out as soon as I can and will definitely describe the feature as experimental and subject to change in future releases, but encourage people to try it and report so their experience can influence future direction. OT - I just registered for PyCon. I haven't been to Montreal since 1975. I'm committed. I'm stoked! -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Announce] Mailman 2.1.16 release.
I am pleased to announce the third release candidate for Mailman 2.1.16. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has a few new features and several bug fixed as detailed in the attached README. Differences from the second candidate are the renaming of the author_is_list feature to from_is_list to more accurately describe what it does. This feature has also been extended to provide the option of leaving the original message intact and wrapping it in an outer part with Content-Type: message/rfc822. The from_is_list feature is considered experimental and subject to change in future releases. It is being released now as a "candidate" to allow some exposure before the final 2.1.16 release which should occur in October. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.16rc3 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ I anticipate that the 2.1.16 final release will be in Mid October. Bugs found between now and then will be fixed if possible, but I hope that most if not all changes between now and then will be i18n updates. Please send any updates to the templates and/or message catalogs in the 2.1.16rc3 release directly to me no later than 15 Oct 2013. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan New Features - There is a new list attribute from_is_list to either rewrite the From: header of posts replacing the posters address with that of the list or wrap the message in an outer message From: the list for compatability with DMARC and or ADSP. There is a new mm_cfg.py setting DEFAULT_FROM_IS_LIST to control the default for new lists, and the existing REMOVE_DKIM_HEADERS setting has been extended to allow removing those headers only for certain from_is_list lists. This feature must be enabled by setting ALLOW_FROM_IS_LIST to Yes in mm_cfg.py. See the description of these settings in Defaults.py for more detail. This feature is experimental in 2.1.16, and it is subject to change or to become just one of the two methods in a subsequent release. People interested in this feature are encouraged to try it and report their experiences to the mailman-us...@python.org list. - There is a new DISPLAY_HELD_SUMMARY_SORT_BUTTONS setting which if set in mm_cfg.py will display a set of radio buttons in the admindb held message summary to select how the held messages are sorted and grouped for display. The exact setting determines the default grouping and sorting. See the description in Defaults.py for details. - Setting digest_size_threshhold to zero now means no digests will be sent based on size instead of a digest being sent with every post. (LP: #558274) - There is a new mm_cfg.py setting SUBSCRIBE_FORM_SECRET which will put a dynamically generated, hidden hash in the listinfo subscribe form and check it upon submission. Setting this will prevent automated processes (bots) from successfully POSTing web subscribes without first retrieving and parsing the form from the listinfo page. The form must also be submitted no later than FORM_LIFETIME nor no earlier than SUBSCRIBE_FORM_MIN_TIME after retrieval. Note that enabling this will break any static subscribe forms on your site. See the description in Defaults.py for more info. (LP: #1082746) - add_members now has an option to add members with mail delivery disabled by admin. (LP: #1070574) - IncomingRunner now logs rejected messages to the vette log. (LP: #1068837) - The name of the mailmanctl master lock file is now congigurable via the mm_cfg.py setting MASTER_LOCK_FILE. (LP: #1082308) - list_lists now has an option to list only lists with public archives. (LP: #1082711) Contributed programs - A new import_majordomo_into_mailman.pl script has been contributed by Geoff Mayes. (LP: #1129742) - A new "sitemap" bash script has been contributed by Tomasz Chmielewski to generate a sitemap.xml file of an installation's public archives for submission to search engines. i18n - A Farsi (Persian) translation has been added thanks to Javad Hoseini and Mahyar Moghimi. - Fixed several misspelled or garbled string replacements in the Spanish message catalog. (LP: #1160138) - pt_BR message catalog has two new and an updated message per Hugo Koji Kobayashi. (LP: #1138578) - G
Re: [Mailman-Developers] Wiki Migration Update
On 11/03/2013 01:37 PM, Paul Boddie wrote: > > Please take another look at your favourite pages and let me know if anything > has gone badly wrong in the conversion process. > > With this I hope we are nearing the point of final migration. I've looked and it seems really good. I agree that we are very close if not there on everything that matters to me. Thank you Paul for this work. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] small patch
On 11/14/2013 02:22 AM, Fil wrote: > Hello, > > I just upgraded to Mailman 2.1.16 and python 2.7 (I was still on MM 2.1.11 > with python 2.3) > > => with a topics-enabled list, I had a few shunted files with this message : > > Nov 14 11:04:29 2013 (21875) Uncaught runner exception: change_header() got > an unexpected keyword argument 'Delete' > > File "/var/local/mailman/Mailman/Handlers/Tagger.py", line 74, in process > > mlist, msg, msgdata, Delete=False) Thanks for the report. The fix is committed for the next release. See <https://bugs.launchpad.net/mailman/+bug/1251495>. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman 2.1.17
Since the release of Mailman 2.1.16 last month, there have been some i18n updates, a new feature affecting which headers are kept in posts to anonymous lists and a few bug fixes. One of these bugs was introduced in 2.1.16 and is fairly serious although it only affects lists with defined topics. See <https://launchpad.net/bugs/1251495>. For this reason, I plan to release Mailman 2.1.17 in about a week. If there are any i18n changes or other things that should go in 2.1.17, please get them to me before next weekend. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman 2.1.17 release.
I am pleased to announce the final release of Mailman 2.1.17. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has two new features and a few bug fixes as detailed in the attached README. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.17 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.17 (23-Nov-2013) New Features - Handling of posts gated from usenet to a list via the Mail <-> News gateway is changed. Formerly, no list membership, moderation or *_these_nonmembers checks were done. Now, if the sender of the usenet post is a moderated member or a nonmember matching a *_these_nonmembers filter, those checks will be done and actions applied. Nonmember posts from senders not matching a *_these_nonmembers filter are still accepted as before. (LP: #1252575) - There is a new mm_cfg.py setting ANONYMOUS_LIST_KEEP_HEADERS. Since it is not possible to know which non-standard headers in a message might reveal sender information, we now remove all headers from incoming posts to anonymous lists except those which match regular expressions in this list. The default setting keeps non X- headers except those known to reveal sender information, Mailman added X- headers and x-Spam- headers. See the description in Defaults.py for more information. (LP: #1246039) i18n - The Japanese message catalog has been updated by SATOH Fumiyasu. (LP: #1248855) Bug Fixes and other patches - Added a reopen command to the sample init.d script in misc/mailman.in. (LP: #1251917) - Fixed a misspelling in Tagger.py causing an "unexpected keyword argument 'Delete'" exception. (LP: #1251495) - Fixed contrib/qmail-to-mailman.py to work with a user other than 'mailman' and to recognize more listname-* addresses. (LP: #412293) - Fixed a possible UnicodeDecodeError in bin/sync_members. (LP: #1243343) - Fixed Makefile to not include $DESTDIR in paths compiled into .pyc files for traceback purposes. (LP: #1241770) signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] probleme install
On 12/07/2013 06:02 AM, Smati Beghoura wrote: > Mailman now works with a list (mailman default) + > newsletter. Postfix on, if I send myself an email through Outlook > postmas...@hellovoyance.com reserved area on postfix) I get well email. > However, if I send an email to the list (newslet...@hellovoyance.com) > Outlook me a mail with return "user unknown". See <http://www.list.org/mailman-install/postfix-integration.html> Note that mailman-us...@python.org <http://mail.python.org/mailman/listinfo/mailman-users> is probably a more appropriate place for this and similar discussions. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Possible bug in marilman arch when doing incremental archiving
On 12/13/2013 05:06 AM, fc lists wrote: > > When the start is higher then counter, to iterate over the mailbox and get > to the starting point requested, the *next()* method on the mbox object is > called which trigger the archfactory which extract the attachment from > messages that were already archived causing the duplicate attachment to > happen. > > My "test fix" is basically to set the factory for the mbox object to the > default rfc822.Message while iterating over the mbox object until the start > is reached , then i set the factory back to the _archfactory ... and > everything seems to work as expected. Thank you for the report. I have created <https://bugs.launchpad.net/mailman/+bug/1260883> for this issue. I think your fix is OK, but I am inclined to set the factory while skipping to the start to Mailman.Mailbox._safeparser rather than the default just in case one of the skipped messages throws MessageParseError. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Possible bug in marilman arch when doing incremental archiving
On 12/13/2013 02:57 PM, Mark Sapiro wrote: > > Thank you for the report. I have created > <https://bugs.launchpad.net/mailman/+bug/1260883> for this issue. > > I think your fix is OK, but I am inclined to set the factory while > skipping to the start to Mailman.Mailbox._safeparser rather than the > default just in case one of the skipped messages throws MessageParseError. I have committed a fix. I fixed this in a way that is probably different from what you did because I didn't want to import private Mailman.Mailbox functions into Mailman/Archiver/pipermail.py. See <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1440> for my fix. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] bug in tests/test_handlers.py
On 12/19/2013 12:07 PM, Stephen Willey Mats Mats wrote: > > tests/test_handlers.py sets digest_size_threshhold to 0. I assume this is an > attempt to force the digest send. But now 0 means ‘no digest’. Below is my > proposed patch to trick ToDigest into sending. Thanks for the report and patch. This and two other failures have been fixed. See <https://bugs.launchpad.net/mailman/+bug/1262950> and <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1441>. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Updating the template HTML and including CSS?
On 02/06/2014 04:18 AM, Ricardo Lafuente wrote: > > I've also found an attempt to bring the markup up to date in this bug > report with an attached patch from 4 years ago; > > https://bugs.launchpad.net/mailman/+bug/398030 > > However, the patch is pretty large and incorporating it into the > codebase would be non-trivial (plus it's certainly outdated), so I > understand why it's been sitting there forgotten. > > I'd like to take up the task of reviewing the patch and create a branch > where changes would be properly documented in commit logs, following the > Mailman development guidelines, so that it could be easily merged into > the main branch. > > I would only like to ask the Mailman devs if this would be a desirable > goal, since it only makes sense for me to work on this if there's > openness for this to be included in the main branch. The main development focus for Mailman is Mailman 3/Postorius/Hyperkitty. Postorius is a totally new web UI for Mailman. Mailman 2.1 is at the end of its life cycle, although I continue to provide support, fix bugs and even implement new things. The main obstacles to merging the branch you propose is i18n considerations and impacts on existing users. I confess, I haven't really looked at the patch at <https://bugs.launchpad.net/mailman/+bug/398030>, but if it can be implemented with full i18n support and transparently to existing users/lists, I would certainly consider merging it. However, keep in mind that anything that works to extend the life of Mailman 2.1 is contrary to our goal of getting everyone on Mailman 3 as soon as possible. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] Kernel update breaks Mailman!!
On 02/20/2014 10:07 AM, Lindsay Haisley wrote: > I'm running Mailman 2.1.15 on a Ubuntu server, feeding into Courier MTA, > running Python 2.7.3. I track security updates and install them > promptly when they're issued by Ubuntu. Yesterday I updated the Linux > kernel from 3.2.0-58-generic (x86_64) to 3.2.0-59-generic and Mailman > quit working. List posts made it through to the archives, and were > apparently queued within Mailman, but wouldn't go out. The mail server > was working OK for non-list email. Today I backed out the kernel update > and posts to lists sent yesterday and today are going out without > problems. What's in Mailman's 'post' and 'smtp' logs for these messages. Are they timestamped before or after you backed out the update. If before, they were queued in the MTA. If after, they were in Mailman's 'out' queue. If the latter, what's in Mailman's 'qrunner' log related to OutgoingRunner. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Implemented Mass Subscription via file upload
Rajeev S wrote: > I have implemented a mass subscription via file upload feature for > Postorious which can be found here. > > https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk > > How am I to submit a merge request to the Postorious repository?I tried to > propose a merge via the launchpad, but says the branch cannot be merged. Did you propose the merge using the "Propose for merging" link on the above page? If you didn't see the link, were you logged in? On the merge proposal page did you specify the target branch as lp:postorius? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Fwd: Implemented Mass Subscription via file upload
On 02/23/2014 01:46 AM, Rajeev S wrote: > First of all, there is no propose to merge link on my > https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk page. > > > home.png<https://docs.google.com/file/d/0B0oFc02F56UzZUVQQTNRNl9iNnM/edit?usp=drive_web> > > > And this is what happens when I propose a merge. > > > proposemerge.png<https://docs.google.com/file/d/0B0oFc02F56UzRkU2R0JkeklMbEk/edit?usp=drive_web> Sorry, this is beyond my knowledge of launchpad. I'm guessing you may first need to import your branch via <https://code.launchpad.net/postorius/+new-import>, but I don't really know. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 Test "" Hangs
On 02/26/2014 02:39 PM, Mark Sapiro wrote: > > I then ran > > nose2 -v &> test.log > > which encountered one error before hanging apparently with a locked > sqlite3 database. My test.log is attached. It is somewhat different from > Tom's in that it hung on a different test, and the actual sequence of > tests is different, and I encountered an error in a test. The error (failed test) was due to the default encoding in this Python installation being UTF-8 rather than ascii. Changing sitecustomise.py to not set UTF-8 allowed the test to succeed. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 Test "" Hangs
On 02/26/2014 06:40 PM, Barry Warsaw wrote: > On Feb 26, 2014, at 02:39 PM, Mark Sapiro wrote: > >> which encountered one error before hanging apparently with a locked >> sqlite3 database. > > This is my fault. I had a couple of revisions sitting in my local branch that > I hadn't pushed to Launchpad. Please pull the latest trunk revision (r7234), > recreate your virtualenv and try again. OK. After pulling the latest trunk, the tests no longer hang. >> python setup.py build_sphinx >> >> to build the docs, and this gives >> >> error: invalid command 'build_sphinx' > > Do you have the python-sphinx package installed? E.g. on Debian/Ubuntu: > > $ sudo apt-get install python-sphinx My fault here. I work on a couple of different machines with different versions of Ubuntu and different packages installed, and this one didn't have python-sphinx. Fixed now. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 Test "" Hangs
On 02/26/2014 06:42 PM, Barry Warsaw wrote: > On Feb 26, 2014, at 04:57 PM, Mark Sapiro wrote: > >> The error (failed test) was due to the default encoding in this Python >> installation being UTF-8 rather than ascii. Changing sitecustomise.py to >> not set UTF-8 allowed the test to succeed. > > Hmm. My locale is UTF-8 and I don't see this failure. Still, if you file a > bug, we should double check that there's not an encoding dependency here. It's more than just locale. You have to run import sys sys.getdefaultencoding() and see what it returns. Normally, it returns 'ascii' even in systems whose locale is UTF-8. You have to put/or enable something in sitecustomize.py (On Ubuntu a symlink to /etc/python2.7/sitecustomize.py) to get it to use the locale. Anyway, when sys.getdefaultencoding() returns 'UTF-8', one of the tests in src/mailman/model/docs/registration.rst fails because it's expecting InvalidEmailAddressError: \x...@example.com and instead of \xa0, it gets the UTF-8 encoding of a no-break space. I've filed <https://bugs.launchpad.net/mailman/+bug/1285496> for this. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 Test "" Hangs
On 02/27/2014 01:04 PM, Barry Warsaw wrote: > On Feb 26, 2014, at 09:21 PM, Mark Sapiro wrote: > >> You have to put/or enable something in sitecustomize.py (On Ubuntu a symlink >> to /etc/python2.7/sitecustomize.py) to get it to use the locale. > > Have you changed your sitecustomize.py file? Yes, I think so. I no longer remember exactly, but this is what I have now: $ ll /usr/lib/python2.7/sitecustomize.py lrwxrwxrwx 1 root root 31 Sep 19 07:47 /usr/lib/python2.7/sitecustomize.py -> /etc/python2.7/sitecustomize.py $ cat /etc/python2.7/sitecustomize.py # Set default encoding for locale (see site.py) import sys import locale loc = locale.getdefaultlocale() if loc[1]: sys.setdefaultencoding(loc[1]) # install the apport exception handler if available try: import apport_python_hook except ImportError: pass else: apport_python_hook.install() I think I added the first part based on stuff in the setencoding() function in site.py > You're right that sys.getdefaultencoding() gets initialized to 'ascii' > everywhere for Python 2.7. The default site.py doesn't change that (even on > Ubuntu), and then it deletes sys.setdefaultencoding, so it's not possible to > change that after initialization. Right, so if you are going to setdefaultencoding(), you need to do it in site.py or sitecustomize.py. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Installation of mailman on local machine
On 02/27/2014 01:08 PM, Tejas Shah wrote: > > However, starting the mailman server using "mailman start", when i try to > test using "nose2 -v" , it gives me o/p: You don't have to start mailman before running tests, but it should be OK. > Ran 593 tests in 43.713s > FAILED (failures=11, errors=72) > > I guess most of them are for HTTP Sockets.. Perhaps if you reported the exact failures and errors we could say more. > I tried opening localhost:8001 > and its giving "405 Method Not Allowed" error on the page This is normal. The REST server doesn't accept a GET / > Please suggest appropriate headers to solve this. See src/mailman/rest/docs/basic.rst. Are the doctests here among the failures? Also see "mailman info" for the rest server base URL (probably something like <http://localhost:8001/3.0/>) and credentials. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 Test difficulty
On 03/02/2014 11:46 AM, Barry Warsaw wrote:
>
> Looks like upstream released zope.interface 4.1.0, but this hasn't been pulled
> into Debian or Ubuntu yet. This breaks other dependencies referenced by
> --system-site-packages.
>
> I'll work on getting a newer zope.interface into the distros, but in the
> meantime, when the `python setup.py develop` command stops with this error,
> just `pip install -U zope.interface` and then run the develop command again.
OK. I now have a puzzle I can't seem to solve.
I have two machines with different software installation histories and
different OS. Various hardware/driver issues preclude my running the
same OS on both. Actually, there's a third machine with yet another OS
version, but I haven't tried running MM 3 on it.
Anyway, on a machine with Ubuntu 13.10 64 bit, I have a virtualenv with
packages up to date, and "python setup.py develop" runs fine and "nose2
-v" runs fine.
On the other machine with Ubuntu 12.10 32 bit, I again have a virtualenv
with packages up to date, and "python setup.py develop" runs fine, but
"nose2 -v" dies immediately with the attached traceback. Both
zope.component and zope.interface are the same version on both machines.
/var/py27 is the virtualenv.
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
(py27)mark@Notebook-09:/var/MM/3.0$ nose2 -v
Traceback (most recent call last):
File "/var/py27/bin/nose2", line 9, in
load_entry_point('nose2==0.4.7', 'console_scripts', 'nose2')()
File
"/var/py27/local/lib/python2.7/site-packages/nose2-0.4.7-py2.7.egg/nose2/main.py",
line 284, in discover
return main(*args, **kwargs)
File
"/var/py27/local/lib/python2.7/site-packages/nose2-0.4.7-py2.7.egg/nose2/main.py",
line 98, in __init__
super(PluggableTestProgram, self).__init__(**kw)
File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
self.parseArgs(argv)
File
"/var/py27/local/lib/python2.7/site-packages/nose2-0.4.7-py2.7.egg/nose2/main.py",
line 118, in parseArgs
self.handleCfgArgs(cfg_args)
File
"/var/py27/local/lib/python2.7/site-packages/nose2-0.4.7-py2.7.egg/nose2/main.py",
line 195, in handleCfgArgs
self.loadPlugins()
File
"/var/py27/local/lib/python2.7/site-packages/nose2-0.4.7-py2.7.egg/nose2/main.py",
line 240, in loadPlugins
self.session.loadPlugins(self.defaultPlugins, self.excludePlugins)
File
"/var/py27/local/lib/python2.7/site-packages/nose2-0.4.7-py2.7.egg/nose2/session.py",
line 134, in loadPlugins
self.loadPluginsFromModule(util.module_from_name(module))
File
"/var/py27/local/lib/python2.7/site-packages/nose2-0.4.7-py2.7.egg/nose2/util.py",
line 80, in module_from_name
__import__(name)
File "/var/MM/3.0/src/mailman/testing/nose.py", line 34, in
from mailman.testing.documentation import setup, teardown
File "/var/MM/3.0/src/mailman/testing/documentation.py", line 35, in
from mailman.app.lifecycle import create_list
File "/var/MM/3.0/src/mailman/app/lifecycle.py", line 34, in
from zope.component import getUtility
File
"/var/py27/local/lib/python2.7/site-packages/zope.component-4.2.0-py2.7.egg/zope/component/__init__.py",
line 19, in
from zope.interface import named
ImportError: cannot import name named
signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] MM3 Test difficulty
On 03/03/2014 07:10 PM, Barry Warsaw wrote:
>
> What happens if you `pip install -U zope.interface` in the virtualenv?
I don't know what was wrong, but I started over. I removed the
virtualenv and then did
virtualenv --system-site-packages /var/py27
source /var/py27/bin/activate
pip install -U zope.interface
cd /var/MM/3.0 (my MM 3 directory)
python setup.py develop
nose2 -v
and this time all was well except two tests failed. The only thing I can
think of is at one point, not realizing this was a 32-bit OS, I rsync'd
the virtualenv from the 64-bit machine. I thought I had cleaned that all
up, but there may have been some .pyc or ?? left.
Anyway, it appears this was my fault in not setting up the virtualenv
properly somehow.
Regarding the failed tests, they seem to possibly be test issues rather
than core issues, but the interesting thing is they don't fail on the
other machine. Possibly there's a race condition. Also, if I just run
the failing tests (and one other) with
nose2 -v -P "users.rst|inject.rst"
they don't fail.
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
==
FAIL: /var/MM/3.0/src/mailman/commands/docs/inject.rst
--
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 2201, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for inject.rst
File "/var/MM/3.0/src/mailman/commands/docs/inject.rst", line 0
--
File "/var/MM/3.0/src/mailman/commands/docs/inject.rst", line 29, in inject.rst
Failed example:
command.process(args)
Differences (ndiff with -expected +actual):
Available queues:
archive
bad
bounces
command
digest
in
nntp
out
pipeline
retry
shunt
+ test
virgin
==
FAIL: /var/MM/3.0/src/mailman/model/docs/users.rst
--
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 2201, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for users.rst
File "/var/MM/3.0/src/mailman/model/docs/users.rst", line 0
--
File "/var/MM/3.0/src/mailman/model/docs/users.rst", line 276, in users.rst
Failed example:
getUtility(ILanguageManager).add('it', 'iso-8859-1', 'Italian')
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1289, in __run
compileflags, 1) in test.globs
File "", line 1, in
getUtility(ILanguageManager).add('it', 'iso-8859-1', 'Italian')
File "/var/MM/3.0/src/mailman/languages/manager.py", line 48, in add
raise ValueError('Language code already registered: ' + code)
ValueError: Language code already registered: it
--
Ran 611 tests in 291.114s
FAILED (failures=2)
signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Moderation rules priority
On 03/11/2014 03:14 PM, Barry Warsaw wrote: > On Mar 11, 2014, at 06:25 PM, Aurelien Bompard wrote: > >> What do you think about all that? Do you agree there's actually an >> issue there? Any idea how to solve it? For example, make the NonMember >> rule exit if a member is found amongst the senders (which would simply >> be equivalent to making it yield to the Member rule). Bad idea? > > Ah, an interesting case! My immediate reaction is that nonmember-moderation > should do exactly what you suggest: test for both membership and > nonmembership. If it's both, then return False as if the action were > Action.defer. This should allow the member-moderation rule to take > precedence. > > Can you think of a reason *not* to do this? I think that's the right thing to do. In 2.1, a single module does both. Addresses are tested from headers in a defined order, and the first member address found determines the action. Only if no member address is found, are non-member tests done. I'm not sure about the architecture of the chain of rules, but maybe the member-moderation rule could set a flag in the metadata to tell the nonmember-moderation rule to take no action rather than testing for membership, but this might be a bad idea as it would make the rules order sensitive. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Virtual Mailman hackathon this weekend: Mailman Suite package!
On 03/13/2014 02:11 PM, Abhilash Raj wrote: > On Friday 14 March 2014 02:25 AM, Terri Oda wrote: >> Hi all! >> >> Something we've done periodically is try to get everyone on IRC over the >> weekend, all working on Mailman at the same time. It's great time for >> people to show and get patches reviewed, chat, and get work done >> together. Everyone is invited! Thanks for getting this started Terri. >> Here's a short line of schedule in UTC. Everyone else, feel free to add >> your own planned hours here so we know when we overlap, or just drop by >> on the day if you're not sure of your schedule in advance. >> >> Terri : Sat 1700UTC - Sun 0100UTC : Mailman Suite packaging > Abhilash(maxking) : Sat 0530UTC - 1430UTC : Finish off the last bits > of OpenPGP integration to mailman msapiro : Sat 1700UTC - Sat 2000UTC : Mostly lurking to try to learn -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] small logging change for ListAdmin.py
On 03/21/2014 02:26 PM, Stephen Willey Mats Mats wrote: > > Please consider this small logging change. Follow the progress of this at <https://bugs.launchpad.net/mailman/+bug/1295875>. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Fwd: DMARC and Mail Lists open space at Pycon
I should have sent the original to this list as well. Original Message Subject: [Mailman-Users] DMARC and Mail Lists open space at Pycon Date: Thu, 10 Apr 2014 17:30:51 -0700 From: Mark Sapiro To: dmarcl...@lists.peachymango.org, Mailman Users I have tentatively scheduled an open space for Friday, 11 April at 18:00 in room 523B at Pycon to talk about DMARC and mail lists. All available interested parties are invited. If the time doesn't work, we can reschedule. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] DMARC and Mail Lists open space at Pycon
On 04/10/2014 05:30 PM, Mark Sapiro wrote: > I have tentatively scheduled an open space for Friday, 11 April at 18:00 > in room 523B at Pycon to talk about DMARC and mail lists. All available > interested parties are invited. If the time doesn't work, we can reschedule. I will need to reschedule this. Check the open space board. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Fwd: DMARC and Mail Lists open space at Pycon
On 04/10/2014 09:25 PM, Stephen J. Turnbull wrote: > Mark Sapiro writes: > > > I have tentatively scheduled an open space for Friday, 11 April at > > 18:00 in room 523B at Pycon to talk about DMARC and mail lists. All > > available interested parties are invited. If the time doesn't work, > > we can reschedule. > > Is that EST or EDT? I'll try to be around on IRC, if somebody can > occasionally forward the sense of the conversation to me. > It's EDT, but it will be rescheduled. I'll try to see that something is on #mailman -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] DMARC and Mail Lists open space at Pycon
On April 11, 2014 7:21:49 AM EDT, Mark Sapiro wrote: >On 04/10/2014 05:30 PM, Mark Sapiro wrote: >> I have tentatively scheduled an open space for Friday, 11 April at >18:00 >> in room 523B at Pycon to talk about DMARC and mail lists. All >available >> interested parties are invited. If the time doesn't work, we can >reschedule. > > >I will need to reschedule this. Check the open space board. Tentatively rescheduled to 17:00 EDT (21:00 GMT) on Friday, 11 Apr in room 525. I will attempt to post realtime summaries on #mailman. -- Mark Sapiro Sent from my Android phone with K-9 Mail. [Unpaid endorsement] ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] DMARC and Mail Lists open space at Pycon
On 04/11/2014 05:25 AM, Mark Sapiro wrote: > > Tentatively rescheduled to 17:00 EDT (21:00 GMT) on Friday, 11 Apr in room > 525. > > I will attempt to post realtime summaries on #mailman. Due to various scheduling issues, this will be rescheduled for Saturday evening (Montreal time). Details to follow. Please email me if you're thinking of attending. So far I know it's me, Florian Fuchs, and Barry Warsaw, but we need DMARC folks too. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] DMARC and Mail Lists open space at Pycon
On April 11, 2014 3:18:13 PM EDT, Mark Sapiro wrote: >On 04/11/2014 05:25 AM, Mark Sapiro wrote: >> >> Tentatively rescheduled to 17:00 EDT (21:00 GMT) on Friday, 11 Apr in >room 525. >> >> I will attempt to post realtime summaries on #mailman. > > >Due to various scheduling issues, this will be rescheduled for Saturday >evening (Montreal time). Details to follow. > >Please email me if you're thinking of attending. So far I know it's me, >Florian Fuchs, and Barry Warsaw, but we need DMARC folks too. We are currently scheduled for 19:00 EDT (23:00 GMT), today, 12 Apr in room 525. It looks like it may just be Barry, Florian and me making dinner plans, but if you're interested and here please come. -- Mark Sapiro Sent from my Android phone with K-9 Mail. [Unpaid endorsement] ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman 2.1.18 release
I am pleased to announce the first release candidate for Mailman 2.1.18. Python 2.4 is the minimum supported, but Python 2.7 is recommended. This release has new features to help with mitigation of the impacts of DMARC on mailing lists. There is also a new dependency associated with these features. Namely, the new Privacy options -> Sender filters -> dmarc_moderation_action feature requires that the dnspython <http://www.dnspython.org/> package be available in Python. There are also bug fixes. See the attached README for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.18rc1 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.18rc1 (18-Apr-2014) Dependencies - There is a new dependency associated with the new Privacy options -> Sender filters -> dmarc_moderation_action feature discussed below. This requires that the dnspython <http://www.dnspython.org/> package be available in Python. New Features - The from_is_list feature introduced in 2.1.16 is now unconditionally available to list owners. There is also, a new Privacy options -> Sender filters -> dmarc_moderation_action feature which applies to list messages where the From: address is in a domain which publishes a DMARC policy of reject or possibly quarantine. This is a list setting with values of Accept, Wrap Message, Munge From, Reject or Discard. There is a new DEFAULT_DMARC_MODERATION_ACTION configuration setting to set the default for this, and the list admin UI is not able to set an action which is 'less' than the default. The prior ALLOW_FROM_IS_LIST setting has been removed and is effectively always Yes. There is a new DMARC_QUARANTINE_MODERATION_ACTION configuration setting which defaults to Yes but can be set to No to exclude domains with DMARC policy of quarantine from dmarc_moderation_action. dmarc_moderation_action and from_is_list interact in the following way. If the message is From: a domain to which dmarc_moderation_action applies and if dmarc_moderation_action is other than Accept, dmarc_moderation_action applies to that message. Otherwise the from_is_list action applies. i18n - Added missing tag to French listinfo template. (LP: #1275964) Bug Fixes and other patches - Fixed a long standing issue in which a notice sent to a user whose language is other than that of the list can cause subsequent things which should be in the list's language to be in the user's language instead. (LP: #1308655) - Fixed the admin Membership List so a search string if any is not lost when visiting subsequent fragments of a chunked list. (LP: #1307454) - For from_is_list feature, use email address from original From: if original From: has no display name and strip domain part from resultant names that look like email addresses. (LP: #1304511) - Added the list name to the vette log "held message approved" entry. (LP: 1295875) - Added the CGI module name to various "No such list" error log entries. (LP: 1295875) - Modified contrib/mmdsr to report module name if present in "No such list error log entries. - Fixed a NameError exception in cron/nightly_gzip when it tries to print the usage message. (LP: #1291038) - Fixed a bug in ListAdmin._handlepost that would crash when trying to preserve a held message for the site admin if HOLD_MESSAGES_AS_PICKLES is False. (LP: #1282365) - The from_is_list header munging feature introduced in Mailman 2.1.16 is no longer erroneously applied to Mailman generated notices. (LP: #1279667) - Changed the message from the confirm CGI to not indicate approval is required for an acceptance of an invitation. (LP: #1277744) - Fixed POSTFIX_STYLE_VIRTUAL_DOMAINS to be case-insensitiive. (LP: #1267003) - Added recognition for another simple warning to bounce processing. (LP: #1263247) - Fixed a few failing tests in tests/test_handlers.py. (LP: #1262950) - Fixed bin/arch to not create scrubbed attachments for messages skipped when processing the --start= option. (LP: #1260883) - Fixed email address validation to do a bit better in obscure cases. (LP: #1258703) - Fixed a bug which caused some authentication coo
Re: [Mailman-Developers] Mailman 2.1.18 release
On 04/17/2014 11:32 AM, Mark Sapiro wrote: > I am pleased to announce the first release candidate for Mailman 2.1.18. I neglected to emphasize that there are some new and some modified i18n strings in this release. I strongly encourage all interested people to look at these and submit translation updates, preferably as launchpad merge proposals but directly to me is OK, before 1 May 2014 to get them in the final release. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-Users] handler to auto detach attachment and link it to a website keeping html
On 04/18/2014 09:48 AM, Sylvain Viart wrote:
> Coding question.
>
> A bit of context:
>
> Goal is to develop a custom handler to perform:
>
> * detach all attachments
> * post detached content somewhere available on http
> * modify the content of the original email, keeping original html,
>adding an html link to the moved document
> * adding a small clip image as an attachment symbol as an embed object
>
>
> Le 16/04/2014 16:01, Mark Sapiro a écrit :
>> <https://docs.python.org/2/library/email.mime.html> to create new
>> sub-parts and use the Message.attach() method to attach them.
>
>
> How can I replace the part which contain the html part, by a new one
> which will become :
>
>
>>> Content-Type: multipart/related
>>>>>Content-Type: text/html;
>>>>> Content-Type: image/png; name="clip-24.png"
>
> The text/html is the old one.
>
> Adding a part is ok, but replacing it with a new one which embed the
> previous one… I dont see.
>
> part of the code I've produced:
>
> if msg.is_multipart():
> syslog('debug', 'multipart message rewriting')
> related = None
>
> for part in msg.walk():
> ctype = part.get_content_type()
> if ctype == 'text/plain' and not part['X-Mailman-Part']:
> new_footer = txt_attacht_replace + footer_attach
> part.set_payload(part.get_payload() + new_footer)
> continue
>
> elif ctype == 'text/html':
> related = MIMEMultipart('related')
This stuff
> clip = MIMEText(attach_clip)
> clip.add_header('Content-Disposition', 'inline')
> clip.add_header('Content-ID', '' % 123412)
> clip['Content-Transfer-Encoding'] = 'base64'
> del clip['Content-type']
> del clip['Content-transfer-encoding']
> clip['Content-type'] = 'image/png;
> name="attachment-24.png"'
> clip['Content-transfer-encoding'] = 'base64'
should be ---
clip = MIMEImage(xxx, 'png')
where xxx is the actual png data, e.g.
xxx = open('some_file.png').read()
> html_footer = html_attachment_holder %
> {'html_attachment_clip_tpl': html_footer_attach}
> html_footer += ''
> old_content = part.get_payload()
> new_content = re.sub(r'', html_footer, old_content)
> part.set_payload(new_content)
>
> related.attach(part)
> related.attach(clip)
Now related is the part you want. all that remains is to replace the
original part with related
>
> # WRONG
> del part
> msg.attach(related)
Correct. That's wrong. You need to do this differently. You need to
walk the message, but with your own code rather than msg.walk so you can
build your new message as you go.
You need some variant of
from email.mime.multipart import MIMEMultipart
from email.mime.image import MIMEImage
def fix_msg(msg):
if msg.is_multipart():
parts = msg.get_payload()
# remove the next level parts, then process and reattach them
msg.set_payload(None)
for p in parts:
msg.attach(fix_msg(p))
return msg
else:
# process the 'leaf' parts
ctype = msg.get_content_type()
if ctype == 'text/plain' and not part['X-Mailman-Part']:
# add footer to plain text
new_footer = txt_attacht_replace + footer_attach
msg.set_payload(part.get_payload() + new_footer)
return msg
elif ctype == 'text/html':
# build multipart/related for HTML
related = MIMEMultipart('related')
clip = MIMEImage(xxx, 'png')
html_footer = html_attachment_holder %
{'html_attachment_clip_tpl': html_footer_attach}
html_footer += ''
old_content = msg.get_payload()
new_content = re.sub(r'', html_footer, old_content)
msg.set_payload(new_content)
related.attach(msg)
related.attach(clip)
return related
def process(mlist, msg, msgdata)
...
msg = fix_msg(msg)
...
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] handler to auto detach attachment and link it to a website keeping html
On 04/18/2014 11:57 PM, Sylvain Viart wrote: > > Le 18/04/2014 22:30, Mark Sapiro a écrit : >> should be --- >> >> clip = MIMEImage(xxx, 'png') > > Yeah, I know. But I've embedded the base64 txt data of the clip image in > the handler.py's code. > So I don't need to manage an external file for the clip. Could MIMEImage > handle internal data as well? > > It seems extra effort, to mime64 decode and let MIMEImage reencode it, > right? You don't have to do that. If xxx is the base64 encoded image data, all you need is clip = MIMEImage(xxx, 'png', _encoder=email.encoders.encode_noop) clip['Content-Transfer-Encoding'] = 'base64' -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 2.1.18 release
On 04/17/2014 11:32 AM, Mark Sapiro wrote: > I am pleased to announce the first release candidate for Mailman 2.1.18. > > Python 2.4 is the minimum supported, but Python 2.7 is recommended. It turns out that Mailman 2.1.18rc1 required Python 2.5 or later. The problem code has been modified and I have released Mailman 2.1.18rc2. Fixing this issue is the only change. If you are trying to run Mailman 2.1.18 with Python 2.4.x, you need to use 2.1.18rc2 or later. If you are running with Python 2.5 or later, either version is OK. Please submit any i18n updates before May 1 to get them in the final release. This release has new features to help with mitigation of the impacts of DMARC on mailing lists. There is also a new dependency associated with these features. Namely, the new Privacy options -> Sender filters -> dmarc_moderation_action feature requires that the dnspython <http://www.dnspython.org/> package be available in Python. There are also bug fixes. See the attached README for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.18rc2 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.18rc2 (19-Apr-2014) - The new Utils.IsDMARCProhibited() used collections.defaultdict which requires Python 2.5. Changed to use a dict and setdefault. 2.1.18rc1 (18-Apr-2014) Dependencies - There is a new dependency associated with the new Privacy options -> Sender filters -> dmarc_moderation_action feature discussed below. This requires that the dnspython <http://www.dnspython.org/> package be available in Python. New Features - The from_is_list feature introduced in 2.1.16 is now unconditionally available to list owners. There is also, a new Privacy options -> Sender filters -> dmarc_moderation_action feature which applies to list messages where the From: address is in a domain which publishes a DMARC policy of reject or possibly quarantine. This is a list setting with values of Accept, Wrap Message, Munge From, Reject or Discard. There is a new DEFAULT_DMARC_MODERATION_ACTION configuration setting to set the default for this, and the list admin UI is not able to set an action which is 'less' than the default. The prior ALLOW_FROM_IS_LIST setting has been removed and is effectively always Yes. There is a new DMARC_QUARANTINE_MODERATION_ACTION configuration setting which defaults to Yes but can be set to No to exclude domains with DMARC policy of quarantine from dmarc_moderation_action. dmarc_moderation_action and from_is_list interact in the following way. If the message is From: a domain to which dmarc_moderation_action applies and if dmarc_moderation_action is other than Accept, dmarc_moderation_action applies to that message. Otherwise the from_is_list action applies. i18n - Added missing tag to French listinfo template. (LP: #1275964) Bug Fixes and other patches - Fixed a long standing issue in which a notice sent to a user whose language is other than that of the list can cause subsequent things which should be in the list's language to be in the user's language instead. (LP: #1308655) - Fixed the admin Membership List so a search string if any is not lost when visiting subsequent fragments of a chunked list. (LP: #1307454) - For from_is_list feature, use email address from original From: if original From: has no display name and strip domain part from resultant names that look like email addresses. (LP: #1304511) - Added the list name to the vette log "held message approved" entry. (LP: 1295875) - Added the CGI module name to various "No such list" error log entries. (LP: 1295875) - Modified contrib/mmdsr to report module name if present in "No such list error log entries. - Fixed a NameError exception in cron/nightly_gzip when it tries to print the usage message. (LP: #1291038) - Fixed a bug in ListAdmin._handlepost that would crash when trying to preserve a held message for the site admin if HOLD_MESSAGES_AS_PICKLES is False. (LP: #1282365) - The from_is_list header munging feature introduced in Mailman 2.1.16 is no longer erroneously applied to Mailman generated notices. (LP: #1279667) - Changed the message from the confirm CGI
Re: [Mailman-Developers] handler to auto detach attachment and link it to a website keeping html
On 04/22/2014 03:46 AM, Sylvain Viart wrote:
>
> List configuration question.
>
> I need to pass some configuration plugin to this handler. Like remote
> ftp parameters. I've seen code like this:
>
> if mlist.convert_html_to_plaintext and
> mm_cfg.HTML_TO_PLAIN_TEXT_COMMAND:
>
>
> I suppose that I configure it that way:
>
> /etc/mailman/mm_cfg.py
> HTML_TO_PLAIN_TEXT_COMMAND = 'path/to/converter'
>
> and in my extend()
>
> mlist.convert_html_to_plaintext = 1
>
> is in /var/lib/mailman/lists/mytestlist/extend.py [debian base path]
If you are doing this as a part of content filtering you just set the
list's Content filtering -> convert_html_to_plaintext to Yes, but I
suspect you are not.
In that case, don't hijack content filtering settings for your own
purpose. It won't work.
If you are going to hard code some setting for your handler to use, just
hard code it in the handler.
> I took it here
> http://wiki.list.org/pages/viewpage.action?pageId=4030615. I used
> extend.py to install my custom handler that way:
>
> import copy
> from Mailman import mm_cfg
> def extend(mlist):
> mlist.pipeline = copy.copy(mm_cfg.GLOBAL_PIPELINE)
> # The next line inserts MyHandler ahead of Moderate.
> mlist.pipeline.insert(mlist.pipeline.index('Moderate'), 'MyHandler')
>
>
> Also, it's indicated that there's a kind of caching involved with the
> Handler's code…:
>
>> Note however, that the first time Mailman saves the list, the pipeline
>> attribute will be saved along with it, so simply removing extend.py
>> from lists/test-list/ won't remove the special pipeline.
It is not caching per se. Once you access the list once and save it,
your modified pipeline is saved as a list attribute just like any other
setting. Removing extend.py will not remove the pipeline attribute from
the list. That is what the above is trying to tell you.
> I do perform a mailman restart to load new handler's code:
>
> /etc/init.d/mailman restart
Yes. That is correct.
> Is there some documentation about list configuration override order?
Not outside the source code. See the __init__ method of the MailList
class in Mailman/MailList.py. The list's extend.py if any is executed
before the list's configuration is loaded from disk. Thus any list
attribute set in extend.py that also exists in the list's saved
configuration will be overridden by the list config.
> I found a topic giving some information for personalizing the list:
>
> 4.48 How can I change the HTML (or .txt) templates used by my mailing
> lists?
> http://wiki.list.org/pages/viewpage.action?pageId=4030605
Which only talks about search rules for the built in templates and has
nothing to do with anything else.
--
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] handler to auto detach attachment and link it to a website keeping html
On 04/22/2014 10:13 PM, Sylvain Viart wrote: > > I need to set : > > mlist.ftp_remote_host = 'ftp.example.com' > mlist.ftp_remote_login = 'somelogin' > mlist.ftp_remote_pass = 'secretstuff' > > > I can set site global vars in /etc/mailman/mm_cfg.py but how do I set > local list parameter exactly? bin/withlist or bin/config_list. E.g., put the above three lines in a file and run bin/config_list -i /path/to/file listname. Note, I just removed the information about using extend.py from the FAQ at <http://wiki.list.org/x/l4A9> because the only reason it was there was for the situation where GLOBAL_PIPELINE would change in the future, and it won't work for that anyway because the list's existing pipeline attribute will override it. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] handler to auto detach attachment and link it to a website keeping html
On 04/23/2014 08:31 AM, Sylvain Viart wrote:
> Le 23/04/2014 15:30, Mark Sapiro a écrit :
>>
>> E.g., put the above three lines in a file and run
>>
>> bin/config_list -i /path/to/file listname.
>
> Works great as you said! :-)
> I wasn't sure how to use this tool. I supposed you have to dump the
> whole config first with -o, add my stuff and reload the whole…
> But it's state's keeping between call of bin/config_list… Cool.
No. config_list will only set/change those things that are in it's
input. So for what you want to do, an input file with just those three
lines is what you want.
> # config_list -v -i t.py testlist
> # withlist -i testlist
> Loading list testlist (unlocked)
> The variable `m' is the testlist MailList instance
>>>> m.ftp_remote_host
> 'ftp.example.com'
>
> this one gives nothing…
> # config_list -o - testlist | grep ftp
>
> Can I guess that this tool don't exactly dump the full list state?
> It can't be used for duplicating or full backup for instance?
Config_list is a very powerful tool. It's input file is actually Python
and is exectuted, so you can do almost anything with it. See the -i
option description in 'config_list -h'.
You can set things in two ways. The first paragraph refers to putting
stuff like
ftp_remote_host = 'ftp.example.com'
in the input. This works to set attributes that already exist in the
list object. It will warn you if the attribute is 'non-standard', i.e.
doesn't appear in the web admin UI, but it will set it if it is already
an attribute of the list. It won't work in your case (at least the first
time) because ftp_remote_host is a "variable that isn't already an
attribute of the list object (and) is ignored"
The second paragraph says you have access to the list object through the
variable 'mlist', so you can set anything, existing or not, via syntax like
mlist.ftp_remote_host = 'ftp.example.com'
On the other hand, 'config_list -o' writes only those standard
attributes that appear in the web admin UI.
> My test this morning was failing because of wrong usage… See bellow.
> I tested your script set_attributes
> <http://fog.ccsf.edu/%7Emsapiro/scripts/set_attributes>
>
>Mark Sapiro's page : scripts that automate certain mailing list
>management tasks <http://fog.ccsf.edu/~msapiro/scripts/
><http://fog.ccsf.edu/%7Emsapiro/scripts/>>
>
>
> Which gives:
>
> # /usr/lib/mailman/bin/list_set_attributes "ftp_remote_host =
> 'ftp.example.org'" testlist
> attribute "ftp_remote_host" changed
> Non-standard property restored: ftp_remote_host
Which means you probably had already put it there some other way or the
output would have been "attribute "ftp_remote_host" ignored"
...
>
>> Note, I just removed the information about using extend.py from the FAQ
>> at <http://wiki.list.org/x/l4A9> because the only reason it was there
>> was for the situation where GLOBAL_PIPELINE would change in the future,
>> and it won't work for that anyway because the list's existing pipeline
>> attribute will override it.
>>
>
> Hum… I'm using it. How I'm supposed to modify the pipeline, so?…
As I say above, the first time you accessed the list with the extend.py
as above, you set the pipeline and maybe other attributes. Once those
attributes exist in the list object, you can't change them via the
extend.py mechanism. Well you can if you also save the list via
mlist.Save() after resetting them, but I don't recommended that which is
why I removed the extend.py stuff from the FAQ.
Use either withlist or config_list to set these attributes.
> /usr/lib/mailman/bin/version
> Using Mailman version: 2.1.15
>
> Using config_list ok… Hum probably not…
>
> # cat t.py
> import copy
> from Mailman import mm_cfg
> mlist.pipeline = copy.copy(mm_cfg.GLOBAL_PIPELINE)
> # The next line inserts MyHandler ahead of Moderate.
> mlist.pipeline.insert(mlist.pipeline.index('Moderate'), 'MyHandler')
>
>
> # config_list -v -i t.py testlist
> attribute "mm_cfg" ignored
> attribute "copy" ignored
1) Open Mailman/Defaults.py
2) Copy the definition of GLOBAL_PIPELINE
3) paste it into a new file changing the name from GLOBAL_PIPELINE to
mlist.pipeline and add your handler so it becomes
mlist.pipeline = [
'SpamDetect',
'Approve',
'Replybot',
# inserting MyHandler here.
'MyHandler',
'Moderate',
'Hold',
'MimeDel',
'Scrubber',
'Emergency',
&#
Re: [Mailman-Developers] Mailman 2.1.18 release
I'm pleased to announce the third candidate release for Mailman 2.1.18. This fixes a few bugs since discovered since the second release candidate. Python 2.4 is the minimum supported, but Python 2.7 is recommended. Please submit any i18n updates before May 1 to get them in the final release. This release has new features to help with mitigation of the impacts of DMARC on mailing lists. There is also a new dependency associated with these features. Namely, the new Privacy options -> Sender filters -> dmarc_moderation_action feature requires that the dnspython <http://www.dnspython.org/> package be available in Python. There are also bug fixes. See the attached README for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.18rc1 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.18rc3 (25-Apr-2014) Bug fixes and other patches - The Reply-To: munging options weren't honored if there was no from_is_list action. (LP: #1313010) - Changed from_is_list actions to insert the list address in Cc: if the list is fully personalized. Otherwise, the list address is only in From: and Reply-To: overrides it. (LP: #1312970) - Fixed the Munge From action to only Munge the From: and/or Reply-To: in the outgoing message and not in archives, digests and messages sent via the usenet gateway. (LP: #1311431) 2.1.18rc2 (19-Apr-2014) Bug fixes and other patches - The new Utils.IsDMARCProhibited() used collections.defaultdict which requires Python 2.5. Changed to use a dict and setdefault. 2.1.18rc1 (18-Apr-2014) Dependencies - There is a new dependency associated with the new Privacy options -> Sender filters -> dmarc_moderation_action feature discussed below. This requires that the dnspython <http://www.dnspython.org/> package be available in Python. This package can be downloaded from the above site or from the CheeseShop <https://pypi.python.org/pypi/dnspython/> or installed with pip. New Features - The from_is_list feature introduced in 2.1.16 is now unconditionally available to list owners. There is also, a new Privacy options -> Sender filters -> dmarc_moderation_action feature which applies to list messages where the From: address is in a domain which publishes a DMARC policy of reject or possibly quarantine. This is a list setting with values of Accept, Wrap Message, Munge From, Reject or Discard. There is a new DEFAULT_DMARC_MODERATION_ACTION configuration setting to set the default for this, and the list admin UI is not able to set an action which is 'less' than the default. The prior ALLOW_FROM_IS_LIST setting has been removed and is effectively always Yes. There is a new DMARC_QUARANTINE_MODERATION_ACTION configuration setting which defaults to Yes but can be set to No to exclude domains with DMARC policy of quarantine from dmarc_moderation_action. dmarc_moderation_action and from_is_list interact in the following way. If the message is From: a domain to which dmarc_moderation_action applies and if dmarc_moderation_action is other than Accept, dmarc_moderation_action applies to that message. Otherwise the from_is_list action applies. i18n - Added missing tag to French listinfo template. (LP: #1275964) Bug Fixes and other patches - Fixed a long standing issue in which a notice sent to a user whose language is other than that of the list can cause subsequent things which should be in the list's language to be in the user's language instead. (LP: #1308655) - Fixed the admin Membership List so a search string if any is not lost when visiting subsequent fragments of a chunked list. (LP: #1307454) - For from_is_list feature, use email address from original From: if original From: has no display name and strip domain part from resultant names that look like email addresses. (LP: #1304511) - Added the list name to the vette log "held message approved" entry. (LP: 1295875) - Added the CGI module name to various "No such list" error log entries. (LP: 1295875) - Modified contrib/mmdsr to report module name if present in "No such list error log entries. - Fixed a NameError exception in cron/nightly_gzip when
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
On 04/27/2014 08:03 AM, Stephen J. Turnbull wrote: > > Unfortunately I don't have a copy of your original, but what may be > happening is not at GMail, but rather that the mailing list tries > pretty hard to avoid HTML mail, throwing away the text/html part if > there's a text/plain alternative, and otherwise running it through an > HTML-to-text converter (probably Lynx with output to a file). > > It could also just be my local MUA, which I have set up to try to > minimize the HTML mail that I see. > > Mark can probably say with some confidence. This list's content filtering removes all text/html parts from list posts. This, combined with the fact that web based MUAs such as Gmail and Yahoo typically default to 'rich text' composition and allow things like bold, underline and italic, can create issues. When you send such an email, the MUA typically creates a multipart/alternative message with text/plain and text/html alternatives. The text/html alternative will generally render very much like what you saw in the composition window, at least in MUAs that understand MIME and render HTML. The text/plain alternative is more problematic. Yahoo's is frankly terrible, at least if you view the raw text. Gmail's is better, but it uses the more or less standard star, underscore and slash convention for *bold*, _underlined_ and /italic/ text. On most (ed. comment - intelligent) discussion lists, you will only receive the text/plain part. If the poster has cut/pasted things, instead of seeing *some bold text*, you may see *bold **some text* or similar anomalies. The bottom line message is use plain text composition to begin with if it is an option. Confidently yours, -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] ANNOUNCE: The GNU Mailman 3 suite, beta 1 preview
On 05/03/2014 07:15 AM, Tom Browder wrote: > On Thu, Apr 24, 2014 at 9:19 AM, Barry Warsaw wrote: > ... >> On behalf of the Mailman development team, I am happy >> to announce the first beta release of the full Mailman 3 suite. >> >> This release includes: > ... >> Core >> project - https://launchpad.net/mailman > ... > > I apologize for my confusion, but I'm not used to the bazaar model for > multiple developers. I'm used to the svn model for C/C++ code where > we keep the trunk as the latest development version (but we keep the > trunk so it always builds without error). > > If I want the latest development version of Mailman should I use the > announced lp address above or the one I'm using now: > > Related branches: > parent branch: http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/ > revision-id: ba...@list.org-20140101145942-b9vqi0xmcewpk4mb > date: 2014-01-01 09:59:42 -0500 > build-date: 2014-05-03 10:07:35 -0400 > revno: 7232 Now I'm confused, but it looks like you are looking at a local (to you) branch that you branched at rev 7232 from lp:mailman or http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/ or some other alias for that branch. If you now cd to that branch on your local machine and do 'bzr pull' it should bring you up to the head of the branch on launchpad at rev 7251. OTOH, if that is not your local branch, but a branch you obtained elsewhere, then you probably should not be using it as the 'official' branch is lp:mailman. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman 2.1.18 final release
I'm pleased to announce the final release for Mailman 2.1.18. This release has new features to help with mitigation of the impacts of DMARC on mailing lists as well as fixing several bugs. Python 2.4 is the minimum supported, but Python 2.7 is recommended. There are significant new i18n strings associated with the DMARC mitigation features. If you are interested in helping with the translations of these strings, see <http://wiki.list.org/x/MQ>. There is also a new dependency associated with these features. Namely, the new Privacy options -> Sender filters -> dmarc_moderation_action feature requires that the dnspython <http://www.dnspython.org/> package be available in Python. See the attached README for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ Mailman 2.1.18 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan 2.1.18 (03-May-2014) Dependencies - There is a new dependency associated with the new Privacy options -> Sender filters -> dmarc_moderation_action feature discussed below. This requires that the dnspython <http://www.dnspython.org/> package be available in Python. This package can be downloaded from the above site or from the CheeseShop <https://pypi.python.org/pypi/dnspython/> or installed with pip. New Features - The from_is_list feature introduced in 2.1.16 is now unconditionally available to list owners. There is also, a new Privacy options -> Sender filters -> dmarc_moderation_action feature which applies to list messages where the From: address is in a domain which publishes a DMARC policy of reject or possibly quarantine. This is a list setting with values of Accept, Wrap Message, Munge From, Reject or Discard. There is a new DEFAULT_DMARC_MODERATION_ACTION configuration setting to set the default for this, and the list admin UI is not able to set an action which is 'less' than the default. The prior ALLOW_FROM_IS_LIST setting has been removed and is effectively always Yes. There is a new dmarc_quarantine_moderation_action list setting with default set by a new DEFAULT_DMARC_QUARANTINE_MODERATION_ACTION configuration setting which in turn defaults to Yes. The list setting can be set to No to exclude domains with DMARC policy of quarantine from dmarc_moderation_action. dmarc_moderation_action and from_is_list interact in the following way. If the message is From: a domain to which dmarc_moderation_action applies and if dmarc_moderation_action is other than Accept, dmarc_moderation_action applies to that message. Otherwise the from_is_list action applies. Also associated with dmarc_moderation_action are configuration settings DMARC_RESOLVER_TIMEOUT and DMARC_RESOLVER_LIFETIME. These are described in more detail in Defaults.py. There are also new vette log entries written when dmarc_moderation_action is found to apply to a post. i18n - Added missing tag to French listinfo template. (LP: #1275964) Bug Fixes and other patches - Removed HTML tags from the title of a couple of rmlist.py pages because browsers don't render tags in the title. (LP: #265848) - Most Mailman generated notices to list owners and moderators are now sent as Precedence: list instead of bulk. (LP: #1313146) - The Reply-To: munging options weren't honored if there was no from_is_list action. (LP: #1313010) - Changed from_is_list actions to insert the list address in Cc: if the list is fully personalized. Otherwise, the list address is only in From: and Reply-To: overrides it. (LP: #1312970) - Fixed the Munge From action to only Munge the From: and/or Reply-To: in the outgoing message and not in archives, digests and messages sent via the usenet gateway. (LP: #1311431) - Fixed a long standing issue in which a notice sent to a user whose language is other than that of the list can cause subsequent things which should be in the list's language to be in the user's language instead. (LP: #1308655) - Fixed the admin Membership List so a search string if any is not lost when visiting subsequent fragments of a chunked list. (LP: #1307454) - For from_is_list feature, use email address from original From: if original From: has no display name an
Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge
On 05/04/2014 06:26 AM, John Levine wrote: > I realize I'm a bit late to this party, but this is a technique that I > don't think has been addressed here. On my lists I've fixed the DMARC > bounces by rewriting From: lines of DMARC'ed domains like this on the > way out: > > From: Marissa > > to > > From: Marissa It's been mentioned on mailman-users. See the post at <https://mail.python.org/pipermail/mailman-users/2014-May/076761.html> and the two following replies. It came too late for 2.1.18, but we would be interested in your experience for a follow-up release. Our concerns are the possibility of mail being rejected by recipient MTAs because of the invalid From: address and user complaints about difficulty in replying to the poster. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge
Hi,
This is my first post here so please be gentle. I know I am risking
telling certain people how to suck eggs.
I'm not currently a Mailman user but will probably begin to use it soon.
I've followed the Mailman-Developers list for some time to familiarise
myself with how Mailman works.
Apologies also for the long message.
On 04/05/2014 19:08, Stephen J. Turnbull wrote:
> > Advantages:
> >
> > * Really fixes DMARC problems
>
> That's a matter of opinion. The DMARC-using domains will disagree, I
> think, as it still means that you are "impersonating" their users (see
> below), and making DMARC ineffective as a means of reducing spam and
> phishing. But we'll see about that soon enough.
Surely that is a case of "so be it". DMARC (well, to be precise, Yahoo's
particular implementation of it combined with Yahoo's size in the
market) has broken longstanding and valid usage patterns and, for simple
practical purposes, needs to be routed around in a way that still
retains interoperability with Yahoo.
I do not think that this method of working around Yahoo's DMARC
implementation will necessarily impact the usefulness of DMARC as an
impersonated-spam/spoofing reduction tool. Whilst it can be argued that
adding ".INVALID" (or something similar, see also below) is still
impersonating Yahoo users, it can also be argued (more persuasively in
my opinion) that "yahoo.com.INVALID" or "yahoo.com.REMOVEME" or similar
is quite clearly not impersonating any valid Yahoo user *when sent from
a mail list*.
> Disadvantages:
>
> The big one is that we can only guess what the long-run consequences
> are going to be. In particular, I think in the short-run we can
> definitely foresee (1) spreading invalid addresses, which will bounce
> if automatically inserted as destination addresses, all over the net,
> possibly creating more backscatter
But who is going to be emailing using those addresses? Surely the only
people who would be emailing from such addresses for the purposes of
spoofing are spammers and any additional backscatter from such a source
would surely only be an incremental additional to the problem of
spamming. DMARC is, in any case, intended to reduce such backscatter.
> and (2) a tendency for people to
> see "@yahoo.com.invalid" as a *valid* form of Yahoo! address
> ("computers are so weird").
To my mind this is a valid criticism of the choice of words (i.e.
".invalid" can quickly start to be taken to be valid!) but not of the
idea in general.
Perhaps a better form of words can be found. For example:
.REMOVEME
.ThisMailProvidersDMARCImplementationIsBroken
.RemoveThisToEmail
.MungedForDMARCPleaseRemoveToEmail
In other words, something that non-technical end users will not so
easily become inured to.
> Tools, most of them simple, will be
> created to hide and to strip ".invalid" automatically, meaning you can
> hide any arbitrary domain from DMARC behind ".invalid". Spammers and
> phishers will pick up on this
This is surely going to happen anyway if spammers want to harvest mail
lists as spam target sources or to harvest identities for spoofing
(which, as I understand it, is what DMARC is particularly intended to
prevent).
I don't see why it should affect mail lists and I don't see why it
should prevent DMARC from working to prevent impersonated/spoofed spam.
Indeed, it is the *removal* of suffixes like ".INVALID" (or whatever)
that DMARC is intended to eventually make worthless (not the addition of
them).
> Yahoo! gets what conspiracy theorists (Hi, Lindsay!)
> think they want, namely locking their users into Yahoo! groups, but I
> think they're going to find that the opposite effect (of annoying
> their users so they move to a more flexible domain) is more important,
> and DMARC will fall of its own weight without leaving too much of a
> mark on the rest of the mail system.
Sadly I suspect that the vast majority Yahoo users will be entirely
oblivious to it.
Out of the very few (relatively speaking) Yahoo users who use services
which are impacted by Yahoo's p=reject DMARC implementation many will
blame the services themselves. The remaining few who understand the
issue will move away to better providers, but I suspect this will be a
negligible proportion of Yahoo's user base.
As far as I can see, DMARC is set to work as Yahoo and its other backers
intend for it. They have the market size to push it through regardless
of standards.
> OTOH, the natural response of the DMARC folks is going to be to try to
> control this. I can't imagine, if they succeed in agreeing on how to
> do so, that it will cause less damage to interoperability than their
> current behavior.
But do they actually need to? As I understand it,
Re: [Mailman-Developers] Mailman 2.1.18 final release
On 05/03/2014 11:30 AM, Mark Sapiro wrote: > I'm pleased to announce the final release for Mailman 2.1.18. It appears that the from_is_list and dmarc_moderation_actions Wrap Message actions may run afoul of this issue <http://bugs.python.org/issue7970> in the Python email library in versions older than 2.6.x where x is some number < 5. I.e. I know the bug is fixed in Python 2.7 and 2.6.5 and not in any 2.5.x or older. I'm not sure about 2.6.1 - 2.6.4. I have attached a patch to Mailman/Message.py which I think will fix this issue if you have it. You will know if you do because all outgoing mail will be shunted with the exception "TypeError: Expected list, got " when SMTPDirect.py invokes the as_string() method on the message object. I think this will only occur with those older Pythons and when a Wrap Message action is applied. As soon as I get confirmation from the original reporter that the patch solves the problem, I will release a fixed version. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan --- /var/MM/2.1/Mailman/Message.py 2014-04-26 21:29:42.282766984 -0700 +++ /var/MM/21/Mailman/Message.py 2014-05-05 22:40:32.412348756 -0700 @@ -59,6 +59,25 @@ return self.__class__(fp, self._mangle_from_, self.__children_maxheaderlen, self.__children_maxheaderlen) +# This is the _handle_message method with the fix for bug 7970. +def _handle_message(self, msg): +s = StringIO() +g = self.clone(s) +# The payload of a message/rfc822 part should be a multipart sequence +# of length 1. The zeroth element of the list should be the Message +# object for the subpart. Extract that object, stringify it, and +# write it out. +# Except, it turns out, when it's a string instead, which happens when +# and only when HeaderParser is used on a message of mime type +# message/rfc822. Such messages are generated by, for example, +# Groupwise when forwarding unadorned messages. (Issue 7970.) So +# in that case we just emit the string body. +payload = msg.get_payload() +if isinstance(payload, list): +g.flatten(msg.get_payload(0), unixfrom=False) +payload = s.getvalue() +self._fp.write(payload) + class Message(email.Message.Message): signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
