Mailman 3 December 2001 - Mailman-Developers

MM Bouncer
by Bob Puff＠NLE 05 Dec '01

05 Dec '01

Wow, MM's 2.0.x bouncer REALLY needs fixing. I just saw it delete someone on the -second- bounce.. the first was back early in November, and the second one was yesterday. Just nuked him at the second bounce! Has anyone looked at that code that I posted a week or so ago? See any holes in it? Bob

3 2

Re: [Mailman-Developers] User Interface Suggestions
by Dan Mick 05 Dec '01

05 Dec '01

> 2) Change-Address feature > > The ability for somebody to go into their 'account' with an old email > and password and then change it to their new email address would help > immensely--even better would be a site-wide email change where the > user could request that their email is changed on each and every list. > (or for that matter, to commit any user configurable change to all > lists on the site). This was actually added, without a lot of fanfare, to MM2.1. I've tested it.

1 0

User Interface Suggestions
by brandon＠roguetrader.com 05 Dec '01

05 Dec '01

A few months ago I migraded a few large lists to MailMan, and since then I have been collecting various user interface comments... I believe some of this can be changed through templates, but I am posting it more for future help than anything. Specifically because a lot of people gripe about open source software because the UI's tend to be lacking in many ways--often because they are developed by techies for techies, not for common users... 1) Too much information Each page presents a lot of information and I have noticed it tends to scare people. Specifically, the mailman/listinfo/[list] page by default overwealms most normal users. Perhaps something as simple as a top section which is less terse, welcoming the user to the [list] information page and presenting them with the things they can do there, in a simple user focused list, such as: ------------- Welcome to the mylist-foo information page. From here you can: * Subscribe to mylist-foo * Unsubscribe or Change your subscription to mylist-foo * Browse historical archives of mylist-foo * Configure mylist-foo (administrators only) You can send a message to this list by emailing mylist-foo(a)domain.com. ------------- With the default page it almost appears to be information overload--even though the information is clearly seperated and organized, I see their eyes just glaze over the second they load the page. At the very least, I think the 'to Change your subscription' MUST be put into its own category, the biggest request I get is people asking how to unsubscribe, and they insist they have viewed the listinfo page yet cannot find anywhere to unsubscribe it. Because it is lumped into the same area as list admin, they just skip it. The administrative pages also have similar issues, but it is less of a problem because most admins are more technically adept... 2) Change-Address feature The ability for somebody to go into their 'account' with an old email and password and then change it to their new email address would help immensely--even better would be a site-wide email change where the user could request that their email is changed on each and every list. (or for that matter, to commit any user configurable change to all lists on the site). 3) Automated cleanup of disabled users This has been discussed recently, but I would also like to put in my 2 bits for an automated cleanup of disabled users. I am willing to help work on a UI adjustment, but I am not willing to learn python (I have enough time dumped into those languages I know, I dont need to learn another one :) I can help from the HTML perspective, however. -Brandon Gillespie

1 0

Two bugs in email 0.96 that you may want to fix sooner rather than later
by Dan Mick 05 Dec '01

05 Dec '01

