Mailman-Developers November 2011

mailman-developers@python.org

15 participants
12 discussions

before next release: disable backscatter in default installation
by Jo Rhett 07 Nov '22

07 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Re: [Mailman-Developers] [Bug 860159] Re: Mailman 3.0 support for Postgres
by Barry Warsaw 29 Nov '11

29 Nov '11

On Nov 29, 2011, at 10:18 AM, Stephane Wirtel \(OpenERP\) wrote: >I'm interested by the support of PostgreSQL by Mailman, is there some >news for a future release with this feature ? PostgreSQL support is in Mailman 3 bzr. It will be available in beta 1, but I have no eta on that at the moment. -Barry

1 0

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Barry Warsaw 28 Nov '11

28 Nov '11

On Oct 13, 2011, at 11:41 PM, Murray S. Kucherawy wrote: >There's movement afoot to deprecate use of "X-" in header field names. Just >call it "Mailman-Topic". And if it's worthwhile, consider registering it >with IANA. I wonder if we should remove the X- prefixes for Mailman 3. Here's a list of ones we still add or recognize (some might be used only in the test suite): X-Message-ID-Hash X-Mailman-Rule-Hits X-Mailman-Rule-Misses X-BeenThere X-Mailman-Version X-Mailman-Approved-At X-Archive X-No-Archive X-Ack X-No-Ack X-Peer X-MailFrom X-RcptTo X-Originally-To X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version X-Mailman-Copy X-List-Administrivia X-Content-Filtered-By X-Topics X-Mailer X-List-Received-Date X-Approve X-Approved -Barry

10 32

Mailman v3 and ban-list
by C Nulk 28 Nov '11

28 Nov '11

Hello, I thought I would ask a quick question on the development of Mailman 3. Over in the Mailman-Users list, Mark Sapiro mentions that he adds a regex into the ban_list of all of his lists. Is there any consideration being given to having a global ban_list which applied across all lists for a mailman instance? It would be nice to have both a global and a list-specific ban_list mechanism. The global version would allow one to put in one ban entry in for all lists. An example would be Mark's regex for answerpot (a list message harvester). Just a thought, Chris

3 2

building/running alpha 8 on MacOS
by Felipe Gasper 27 Nov '11

27 Nov '11

Is this possible? I’m trying: python bootstrap.py -d …and that works. (It seems to need the -d; otherwise it won’t find the setuptools that MacPorts installs.) But when I do bin/buildout, I get this mess: -------------------------------------- Traceback (most recent call last): File "/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmp3WxCTH", line 11, in <module> execfile('/Users/felipe/code/mailman/./setup.py') File "/Users/felipe/code/mailman/./setup.py", line 110, in <module> 'zope.testing<4', File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/core.py", line 113, in setup _setup_distribution = dist = klass(attrs) File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/dist.py", line 223, in __init__ _Distribution.__init__(self,attrs) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/dist.py", line 270, in __init__ self.finalize_options() File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/dist.py", line 256, in finalize_options ep.load()(self, ep.name, value) File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/pkg_resources.py", line 1912, in load raise ImportError("%r has no %r attribute" % (entry,attr)) ImportError: <module 'setuptools.dist' from '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/dist.pyc'> has no 'check_packages' attribute While: Installing. Processing develop directory '/Users/felipe/code/mailman/.'. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py", line 1805, in main File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py", line 446, in install File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py", line 686, in _develop File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/easy_install.py", line 1189, in develop AssertionError --------------------------------- Does buildout not work on MacOS? -FG

3 2

Re: [Mailman-Developers] Mailman headers roundup
by Stephen J. Turnbull 15 Nov '11

15 Nov '11

Murray S. Kucherawy writes: > However, the IETF might want to change it to the opposite name from > the one you pick, or even something else. So you're quite possibly > going to repeat this debate in their forum, so save (some of) your > strength. Or the posts. ;-)

1 0

Mailman headers roundup
by Patrick Ben Koetter 15 Nov '11

15 Nov '11