I've reported these to Barry, and so real fixes are on the way eventually; however, they're both annoying enough that I thought I might drop them here too. AFAIK, these bugs are still present in email 1.0 as well. 1) MIME messages with spaces around = sign in parameters of Content-Type aren't handled I think this is a non-compliant message, but I get a bunch of bounces (mostly from Hotmail..big shock that *they'd* be noncompliant, huh?) that have Content-Type headers of the form: Content-Type: Multipart/mixed; boundary = "CPIMSSMTPC06p5f3tG" The spaces around the = are the problem. This fixes them, I think without doing any other harm. (Message.py in the email package): --- Message.py Mon Dec 3 18:13:50 2001 *************** *** 304,309 **** --- 304,311 ---- for p in paramre.split(value): try: name, val = p.split('=', 1) + name = name.strip() + val = val.strip() except ValueError: # Must have been a bare attribute name = p Without this, qfiles/shunt fills up full of these messages. 2) MIME messages with long header lines have those headers corrupted on regeneration of messages. I'm pretty sure Bob Puff noticed this, but I can't find the thread anymore. Anyway, you end up with Content-Type (typically) that's been weirdly formatted into things like Content-Type: multipart/report;; Content-Type: multipart/report;;boundary=foo instead of the proper Content-Type: multipart/report; boundary=foo because of some full-part/subpart variable name confusion in email's Generator.py: Printing long header lines that require split_header() in Generator.py can go wrong because of confusion between the original line and the sub-lines. Here's a unified diff. For the most part, it's replacing 'text' with 'line' in the right places. --- /export/home/dmick/pymod/Generator.py Mon Dec 3 17:59:58 2001 +++ Generator.py Mon Dec 3 18:57:02 2001 @@ -175,22 +175,22 @@ rtn.append(line) SEMINLTAB.join(rtn) else: - oldlen = len(text) + oldlen = len(line) # Try to break the line on semicolons, but if that doesn't # work, try to split on folding whitespace. - while len(text) > maxheaderlen: - i = text.rfind(';', 0, maxheaderlen) + while len(line) > maxheaderlen: + i = line.rfind(';', 0, maxheaderlen) if i < 0: break - rtn.append(text[:i]) - text = text[i+1:].lstrip() - if len(text) <> oldlen: + rtn.append(line[:i]) + line = line[i+1:].lstrip() + if len(line) <> oldlen: # Splitting on semis worked - rtn.append(text) + rtn.append(line) return SEMINLTAB.join(rtn) # Splitting on semis didn't help, so try to split on # whitespace. - parts = re.split(r'(\s+)', text) + parts = re.split(r'(\s+)', line) # Watch out though for "Header: longnonsplittableline" if parts[0].endswith(':') and len(parts) == 3: return text

1 0

Fully Zope-based Mailman Version
by Stephan Richter 04 Dec '01

04 Dec '01

Hello everyone, I just had a look into Mailman again. The API seems to be very clear, even though I could not find any UML diagrams anywhere. However I found out that porting Mailman to Zope (as a Python Product) might be a very simple task. Due to the nature of the project, the implementation phase could be setup in a couple of independent steps: 1. Convert the HTML screens to Zope DTML and connect the functionality to Mailman. 2. Move storage of list and user info to the ZODB 3. Move archives to the ZODB. 4. Create a nice installer that can bind the latest Mailman release with Zope. I think a first alpha release could be produced in about 40-60 hours and the full-fledged Mailman Distribution beta in about 1.5 man-month (270 hours). In fact most of the API would not even need to change, since we just need to insert our modified API at specific places, such as database connectivity and saving processes. Later we could even provide a Mailman UserFolder and search functionality for the archive. For people that do not think that the ZODB is up to handling large archives, DBObjects could be used for transparent R2O mapping from PostGreSQL (or any other RDB). The reason I write is, because I wanted to know whether someone would be interested in helping with this project, that would start after mid-December... Help can be offered in terms of programming or financial support of course. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management

5 8

[정보제공 ] ★ 무료로 팔아 드립니다..
by 한일우 04 Dec '01

04 Dec '01

::: 파라주라 메일 발송 ::::::::::::::::::: 먼저 사전 양해없이 메일을 보내드려 죄송합니다. 본 메일은 정통부 권고사항에 의거 제목에(광고)라 표시된 광고 메일입니다. 더이상 메일을 받고싶지 않으시면 [수신거부]를 눌러주세요. 죄송합니다.

3 2

RE: [ZMailman] Goals and next steps?
by barry＠zope.com 04 Dec '01

04 Dec '01

>>>>> "TT" == Trevor Toenjes <zope(a)toenjes.com> writes: TT> My wishes: TT> A. I would like to use Zmailman as an MTA from Zope. TT> So I would like to deliver a payload of Zope multi-part mime TT> content to zMailman and assign it to a list for delivery. This will be easy in MM2.1. Using the email package, you compose the MIME subparts into a Message object, then you use Mailman's Post.py module to get the message into the incoming queue. MM's incoming queue runner then picks it up and does the normal moderate-and-munge pipeline processing on the message, eventually sending it to the sink queues -- outgoing, archiver, digester, news -- as appropriate. Nothing too Zope specific here. TT> Then I would like to get to the bounce data, etc, from Zope. I'm not sure what that means. Do you mean you want the user-specific bounce statistics to be stored in Zope? That will be doable when I integrate the bounce stats into the MemberAdaptor API (which I will do this week as part of the bounce processing overhaul). TT> And perform logic on the list, like automatically removing TT> names from the list that are bounced after 48 hours. So, we TT> should allow for Mailman to reside on its own server for TT> high-volume cases. All doable in MM2.1 because it will do all the member-specific data access and modifications through the MemberAdaptor. TT> B. I would also like to get at and improve Mailman's TT> validation capability. None of this is Zope specific BTW. TT> Zmailman should have 3 options to validate an email address. TT> 1. Syntax -- Parses the address to ensure legal syntax Less TT> than one millisecond. Right. We do some of this, but could/should be using Python's RFC 2822 address parser as well. TT> 2. DNS -- All of the above, plus makes TT> sure the domain exists and has an address for receiving email TT> (as specified by MX or A records) A second or two. Default TT> timeout is 10 seconds. Doable, although not curently done. TT> 3. SMTP -- All of the above, plus TT> contacts the domain's mail server and inquires about the TT> recipient Tens of seconds. Default timeout is 60 seconds. TT> Combined with the DNS timeout, this makes a worst case of 70 TT> seconds. Harder, because you are not at all guaranteed that the SMTP server provides validation services (i.e. VRFY). The web page you reference even points this out. Note that all this could be done fairly easily in Python and hooked into the Utils.ValidateEmail() function in Mailman. It probably /should/ be done for MM2.1. Note further though that just because an email address is RFC 822 valid doesn't necessarily mean we want to support them in Mailman. First off, it should be RFC 2822 compliant. Second off, does Mailman really need to accept UUCP addresses these days? | http://www.hexillion.com/docs/guides/HexValidEmail/concepts/ | good reference Interest, thanks! -Barry

2 2

Re: [ZMailman] Development Plan
by barry＠zope.com 04 Dec '01

04 Dec '01

>>>>> "SR" == Stephan Richter <srichter(a)cbu.edu> writes: SR> 3. First I plan to integrate the data structures, since this SR> will save us from rewriting the management screens. One other thing you need to decide: will you support backwards compatibility, or an upgrade path for existing Mailman installations? That's going to be very tricky, so perhaps you should not worry about it for now. One example: each list has its own notions of a "user account", keyed off the address. How do you merge the accounts for each user? There might be 7 different passwords, 3 different delivery settings, and all the options might be different. You'll need to eventually support this level of user configurability anyway. Another tricky bit: users should be able to associate multiple email addresses with their account, and select which ones receive email for which lists. All should be valid for posting purposes though, and there ought to be some failover when bounces are detected. But maybe that's for later. -Barry

1 0

Re: [ZMailman] Goals and next steps?
by barry＠zope.com 04 Dec '01

04 Dec '01