I've created a list to sum up the current discussion/threads on the mailman header work. The list is separated in four sections: I. CLARIFY Needs discussion. II. MODIFY Needs to be registered with IETF or changes X- name. III. KEEP Do not change VI. DELETE Remove from MM3 code Please cross-check and pickup discussion on the CLARIFY items. Once we are done I will approach IETF for the headers that need standardizing. I. CLARIFY X-List-Received-Date This only gets added when the message is sent to the archive. Modify to: List-Archive-Sent Next Step: Discuss X-Message-ID-Hash propose an RFC as an extension of RFC 5064 Modify to: unclear Next Step: Discuss X-Mailman-Version The version of Mailman that sent the message. It can lose the X- prefix. Modify to: List-Agent, Mediator Next Step: Discuss X-Mailman-Approved-At lose the X-prefix Modify to: List-Approved-Date Next Step: Create RFC or Extend RFC 2369? II. MODIFY X-Mailer Only used when Mailman originates messages such as autoresponses. Modify to: User-Agent Next Step: Change code X-Topics This contains a list of all the topic names that matched the message. Are there any other MLMs that support topics in a way that would make that header generally useful? Modify to: Tag Next Step: Create RFC X-Mailman-Rule-Hits They could certainly lose the X- prefix. Modify to: Mailman-Rule-Hits Next Step: Create RFC X-Mailman-Rule-Misses They could certainly lose the X- prefix. Modify to: Mailman-Rule-Misses Next Step: Create RFC X-Content-Filtered-By I think this should be renamed to (X-)Mailman-Content-Filter. Modify to: Mailman-Content-Filter Next Step: Create RFC III. KEEP X-Peer X-MailFrom X-RcptTo Ignore this, it's used in the test suite only. Next Step: Ignore X-Originally-To Probably not worth changing. Next Step: Ignore X-Original-CC X-Original-Content-Transfer-Encoding X-MIME-Version Ignore these. Next Step: Ignore X-Ack X-No-Ack These should keep the X- prefix. Next Step: Ignore X-Approve X-Approved need to keep the above two for backward compatibility Next Step: Ignore VI. DELETE X-Mailman-Copy It can either be removed or lose the X- prefix. Next Step: Remove from code X-BeenThere legacy Next Step: Remove from code X-Archive X-No-Archive deprecated Next Step: Remove from code X-List-Administrivia X-List-Administrivia is just useless and should be removed. Next Step: Remove from code p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563

10 20

Re: [Mailman-Developers] New RFC on using DKIM with MLMs
by Barry Warsaw 15 Nov '11

15 Nov '11

On Oct 28, 2011, at 11:45 PM, Murray S. Kucherawy wrote: >I've got a separate draft that adds to Received: fields a tag that indicates >transitions of messages into administrative hold states (quarantining, timed >delivery and list moderation are included in the initial list of reasons) >ready to go. I just missed the -00 submission deadline prior to the next >IETF meeting in November, so it's not in the IETF datatracker but it is here: >http://www.blackops.org/~msk/draft-kucherawy-received-state.txt. Comments >welcome. > >The idea: When the MLM selects a message for moderation it would a Received: >field with such a tag, and then on release the next MTA in the chain adds >another Received: as per normal which, presumably, completes the handling >chain in a way that the end user can see what happened (i.e., when it entered >the hold and when it came out). > >This doesn't include a mechanism for tracking who did the approval, but >you've got that separately on your list anyway. That's pretty interesting. Currently MM3 doesn't add any Received headers, but this bug tracks that: https://bugs.launchpad.net/mailman/+bug/885715 -Barry

2 1

GHC11 open source day
by Terri Oda 14 Nov '11

14 Nov '11

GHC11 included an open source hackathon on Saturday, and I was lucky enough to find some great people who spent the day helping with usability testing and interface mockups for Mailman. We focused a bunch on the admin interfaces, which (unlike the archives and the member options pages) haven't been particularly usability tested before, and poked through using the first roughs for Mailman 3.0 (Thanks again for letting us abuse your server, Florian!). I've got a huge pile of notes and a suitcase filled with big paper prototypes, like the one Mel's working on in this photo: https://photos-2.dropbox.com/i/l/tGZOpFHyUZYWdP8qQIWC3bCtfwQ7vqHMrwqhz8tGWC… Over the next week or so I'll be digitizing what we produced in the form of photos, ui mockups and notes on the wiki. If anyone's interested in helping with the UI work, I could use some help! This is a great place to start if you've always wanted to help but weren't sure what to do or were worried your python skills weren't up to snuff. I should have the photos of the paper prototypes up Monday evening (I'm on US Mountain time) and I'd love some help translating the photos into UI mockups (either on the wiki or semi-functional HTML/JavaScript prototypes) to start. Terri

5 8

Re: [Mailman-Developers] GHC11 open source day
by Florian Fuchs 14 Nov '11

14 Nov '11

Hi, > I'll take this opportunity to announce something that we've been chatting > about in private for a little while. I want to officially announce that Terri > and Florian are leading the new Mailman 3 web-ui sub-project. Thanks so much for the confidence, Barry! I hope I can live up to it and I'm really looking forward to work with Terri (and hopefully many more contributers). I'm sure it will be as much fun as it has been up until now. Happy to be part of this great project! Cheers Florian

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers November 2011