>>>>> "FWH" == Fred Wilson Horch <fhorch(a)ecoaccess.org> writes: FWH> Possible Goal A: Quick and dirty Zmailman hack? The goal FWH> would be just to get Mailman 2.0.8 and Zope 2.3.3 to work FWH> together. To achieve this goal we could download the code FWH> for Mailman 2.0.8, study its API, and write a few DTML FWH> screens that replace the CGI part of Mailman. We would not FWH> plan to continue to support or improve Zmailman after we got FWH> it working. That would be interesting as a proof of concept. The API that Mailman expects from its cgi isn't well defined. Essentially you can think of that as the set of attributes on the MailList object. In Mailman 2.1, these are embodied in the Mailman/Gui/*.py classes. Things are still fluid too, until Mailman 2.1 enters beta. We're better off on the membership front because there, I /have/ defined an API. Look at Mailman/MemberAdaptor.py for the interface, and Mailman/OldStyleMemberships.py for an implementation that retains the existing list-independent membership approach. I believe it would be quite easy to write a ZopeMemberships.py class that implemented the MemberAdaptor interface by storing all membership information in Zope/ZODB. Using MM2.1's list extension mechanism, you could then move lists to Zope independently. Also, because you're using ZODB, you should be able to utilize a centralized member database so all the lists share the same membership information. I.e. change your password in one place, change them everywhere! Note that there will still be parts of MM2.1 that think each list's member data is independent of other lists. My intention is to clean that up for MM3, but there's a lot of backwards compatibility that has to be dealt with in order to merge existing list member databases. FWH> Possible Goal B: Fork Zmailman? The goal would be to take FWH> some version of Mailman and fork from the main Mailman FWH> project. We'd work on our fork independently of the other FWH> Mailman hackers, with the goal of continuing to support and FWH> improve Zmailman. I'd /really/ /really/ like to avoid that, for a raft of reasons. I don't see any reason why we can't put all this work (eventually) in the Mailman core. While I don't want to /require/ Zope to run Mailman, I do want to make it trivial to integrate the two, and I firmly believe that if we design the interfaces correctly, anything we produce in this effort will help others wanting to integrate Mailman with their own web and database management systems. FWH> Possible Goal C: Improve Mailman? For some of us that's not just a goal, it's a way of life. Or maybe it's a punishment for a previous life as a mass marketer. I dunno. FWH> The goal would be to add Zope support to Mailman. We'd work FWH> with the other Mailman hackers. It would make the most sense FWH> to branch from the Mailman CVS, either the latest Mailman FWH> 2.0.x release or the new Mailman 2.1 beta. Of course, maybe FWH> the other Mailman hackers don't want to add Zope support to FWH> Mailman, in which case we won't be able to achieve this goal. The "other Mailman hackers" absolutely do want to make this work! :) However, since I'm frantically trying to find the time to finish up Mailman 2.1, I don't think it's feasible to add this stuff to MM2.1, even though I highly encourage all prototyping to be done against the 2.1 code base. Should it become worthwhile, I can create a Mailman3 branch in cvs. [While I was writing this, Stephan called me up. We had an excellent conversation -- Thanks, Stephan! -BAW] FWH> With either goal B or C we need to decide which version(s) of FWH> Zope we're aiming for now. EcoAccess runs Python 1.5.2, so FWH> anything which forces us into Python 2.x would not be our top FWH> choice. We run Zope 2.3.3 and Mailman 2.0.8 because they do FWH> not require Python 2.x. Does Mailman 2.1 require Python 2.x? Yes. Right now, Python 2.0 or better but it's also likely that Python 2.1 or better will be required. Python 2.2 support is still up in the air at the moment, but it will be supported in Mailman 2.1 (just not required). FWH> It would be great if we could aim for a Zope product that FWH> works with Zope 2.3.3 or better and Python 1.5.2 or better. That limits you to Mailman 2.0.x then, which is too bad, because a lot of this will be so much easier in Mailman 2.1. -Barry

1 0

parody t-shirts & stickers in time for the holidays
by Zack 04 Dec '01

04 Dec '01

Great gifts for the liberals and lefties in your life... Hilarious political t-shirts and bumper stickers from GWBush.com: http://gwbush.com/store/order.html Many new designs. Gift wrapping availible. We'll send it straight to them for you with a card. Patriotic recession special: T-shirts $7-$10 Stickers $1, $2 & $3 We have a new "Got Democracy?" t-shirt that must be seen. And finally back on a t-shirt: "There ought to be limits to freedom" --George W Bush, May 21 1999 Just a few of our stickers--now in 3 sizes: "Don't Blame me I voted for the majority" "Trim Bush: Take back the house in 2002" "Bush: Born on Third Base, thought he hit a triple." "Which is worse: scr--ing an intern or scr--ing the country?" "I don't have to like Bush to love America" "Justice not Vengeance" "Islam is not the Enemy" "Another Bush, Another Recession" and many, many more. Remember: "To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." ---Teddy Roosevelt. This is a one-time mailing. Click here to be permenantly removed from this list: http://gwbush.com/cgi-bin/un?e=mailman-developers@python.org Click here to be added to GWBush.com's monthly update mailing: http://gwbush.com/cgi-bin/mon?e=mailman-developers@python.org if those addresses are not highlighted as hyperlinks, then you can copy them and then paste them into your browser address bar.

1 0