From Dale Newfield Sat Dec 1 06:08:35 2001 From: Dale Newfield (Dale Newfield) Date: Sat, 1 Dec 2001 01:08:35 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options In-Reply-To: <15367.57301.922260.236155@anthem.wooz.org> Message-ID: On Fri, 30 Nov 2001, Barry A. Warsaw wrote: > - For simplicity, let's treat non-fatal bounces (some temporary > outage) the same as fatal bounces (user goes away) Your scheme makes sense--I like the idea that subscribers can wind up "on probation" (assuming the list admin configures the list that way). I understand that this simplifying assumption makes the design much easier to think through. As a list admin, though, I'd like to be able to throw a switch that causes Mailman to completely ignore non-fatal bounces (Assuming it's possible to distinguish between them, which is maybe the can of worms you were trying to avoid opening). -Dale From barry@zope.com Sat Dec 1 07:18:45 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 1 Dec 2001 02:18:45 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options References: <040401c178eb$752e49a0$7b008d0a@sc.slr.com> <20011129100824.A12696@ssc.com> <15366.41687.561263.356123@anthem.wooz.org> <20011129155526.A14551@ssc.com> <1007118397.1524.13.camel@gaspode.localnet> <20011130090120.D20009@ssc.com> <15367.57301.922260.236155@anthem.wooz.org> <3C080995.373AC64B@nleaudio.com> Message-ID: <15368.33877.444422.247080@anthem.wooz.org> >>>>> "B" == Bob writes: B> On all my lists, if a person is bouncing, I want them removed, B> not just set to nomail. I envision this as possible via the 1st phase disposition being set to "Remove now" (with or without one last notice). B> Otherwise as you mentioned, the nomail list gets bigger and B> bigger. AFAIK, the only people that should be on the nomail B> list are those who have signed up as such. Yes, I want to separate the concepts of disabled-by-choice and disabled-by-bounce. Right now, you've got no idea. B> So if you want to do the "I'm about to nuke you, one last B> chance" thing, I would suggest _another_ bit be used in their B> settings to identify this. It will likely be implemented as a separate flag, mostly for backwards compatibility. Actually, it's possible that both disabled-by-* states will be represented by new flags so we can try to do /something/ with the current messy state of affairs. B> Also update list_members so that you can sort by these fields. B> (Shameless plug - my modified list_members already lets you B> sort by nomail, and digest type. Did this patch get merged B> into 2.08?) Nope, but it wouldn't anyway. I've consigned 2.0.x to critical (mostly security) fixes only. Otherwise, there's no hope 2.1 will get done. ;) B> I'm not so sure if doing an estimated average of messages sent B> is the right thing. Me neither. It /seems/ reasonable... B> How about something like this: B> Each user has three entries: time/date stamp for first bounce, B> time/date stamp for last bounce, and a bounce counter (16 bits B> should be fine!) B> Upon a bounce, do this: B> 1. Time/date stamp the last_bounce field with the current B> time/date. 2. Check the first_bounce field to see if it is B> null. If so, put the current time/date stamp there too, and B> set the bounce_counter to 0. 3. Increment the bounce counter. B> (actually not used in this text.) B> Do nothing else at this point. B> Now, we know when a regular message goes out, and we also know B> when a digest goes out. Keep a record of the last x (21?) B> days' worth of postings (see below). B> Now! Once a day, set up a cron script to go through each user B> entry. Do the following: B> 1. Examine the first_bounce time/date stamp. If null, skip to B> the next user. 2. Check out post log to see how many days B> since first_bounce have had messages. Is it less than X days? B> YES: does last_bounce = the last entry date in the posting B> log (or today)? YES: we're still bouncing, but haven't hit our B> cutoff yet. Skip to the next user. NO: NULL out the B> first_bounce, and go to the next user. We apparently stopped B> bouncing, so we need to reset. NO: we've hit our age limit. B> Let's see if he's still bouncing: Does last_bounce = the last B> entry date in the posting log (or today)? YES: NUKE EM!!! NO: B> Null out the first_bounce, and go to the next user. Apparently B> this guy really lucked out, and stopped bouncing the day before B> he would have been nuked (remember, we are doing this every B> day). If I understand your approach correctly, the problem is that bounces may be clumped and may not be correlated in time with the postings that causes them. You might send out 10 messages today, but you may not see the bounces for them for a couple of days. And then you might see all 10, one today and nine tomorrow, etc. And there's no feasible way to connect the bounces with the messages they were in reference to. By averaging things out, I'm trying to get a general sense of whether the user is receiving things or not. The interesting idea you have is the post counter buckets. By keeping a sliding average of only the last 30 days or 60 days our bouncer might adjust better to longer term changes in mailing traffic, while still smoothing out the peaks and valleys. B> Using the above algorithm does have this flaw: if a user B> bounces one message per day, it will still remove them. But B> sporatic problems usually don't surface like that. I'm more concerned with the user who fills up his disk and doesn't notice it for a week because they're on vacation. I'd like Mailman to be robust against this, and I think the average non-deliveries over a couple of weeks, with consignment to probation probably catches most of this use case. Thanks, -Barry From barry@zope.com Sat Dec 1 07:27:25 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 1 Dec 2001 02:27:25 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options References: <15367.57301.922260.236155@anthem.wooz.org> Message-ID: <15368.34397.131590.610588@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> Your scheme makes sense--I like the idea that subscribers can DN> wind up "on probation" (assuming the list admin configures the DN> list that way). I understand that this simplifying assumption DN> makes the design much easier to think through. As a list DN> admin, though, I'd like to be able to throw a switch that DN> causes Mailman to completely ignore non-fatal bounces DN> (Assuming it's possible to distinguish between them, which is DN> maybe the can of worms you were trying to avoid opening). I'm not sure it always /is/ possible to distinguish them, especially if you add VERP into the mix. AFAICT, that's the one flaw with VERP. With bounce detection at least you have a wild-ass chance of distinguishing permanent from temporary failures (e.g. DSN). My simplification assumes that temporary failures really /are/ temporary! I think my approach is robust in the face of probably the most common temporary failure I see as a list admin: a user running out of disk space for a period of several days or a week. Once they get a clue and free up some room, and deliveries start to succeed, I want them to get off probation. Ideally automatically, but as a failsafe, by the probation notices. -Barry From chuqui@plaidworks.com Sat Dec 1 19:46:02 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sat, 01 Dec 2001 11:46:02 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options In-Reply-To: Message-ID: On 11/30/01 10:08 PM, "Dale Newfield" wrote: > On Fri, 30 Nov 2001, Barry A. Warsaw wrote: >> - For simplicity, let's treat non-fatal bounces (some temporary >> outage) the same as fatal bounces (user goes away) > > Your scheme makes sense What you might consider is this: If the bounce is RFC compliant, it's fairly simple to determine "hard" and "soft" bounces, and since they are following the standards, it's not a huge amount of work. Treat a "soft" bounce as half a bounce. That gives the soft bounce twice as long to actually come into effect. If the bounce is one of the many non-RFC compliant mail systems, treat everything as hard bounces. You don't spend the work trying to read their non-compliant tea leaves, and they have some quiet encouragement to get their act together and become RFC compliant. > I like the idea that subscribers can wind up "on > probation" (assuming the list admin configures the list that way). I > understand that this simplifying assumption makes the design much easier > to think through. It'd be really nice if bounce-nomail and user-nomail are separate modes, so we can tell the difference. Beyond that, what would be optimum for me is if bounces went to nomail mode, and then if they're still nomail 30 days later, deleted from the system. That gives a user a chance to "come back" without losing their subscription state, but not hang around forever.... At some point, it'd be nice to be able to validate those other nomail addresses, similar to the monthly password reminder (or part of it). Something that says "you have this account sent to this mode. If you want this, click 'here'. If you don't, do nothing and we'll delete it. Where 'click here' takes you to a link that sets the "I'm okay" counter on that nomail status for another 90 days or something... From barry@zope.com Sat Dec 1 19:53:28 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 1 Dec 2001 14:53:28 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options References: Message-ID: <15369.13624.813786.533164@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> If the bounce is RFC compliant, it's fairly simple to CVR> determine "hard" and "soft" bounces, and since they are CVR> following the standards, it's not a huge amount of CVR> work. Treat a "soft" bounce as half a bounce. That gives the CVR> soft bounce twice as long to actually come into effect. Nice. I like that. CVR> If the bounce is one of the many non-RFC compliant mail CVR> systems, treat everything as hard bounces. You don't spend CVR> the work trying to read their non-compliant tea leaves, and CVR> they have some quiet encouragement to get their act together CVR> and become RFC compliant. Yup. >> I like the idea that subscribers can wind up "on probation" >> (assuming the list admin configures the list that way). I >> understand that this simplifying assumption makes the design >> much easier to think through. CVR> It'd be really nice if bounce-nomail and user-nomail are CVR> separate modes, so we can tell the difference. Beyond that, CVR> what would be optimum for me is if bounces went to nomail CVR> mode, and then if they're still nomail 30 days later, deleted CVR> from the system. That gives a user a chance to "come back" CVR> without losing their subscription state, but not hang around CVR> forever.... Yes, definitely. That's part of the plan. CVR> At some point, it'd be nice to be able to validate those CVR> other nomail addresses, similar to the monthly password CVR> reminder (or part of it). Something that says "you have this CVR> account sent to this mode. If you want this, click 'here'. If CVR> you don't, do nothing and we'll delete it. Where 'click here' CVR> takes you to a link that sets the "I'm okay" counter on that CVR> nomail status for another 90 days or something... Yes. That's why the current "disabled-by-idunno" state should be a third, transitional state. We can hook that in with some cronjob to convert folks. Thanks, -Barry From chuqui@plaidworks.com Sat Dec 1 23:06:23 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sat, 01 Dec 2001 15:06:23 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options In-Reply-To: <15368.33877.444422.247080@anthem.wooz.org> Message-ID: On 11/30/01 11:18 PM, "Barry A. Warsaw" wrote: > B> I'm not so sure if doing an estimated average of messages sent > B> is the right thing. > > Me neither. It /seems/ reasonable... It is, but it's lots of work. How about something simpler: Timestamp the FIRST bounce on each day. Then, track bounces for N days (N being configurable per list). If you're allowing a user to bounce for 3 days, then if you have a bounce for day N, and day N-3, then you have a match and the user is disabled. At some time longer than N days, bounce timestamps are deleted, since they're no longer valid. You can set a default value for the 'typical' list as the default. I tend to think that any moderately busy list (say, more than 2-3 messages a day) would be handle by N=3 to N=5, depending on whether you want to avoid the possibility of long-weekend-daemon breakage or not. Then add in the "soft bounce = .5 bounce", and soft bounces would extend N. And digests, do they need to be handled differently? I tend to think so. For digests, to be careful, I'd probably start them at soft-bounce, and if their bounces ARE soft, go to .25 bounce... Trying to count messages and then figure out some percentage of them as having bounced, and etc -- I think from my experience it's overkill. You get almost all of that by keeping track of "we have records of bouncing over this period of time....". You might occasionally nail a person who's system is bouncing every 8th message or some godawful thing, but IMHO, that person ought to thank you for helping them find that out... For announce, moderated and or things like e-newsletters, with very low volumes, an admin would have to decide what N should be, and likely, set it longer. You might want to keep track of them for 14 days, and if you've bounced at least twice in that time (once 14 days ago, once today), that constitutes a legitimate bounce. For something like an e-newsletter, N might even be 45 or 60 days: imagine a once-a-month beast where you want at least two bounces to prove it's dead. Hmm. That brings up a glitch in my design. If you have < 1 posting a day, that first posting has to be within some "window" around that N days, you can't depend on it being exactly N days away. So you really need some kind of way of saying "Bounces N days apart, with at least M bounces in that time, and the first bounce within Q days" -- 60 days, 3 or more recorded bounces, first bounce within 5 days of "N". Make sense? It's still a much simpler accounting system than we currently have, or one that requires tracking what the list does, and trying to guess what bounces should do from that. Let the admin define the policy, which boils down to "how long", "minimum # of bounces in then" and "granularity" (for lack of a better word) > If I understand your approach correctly, the problem is that bounces > may be clumped and may not be correlated in time with the postings > that causes them. This is correct. There are some sites (not as prevalant as it once was) that only send back bounces and admin mail during "off" hours. Since most of them seemed to be european, of course, it meant their bounces showed up in MY prime time, but that's not their problem.... (grin). You can't depend on bounces returning in any kind of "reliable" stream. > I'm more concerned with the user who fills up his disk and doesn't > notice it for a week because they're on vacation. I'd like Mailman to > be robust against this, and I think the average non-deliveries over a > couple of weeks, with consignment to probation probably catches most > of this use case. The above handles that, especially if you throw in the "soft bounce" factoring... You can set "N" to a week, or ten days, if you don't mind having more bounces flowing in and out of the system. But users who need to minimize throughput or are more willing to be strict can cut it shorter. (one other thought, which some mailers do. When bounces START, switch them to digest mode. It cuts the overhead on all sides, and allows them a cahnce to fix things before disabling, without all those bounces and etc rolling around... ) From bob@nleaudio.com Sun Dec 2 00:56:55 2001 From: bob@nleaudio.com (Bob Puff@@NLE) Date: Sat, 01 Dec 2001 19:56:55 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options References: Message-ID: <3C097C57.B8530489@nleaudio.com> Ok, I've thought more about this today, and optimized my code a little.. Check this out: min_bounce_days = 5 (max # of days we say it will take for a bounce to come to us) max_bounce_days = 14 (number of days to allow bouncing) Once every day (really doesn't matter when), post_counter is incremented ONLY if a message went out that day. This would probably be a 16 bit non-signed number. There are only three numeric entries (16 bit unsigned as well) needed per user. They are: first_bounce, last_bounce, and bounce_count. Here's the logic: Upon receiving a bounce, the user record is called up. if user(first_bounce) = null { user(first_bounce)=post_counter user(bounce_count)=0 } user(last_bounce)=post_counter; user(bounce_count)++; print to the log "User x Bounced "user(bounce_count)" times." Now for the script that gets run once a day: if there were any posts today, do this: post_counter++; for all users: if user(first_bounce) <> NULL { if (post_counter - user(first_bounce)) < min_bounce_days then break out, exit. # We don't want to do anything for the first few days.. just keep logging, and exit. if (post_counter - user(last_bounce)) > min_bounce_days { user(first_bounce) = user(last_bounce) = NULL; print to log, "User x stopped bouncing." } - exit out. # our last bounce was a while ago, so looks like we've been delivering # mail ok, so we reset the counters and exit. if (user(last_bounce) - user(first_bounce) > max_bounce_days { remove the sucker! or set him to "bouncing nomail" also don't forget to set user(first_bounce) = NULL } } Pretty simple code, huh? One thing that needs fixing is the wrapping of the 16 bit numbers, and taking care of the proper subtraction when one number wraps. The way it works is this: When a user fresh bounces, it sets their first_bounce and last_bounce to the current post_counter. Now let's say the user stops bouncing mail. After a while, we'll see that our last_bounce number is getting further from the current post_counter. So if we see that last_bounce gets more than say 5 counts (days) away from current, we can safely assume they haven't been bouncing, and can clear their entries. If a user is still bouncing, we'll see the last_bounce stay pretty close to post_counter. So now we have to see how long they have been bouncing, which can be done by simply subtracting last_bounce from first_bounce. The code in the preceeding paragraph cleans up any old junk, so we can be certain this is current data. The beauty of this is that even on a list that gets a post every other week, this code will work. Or if you get 100 messages/day, it still works, because it's based on message days. Those who have inactive lists may want to set max_bounce_days to something like 7-8, and will have to realize that this means 7-8 days messages went out.. so if you have 1 message per week, it would take 7-8 weeks for the first user to be flagged. The other variable, min_bounce_days, lets you tune it for however long you think it would take a mail server to respond with a bounce. I've seen 5 day messages, so that might be a good initial value. The code will wait for that many "message days" before considering a one-time bouncer has stopped bouncing... which is no big deal, because we haven't done anything drastic at this point anyway. What do you guys think? The above code is not in any defined programming language.. :-) Chuq: I do like the idea of the warning messages. Could probably scan for that "bounce-nomail" flag in the same once-a-day script and generate emails at specified days as you said. Bob From bob@nleaudio.com Sun Dec 2 01:32:17 2001 From: bob@nleaudio.com (Bob Puff@@NLE) Date: Sat, 01 Dec 2001 20:32:17 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options References: <15367.57301.922260.236155@anthem.wooz.org> <15368.34397.131590.610588@anthem.wooz.org> Message-ID: <3C0984A1.3677250B@nleaudio.com> > My simplification assumes that temporary failures really /are/ > temporary! I think my approach is robust in the face of probably the > most common temporary failure I see as a list admin: a user running > out of disk space for a period of several days or a week. Once they > get a clue and free up some room, and deliveries start to succeed, I > want them to get off probation. Ideally automatically, but as a > failsafe, by the probation notices. I agree. Mailman has a hard enough time now detecting the bounces; trying to parse out permanent vs non-permanent is IMHO wasted code. I think just setting the bounce numbers higher will let this automagically happen. Bob From jwblist@olympus.net Sun Dec 2 04:58:23 2001 From: jwblist@olympus.net (John W Baxter) Date: Sat, 1 Dec 2001 20:58:23 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options In-Reply-To: <15368.33877.444422.247080@anthem.wooz.org> References: <040401c178eb$752e49a0$7b008d0a@sc.slr.com> <20011129100824.A12696@ssc.com> <15366.41687.561263.356123@anthem.wooz.org> <20011129155526.A14551@ssc.com> <1007118397.1524.13.camel@gaspode.localnet> <20011130090120.D20009@ssc.com> <15367.57301.922260.236155@anthem.wooz.org> <3C080995.373AC64B@nleaudio.com> <15368.33877.444422.247080@anthem.wooz.org> Message-ID: At 2:18 -0500 12/1/01, Barry A. Warsaw wrote: >I'm more concerned with the user who fills up his disk and doesn't >notice it for a week because they're on vacation. I'd like Mailman to >be robust against this, and I think the average non-deliveries over a >couple of weeks, with consignment to probation probably catches most >of this use case. I'd prefer that such folks subscribe again if still interested. You've provided that option, so that's not a complaint about the design. Note that the "one last warning" may well bounce in this case. On the other hand, I was on one list with a one bounce and you're out rule (clearly stated in the welcome message). That's too draconian for even me to use (I had to resubscribe about 4 times over 3 years). They were using Majordomo, and the person in charge had a quick trigger finger. ;-) --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From srichter@cbu.edu Sun Dec 2 07:48:44 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 02 Dec 2001 01:48:44 -0600 Subject: [Mailman-Developers] Fully Zope-based Mailman Version Message-ID: <5.1.0.14.2.20011202011814.03565d10@mail.cbu.edu> 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 From srichter@cbu.edu Sun Dec 2 11:51:54 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 02 Dec 2001 05:51:54 -0600 Subject: [Mailman-Developers] Re: [Zope-dev] Fully Zope-based Mailman Version In-Reply-To: <5.1.0.14.2.20011202011814.03565d10@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011202054442.03532828@mail.cbu.edu> >1. Convert the HTML screens to Zope DTML and connect the functionality to >Mailman. Okay, I just wrote a proof of concept by simulating the admin intro screen and it works just fine. The most amount of work will come from the HTML page translations into DTML. If you want to know how to setup and run Mailman for Zope, please send me an E-mail privately. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From spacey-mailman@lenin.nu Sun Dec 2 12:15:05 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Sun, 2 Dec 2001 04:15:05 -0800 Subject: [Mailman-Developers] alternative policy for postings to subscribers-only lists Message-ID: <20011202041505.B20693@lenin.nu> Hi, At nylug (the NY linux users group) we've implemented a strict no-posting policy for all non-subscribed email addresses. To make this easier on us, I made a slight change to mailman to make that the only policy on our lists. I think this would be useful to mailman in general, and save time on the part of mailing list admins. If this hasn't been implemented in mailman releases > 2.0.6 yet, I have 2 questions: 1) Would this make it into mainline mailman? 2) What do I need to do to change the UI to make this option selectable? -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From les@2pi.org Sun Dec 2 15:49:20 2001 From: les@2pi.org (Les Niles) Date: Sun, 2 Dec 2001 07:49:20 -0800 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options In-Reply-To: <15368.33877.444422.247080@anthem.wooz.org> (barry@zope.com) References: <040401c178eb$752e49a0$7b008d0a@sc.slr.com> <20011129100824.A12696@ssc.com> <15366.41687.561263.356123@anthem.wooz.org> <20011129155526.A14551@ssc.com> <1007118397.1524.13.camel@gaspode.localnet> <20011130090120.D20009@ssc.com> <15367.57301.922260.236155@anthem.wooz.org> <3C080995.373AC64B@nleaudio.com> <15368.33877.444422.247080@anthem.wooz.org> Message-ID: <200112021549.HAA23342@mutiny.2pi.org> On Sat, 1 Dec 2001 02:18:45 -0500 barry@zope.com (Barry A. Warsaw) wrote: > B> Otherwise as you mentioned, the nomail list gets bigger and > B> bigger. AFAIK, the only people that should be on the nomail > B> list are those who have signed up as such. > >Yes, I want to separate the concepts of disabled-by-choice and >disabled-by-bounce. Right now, you've got no idea. And having the status clearly displayed to the user as "you were disabled due to bounces" should eliminate a lot of queries to the list admin. >I'm more concerned with the user who fills up his disk and doesn't >notice it for a week because they're on vacation. I'd like Mailman to >be robust against this, and I think the average non-deliveries over a >couple of weeks, with consignment to probation probably catches most >of this use case. For the lists I run, a long probation period would work best: the overhead of re-subscribing, both for the user and the list admin, would outweigh any disadvantage of having a pile of disabled subscriptions laying around. IOW, the probation period ought to be configurable. On a related note, keeping timestamps for the last time the various states changed -- not just disabled-by-bounce but also disabled-by- choice, etc. -- would be useful. It makes it possible to do things like build a vacation-hold interface that allows users to disable their subscriptions for a defined period. -les From chrisw@nipltd.com Sun Dec 2 15:55:04 2001 From: chrisw@nipltd.com (Chris Withers) Date: Sun, 02 Dec 2001 15:55:04 +0000 Subject: [Mailman-Developers] Re: [Zope-dev] Fully Zope-based Mailman Version References: <5.1.0.14.2.20011202054442.03532828@mail.cbu.edu> Message-ID: <3C0A4ED8.89489D19@nipltd.com> Stephan Richter wrote: > > >1. Convert the HTML screens to Zope DTML and connect the functionality to > >Mailman. > > Okay, I just wrote a proof of concept by simulating the admin intro screen > and it works just fine. The most amount of work will come from the HTML > page translations into DTML. Can I suggest you use ZPT rather than DTML and make your life easier in the long run? cheers, Chris From srichter@cbu.edu Sun Dec 2 17:21:07 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 02 Dec 2001 11:21:07 -0600 Subject: [Mailman-Developers] Re: [Zope-dev] Fully Zope-based Mailman Version In-Reply-To: <3C0A4ED8.89489D19@nipltd.com> References: <5.1.0.14.2.20011202054442.03532828@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011202105550.03580648@mail.cbu.edu> At 03:55 PM 12/2/2001 +0000, Chris Withers wrote: >Stephan Richter wrote: > > > > >1. Convert the HTML screens to Zope DTML and connect the functionality to > > >Mailman. > > > > Okay, I just wrote a proof of concept by simulating the admin intro screen > > and it works just fine. The most amount of work will come from the HTML > > page translations into DTML. > >Can I suggest you use ZPT rather than DTML and make your life easier in >the long >run? I haven't looked at ZPT at all yet, simply because I did not have to and usually my DTML is minimal, since I develop all logical features in Python in anyway. However, now that it becomes Zope Core Component that might be a possible choice. How do you think will ZPT be better (other than that DTML is not the future)? I just installed ZPT on the Mailman-Zope installation. I would like someone on the mailing list to convert the manage_admin.dtml script to manage_admin_zpt (I created the bare script already) inside this Zope Installation. I will give you the necessary access once you reply. Mmmh, actually, if you (anyone) is willing to work on it, what the heck, I give you FTP access (the restriction is that I have to know you from previous discussions) to the Zope Tree/Products as well, so you can start making some progress there as well. I will not have much time until exams are over, so I do not want to kill the momentum I seem to have generated (seeing my personal Inbox). I welcome everyone to help with the coding and will do my best to support you. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From srichter@cbu.edu Sun Dec 2 18:01:53 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 02 Dec 2001 12:01:53 -0600 Subject: [Mailman-Developers] Re: [Zope-dev] Fully Zope-based Mailman Version In-Reply-To: <5.1.0.14.2.20011202105550.03580648@mail.cbu.edu> References: <3C0A4ED8.89489D19@nipltd.com> <5.1.0.14.2.20011202054442.03532828@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011202115052.0357b638@mail.cbu.edu> At 11:21 AM 12/2/2001 -0600, Stephan Richter wrote: >Mmmh, actually, if you (anyone) is willing to work on it, what the heck, I >give you FTP access (the restriction is that I have to know you from >previous discussions) to the Zope Tree/Products as well, so you can start >making some progress there as well. Cool, eight (8) people have now already access to my little development installation. Could this be a way of Extreme Programming remotely over the net? Well, I am certainly open for the test drive! Mmh, of course problems can arise in terms cancelling each others work, but if you work with versioning and CVS (for the Python Code maybe), you should be able to avoid that (assuming that everyone creates their own username, once they are in). It is certainly not made for a long-term condition, but I believe it will be great to address the most obvious initial issues. Once they are solved a design can be made with some "Getting Started" instructions and everyone can develop on their local machine. But I would still keep the test-Zope up and running, so people can check-in and test their latest advancements and there will be always a place where the latest functional code is publicly viewable and executable. Security is of course another issue, this is why I limited the access a little bit. But I think one must calculate with some of the security risks in order to increase development performance. That's it for now. If you want to be part of this little experiment, E-mail me and I give you the info you need. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From gward@mems-exchange.org Mon Dec 3 19:16:42 2001 From: gward@mems-exchange.org (Greg Ward) Date: Mon, 3 Dec 2001 14:16:42 -0500 Subject: [Mailman-Developers] New FAQ entry: broken autoresponders Message-ID: <20011203141642.A2745@mems-exchange.org> 3.6. What can I do about users with broken autoresponders? http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.006.htp From rodolfo@linux.org.uy Mon Dec 3 20:41:28 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 03 Dec 2001 17:41:28 -0300 Subject: [Mailman-Developers] OldStyleMembership.py error Message-ID: <1007412089.3365.2.camel@claudia> I am updating Mailman 2.1a2 to 2.1a3. I have Python 2.0 and I have just installed email-0.93 manually. But the 'make install' shows the following error: File "/usr/lib/mailman/Mailman/OldStyleMemberships.py", line 231, in setMemberOption assert self.__mlist.Locked() AssertionError make: *** [update] Error 1 Can you help me? -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From mhz@alt-linux.org Tue Dec 4 00:07:13 2001 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Tue, 4 Dec 2001 03:07:13 +0300 Subject: [Mailman-Developers] Re: [ python-Patches-486375 ] Use charset in email.Utils.encode In-Reply-To: References: Message-ID: <20011204000713.GA6896@localhost.localdomain> Hello, Sorry for replying in the Mailman list, but I'm not subscribed elsewhere, and I think the email package is crucial for Mailman, so... On Mon, Dec 03, 2001 at 11:26:41AM -0800, noreply@sourceforge.net wrote: > > Patches item #486375, was opened at 2001-11-27 22:45 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=305470&aid=486375&group_id=5470 > > Category: Library (Lib) > Group: None > >Status: Closed > >Resolution: Rejected > Priority: 7 > Submitted By: Mikhail Zabaluev (mzabaluev) > Assigned to: Barry Warsaw (bwarsaw) > Summary: Use charset in email.Utils.encode > > Initial Comment: > Here's a patch that makes email.Utils.encode actually > _use_ its charset parameter. Note: a string is encoded > into the specified character set using the 'replace' > mode in order to provide high tolerance for missing > characters, typical for email applications. > The patch also slightly optimizes the code around > (cough cough). > > ---------------------------------------------------------------------- > > >Comment By: Barry Warsaw (bwarsaw) > Date: 2001-12-03 11:26 > > Message: > Logged In: YES > user_id=12800 > > Sorry, but this isn't correct. email.Utils.encode() states > that the argument "s" must already be encoded in the given > character set. The charset argument is required because > Python can't guess what charset s is encoded in. I just thought it would be nicer to specify charset once: email.Utils.encode(s, 'cp1251', 'b') , not like this: email.Utils.encode(s.encode('cp1251'), 'cp1251', 'b') The argument "s" could be reconsidered as a Unicode string. This would constitute a better symmetry with email.Utils.decode, no? -- Stay tuned, MhZ JID: mookid@jabber.org ___________ Conformity is the refuge of the unimaginative. From tollef@add.no Tue Dec 4 07:12:31 2001 From: tollef@add.no (Tollef Fog Heen) Date: 04 Dec 2001 08:12:31 +0100 Subject: [Mailman-Developers] Internal server error when accessing admin pages In-Reply-To: <20010726114255.D23679@magic.merlins.org> References: <20010726082614.A22086@magic.merlins.org> <15200.23428.295322.627606@anthem.wooz.org> <20010726114255.D23679@magic.merlins.org> Message-ID: <87u1v77928.fsf@arabella.intern.opera.no> * Marc MERLIN | On Thu, Jul 26, 2001 at 02:03:48PM -0400, Barry A. Warsaw wrote: | > Now, I've /only/ ever seen it with Mozilla 0.9.2 and have never hit it | > with NS4 or IE on Windows. Can you find out which browser these | > users were using? I'm not saying it's Mozilla related, but that's the | > only connection I've got so far. | | I've gotten a couple of reports for konqueror, a couple for mozilla, and one | person said it also failed with netscape when he tried that instead (I think | the ticket I attached was that one actually), but considering it's my only | report of it failing with netscape, I can't say for sure. | | I'll definitely keep asking what browsers were involved. FWIW, I've got a report about this with Konqueror now. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=122119&repeatmerged=yes -- Tollef Fog Heen Axiom #1: You Can't Win From joshuae@bitmine.net Tue Dec 4 07:58:01 2001 From: joshuae@bitmine.net (Joshua Eichen) Date: Mon, 3 Dec 2001 23:58:01 -0800 (PST) Subject: [Mailman-Developers] Email Dispatches Message-ID: Hi, I've been looking around the mailman code for a couple of weeks now and I haven't been able to find the function that dispatches the email to each member of the mailing list. I want to modify the message body before each message goes out to the individual mailing list members. I'm not on the list so if anyone knows will the reply to me directly. Thank you, Joshua From Nigel.Metheringham@VData.co.uk Tue Dec 4 09:46:38 2001 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: 04 Dec 2001 09:46:38 +0000 Subject: [Mailman-Developers] New FAQ entry: broken autoresponders In-Reply-To: <20011203141642.A2745@mems-exchange.org> References: <20011203141642.A2745@mems-exchange.org> Message-ID: <1007459198.2395.4.camel@gaspode.localnet> On Mon, 2001-12-03 at 19:16, Greg Ward wrote: > 3.6. What can I do about users with broken autoresponders? > > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.006.htp I'm impressed - an answer to this question which doesn't involve dark threats and/or baseball bats. Nigel. From spacey-mailman@lenin.nu Tue Dec 4 09:50:49 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Tue, 4 Dec 2001 01:50:49 -0800 Subject: [Mailman-Developers] How to make mods to config.db? Message-ID: <20011204015049.J20693@lenin.nu> Is there a simple way to modify config.db for an update? I've created a custom config variable and some actions based on it. To work properly it seems to need to be added to config.db for existing lists (it seems to work fine for new lists), and I'm having some trouble finding the "right" way to do this. I have added the following to versions.py: # Add the option to not have to admin bouncing messages if not hasattr(l, "auto_reject_nonmembers"): setattr(l, "auto_reject_nonmembers", mm_cfg.DEFAULT_AUTO_REJECT_NONMEMBERS) But this doesn't seem to update the list after a "make install" of an updgrade. Any help is appreciated, -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From barry@zope.com Tue Dec 4 20:16:14 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 4 Dec 2001 15:16:14 -0500 Subject: [Mailman-Developers] Re: Fully Zope-based Mailman Version References: <5.1.0.14.2.20011202011814.03565d10@mail.cbu.edu> Message-ID: <15373.12046.722974.664655@anthem.wooz.org> [I've changed the CC's to zmailman and mailman-developers, leaving zope-dev out of this for now. -BAW] There's been a lot of traffic about this over the weekend, so my responses may be a bit fractured. Let me start with two things: first, way cool Stephan! Thanks for putting together this list and doing the prototyping. Second, for now, let's talk about Mailman 2.1 and beyond. What would be neat is if a Mailman3 played nicely with a Zope3. Given where each project is headed, I think that's entirely doable. >>>>> "SR" == Stephan Richter writes: SR> I just had a look into Mailman again. The API seems to be very SR> clear, even though I could not find any UML diagrams SR> anywhere. Nope, there are no UML diagrams, or any internals documentation except for the source. And even that has gone through a lot of changes for MM2.1, hopefully to make things cleaner, and to provide interfaces in many cases (although not everywhere). SR> 1. Convert the HTML screens to Zope DTML and connect the SR> functionality to Mailman. 2. Move storage of list and user SR> info to the ZODB 3. Move archives to the ZODB. 4. Create a SR> nice installer that can bind the latest Mailman release with SR> Zope. All but the last have long been goals of mine. Not to /require/ Zope for Mailman, but to enable an easy integration of them. I think MM2.1 should make things easier, because of the membership API and other APIs. More to follow... -Barry From barry@zope.com Tue Dec 4 21:09:31 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 4 Dec 2001 16:09:31 -0500 Subject: [Mailman-Developers] Re: [ZMailman] Goals and next steps? References: <20011203233650.578e51af.fhorch@ecoaccess.org> Message-ID: <15373.15243.911732.838510@anthem.wooz.org> >>>>> "FWH" == Fred Wilson Horch 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 From barry@zope.com Tue Dec 4 21:23:09 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 4 Dec 2001 16:23:09 -0500 Subject: [Mailman-Developers] RE: [ZMailman] Goals and next steps? References: <20011203233650.578e51af.fhorch@ecoaccess.org> Message-ID: <15373.16061.931673.890251@anthem.wooz.org> >>>>> "TT" == Trevor Toenjes 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 From barry@zope.com Tue Dec 4 21:31:27 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 4 Dec 2001 16:31:27 -0500 Subject: [Mailman-Developers] Re: [ZMailman] Development Plan References: <5.1.0.14.2.20011204041955.035f2088@mail.cbu.edu> Message-ID: <15373.16559.502507.149455@anthem.wooz.org> >>>>> "SR" == Stephan Richter 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 From zope@toenjes.com Tue Dec 4 22:25:22 2001 From: zope@toenjes.com (Trevor Toenjes) Date: Tue, 4 Dec 2001 17:25:22 -0500 Subject: [Mailman-Developers] RE: [ZMailman] Goals and next steps? In-Reply-To: <15373.16061.931673.890251@anthem.wooz.org> Message-ID: Barry, Thank you so much for getting involved with this project. yeehaw!! Sorry for all the MTA requests. I have never admined Mailman. I was planning on installing it in the next few weeks and then this project was born. > 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). Yes. That is what I meant. I want be able to put rules on bounces as they come back into Zope to delete, notify the list's manager, or notify an account mamager responsible for that email. Bounce management could be a whole workflow and list management module on its own. The further we can go with Validation prior to delivery the better. I agree with the UUCP fossile reference. Cheers, Trevor > -----Original Message----- > From: zmailman-admin@mail.iuveno-net.de > [mailto:zmailman-admin@mail.iuveno-net.de]On Behalf Of Barry A. Warsaw > Sent: Tuesday, December 04, 2001 4:23 PM > To: Trevor Toenjes > Cc: Fred Wilson Horch; Stephan Richter; Zmailman List; > mailman-developers@python.org > Subject: RE: [ZMailman] Goals and next steps? > > > > >>>>> "TT" == Trevor Toenjes 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 > _______________________________________________ > ZMailman mailing list > ZMailman@mail.iuveno-net.de > http://mail.iuveno-net.de/mailman/listinfo/zmailman From barry@zope.com Tue Dec 4 22:34:42 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 4 Dec 2001 17:34:42 -0500 Subject: [Mailman-Developers] RE: [ZMailman] Goals and next steps? References: <15373.16061.931673.890251@anthem.wooz.org> Message-ID: <15373.20355.332913.974527@anthem.wooz.org> >>>>> "TT" == Trevor Toenjes writes: TT> Barry, Thank you so much for getting involved with this TT> project. yeehaw!! No problem. I've been psyched to do something like this even before DC/ZC hired us. :) > 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> Yes. That is what I meant. I want be able to put rules on TT> bounces as they come back into Zope to delete, notify the TT> list's manager, or notify an account mamager responsible for TT> that email. Bounce management could be a whole workflow and TT> list management module on its own. Good idea. I hadn't thought of handling bounce management as a workflow, but that does make sense. It's likely that there will be some moderately flexible workflow for bounce handling in MM2.1, with something more elaborate coming down the pike. -Barry From stuff@gwbush.com Tue Dec 4 19:44:15 2001 From: stuff@gwbush.com (Zack) Date: Tue, 4 Dec 2001 11:44:15 -0800 Subject: [Mailman-Developers] parody t-shirts & stickers in time for the holidays Message-ID: <200112041943.fB4Jhrd65168@gwbush.com> 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. From midnight@the-oasis.net Wed Dec 5 00:43:38 2001 From: midnight@the-oasis.net (Phil Barnett) Date: Tue, 4 Dec 2001 19:43:38 -0500 Subject: [Mailman-Developers] Re: Fully Zope-based Mailman Version In-Reply-To: <15373.12046.722974.664655@anthem.wooz.org> References: <5.1.0.14.2.20011202011814.03565d10@mail.cbu.edu> <15373.12046.722974.664655@anthem.wooz.org> Message-ID: On Tuesday 04 December 2001 15:16, you wrote: > Second, for now, let's talk about Mailman 2.1 and beyond.  What would > be neat is if a Mailman3 played nicely with a Zope3.  Given where > each project is headed, I think that's entirely doable. Playing nice is a great ideal, but I hope it never becomes a dependent relationship. From hanil@hanmail.net Wed Dec 5 04:28:21 2001 From: hanil@hanmail.net (=?ks_c_5601-1987?B?x9HAz7/s?=) Date: Wed, 05 Dec 2001 13:28:21 +0900 Subject: [Mailman-Developers] =?ks_c_5601-1987?B?W8GkurjBprD4IF0godoguau34bfOIMbIvsYgteW4s7TPtNkuLg==?= Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0137_01C0F05A.93A28C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Ojo6IMbEtvPB1rbzILjewM8gud+82yA6Ojo6Ojo6Ojo6Ojo6Ojo6Ojo6ICAgICAgICAgICAg ICAgICAgICAgICAguNXA+iC758D8IL7nx9i++MDMILjewM/AuyC6uLO7teW3wSDBy7zbx9W0 z7TZLg0KILq7ILjewM/AuiDBpMXrus4gscew7bvnx9e/oSDAx7DFIMGmuPG/oSixpLDtKbbz IMelvcO1yCCxpLDtILjewM/A1LTPtNkuDQogtPXAzLvzILjewM/AuyC53rDtvc3B9iC+ysC4 vcO46SBbvPa9xbDFus5duKYgtK23r8HWvLy/5C4NCiDBy7zbx9W0z7TZLg0KICAgICAgICAg ICAgICAgICA= ------=_NextPart_000_0137_01C0F05A.93A28C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT46OjogxsS288HWtvMguN7AzyC537zbIDo6Ojo6Ojo6 Ojo6Ojo6Ojo6Ojo8L3RpdGxlPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjxzdHlsZSB0eXBlPSJ0ZXh0 L2NzcyI+DQo8IS0tDQphOmxpbmssYTphY3RpdmUsYTp2aXNpdGVke3RleHQtZGVjb3JhdGlv bjpub25lOyBjb2xvcjojMDAwMDAwfQ0KYTpob3Zlcnt0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lOyBjb2xvcjojMDI1YTk3fQ0KDQphLjE6bGluayxhLjE6YWN0aXZlLGEuMTp2aXNpdGVk e3RleHQtZGVjb3JhdGlvbjpub25lOyBjb2xvcjojQzYwMDAwfQ0KYS4xOmhvdmVye3RleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7IGNvbG9yOiMzMzMzMzN9DQoNCnRke2ZvbnQtc2l6ZTo5 cHR9DQpkaXZ7Zm9udC1zaXplOjlwdH0NCg0KYm9keSB7DQogICAgICAgIHNjcm9sbGJhci1m YWNlLWNvbG9yOiNmZmZmZmY7DQogICAgICAgIHNjcm9sbGJhci1zaGFkb3ctY29sb3I6Izc4 Nzg3ODsNCiAgICAgICAgc2Nyb2xsYmFyLWhpZ2hsaWdodC1jb2xvcjojZjNmM2YzOw0KICAg ICAgICBzY3JvbGxiYXItM2RsaWdodC1jb2xvcjojZmZmZmZmOw0KICAgICAgICBzY3JvbGxi YXItZGFya3NoYWRvdy1jb2xvcjojZmZmZmZmOw0KICAgICAgICBzY3JvbGxiYXItdHJhY2st Y29sb3I6I2ZmZmZmZjsNCiAgICAgICAgc2Nyb2xsYmFyLWFycm93LWNvbG9yOiM3ODc4NzgN Cn0NCi0tPg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIj4NCg0KPC9ib2R5 Pg0KPC9odG1sPg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgbGVmdG1hcmdpbj0iMCIgdG9w bWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIiBiYWNrZ3JvdW5k PSJpbWFnZS9iZy5naWYiPg0KPC9zdHlsZT4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3Jp cHQiPg0KPCEtLQ0KZnVuY3Rpb24gTU1fb3BlbkJyV2luZG93KHRoZVVSTCx3aW5OYW1lLGZl YXR1cmVzKSB7IC8vdjIuMA0KICB3aW5kb3cub3Blbih0aGVVUkwsd2luTmFtZSxmZWF0dXJl cyk7DQp9DQovLy0tPg0KPC9zY3JpcHQ+DQo8Ym9keSBiYWNrZ3JvdW5kPSJpbWFnZS9iZy5n aWYiIGxlZnRtYXJnaW49IjAiIHRvcG1hcmdpbj0iMCIgbWFyZ2lud2lkdGg9IjAiIG1hcmdp bmhlaWdodD0iMCI+DQo8dGFibGUgd2lkdGg9IjYzNSIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJjZW50ZXIiPg0KICA8dHI+IA0KICAgIDx0 ZCBoZWlnaHQ9IjIzIj48aW1nIHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1h Z2UvbWFpbF8wMS5naWYiIHdpZHRoPSI2MzUiIGhlaWdodD0iNjYiIHVzZW1hcD0iI01hcCIg Ym9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBoZWlnaHQ9IjU4 Ij48aW1nIHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1hZ2UvbWFpbF8wMi5n aWYiIHdpZHRoPSI2MzUiIGhlaWdodD0iNTgiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQog ICAgPHRkIGhlaWdodD0iNzEiPjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL21haWww Mi9pbWFnZS9tYWlsXzAzLmdpZiIgd2lkdGg9IjYzNSIgaGVpZ2h0PSI3MSIgdXNlbWFwPSIj TWFwMiIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZD48aW1n IHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1hZ2UvbWFpbF8wNC5naWYiIHdp ZHRoPSI2MzUiIGhlaWdodD0iNzAiIHVzZW1hcD0iI01hcDMiIGJvcmRlcj0iMCI+PC90ZD4N CiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly9wYXJhanVyYS5j b20vbWFpbDAyL2ltYWdlL21haWxfMDUuZ2lmIiB3aWR0aD0iNjM1IiBoZWlnaHQ9IjY5IiB1 c2VtYXA9IiNNYXA0IiBib3JkZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAg PHRkIGhlaWdodD0iMzgiPjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL21haWwwMi9p bWFnZS9tYWlsXzA2LmdpZiIgd2lkdGg9IjYzNSIgaGVpZ2h0PSI3MSIgdXNlbWFwPSIjTWFw NSIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBoZWlnaHQ9 Ijc1Ij48aW1nIHNyYz0iaHR0cDovL3BhcmFqdXJhLmNvbS9tYWlsMDIvaW1hZ2UvbWFpbF8w Ny5naWYiIHdpZHRoPSI2MzUiIGhlaWdodD0iMTg4IiB1c2VtYXA9IiNNYXA2IiBib3JkZXI9 IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGhlaWdodD0iMTA3IiBiYWNr Z3JvdW5kPSJodHRwOi8vcGFyYWp1cmEuY29tL21haWwwMi9pbWFnZS9tYWlsXzA4LmdpZiI+ DQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPrjVwPogu+fA/CC+58fYvvjAzCC43sDPwLsg urizu7Xlt8Egwcu828fVtM+02S48YnI+DQogICAgICAgILq7ILjewM/AuiDBpMXrus4gscew 7bvnx9e/oSDAx7DFIMGmuPG/oSixpLDtKbbzIMelvcO1yCCxpLDtILjewM/A1LTPtNkuPGJy Pg0KICAgICAgICC09cDMu/MguN7Az8C7ILnesO29zcH2IL7KwLi9w7jpIDxiPls8YSBocmVm PSJtYWlsdG86cGFyYWp1cmFAcGFyYWp1cmEuY29tIj689r3FsMW6zjwvYT5dPC9iPrimILSt t6/B1ry8v+QuPGJyPg0KICAgICAgICDBy7zbx9W0z7TZLjwvZGl2Pg0KICAgIDwvdGQ+DQog IDwvdHI+DQo8L3RhYmxlPg0KPG1hcCBuYW1lPSJNYXAiPiANCiAgPGFyZWEgc2hhcGU9InJl Y3QiIGNvb3Jkcz0iNyw3LDE4MSw1MSIgaHJlZj0iaHR0cDovL3d3dy5wYXJhanVyYS5jb20i IHRhcmdldD0iX2JsYW5rIiBhbHQ9IsbEtvPB1rbztOXExMC4t84iIHRpdGxlPSLGxLbzwda2 87TlxMTAuLfOIj4NCiAgICAgIDwvbWFwPg0KPG1hcCBuYW1lPSJNYXAyIj4gDQogIDxhcmVh IHNoYXBlPSJwb2x5IiBjb29yZHM9IjQ1MywyNyw0NTQsNDgsNTMxLDQ5LDUzMiw2Miw1OTks MzcsNTMzLDE0LDUzMiwyOSw0NTEsMjYiIGhyZWY9Imh0dHA6Ly93d3cucGFyYWp1cmEuY29t IiB0YXJnZXQ9Il9ibGFuayIgYWx0PSLB97DFt6HA5cXNIiB0aXRsZT0iwfewxbehwOXFzSI+ DQo8L21hcD4NCjxtYXAgbmFtZT0iTWFwMyI+IA0KICA8YXJlYSBzaGFwZT0icG9seSIgY29v cmRzPSI0NTMsMjYsNDUzLDQ2LDUzMiw0OSw1MzIsNjIsNTk5LDM4LDUzMiwxNSw1MzEsMjgs NDU1LDI2IiBocmVmPSJodHRwOi8vd3d3LnBhcmFqdXJhLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGFsdD0ius61v7vqwPy5rrj0IiB0aXRsZT0ius61v7vqwPy5rrj0Ij4NCjwvbWFwPg0KPG1h cCBuYW1lPSJNYXA0Ij4gDQogIDxhcmVhIHNoYXBlPSJwb2x5IiBjb29yZHM9IjQ1NCwyNiw1 MzMsMjYsNTMzLDE2LDYwMCwzOCw1MzQsNjAsNTMyLDQ5LDQ1NCw1MCw0NTMsMjYiIGhyZWY9 Imh0dHA6Ly93d3cucGFyYWp1cmEuY29tIiB0YXJnZXQ9Il9ibGFuayIgYWx0PSLIuL/4sKHA 1CIgdGl0bGU9Isi4v/iwocDUIiBvbkNsaWNrPSJNTV9vcGVuQnJXaW5kb3coJ2h0dHA6Ly93 d3cucGFyYWp1cmEuY29tL21lbWJlcnNoaXAvbWVtYmVyX2dhaXAuaHRtJywnJywnc2Nyb2xs YmFycz15ZXMsd2lkdGg9NjIwLGhlaWdodD01MDAnKSI+DQo8L21hcD4NCjxtYXAgbmFtZT0i TWFwNSI+IA0KICA8YXJlYSBzaGFwZT0icG9seSIgY29vcmRzPSI0NTMsMjcsNDUyLDQ5LDUz MCw1MCw1MzIsNjIsNTk4LDM4LDUzMiwxNSw1MzEsMjcsNDU0LDI2IiBocmVmPSJodHRwOi8v d3d3LnBhcmFqdXJhLmNvbS9wYXJ0bmVyL3BhcnRlcl9kZWZhdWx0Lmh0bSIgdGFyZ2V0PSJf YmxhbmsiIGFsdD0iu/nHw7q4seIiIHRpdGxlPSK7+cfDurix4iI+DQo8L21hcD4NCjxtYXAg bmFtZT0iTWFwNiI+IA0KICA8YXJlYSBzaGFwZT0icmVjdCIgY29vcmRzPSIxMCw2LDIxMCwx ODIiIGhyZWY9Imh0dHA6Ly93d3cucGFyYWp1cmEuY29tL2hvbWVwYWdlL2hvbWVwYWdlLmh0 bSIgdGFyZ2V0PSJfYmxhbmsiIGFsdD0iu/nHwzEiIHRpdGxlPSK7+cfDMSI+DQogIDxhcmVh IHNoYXBlPSJyZWN0IiBjb29yZHM9IjIxNyw1LDQxNiwxNzgiIGhyZWY9Imh0dHA6Ly93d3cu cGFyYWp1cmEuY29tL2hvbWVwYWdlL2hvbWVwYWdlLmh0bSIgdGFyZ2V0PSJfYmxhbmsiIGFs dD0iu/nHwzIiIHRpdGxlPSK7+cfDMiI+DQogIDxhcmVhIHNoYXBlPSJyZWN0IiBjb29yZHM9 IjQyNCw1LDYyNCwxNzkiIGhyZWY9Imh0dHA6Ly93d3cucGFyYWp1cmEuY29tL2hvbWVwYWdl L2hvbWVwYWdlLmh0bSIgdGFyZ2V0PSJfYmxhbmsiIGFsdD0iu/nHwzMiIHRpdGxlPSK7+cfD MyI+DQo8L21hcD4NCg== ------=_NextPart_000_0137_01C0F05A.93A28C00-- From spacey-mailman@lenin.nu Wed Dec 5 05:07:28 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Tue, 4 Dec 2001 21:07:28 -0800 Subject: [Mailman-Developers] Re: =?iso-8859-1?Q?=5BMailman-Developers=5D_=5B=C1=A4=BA=B8=C1=A6=B0=F8_=5D_?= =?iso-8859-1?Q?=A1=DA_=B9=AB=B7=E1=B7=CE_=C6=C8=BE=C6_=B5=E5=B8=B3=B4=CF?= =?iso-8859-1?Q?=B4=D9=2E=2E?= In-Reply-To: ; from hanil@hanmail.net on Wed, Dec 05, 2001 at 01:28:21PM +0900 References: Message-ID: <20011204210728.D20693@lenin.nu> Nope, no idea. Sorry. On Wed, Dec 05, 2001 at 01:28:21PM +0900, ÇÑÀÏ¿ì wrote: > ::: ÆĶóÁÖ¶ó ¸ÞÀÏ ¹ß¼Û ::::::::::::::::::: ¸ÕÀú »çÀü ¾çÇؾøÀÌ ¸ÞÀÏÀ» º¸³»µå·Á Á˼ÛÇÕ´Ï´Ù. > º» ¸ÞÀÏÀº Á¤ÅëºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡(±¤°í)¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù. > ´õÀÌ»ó ¸ÞÀÏÀ» ¹Þ°í½ÍÁö ¾ÊÀ¸½Ã¸é [¼ö½Å°ÅºÎ]¸¦ ´­·¯ÁÖ¼¼¿ä. > Á˼ÛÇÕ´Ï´Ù. > -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From che@debian.org Wed Dec 5 05:16:13 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 05 Dec 2001 14:16:13 +0900 Subject: [Mailman-Developers] Re: [Mailman-Developers] =?ks_c_5601-1987?B?W8GkurjBprD4IF0godoguau34bfOIMbIvsYgteW4s7TPtNkuLg==?= In-Reply-To: (=?ks_c_5601-1987?B?x9HAz7/s?='s message of "Wed, 05 Dec 2001 13:28:21 +0900") References: Message-ID: <87oflent5u.fsf@nausicaa.interq.or.jp> Actually, this was brought up on the Debian lists recently; the particular encoding this Korean spam uses, ks_c_5601-1987, is *NOT* a standard, and no Korean developer would ever use it. (They use euc-kr instead.) You can all pretty safely filter any messages with this Korean windows-specific charset and 99.999% of the time, it'll be spam. Ben -- Brought to you by the letters E and R and the number 9. "I don't want the world.. I just want your half." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From barry@zope.com Wed Dec 5 05:30:11 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 5 Dec 2001 00:30:11 -0500 Subject: [Mailman-Developers] Re: Fully Zope-based Mailman Version References: <5.1.0.14.2.20011202011814.03565d10@mail.cbu.edu> <15373.12046.722974.664655@anthem.wooz.org> Message-ID: <15373.45283.962734.116904@anthem.wooz.org> >>>>> "PB" =3D=3D Phil Barnett writes: >> Second, for now, let's talk about Mailman 2.1 and beyond. =A0Wha= t >> would be neat is if a Mailman3 played nicely with a >> Zope3. =A0Given where each project is headed, I think that's >> entirely doable. PB> Playing nice is a great ideal, but I hope it never becomes a PB> dependent relationship. No, it won't. But I suspect that the bulk of the work to get them to easily integrate will translate to other people who want to integrate Mailman with their own backend systems. it's-all-about-the-api's-ly y'rs, -Barry From Dale Newfield Wed Dec 5 06:38:38 2001 From: Dale Newfield (Dale Newfield) Date: Wed, 5 Dec 2001 01:38:38 -0500 (EST) Subject: [Mailman-Developers] Re: Fully Zope-based Mailman Version In-Reply-To: <15373.45283.962734.116904@anthem.wooz.org> Message-ID: On Wed, 5 Dec 2001, Barry A. Warsaw wrote: > No, it won't. But I suspect that the bulk of the work to get them to > easily integrate will translate to other people who want to integrate > Mailman with their own backend systems. (php and mysql here) > it's-all-about-the-api's-ly y'rs, Yep :-) -Dale From Dan Mick Thu Dec 6 03:20:40 2001 From: Dan Mick (Dan Mick) Date: Wed, 5 Dec 2001 19:20:40 -0800 (PST) Subject: [Mailman-Developers] Two bugs in email 0.96 that you may want to fix sooner rather than later Message-ID: <200112060320.TAA21462@utopia.West.Sun.COM> 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 From brandon@roguetrader.com Thu Dec 6 03:37:45 2001 From: brandon@roguetrader.com (brandon@roguetrader.com) Date: Wed, 5 Dec 2001 20:37:45 -0700 Subject: [Mailman-Developers] User Interface Suggestions Message-ID: <20011205203745.A24602@mojo.cold.org> 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@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 From Dan Mick Thu Dec 6 03:49:55 2001 From: Dan Mick (Dan Mick) Date: Wed, 5 Dec 2001 19:49:55 -0800 (PST) Subject: [Mailman-Developers] User Interface Suggestions Message-ID: <200112060350.TAA21937@utopia.West.Sun.COM> > 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. From bob@nleaudio.com Thu Dec 6 04:56:28 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Wed, 05 Dec 2001 23:56:28 -0500 Subject: [Mailman-Developers] MM Bouncer Message-ID: <3C0EFA7C.2B043C2B@nleaudio.com> 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 From dan@ssc.com Thu Dec 6 06:40:31 2001 From: dan@ssc.com (Dan Wilder) Date: Wed, 5 Dec 2001 22:40:31 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <3C0EFA7C.2B043C2B@nleaudio.com> References: <3C0EFA7C.2B043C2B@nleaudio.com> Message-ID: <20011205224031.B30207@ssc.com> On Wed, Dec 05, 2001 at 11:56:28PM -0500, Bob Puff@NLE wrote: > 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! > Yeah, it's ailing. > Has anyone looked at that code that I posted a week or so ago? See any holes in it? I was looking at it earlier this evening. The approach of the holidays, helping with some kids' end-of-term school projects, plus car troubles, have my life robbing my avocations of time ... -- ----------------------------------------------------------------- Dan Wilder Technical Manager & Editor SSC, Inc. P.O. Box 55549 Phone: 206-782-8808 Seattle, WA 98155-0549 URL http://embedded.linuxjournal.com/ ----------------------------------------------------------------- From spacey-mailman@lenin.nu Thu Dec 6 07:02:01 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Wed, 5 Dec 2001 23:02:01 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <3C0EFA7C.2B043C2B@nleaudio.com>; from bob@nleaudio.com on Wed, Dec 05, 2001 at 11:56:28PM -0500 References: <3C0EFA7C.2B043C2B@nleaudio.com> Message-ID: <20011205230201.O20693@lenin.nu> I haven't looked at it, but I do wish I could play with it and perhaps try out a VERP implementation. Qmail, courier, and postfix all give the ability to send messages with VERPs and it would be nice if that feature could be used. On a relatively small list (a few hundred subscribers) that I've had on mailman for about a month I've already had road runner's MX's bounce me messages whose headers were completely scrambled. I was wishing that the recipient could have been encoded in the envelope-from while I was scratching my head trying to figure out who it was. I have a feeling that VERPs can be implemented in a way that they can work on any MTA. -Peter On Wed, Dec 05, 2001 at 11:56:28PM -0500, Bob Puff@NLE wrote: > 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 > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From claw@kanga.nu Thu Dec 6 07:17:08 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 05 Dec 2001 23:17:08 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: Message from "Peter C. Norton" of "Wed, 05 Dec 2001 23:02:01 PST." <20011205230201.O20693@lenin.nu> References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> Message-ID: <25404.1007623028@kanga.nu> On Wed, 5 Dec 2001 23:02:01 -0800 Peter C Norton wrote: > I have a feeling that VERPs can be implemented in a way that they > can work on any MTA. The problem isn't making them work with any MTA -- that's actually fairly trivial. The problem is keeping IO loads on the host reasonable with VERP with any MTA which is quite difficult. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From m.hubbard@ic.ac.uk Thu Dec 6 12:11:44 2001 From: m.hubbard@ic.ac.uk (Hubbard, Matt) Date: Thu, 6 Dec 2001 12:11:44 -0000 Subject: [Mailman-Developers] Virtual Hosting Implementation Message-ID: Hi, I'm looking at implementing the Virtual Hosting support as described in the relevant design notes on the Wiki. I would like to query the usefulness / necessity of having global lists. Surely from an implementation point of view, things would be far simpler if all hosted domains (including the "default") are managed in the same way as the virtual domains? In regard to directory layout, would it not be a good idea to place the lists, archives and "virtual domain site configuration" under one directory, rather than "./lists/vdomain/" etc. For instance: vhosts/python.org vhosts/python.org/site-config vhosts/python.org/lists/ vhosts/python.org/public_archive/ vhosts/python.org/private_archive/ vhosts/virtual.org vhosts/virtual.org/site-config .. etc... Cheers, Matt. From R.Barrett@ftel.co.uk Thu Dec 6 15:21:05 2001 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Thu, 06 Dec 2001 15:21:05 +0000 Subject: [Mailman-Developers] Amending list web_page_url attribute on Python2.1a3 Message-ID: <5.1.0.14.2.20011206150629.03758e28@pop.ftel.co.uk> I'm using MM 2.1a3 off sourceforge to redevelop my mailman-htdig integration patches; I'm work with the mailman-2.1a3.tgz download not from CVS. With MM 2.0.X amending a list's web_page_url attribute could be done directly at the bottom of the General admin page. With MM 2.1a3 the field at the bottom of the General admin page is now the host_name attribute. MM 2.1a3 admin page lets me change the host to for the list but I cannot see any way on the list admin pages to change the addressing scheme for the list, e.g from http to https. Have I missed something or am I reduce to using $prefix/bin/withlist? From jra@baylink.com Thu Dec 6 15:37:36 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 6 Dec 2001 10:37:36 -0500 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <25404.1007623028@kanga.nu>; from J C Lawrence on Wed, Dec 05, 2001 at 11:17:08PM -0800 References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> Message-ID: <20011206103736.28383@scfn.thpl.lib.fl.us> On Wed, Dec 05, 2001 at 11:17:08PM -0800, J C Lawrence wrote: > The problem isn't making them work with any MTA -- that's actually > fairly trivial. The problem is keeping IO loads on the host > reasonable with VERP with any MTA which is quite difficult. I don't see that there *is* any theoretical way to *keep* loads down with VERP, by it's very nature. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From spacey-mailman@lenin.nu Thu Dec 6 16:00:18 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Thu, 6 Dec 2001 08:00:18 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206103736.28383@scfn.thpl.lib.fl.us>; from jra@baylink.com on Thu, Dec 06, 2001 at 10:37:36AM -0500 References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> Message-ID: <20011206080018.G2123@lenin.nu> On Thu, Dec 06, 2001 at 10:37:36AM -0500, Jay R. Ashworth wrote: > On Wed, Dec 05, 2001 at 11:17:08PM -0800, J C Lawrence wrote: > > The problem isn't making them work with any MTA -- that's actually > > fairly trivial. The problem is keeping IO loads on the host > > reasonable with VERP with any MTA which is quite difficult. > > I don't see that there *is* any theoretical way to *keep* loads down > with VERP, by it's very nature. The only way to make the load a non-issue is to support VERPs in the MTA. I know qmail and courier support this. I wish that more MTA's did. Does anyone know if postfix, exim, or sendmail expect to support VERPs? -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From jra@baylink.com Thu Dec 6 16:03:18 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 6 Dec 2001 11:03:18 -0500 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206080018.G2123@lenin.nu>; from "Peter C. Norton" on Thu, Dec 06, 2001 at 08:00:18AM -0800 References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> <20011206080018.G2123@lenin.nu> Message-ID: <20011206110318.50750@scfn.thpl.lib.fl.us> On Thu, Dec 06, 2001 at 08:00:18AM -0800, Peter C. Norton wrote: > On Thu, Dec 06, 2001 at 10:37:36AM -0500, Jay R. Ashworth wrote: > > On Wed, Dec 05, 2001 at 11:17:08PM -0800, J C Lawrence wrote: > > > The problem isn't making them work with any MTA -- that's actually > > > fairly trivial. The problem is keeping IO loads on the host > > > reasonable with VERP with any MTA which is quite difficult. > > > > I don't see that there *is* any theoretical way to *keep* loads down > > with VERP, by it's very nature. > > The only way to make the load a non-issue is to support VERPs in the MTA. I > know qmail and courier support this. I wish that more MTA's did. Does > anyone know if postfix, exim, or sendmail expect to support VERPs? Yes, but he *did* say "IO Load". If I'm sending 100 copies to @aol.com, without VERP, I send the message once. With VERP, I have to send it 100 times. Right, JC? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From Nigel.Metheringham@dev.InTechnology.co.uk Thu Dec 6 16:15:59 2001 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 06 Dec 2001 16:15:59 +0000 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206110318.50750@scfn.thpl.lib.fl.us> References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> <20011206080018.G2123@lenin.nu> <20011206110318.50750@scfn.thpl.lib.fl.us> Message-ID: <1007655359.7077.9.camel@gaspode.localnet> On Thu, Dec 06, 2001 at 08:00:18AM -0800, Peter C. Norton wrote: > The only way to make the load a non-issue is to support VERPs in the MTA. I > know qmail and courier support this. I wish that more MTA's did. Does > anyone know if postfix, exim, or sendmail expect to support VERPs? Exim will support VERP if you configure it right. Support has been in exim for a long time, but to tell you the truth I know of *noone* actually using it. In the thread on 2.1 and MTA interfaces a couple of weeks back I sketched out a config for exim which would trivially handle VERPing. Its untested since the infrastructure I was proposing to support it isn't there either :-) Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From tollef@add.no Thu Dec 6 16:41:25 2001 From: tollef@add.no (Tollef Fog Heen) Date: 06 Dec 2001 17:41:25 +0100 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206080018.G2123@lenin.nu> References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> <20011206080018.G2123@lenin.nu> Message-ID: <87n10w8fnu.fsf@arabella.intern.opera.no> * "Peter C. Norton" | The only way to make the load a non-issue is to support VERPs in the MTA. I | know qmail and courier support this. I wish that more MTA's did. Does | anyone know if postfix, exim, or sendmail expect to support VERPs? After a quick googling, it seems like Postfix supports VERP just fine, at least http://www.postfix.org/smtpd.8.html says: default_verp_delimiters The default VERP delimiter characters that are used when the XVERP command is specified without explicit delimiters. [snip] verp_delimiter_filter The characters that Postfix accepts as VERP delim- iter characters. -- Tollef Fog Heen Axiom #1: You Can't Win From chuqui@plaidworks.com Thu Dec 6 16:45:38 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 06 Dec 2001 08:45:38 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206110318.50750@scfn.thpl.lib.fl.us> Message-ID: On 12/6/01 8:03 AM, "Jay R. Ashworth" wrote: > If I'm sending 100 copies to @aol.com, without VERP, I send the message > once. Not true. You send it 100/SMTP_MAX_RCPTS times (rounded up, of course). So if your SMTP_MAX_RCPTS is set to ten, you send it ten times. > With VERP, I have to send it 100 times. Unless the MTA does the VERP for you, but in the scheme of things, I think we look at the wrong solution if we only look at VERP. It solves a problem, but not the entire class of problems -- instead of thinking VERP, think about per-user custom e-mail, since you not only can put in the stuff VERP does, but also a lot of good user-experience stuff, like a url that takes the user to the listinfo page AND brings up his user record in one click. When you start looking beyond 'just' VERP to what you can do to improve mail lsits for the end user, especially the less technical ones, it starts being a lot more interesting. And once you start adding in this functionality, you can bring along VERP basically for free, whether or not you use a VERP-capable MTA. FWIW... From jra@baylink.com Thu Dec 6 16:48:50 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 6 Dec 2001 11:48:50 -0500 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: ; from Chuq Von Rospach on Thu, Dec 06, 2001 at 08:45:38AM -0800 References: <20011206110318.50750@scfn.thpl.lib.fl.us> Message-ID: <20011206114850.14205@scfn.thpl.lib.fl.us> On Thu, Dec 06, 2001 at 08:45:38AM -0800, Chuq Von Rospach wrote: > > If I'm sending 100 copies to @aol.com, without VERP, I send the message > > once. > > Not true. You send it 100/SMTP_MAX_RCPTS times (rounded up, of course). So > if your SMTP_MAX_RCPTS is set to ten, you send it ten times. Right, of course... > > With VERP, I have to send it 100 times. > > Unless the MTA does the VERP for you, Well, see, here's the thing. That *still* doesn't unload the *wire*, just the MLM. > but in the scheme of things, I think > we look at the wrong solution if we only look at VERP. It solves a problem, > but not the entire class of problems -- instead of thinking VERP, think > about per-user custom e-mail, since you not only can put in the stuff VERP > does, but also a lot of good user-experience stuff, like a url that takes > the user to the listinfo page AND brings up his user record in one click. > > When you start looking beyond 'just' VERP to what you can do to improve mail > lsits for the end user, especially the less technical ones, it starts being > a lot more interesting. And once you start adding in this functionality, you > can bring along VERP basically for free, whether or not you use a > VERP-capable MTA. At the expense of loading the wire, the MTA, *and* the MLM. How big are your lists, Chuq? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From marc_news@valinux.com Thu Dec 6 16:58:37 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Thu, 6 Dec 2001 08:58:37 -0800 Subject: [Mailman-Developers] New FAQ entry: broken autoresponders In-Reply-To: <1007459198.2395.4.camel@gaspode.localnet>; from Nigel.Metheringham@VData.co.uk on Tue, Dec 04, 2001 at 09:46:38AM +0000 References: <20011203141642.A2745@mems-exchange.org> <1007459198.2395.4.camel@gaspode.localnet> Message-ID: <20011206085836.H14509@magic.merlins.org> On Tue, Dec 04, 2001 at 09:46:38AM +0000, Nigel Metheringham wrote: > On Mon, 2001-12-03 at 19:16, Greg Ward wrote: > > 3.6. What can I do about users with broken autoresponders? > > > > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.006.htp > > I'm impressed - an answer to this question which doesn't involve dark > threats and/or baseball bats. But then, it can't be the right answer :-) More seriously, well written document Greg, kudos BTW, if you want to use anything from http://marc.merlins.org/netrants/autoresponders.txt feel free to do so. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From spacey-mailman@lenin.nu Thu Dec 6 17:44:07 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Thu, 6 Dec 2001 09:44:07 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206114850.14205@scfn.thpl.lib.fl.us>; from jra@baylink.com on Thu, Dec 06, 2001 at 11:48:50AM -0500 References: <20011206110318.50750@scfn.thpl.lib.fl.us> <20011206114850.14205@scfn.thpl.lib.fl.us> Message-ID: <20011206094407.L2123@lenin.nu> On Thu, Dec 06, 2001 at 11:48:50AM -0500, Jay R. Ashworth wrote: > > > With VERP, I have to send it 100 times. > > > > Unless the MTA does the VERP for you, > > Well, see, here's the thing. That *still* doesn't unload the *wire*, > just the MLM. It also unloads the disk. The wire is rarely where you need to save time. I've seen a single mailhost with over a million messages queued empty out overnight over a t1. The biggest delays had nothing to do with mail traffic over the wire. > > When you start looking beyond 'just' VERP to what you can do to improve mail > > lsits for the end user, especially the less technical ones, it starts being > > a lot more interesting. And once you start adding in this functionality, you > > can bring along VERP basically for free, whether or not you use a > > VERP-capable MTA. > > At the expense of loading the wire, the MTA, *and* the MLM. > > How big are your lists, Chuq? :-) Again, I don't think the wire is usually an issue. The MTA could be isolated to a special output channel that is just for "more-then-verp" processes, so the MTA in general wouldn't be loaded, just the M-T-V process and pipeline. So, to speculate, a sensible MTA puts metadata in a seperate file. To do M-T-V you'd only have to can a message once in the queue, and if the M-T-V flag is set then scan the file for replacement strings (I think it'd be appropriate to have a flag, or a seperate process since mangling content in the message is a bad thing to do most of the time). One of the inputs for the M-T-V message->queue program should be a list of replacement strings, with some specially reserved strings (like for VERP). The M-T-V inputter should then record in the metadata the offset of each replacement, and the string or command that would replace it. This is sounding more and more like a mass-mailing program, eh? So each recipient, instead of being an rfc822/2822 address would be a delimited string with an 822 address, and replacement string 1, 2, 3, etc... and in the body of the message would be a special character (say %1%, %2%, etc) that would be subjected to positional replacement. The re-writing would be done on the way out to the remote host, and it would be pretty cheap to implement at this phase. Is this about the right idea? -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From chuqui@plaidworks.com Thu Dec 6 18:14:42 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 06 Dec 2001 10:14:42 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206114850.14205@scfn.thpl.lib.fl.us> Message-ID: On 12/6/01 8:48 AM, "Jay R. Ashworth" wrote: > At the expense of loading the wire, the MTA, *and* the MLM. > > How big are your lists, Chuq? :-) Last time I looked my mailman-system delivers about 12 million pieces of email a week, more or less. My big list server is custom coded, not mailman, but I'm not allowed to discuss numbers on it. And one of my upcoming projects is to do exactly what I suggested for it. My biggest problem right now is I'm saturating my ethernet. We've been experimenting with a quad 100bt on it, but after the holidays, we'll be installing the first set of what I'm now calling my smurf army, which eventually will be a bunch of smaller machines that only do delivery. Trying to incrementally improve delivery of a single big machine hits expense issues -- you start spending more and more for smaller and smaller improvements, so we're moving to the small-many model... From chuqui@plaidworks.com Thu Dec 6 18:22:29 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 06 Dec 2001 10:22:29 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206094407.L2123@lenin.nu> Message-ID: On 12/6/01 9:44 AM, "Peter C. Norton" wrote: >> At the expense of loading the wire, the MTA, *and* the MLM. >> >> How big are your lists, Chuq? :-) > > Again, I don't think the wire is usually an issue. It is on my machine, but you don't want to know how much work we've done into getting the disk I/O under control. And to be honest, I bet if I put even more disks, or a ram-based disk system on it, I'd speed it up another 20-30%, but it gets more and more expensive for less and less gain. I expect to lose some performance going to the one-per-address customized format, which is one reason why I'm going ot the army of smurfs -- but we feel strongly it's great for the subscriber and gives us some nice usage advantages, and besides, that system was originally designed to delivery about 250,000 addresses and hour, and it's now doing about 600K, so I have some slop before I fall below my performance metrics... (and that's using sendmail. I expect once I get comfortable with postfix and migrate my sites to it, it'll get better) > So, to speculate, a sensible MTA puts metadata in a seperate file. > The re-writing would be done on the way out to the remote host, and it would > be pretty cheap to implement at this phase. > > Is this about the right idea? If you're going to go that way, cut the MTA completely out of the loop. Simply write a delivery agent that writes directly out to the receiver's SMTP port, so it never actually touches disk unless the first delivery attempt fails for some reason (if it does, stuff it in a standard MTA and let it worry about redeliveries, unless you want to keep lots of state around). I've done some noodling on doing something like this, and if you do it right (it's a fair amount of work), you can really do some fun stuff, because you're literally writing the message on the fly out the wire. But ti's not worth it except for customized, high-volume operations. For 99% of mailman installations, it'd be hoplessly overkill technology, even if you want customized messages. From spacey-mailman@lenin.nu Thu Dec 6 18:33:30 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Thu, 6 Dec 2001 10:33:30 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: ; from chuqui@plaidworks.com on Thu, Dec 06, 2001 at 10:22:29AM -0800 References: <20011206094407.L2123@lenin.nu> Message-ID: <20011206103330.R2123@lenin.nu> On Thu, Dec 06, 2001 at 10:22:29AM -0800, Chuq Von Rospach wrote: > I said [ that is, "Peter C. Norton" ] > > So, to speculate, a sensible MTA puts metadata in a seperate file. > > > The re-writing would be done on the way out to the remote host, and it would > > be pretty cheap to implement at this phase. > > > > Is this about the right idea? > > If you're going to go that way, cut the MTA completely out of the loop. > Simply write a delivery agent that writes directly out to the receiver's > SMTP port, so it never actually touches disk unless the first delivery > attempt fails for some reason (if it does, stuff it in a standard MTA and > let it worry about redeliveries, unless you want to keep lots of state > around). I've done some noodling on doing something like this, and if you do > it right (it's a fair amount of work), you can really do some fun stuff, > because you're literally writing the message on the fly out the wire. It could be written as a before-the MTA, never-enque model, but it seems like the design of courier and postfix make wedging in output modules relatively easy. Certianly easier then writing everything myself, and they do all the work. > But ti's not worth it except for customized, high-volume operations. For 99% > of mailman installations, it'd be hoplessly overkill technology, even if you > want customized messages. Definetely the high-volume impelmentation is overkill. But the re-writing engine would be valuable for any mailing list manager. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From chuqui@plaidworks.com Thu Dec 6 19:04:09 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 06 Dec 2001 11:04:09 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <20011206103330.R2123@lenin.nu> Message-ID: On 12/6/01 10:33 AM, "Peter C. Norton" wrote: >> around). I've done some noodling on doing something like this, and if you do >> it right (it's a fair amount of work), you can really do some fun stuff, >> because you're literally writing the message on the fly out the wire. > > It could be written as a before-the MTA, never-enque model, but it seems > like the design of courier and postfix make wedging in output modules > relatively easy. Certianly easier then writing everything myself, and they > do all the work. Exactly. When you take something like postfix or sendmail and throw it out, you are, (ta da!) writing a replacement. Now, in the case of something like this, what you're really doing is keeping the MTA around to do most of the grunt work (like incoming mail and retrying failed mail), but still -- you have to write a fair amount of code to replace the code you're tossing out. For almost all environments, it ain't worth it. But for those off-the-edge sites, you can get some serious gains by doing it, at the cost of a fair chunk o' code and engineering. When you start looking at just the issue of resolving and dealign with MX issues, you start seeing code bloat, and if you read the Postfix list, you find you run into huge amounts of fun sending mail to servers that don't quite work to standard (or at all). To some degree, you can choose to let those transactions fail and retry through the MTA, but... It gets gnarly, fast. > Definetely the high-volume impelmentation is overkill. But the re-writing > engine would be valuable for any mailing list manager. Yes, it would be. And it's actually not that difficult to add, at least conceptually. Mailman, in fact, already does some swapping of system variables into header templates. It's not that tough to extend the number of variables it knows about (and then extend that to allow for per-user data) and extend the global search/replace to include the entire message. Then you 'simply' set up your messages to include template variables that get updated as you send things out... In practice, it's not quite one paragraph of text to do, but the underlying system's not that bad. From claw@kanga.nu Thu Dec 6 21:32:20 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 06 Dec 2001 13:32:20 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: Message from "Jay R. Ashworth" of "Thu, 06 Dec 2001 10:37:36 EST." <20011206103736.28383@scfn.thpl.lib.fl.us> References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> Message-ID: <15983.1007674340@kanga.nu> On Thu, 6 Dec 2001 10:37:36 -0500 Jay R Ashworth wrote: > I don't see that there *is* any theoretical way to *keep* loads > down with VERP, by it's very nature. External IO, yes, disk IO, no. QMail allows you to initiate a single spool file with a list of addresses to VERP against, and from there every message is delivered individually. This cuts local disk IO, the ultimate constraining performance factor, drastically. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Thu Dec 6 21:44:05 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 06 Dec 2001 13:44:05 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: Message from "Peter C. Norton" of "Thu, 06 Dec 2001 09:44:07 PST." <20011206094407.L2123@lenin.nu> References: <20011206110318.50750@scfn.thpl.lib.fl.us> <20011206114850.14205@scfn.thpl.lib.fl.us> <20011206094407.L2123@lenin.nu> Message-ID: <16182.1007675045@kanga.nu> On Thu, 6 Dec 2001 09:44:07 -0800 Peter C Norton wrote: > It also unloads the disk. The wire is rarely where you need to > save time. I've seen a single mailhost with over a million > messages queued empty out overnight over a t1. The biggest delays > had nothing to do with mail traffic over the wire. ObStats: Running Postfix on a mostly unloaded and minimally tuned box with a T3 tier II connection I've repeatedly seen sustained mail delivery rates of 1,500 messages per minute (fairly flat MX distribution; AOL/MSN/Hotman together are less than 3% of the base). I've also seen occasional peaks over 3,200 messages per minute, but I've never sustained that sort of transfer rate (not enough mail traffic). Not great, not too shabby. Now, would you mind NOT setting a personal Mail-FollowUp-To? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From chuqui@plaidworks.com Thu Dec 6 21:45:03 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 06 Dec 2001 13:45:03 -0800 Subject: [Mailman-Developers] Quick script to update footers sitewide? Message-ID: Anyone got a quick script handy I can use to update configuration data for all lists? I want to tweak my headers and footers. I know I want ot use with_list, but I've never done it. Anyone got a script handy I can borrow/tweak and put on the FAQ? From tneff@bigfoot.com Thu Dec 6 21:59:50 2001 From: tneff@bigfoot.com (tneff@bigfoot.com) Date: Thu, 06 Dec 2001 16:59:50 -0500 Subject: [Mailman-Developers] Re: Theoretical way to minimize IO load with MTA supported VERP In-Reply-To: References: Message-ID: <2340493578.1007657990@t283742ghzz> "Jay R. Ashworth" wrote: > I don't see that there *is* any theoretical way to *keep* loads down > with VERP, by it's very nature. ... > If I'm sending 100 copies to @aol.com, without VERP, I send the message > once. > > With VERP, I have to send it 100 times. If one was willing to extend SMTP again, it would be theoretically possible to send one copy of a message to aol.com for 100 recipients with a form of VERP, using an extended syntax like MAIL FROM:mylist-owner@mydomain.com 250 mylist-owner@mydomain.com... Sender ok RCPT TO:johnsmith@aol.com EPFX:johnsmith-aol.com- 250 johnsmith@aol.com... Recipient ok RCPT TO:joerandom@aol.com EPFX:joerandom-aol.com- 250 joerandom@aol.com... Recipient ok DATA and the receiving MTA would prepend the EPFX value to the envelope sender for each recipient. From peterw@usa.net Thu Dec 6 22:35:24 2001 From: peterw@usa.net (Peter W) Date: Thu, 6 Dec 2001 17:35:24 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: <2340493578.1007657990@t283742ghzz>; from tneff@bigfoot.com on Thu, Dec 06, 2001 at 04:59:50PM -0500 References: <2340493578.1007657990@t283742ghzz> Message-ID: <20011206173524.A25983@usa.net> On Thu, Dec 06, 2001 at 04:59:50PM -0500, tneff@bigfoot.com wrote: > If one was willing to extend SMTP again, it would be theoretically possible > to send one copy of a message to aol.com for 100 recipients with a form of > VERP, using an extended syntax like > > MAIL FROM:mylist-owner@mydomain.com > 250 mylist-owner@mydomain.com... Sender ok > RCPT TO:johnsmith@aol.com EPFX:johnsmith-aol.com- > 250 johnsmith@aol.com... Recipient ok > and the receiving MTA would prepend the EPFX value to the envelope sender > for each recipient. I like the basic idea a lot, but that doesn't look very backwards compatible, though. Why not something like MAIL FROM: mylist-owner@mydomain.com 250 mylist-owner@mydomain.com... Sender ok RCPT TO: johnsmith@aol.com 250 johnsmith@aol.com... Recipient ok OVRD "MAIL FROM: johnsmith-aol.com-mylist-owner@mydomain.com" 250 per-recipient override of "MAIL" ok DATA i.e., a new SMTP command, not a change in existing rules. The sending MTA, if it got an error in response to OVRD, could flag that SMTP connection as being OVRD-incompatible, issue a NOOP, and procede to either give on message efficiently w/o VERP, or several messsages with VERP using the old-style, bandwidth-hogging (current) technique. The NOOP-backout technique appears to be fully compatible with the SMTP RFC. Issuing a NOOP means the sender would not have to be concerened with whether the recipient MTA does not like messages sent with unrecognized control commands. 100% backwards compatible. If VERP is the only real case where per-recipient overrides make sense, then it might make more sense to make a simple VERP command, e.g. VERP johnsmith-aol.com-mylist-owner@mydomain.com -Peter -- I am what I am 'cause I ain't what I used to be. - S Bruton & J Fleming From tneff@bigfoot.com Thu Dec 6 22:43:15 2001 From: tneff@bigfoot.com (tneff@bigfoot.com) Date: Thu, 06 Dec 2001 17:43:15 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: <20011206173524.A25983@usa.net> References: <20011206173524.A25983@usa.net> Message-ID: <2343098343.1007660595@t283742ghzz> --On Thursday, December 06, 2001 5:35 PM -0500 Peter W wrote: > I like the basic idea a lot, but that doesn't look very backwards > compatible, though. Why not something like > MAIL FROM: mylist-owner@mydomain.com > 250 mylist-owner@mydomain.com... Sender ok > RCPT TO: johnsmith@aol.com > 250 johnsmith@aol.com... Recipient ok > OVRD "MAIL FROM: johnsmith-aol.com-mylist-owner@mydomain.com" > 250 per-recipient override of "MAIL" ok > DATA > > i.e., a new SMTP command, not a change in existing rules. I guess I was a little afraid that MTA's would get lost matching up separately-issued RCPT TO: and OVRD commands that were supposed to function as logical pairs. I think that the ESMTP syntax would not be gravely injured by adding another whitespace-separated atom after the TO: and address, but I might be wrong. Another approach would be to add a VERP "mode" with a single command: VERP ON 250 Variable envelope mode ok so that subsequently saying MAIL FROM: mylist-owner@mydomain.com and then RCPT TO: johnsmith@aol.com would automatically ensure that the envelope sender for that message would be transformed according to a well-known rule, e.g. johnsmith-aol.com-mylist-owner@mydomain.com I think this would do the least violence overall because if VERP isn't supported, no big deal, and the dialog syntax doesn't change in any other way. From mailman-developers@python.org Thu Dec 6 23:00:15 2001 From: mailman-developers@python.org (Peter W) Date: Thu, 6 Dec 2001 18:00:15 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: <2343098343.1007660595@t283742ghzz>; from tneff@bigfoot.com on Thu, Dec 06, 2001 at 05:43:15PM -0500 References: <20011206173524.A25983@usa.net> <2343098343.1007660595@t283742ghzz> Message-ID: <20011206180015.A26609@usa.net> On Thu, Dec 06, 2001 at 05:43:15PM -0500, tneff@bigfoot.com wrote: > --On Thursday, December 06, 2001 5:35 PM -0500 Peter W > wrote: > > I like the basic idea a lot, but that doesn't look very backwards > > compatible, though. Why not something like > > RCPT TO: johnsmith@aol.com > > 250 johnsmith@aol.com... Recipient ok > > OVRD "MAIL FROM: johnsmith-aol.com-mylist-owner@mydomain.com" > I guess I was a little afraid that MTA's would get lost matching up > separately-issued RCPT TO: and OVRD commands that were supposed to function > as logical pairs. Yes, that makes sense. But couldn't that be clarified in the new RFC/draft? > I think that the ESMTP syntax would not be gravely > injured by adding another whitespace-separated atom after the TO: and > address, but I might be wrong. Well, existing MTAs don't like it. sendmail says: RCPT TO: VERP: other-string-here 555 5.5.4 VERP parameter unrecognized and I'd rather ask smtpd coders to add something new than extend something as critical as RCPT. > Another approach would be to add a VERP "mode" with a single command: > > VERP ON > would automatically ensure that the envelope sender for that message would > be transformed according to a well-known rule, e.g. > > johnsmith-aol.com-mylist-owner@mydomain.com > > I think this would do the least violence overall because if VERP isn't > supported, no big deal, and the dialog syntax doesn't change in any other > way. A couple problems I see with that: 1) MTAs would have to be 100% uniform in the way they constructed VERP return paths, or apps like mailman would not be able to use them 2) this takes aways some flexibility from the sending MTA, which currently has the flexibility to deal with VERP in arbitrarily complex ways. For instance, a sending MTA might use a hash routine and shared secret to construct a return path like johnsmith-aol.com-1007679391-351810f710b71cd6c44181f04c30dabd-mylist-owner@mydomain.com so that any returned messages can be cryptographically verified before being passed to mailman (I could be off-base here, but I'm guessing/fearing that a miscreant could spoof some VERP bounces to a mailman server and make mailman remove someone improperly) -Peter -- I am what I am 'cause I ain't what I used to be. - S Bruton & J Fleming From Dan Mick Thu Dec 6 23:40:52 2001 From: Dan Mick (Dan Mick) Date: Thu, 6 Dec 2001 15:40:52 -0800 (PST) Subject: [Mailman-Developers] FWIW: Postfix does VERP Message-ID: <200112062341.PAA24153@utopia.West.Sun.COM> At least as of the snapshot I'm running, 20010714, postfix does VERP just as you'd expect, merely by adding -V to the "sendmail" invocation. (It works with multiple addresses, too.) Hmmm; maybe it's time to play around with Sendmail.py again. There seems to be no way to invoke such behavior through an SMTP connection (not surprisingly). From Dan Mick Thu Dec 6 23:55:30 2001 From: Dan Mick (Dan Mick) Date: Thu, 6 Dec 2001 15:55:30 -0800 (PST) Subject: [Mailman-Developers] FWIW: Postfix does VERP Message-ID: <200112062355.PAA25137@utopia.West.Sun.COM> > At least as of the snapshot I'm running, 20010714, postfix does VERP just > as you'd expect, merely by adding -V to the "sendmail" invocation. > (It works with multiple addresses, too.) Hmmm; maybe it's time to > play around with Sendmail.py again. > > There seems to be no way to invoke such behavior through an > SMTP connection (not surprisingly). I lied: EHLO reports that XVERP is an optional command, and indeed MAIL FROM: XVERP is legal and generates a VERPed address. Hmm. Maybe this SMTP extension is already "defined". Sure looks like one could hack SMTPDirect.py to use it. Hmm, hmm, hmm. From Dan Mick Fri Dec 7 00:20:52 2001 From: Dan Mick (Dan Mick) Date: Thu, 6 Dec 2001 16:20:52 -0800 (PST) Subject: [Mailman-Developers] FWIW: Postfix does VERP Message-ID: <200112070021.QAA26146@utopia.West.Sun.COM> > > At least as of the snapshot I'm running, 20010714, postfix does VERP just > > as you'd expect, merely by adding -V to the "sendmail" invocation. > > (It works with multiple addresses, too.) Hmmm; maybe it's time to > > play around with Sendmail.py again. > > > > There seems to be no way to invoke such behavior through an > > SMTP connection (not surprisingly). > > I lied: EHLO reports that XVERP is an optional command, and indeed > MAIL FROM: XVERP is legal and generates a VERPed address. > > Hmm. Maybe this SMTP extension is already "defined". Sure looks > like one could hack SMTPDirect.py to use it. > > Hmm, hmm, hmm. At least Courier and Postfix seem to implement this extension. http://courier.sourceforge.net/intro.html http://www.postfix.org continuing 'hmm'-ing. From jra@baylink.com Fri Dec 7 01:42:44 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 6 Dec 2001 20:42:44 -0500 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <15983.1007674340@kanga.nu>; from J C Lawrence on Thu, Dec 06, 2001 at 01:32:20PM -0800 References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> <15983.1007674340@kanga.nu> Message-ID: <20011206204244.07444@scfn.thpl.lib.fl.us> On Thu, Dec 06, 2001 at 01:32:20PM -0800, J C Lawrence wrote: > On Thu, 6 Dec 2001 10:37:36 -0500 > Jay R Ashworth wrote: > > I don't see that there *is* any theoretical way to *keep* loads > > down with VERP, by it's very nature. > > External IO, yes, disk IO, no. QMail allows you to initiate a > single spool file with a list of addresses to VERP against, and from > there every message is delivered individually. This cuts local disk > IO, the ultimate constraining performance factor, drastically. Except that, as was noted earlier, Chuq's problem *is* his wires. :-) Cheers, - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From tneff@bigfoot.com Fri Dec 7 01:54:46 2001 From: tneff@bigfoot.com (Tom Neff) Date: Thu, 06 Dec 2001 20:54:46 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: References: Message-ID: <85901234.1007672085@[192.168.1.101]> Peter W wrote: >> I guess I was a little afraid that MTA's would get lost matching up >> separately-issued RCPT TO: and OVRD commands that were supposed to >> function as logical pairs. > > Yes, that makes sense. But couldn't that be clarified in the new > RFC/draft? yes, it might even be obeyed :) but yes. > A couple problems I see with that: > > 1) MTAs would have to be 100% uniform in the way they constructed > VERP return paths, or apps like mailman would not be able to use them > > 2) this takes aways some flexibility from the sending MTA, which > currently has the flexibility to deal with VERP in arbitrarily > complex ways... Okay, I agree, your way is better. Let's make it as simple as possible: HELO shrek.org 250 smtp.aol.com Hello shrek.org [123.45.6.7], glad to see you. MAIL FROM:news@shrek.org 250 news@shrek.org... Sender ok RCPT TO:ogre@aol.com 250 ogre@aol.com... Recipient ok VERP FROM:ogre-aol.com-1007679391-1f04c30dabd-news@shrek.org 250 ogre-aol.com-1007679391-1f04c30dabd-news@shrek.org... Sender ok RCPT TO:witch@aol.com 250 witch@aol.com... Recipient ok VERP FROM:witch-aol.com-1007679391-297c0dd13a3-news@shrek.org 250 witch-aol.com-1007679391-297c0dd13a3-news@shrek.org... Sender ok DATA From Dan Mick Fri Dec 7 02:00:52 2001 From: Dan Mick (Dan Mick) Date: Thu, 6 Dec 2001 18:00:52 -0800 (PST) Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP Message-ID: <200112070201.SAA00466@utopia.West.Sun.COM> > Okay, I agree, your way is better. Let's make it as simple as possible: > > HELO shrek.org > 250 smtp.aol.com Hello shrek.org [123.45.6.7], glad to see you. > MAIL FROM:news@shrek.org > 250 news@shrek.org... Sender ok > RCPT TO:ogre@aol.com > 250 ogre@aol.com... Recipient ok > VERP FROM:ogre-aol.com-1007679391-1f04c30dabd-news@shrek.org > 250 ogre-aol.com-1007679391-1f04c30dabd-news@shrek.org... Sender ok > RCPT TO:witch@aol.com > 250 witch@aol.com... Recipient ok > VERP FROM:witch-aol.com-1007679391-297c0dd13a3-news@shrek.org > 250 witch-aol.com-1007679391-297c0dd13a3-news@shrek.org... Sender ok > DATA The way it's already implemented in Postfix is: MAIL FROM: sender@sender.dom XVERP everything else is as normal, but the envelopes get VERPed. From claw@kanga.nu Fri Dec 7 02:15:21 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 06 Dec 2001 18:15:21 -0800 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: Message from "Jay R. Ashworth" of "Thu, 06 Dec 2001 20:42:44 EST." <20011206204244.07444@scfn.thpl.lib.fl.us> References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> <15983.1007674340@kanga.nu> <20011206204244.07444@scfn.thpl.lib.fl.us> Message-ID: <22291.1007691321@kanga.nu> On Thu, 6 Dec 2001 20:42:44 -0500 Jay R Ashworth wrote: > On Thu, Dec 06, 2001 at 01:32:20PM -0800, J C Lawrence wrote: >> On Thu, 6 Dec 2001 10:37:36 -0500 Jay R Ashworth >> External IO, yes, disk IO, no. QMail allows you to initiate a >> single spool file with a list of addresses to VERP against, and >> from there every message is delivered individually. This cuts >> local disk IO, the ultimate constraining performance factor, >> drastically. > Except that, as was noted earlier, Chuq's problem *is* his wires. > :-) Umm, those are his wires within his network, not the wires to the great untapped 'network at large. Yeesh. MTAs are fundamentally disk IO bound. No two ways about it. Not much you can do about it either, not without violating the commit semantics of the protocol. Chuq speaks better for himself than I do. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Fri Dec 7 02:16:27 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 06 Dec 2001 18:16:27 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: Message from Dan Mick of "Thu, 06 Dec 2001 18:00:52 PST." <200112070201.SAA00466@utopia.West.Sun.COM> References: <200112070201.SAA00466@utopia.West.Sun.COM> Message-ID: <22305.1007691387@kanga.nu> On Thu, 6 Dec 2001 18:00:52 -0800 (PST) Dan Mick wrote: > MAIL FROM: sender@sender.dom XVERP Cheap prediction: Mailman is going to end up with a set of MTA-specific and internally configurable VERP configurations to chose from. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Fri Dec 7 03:14:35 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 6 Dec 2001 22:14:35 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> Message-ID: <15376.13339.661615.544307@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Mailman is going to end up with a set of MTA-specific and JCL> internally configurable VERP configurations to chose from. I actually don't think that MTA-directed VERPing helps us out much. Sure, it can give us an envelope sender that we can use for better bounce detection[*], but I think that the much more interesting personalization is content personalization. I.e. inserting into the message body, footers, headers, RFC 2822 headers, etc. information specific to the recipient. Only Mailman knows that data and how to interpolate it into the message body. AFAIK, there's no way to coordinate this with the MTA, so content personalization is always going to be performed by Mailman. The VERP-like approach in MM2.1 toward the envelope sender is mostly just gravy. (I try to be careful to describe it as VERP-like since it isn't technically VERP.) BTW, see VERP_REGEXP and VERP_FORMAT for how the envelope sender is composed and parsed. -Barry [*] VERP helps with knowing exactly which address on which list is bouncing, but I don't think it helps much with knowing the severity of the bounce. From spacey-mailman@lenin.nu Fri Dec 7 03:53:24 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Thu, 6 Dec 2001 19:53:24 -0800 Subject: [Mailman-Developers] Re: Theoretical way to minimize IO load with MTA supported VERP In-Reply-To: <2340493578.1007657990@t283742ghzz>; from tneff@bigfoot.com on Thu, Dec 06, 2001 at 04:59:50PM -0500 References: <2340493578.1007657990@t283742ghzz> Message-ID: <20011206195324.C31902@lenin.nu> Yeah, reading the courier docs mrsam has implemented something like that. It is a good idea. -Peter On Thu, Dec 06, 2001 at 04:59:50PM -0500, tneff@bigfoot.com wrote: > If one was willing to extend SMTP again, it would be theoretically possible > to send one copy of a message to aol.com for 100 recipients with a form of > VERP, using an extended syntax like > > MAIL FROM:mylist-owner@mydomain.com > 250 mylist-owner@mydomain.com... Sender ok > RCPT TO:johnsmith@aol.com EPFX:johnsmith-aol.com- > 250 johnsmith@aol.com... Recipient ok > RCPT TO:joerandom@aol.com EPFX:joerandom-aol.com- > 250 joerandom@aol.com... Recipient ok > DATA > > and the receiving MTA would prepend the EPFX value to the envelope sender > for each recipient. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From spacey-mailman@lenin.nu Fri Dec 7 03:57:59 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Thu, 6 Dec 2001 19:57:59 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: <15376.13339.661615.544307@anthem.wooz.org>; from barry@zope.com on Thu, Dec 06, 2001 at 10:14:35PM -0500 References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> Message-ID: <20011206195759.D31902@lenin.nu> On Thu, Dec 06, 2001 at 10:14:35PM -0500, Barry A. Warsaw wrote: > [*] VERP helps with knowing exactly which address on which list is > bouncing, but I don't think it helps much with knowing the severity of > the bounce. Sure, but the beauty is that there's almost no way that a broken MTA can bounce in such a way as to not know where the message went. Autoresponders, on the other hand, suck rocks through straws. So you can afford to handle a lot more bounces, and implement an ezmlm-like probe when it gets critical, all in the certianty that you're (a) not bouncing messages to the list admins that they have to read and (b) if you miss any messages over a long time you can reset your counter and let the user know what they've missed. These are 2 really nice ezmlm features... -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From barry@zope.com Fri Dec 7 04:18:57 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 6 Dec 2001 23:18:57 -0500 Subject: [Mailman-Developers] Quick script to update footers sitewide? References: Message-ID: <15376.17201.952757.206056@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Anyone got a quick script handy I can use to update CVR> configuration data for all lists? I want to tweak my headers CVR> and footers. I know I want ot use with_list, but I've never CVR> done it. withlist is really mostly geared for operations on single lists (maybe it should be elaborated). But it's easy enough to write a one off. Let's say you want to append "Chuq's List" to the end of every footer. Something like this ought to do it (untested -- and perhaps Py2.x and MM2.1-ish). -------------------- snip snip --------------------bin/chuq.py import paths from Mailman import Utils from Mailman.MailList import MailList for listname in Utils.list_names(): # Block until you acquire the list lock mlist = MailList(listname) try: mlist.msg_footer += "\nChuq's List" mlist.Save() finally: mlist.Unlock() -------------------- snip snip -------------------- % cd /path/to/mailman/install % python bin/chuq.py Cook to taste. -Barry From barry@zope.com Fri Dec 7 04:32:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 6 Dec 2001 23:32:17 -0500 Subject: [Mailman-Developers] Amending list web_page_url attribute on Python2.1a3 References: <5.1.0.14.2.20011206150629.03758e28@pop.ftel.co.uk> Message-ID: <15376.18001.322595.528993@anthem.wooz.org> >>>>> "RB" == Richard Barrett writes: RB> MM 2.1a3 admin page lets me change the host to for the list RB> but I cannot see any way on the list admin pages to change the RB> addressing scheme for the list, e.g from http to https. RB> Have I missed something or am I reduce to using RB> $prefix/bin/withlist? Yes, because too many list admins f*cked up their lists by typing an incorrect or unreachable url prefix there. The best way to solve this globally is to set mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.DEFAULT_URL_HOST to whatever you want (e.g. http -> https). All newly created lists after this change will simply inherit these new values. To fix existing lists, use withlist and fix_url.py (this latter is in cvs; I'm not sure if it made it to alpha3). % bin/withlist -r fix_url -l mylist -Barry From barry@zope.com Fri Dec 7 04:40:37 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 6 Dec 2001 23:40:37 -0500 Subject: [Mailman-Developers] Re: [Mailman-Users] Bounce Options References: <3C097C57.B8530489@nleaudio.com> Message-ID: <15376.18501.281299.826971@anthem.wooz.org> This makes some sense. I'll try to put all the ideas together and implement some code. I'll make it as modular as possible so we can swap in different logic if we find the algorithm has flaws. I'll concentrate on that tomorrow night. Right now, sleep. :) -Barry From claw@kanga.nu Fri Dec 7 05:02:02 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 06 Dec 2001 21:02:02 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Thu, 06 Dec 2001 22:14:35 EST." <15376.13339.661615.544307@anthem.wooz.org> References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> Message-ID: <25825.1007701322@kanga.nu> On Thu, 6 Dec 2001 22:14:35 -0500 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Mailman is going to end up with a set of MTA-specific and JCL> internally configurable VERP configurations to chose from. > I actually don't think that MTA-directed VERPing helps us out > much. Its a question of publics and their needs. There are large and desperately unfilled needs for body-customisation in list servers to be sure. That's an untapped market. Its also a non-traditional MLM market. VERP, for Mailman, solves fundamental problems in bounce handling and membership roll maintenance, and the majority of Mailman's current and traditional userbase are going to be wildly interested in that, not in message body customisation. Which doesn't mean we can't or shouldn't do both, just that (at least initially) the target consumers are rather different. > Sure, it can give us an envelope sender that we can use for better > bounce detection[*], but I think that the much more interesting > personalization is content personalization. I.e. inserting into > the message body, footers, headers, RFC 2822 headers, > etc. information specific to the recipient. Only Mailman knows > that data and how to interpolate it into the message body. AFAIK, > there's no way to coordinate this with the MTA, so content > personalization is always going to be performed by Mailman. Yup. Not a whole lot of argument going on at this end. > The VERP-like approach in MM2.1 toward the envelope sender is > mostly just gravy. (I try to be careful to describe it as > VERP-like since it isn't technically VERP.) Technical precision terminology: always bites you in the arse when you're trying to say something useful. > BTW, see VERP_REGEXP and VERP_FORMAT for how the envelope sender > is composed and parsed. Will do. I'm behind on my 2.1 reading (been looking into a CRM system to bolt Mailman into). > [*] VERP helps with knowing exactly which address on which list is > bouncing, but I don't think it helps much with knowing the > severity of the bounce. It doesn't. I'm strongly tempted to treat all bounces as hard, unless we can cheaply _and_ conclusively determine that they are soft. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From bob@nleaudio.com Fri Dec 7 05:18:57 2001 From: bob@nleaudio.com (bob@nleaudio.com) Date: Fri, 7 Dec 2001 00:18:57 -0500 (EST) Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP Message-ID: <20011207051857.94DAA13D126@main.nlenet.net> This is a MIME-encapsulated message. --------------819377684907883932693698 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> [*] VERP helps with knowing exactly which address on which list is >> bouncing, but I don't think it helps much with knowing the >> severity of the bounce. > >It doesn't. I'm strongly tempted to treat all bounces as hard, >unless we can cheaply _and_ conclusively determine that they are >soft. I don't think it would be easily done, and I would venture to say it's not worth the time investment trying to code. I think time is the key to separating hard vs soft. Bounces don't seem to take up much resources, so what's the big deal if we tolerate them over a little longer period of time? Bob --------------819377684907883932693698-- From claw@kanga.nu Fri Dec 7 05:47:24 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 06 Dec 2001 21:47:24 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: Message from bob@nleaudio.com of "Fri, 07 Dec 2001 00:18:57 EST." <20011207051857.94DAA13D126@main.nlenet.net> References: <20011207051857.94DAA13D126@main.nlenet.net> Message-ID: <26643.1007704044@kanga.nu> On Fri, 7 Dec 2001 00:18:57 -0500 (EST) bob wrote: >>> [*] VERP helps with knowing exactly which address on which list >>> is bouncing, but I don't think it helps much with knowing the >>> severity of the bounce. >> It doesn't. I'm strongly tempted to treat all bounces as hard, >> unless we can cheaply _and_ conclusively determine that they are >> soft. > I don't think it would be easily done, and I would venture to say > it's not worth the time investment trying to code. I'm not going to argue either way with the man who writes the patch. His choice. His call. > I think time is the key to separating hard vs soft. I'd tend to cutting on the line of RFC compliance. If its an RFC compliant bounce, and its soft... > Bounces don't seem to take up much resources, so what's the big > deal if we tolerate them over a little longer period of time? This depends on the churn rate on your list, and the posting/bounce-detection rate. Larger lists tend to have (numerically larger churn rates, and can become brutally painful quickly. At one point I had a 140K list with ~35% bad addresses (single opt-in silliness I inherited). It was *NOT* fun for a while. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From Nigel.Metheringham@VData.co.uk Fri Dec 7 10:12:23 2001 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: 07 Dec 2001 10:12:23 +0000 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: <20011206195759.D31902@lenin.nu> References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <20011206195759.D31902@lenin.nu> Message-ID: <1007719943.1219.2.camel@gaspode.localnet> On Fri, 2001-12-07 at 03:57, Peter C. Norton wrote: > Sure, but the beauty is that there's almost no way that a broken MTA can > bounce in such a way as to not know where the message went. I just *love* this boundless optimism. Never underestimate the ability of MTA writers and postmasters (ie those configuring their MTA) to do something *really* obscure to screw you. [VERP-ed header addresses, folks? :-) ] > So you can afford to handle a > lot more bounces, and implement an ezmlm-like probe when it gets critical, > all in the certianty that you're (a) not bouncing messages to the list > admins that they have to read and (b) if you miss any messages over a long > time you can reset your counter and let the user know what they've missed. Yeah - some of the MLMs are encoding the message number (ie a sequential number per mailing list message) into the VERP. That opens up interesting possibilities. [Hmm... are there systems that are broken by long sender addresses?] Nigel. From dan.mick@west.sun.com Fri Dec 7 11:41:00 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Fri, 07 Dec 2001 03:41:00 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> Message-ID: <3C10AACC.D26D256C@west.sun.com> "Barry A. Warsaw" wrote: > > >>>>> "JCL" == J C Lawrence writes: > > JCL> Mailman is going to end up with a set of MTA-specific and > JCL> internally configurable VERP configurations to chose from. > > I actually don't think that MTA-directed VERPing helps us out much. > Sure, it can give us an envelope sender that we can use for better > bounce detection[*], ...which is clearly all it's good for. I have a significant percentage of users whose bounces are useless without VERP, and it's tiring dealing with the uncaught bounces. If I can get VERP with little extra load (because it's done in the MTA) then I'm happy. (Been running for the last 8-10 hours with Postfix doing the VERPing, with a small hack to SMTPDirect.py, and some logging in BounceRunner.py, and it looks really nice so far.) > but I think that the much more interesting > personalization is content personalization. I.e. inserting into the > message body, footers, headers, RFC 2822 headers, etc. information > specific to the recipient. Only Mailman knows that data and how to > interpolate it into the message body. AFAIK, there's no way to > coordinate this with the MTA, so content personalization is always > going to be performed by Mailman. Sure. But that's *expensive*. It's stunning how much more time that all uses up. Granted, I haven't done the various spool vs. syslog optimizations etc., but the point is I don't have to until we get to one-MLM-to-MTA-transaction-per-user. That's when it gets brutal. Anyway, the VERP-in-the-MTA thing seems like a useful featurelet, even if it has limited benefit. Hopefully more MTAs will follow. From Nigel.Metheringham@VData.co.uk Fri Dec 7 11:53:57 2001 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: 07 Dec 2001 11:53:57 +0000 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: <3C10AACC.D26D256C@west.sun.com> References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> Message-ID: <1007726038.1219.8.camel@gaspode.localnet> On Fri, 2001-12-07 at 11:41, Dan Mick wrote: > Anyway, the VERP-in-the-MTA thing seems like a useful featurelet, even > if it has limited benefit. Hopefully more MTAs will follow. I've kicked off discussion on this on the exim lists. It would be nice if there was some form of spec for it though - there appears to be one for a VERP extension on the courier site, but thats using a VERP keyword and not XVERP (presumably they are just about the same, but one you don't need to clear with the ESMTP spec gurus). Nigel. From dan.mick@west.sun.com Fri Dec 7 12:00:11 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Fri, 07 Dec 2001 04:00:11 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTAsupported VERP References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> <1007726038.1219.8.camel@gaspode.localnet> Message-ID: <3C10AF4B.12A086F5@west.sun.com> Nigel Metheringham wrote: > It would be nice > if there was some form of spec for it though - there appears to be one > for a VERP extension on the courier site, but thats using a VERP keyword > and not XVERP (presumably they are just about the same, but one you > don't need to clear with the ESMTP spec gurus). The bottom of http://www.courier-mta.org/ links that VERP proposal behind the name XVERP. I'm sure that the X is there simply to allow its presence and use before the RFC reaches some consensus. A thing I hadn't thought about: if the local MTA senses that the remote MTA *also* supports XVERP, it doesn't have to do the expansion itself; it can simply send on one XVERP-ed multirecipient message, and let the final MTA handle the envelope multiplication. From jra@baylink.com Fri Dec 7 15:41:48 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 7 Dec 2001 10:41:48 -0500 Subject: [Mailman-Developers] MM Bouncer In-Reply-To: <22291.1007691321@kanga.nu>; from J C Lawrence on Thu, Dec 06, 2001 at 06:15:21PM -0800 References: <3C0EFA7C.2B043C2B@nleaudio.com> <20011205230201.O20693@lenin.nu> <25404.1007623028@kanga.nu> <20011206103736.28383@scfn.thpl.lib.fl.us> <15983.1007674340@kanga.nu> <20011206204244.07444@scfn.thpl.lib.fl.us> <22291.1007691321@kanga.nu> Message-ID: <20011207104148.05537@scfn.thpl.lib.fl.us> On Thu, Dec 06, 2001 at 06:15:21PM -0800, J C Lawrence wrote: > > Except that, as was noted earlier, Chuq's problem *is* his wires. > > :-) > > Umm, those are his wires within his network, not the wires to the > great untapped 'network at large. Yeesh. MTAs are fundamentally > disk IO bound. No two ways about it. Not much you can do about it > either, not without violating the commit semantics of the protocol. > > Chuq speaks better for himself than I do. And me, but would it be pertinent to point out here, that it he's melting down Fast-Ethernet, then the size of his uplink pretty much doesn't matter? ;-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Fri Dec 7 15:46:55 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 7 Dec 2001 10:46:55 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTAsupported VERP In-Reply-To: <3C10AF4B.12A086F5@west.sun.com>; from Dan Mick on Fri, Dec 07, 2001 at 04:00:11AM -0800 References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> <1007726038.1219.8.camel@gaspode.localnet> <3C10AF4B.12A086F5@west.sun.com> Message-ID: <20011207104655.10306@scfn.thpl.lib.fl.us> On Fri, Dec 07, 2001 at 04:00:11AM -0800, Dan Mick wrote: > A thing I hadn't thought about: if the local MTA senses that the remote > MTA *also* supports XVERP, it doesn't have to do the expansion > itself; it can simply send on one XVERP-ed multirecipient message, > and let the final MTA handle the envelope multiplication. Which would be the True Win... but *absolutely requires* an RFC for verp syntax, which will have to be extensible. No, really. It will. Take my word for it. :-) *I* think that sending a VERP template, with a spot marked for the destination MTA to put the destination email address, would be the most flexible approach. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From R.Barrett@ftel.co.uk Fri Dec 7 15:47:00 2001 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Fri, 07 Dec 2001 15:47:00 +0000 Subject: [Mailman-Developers] Amending list web_page_url attribute on Python2.1a3 In-Reply-To: <15376.18001.322595.528993@anthem.wooz.org> References: <5.1.0.14.2.20011206150629.03758e28@pop.ftel.co.uk> Message-ID: <5.1.0.14.2.20011207142727.02bc2008@pop.ftel.co.uk> At 23:32 06/12/2001 -0500, Barry A. Warsaw wrote: > >>>>> "RB" == Richard Barrett writes: > > RB> MM 2.1a3 admin page lets me change the host to for the list > RB> but I cannot see any way on the list admin pages to change the > RB> addressing scheme for the list, e.g from http to https. > > RB> Have I missed something or am I reduce to using > RB> $prefix/bin/withlist? > >Yes, because too many list admins f*cked up their lists by typing an >incorrect or unreachable url prefix there. > >The best way to solve this globally is to set >mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.DEFAULT_URL_HOST to whatever you >want (e.g. http -> https). All newly created lists after this change >will simply inherit these new values. > >To fix existing lists, use withlist and fix_url.py (this latter is in >cvs; I'm not sure if it made it to alpha3). > >% bin/withlist -r fix_url -l mylist > >-Barry While I understand why you've gone this route, I think it is the wrong approach. Say a user wants to protect Web UI access to some sensitive lists and only make them available via HTTPS with client side certificates, while other of the site's lists are available via HTTP. Setting this up now becomes a real pain in Mailman. I'd have to temporarily change mm_cfg so that fix_url will pick up the desired addressing scheme from DEFAULT_URL, pray no other admin creates a new list while this change is in place or we'll be recursing to fix their newly created problem, run withlist and then hastily revert mm_cfg. Alternatively I can run withlist raw (without hacking mm_cfg) to change the list's web_page_url, which is even more error prone. Yes, I know that isolating the sensitive lists so that the server will only serve them through port 443 is also a pain but that's an Apache config issue not a Mailman problem. I say it would be better to offer a selection of addressing schemes (probably only http and https) for a list using a SELECT/OPTION tags at the end in the General Options page near the host_name field. That way the code can ensure the web_page_url formed is technically valid. fix_url can still be used for recovering from major stupidity on the admin's part. In a similar vein, the pages generated by /mailman/admin and /mailman/listinfo use relative URLs for the links to each list's admin or listinfo page. Wouldn't the full absolute URL derived from the web_page_url of each list for each list be more appropriate? I'm willing to try and build a patch for 2.1a3 to implement these changes if you think they would be acceptable. Richard From bob@nleaudio.com Fri Dec 7 19:18:05 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 07 Dec 2001 14:18:05 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> <1007726038.1219.8.camel@gaspode.localnet> Message-ID: <3C1115ED.DFB42D6B@nleaudio.com> Speaking of Exim.. one thing that really bothers me about Exim is the message(s) it sends when it has to wait to deliver the message... these would be interpreted as bounces, although they really are not. I've seen a few such messages, only to have the message delivered normally. That would trigger some bounce logic to at least pick up on what really isn't (yet) a bounce. Bob From mailman-developers@python.org Fri Dec 7 19:36:39 2001 From: mailman-developers@python.org (Peter W) Date: Fri, 7 Dec 2001 14:36:39 -0500 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: <15376.13339.661615.544307@anthem.wooz.org>; from barry@zope.com on Thu, Dec 06, 2001 at 10:14:35PM -0500 References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> Message-ID: <20011207143639.C4739@usa.net> On Thu, Dec 06, 2001 at 10:14:35PM -0500, Barry A. Warsaw wrote: > I actually don't think that MTA-directed VERPing helps us out much. > Sure, it can give us an envelope sender that we can use for better > bounce detection[*] How robust is the bounce detection? Even with VERP and/or good MTAs, is there enough smarts in the system to prevent a black hat from connecting to the MTA on the mailman server and using fake bounce messages to knock someone off a list without their knowledge? >, but I think that the much more interesting > personalization is content personalization. I.e. inserting into the > message body, footers, headers, RFC 2822 headers, etc. information Also RFC 2369 List-* headers and in-body subscription management links. :-) > specific to the recipient. Only Mailman knows that data and how to > interpolate it into the message body. Yep. I'm glad to hear you considering this as an option, though I imagine a lot of folks, for good reason, want the current efficient behavior as a choice. > [*] VERP helps with knowing exactly which address on which list is > bouncing, but I don't think it helps much with knowing the severity of > the bounce. Or the authenticity. If Mailman did VERP-like customizations itself, you could do something like my crypto-VERP proposal, where if you sent message number 1234 to me, the unique return path would look something like peterw-usa-net-1234-033fe9dbe554a34839e1b82ec4eb5ab0-list-owner@example.com or maybe list-owner+peterw-usa-net-1234-033fe9dbe554a34839e1b82ec4eb5ab0@example.com where 033fe9dbe554a34839e1b82ec4eb5ab0 is the MD5 hash of peterw-usa-net-1234-secret (the MM install routine would pick a random phrase to be used as the secret, which would probably be long). This way, mailman could be quite certain if a bounce was legit, and in response to a recent message delivery attempt (valid bounces for old messages [> 14 days?] could be ignored; alternately MM could use time_t instead of a message number, making calculations easier). Thoughts? -Peter -- I am what I am 'cause I ain't what I used to be. - S Bruton & J Fleming From dan.mick@west.sun.com Fri Dec 7 21:21:00 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Fri, 07 Dec 2001 13:21:00 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTAsupported VERP References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> <1007726038.1219.8.camel@gaspode.localnet> <3C10AF4B.12A086F5@west.sun.com> <20011207104655.10306@scfn.thpl.lib.fl.us> Message-ID: <3C1132BC.14C7B68B@west.sun.com> "Jay R. Ashworth" wrote: > > On Fri, Dec 07, 2001 at 04:00:11AM -0800, Dan Mick wrote: > > A thing I hadn't thought about: if the local MTA senses that the remote > > MTA *also* supports XVERP, it doesn't have to do the expansion > > itself; it can simply send on one XVERP-ed multirecipient message, > > and let the final MTA handle the envelope multiplication. > > Which would be the True Win... but *absolutely requires* an RFC for > verp syntax, which will have to be extensible. No, really. It will. > Take my word for it. :-) Oh, absolutely. > *I* think that sending a VERP template, with a spot marked for the > destination MTA to put the destination email address, would be the most > flexible approach. ? You're talking about some other ESMTP extension then? From jra@baylink.com Fri Dec 7 21:47:18 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 7 Dec 2001 16:47:18 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTAsupported VERP In-Reply-To: <3C1132BC.14C7B68B@west.sun.com>; from Dan Mick on Fri, Dec 07, 2001 at 01:21:00PM -0800 References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> <1007726038.1219.8.camel@gaspode.localnet> <3C10AF4B.12A086F5@west.sun.com> <20011207104655.10306@scfn.thpl.lib.fl.us> <3C1132BC.14C7B68B@west.sun.com> Message-ID: <20011207164718.05293@scfn.thpl.lib.fl.us> On Fri, Dec 07, 2001 at 01:21:00PM -0800, Dan Mick wrote: > > *I* think that sending a VERP template, with a spot marked for the > > destination MTA to put the destination email address, would be the most > > flexible approach. > > ? You're talking about some other ESMTP extension then? I was not aware that ESMTP already *had* an extension for VERP; so, "yes", I guess. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From Dan Mick Sat Dec 8 00:50:57 2001 From: Dan Mick (Dan Mick) Date: Fri, 7 Dec 2001 16:50:57 -0800 (PST) Subject: [Mailman-Developers] Re: way to minimize IO load with MTAsupported VERP Message-ID: <200112080051.QAA13510@utopia.West.Sun.COM> > On Fri, Dec 07, 2001 at 01:21:00PM -0800, Dan Mick wrote: > > > *I* think that sending a VERP template, with a spot marked for the > > > destination MTA to put the destination email address, would be the most > > > flexible approach. > > > > ? You're talking about some other ESMTP extension then? > > I was not aware that ESMTP already *had* an extension for VERP; so, > "yes", I guess. :-) I'm sure you're clear on this, but just in case: no, I don't think ESMTP *does* have any other extension, but there's clearly one in some stage of proposal by the Courier guys, and apparently Wietse latched on to it too. From spacey-mailman@lenin.nu Sat Dec 8 02:40:15 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Fri, 7 Dec 2001 18:40:15 -0800 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: <20011207143639.C4739@usa.net>; from peterw@usa.net on Fri, Dec 07, 2001 at 02:36:39PM -0500 References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <20011207143639.C4739@usa.net> Message-ID: <20011207184014.B30416@lenin.nu> On Fri, Dec 07, 2001 at 02:36:39PM -0500, Peter W wrote: > On Thu, Dec 06, 2001 at 10:14:35PM -0500, Barry A. Warsaw wrote: > > > I actually don't think that MTA-directed VERPing helps us out much. > > Sure, it can give us an envelope sender that we can use for better > > bounce detection[*] > > How robust is the bounce detection? Even with VERP and/or good MTAs, > is there enough smarts in the system to prevent a black hat from connecting > to the MTA on the mailman server and using fake bounce messages to > knock someone off a list without their knowledge? You can avoid this by is by sending a test message to them and use a cookie in the envelope-from that is a hash of a saved secret value that you can compare to on the bounce. If you get a bounce to the address that has the proper hash, then you can pretty safely disable them (unless their postmaster is out to get them. But you can't save them from that). If you don't get the message bounced back then that email address isn't really (or at least always) bouncing. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From jwblist@olympus.net Sat Dec 8 03:16:34 2001 From: jwblist@olympus.net (John W Baxter) Date: Fri, 7 Dec 2001 19:16:34 -0800 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: <3C1115ED.DFB42D6B@nleaudio.com> References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> <1007726038.1219.8.camel@gaspode.localnet> <3C1115ED.DFB42D6B@nleaudio.com> Message-ID: At 14:18 -0500 12/7/2001, Bob Puff@NLE wrote: >Speaking of Exim.. one thing that really bothers me about Exim is the >message(s) it sends when it has to wait to deliver the message... these >would be interpreted as bounces, although they really are not. I've seen >a few such messages, only to have the message delivered normally. That >would trigger some bounce logic to at least pick up on what really isn't >(yet) a bounce. Exim's delayed delivery warnings are "orderly" enough that it would be quite easy to ignore them in bounce processing. In several ways, they don't look like failure messages. Meanwhile, they let a user who has mistyped an address know about it sooner than without the messages. For an Exim running in support of "live" users. Assuming, of course, that the Exim administrator has resisted the temptation to "improve" the delayed delivery message. If she's done that, users are likely to fall off lists. One hopes that the Exim admin and the Mailman admin are speaking to each other. If the Exim is running just to handle Mailman, the warning message can be done away with entirely (and the retry intervals can be adjusted, and several other such adjustments made). Trivially. But of course, you can't configure away messages generated by remote sites you don't control. --John From chuqui@plaidworks.com Sat Dec 8 04:01:57 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 07 Dec 2001 20:01:57 -0800 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: <20011207184014.B30416@lenin.nu> Message-ID: On 12/7/01 6:40 PM, "Peter C. Norton" wrote: > If you > don't get the message bounced back then that email address isn't really (or > at least always) bouncing. Unless, of course, the postmaster implements bounces using a "not here any more" mailbot, which will strip all of the headers, not return as a bounce, and probably not be parsable by anything but a human, and maybe not then. This is called "being helpful", of course. From bob@nleaudio.com Sat Dec 8 04:11:42 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 07 Dec 2001 23:11:42 -0500 Subject: [Mailman-Developers] MTA load, custom messages, bounces References: Message-ID: <3C1192FE.6078F2AA@nleaudio.com> Chuq Von Rospach wrote: > Unless, of course, the postmaster implements bounces using a "not here any > more" mailbot, which will strip all of the headers, not return as a bounce, > and probably not be parsable by anything but a human, and maybe not then. > > This is called "being helpful", of course. I -just- experienced one of those! Had a bunch of them in my mailman-owner mailbox from this one guy on an active list. Sigh. Bob From spacey-mailman@lenin.nu Sat Dec 8 04:09:25 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Fri, 7 Dec 2001 20:09:25 -0800 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: ; from chuqui@plaidworks.com on Fri, Dec 07, 2001 at 08:01:57PM -0800 References: <20011207184014.B30416@lenin.nu> Message-ID: <20011207200925.C30416@lenin.nu> On Fri, Dec 07, 2001 at 08:01:57PM -0800, Chuq Von Rospach wrote: > On 12/7/01 6:40 PM, "Peter C. Norton" wrote: > > > If you > > don't get the message bounced back then that email address isn't really (or > > at least always) bouncing. > > Unless, of course, the postmaster implements bounces using a "not here any > more" mailbot, which will strip all of the headers, not return as a bounce, > and probably not be parsable by anything but a human, and maybe not then. Sure it will. The message will go back to the envelope sender, which will be a cookied address. I guess to be sure you'd want to put the address in the header from, too. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From mailman-developers@python.org Sat Dec 8 04:23:02 2001 From: mailman-developers@python.org (Peter W) Date: Fri, 7 Dec 2001 23:23:02 -0500 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: <20011207184014.B30416@lenin.nu>; from spacey-mailman@lenin.nu on Fri, Dec 07, 2001 at 06:40:15PM -0800 References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <20011207143639.C4739@usa.net> <20011207184014.B30416@lenin.nu> Message-ID: <20011207232302.A12423@usa.net> On Fri, Dec 07, 2001 at 06:40:15PM -0800, Peter C. Norton wrote: > On Fri, Dec 07, 2001 at 02:36:39PM -0500, Peter W wrote: > > How robust is the bounce detection? Even with VERP and/or good MTAs, > > is there enough smarts in the system to prevent a black hat from connecting > > to the MTA on the mailman server and using fake bounce messages to > > knock someone off a list without their knowledge? > > You can avoid this by is by sending a test message to them and use a cookie > in the envelope-from that is a hash of a saved secret value that you can > compare to on the bounce. Right. That's what I'm suggesting, that maybe such a cookie plan should be implemented. I like my idea of the cookie being a hash of both the recipient address and something like a time value, so that "replay" attacks are less feasible. You shouldn't be able to pick up a disk drive that Barry W discarded a year earlier and get a cookie that still lets you unsubscribe him from this list. :-) > If you get a bounce to the address that has the > proper hash, then you can pretty safely disable them (unless their > postmaster is out to get them. But you can't save them from that). Or if someone gets to their saved messages, right. > If you > don't get the message bounced back then that email address isn't really (or > at least always) bouncing. Eaxctly. Sounds like we're in basic agrement about the potential value of a cookie-laden envelope? -Peter -- I am what I am 'cause I ain't what I used to be. - S Bruton & J Fleming From bob@nleaudio.com Sat Dec 8 04:27:53 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Fri, 07 Dec 2001 23:27:53 -0500 Subject: [Mailman-Developers] MTA load, custom messages, bounces References: <20011207184014.B30416@lenin.nu> <20011207200925.C30416@lenin.nu> Message-ID: <3C1196C9.D85E1C85@nleaudio.com> Peter C. Norton wrote: > Sure it will. The message will go back to the envelope sender, which will > be a cookied address. I guess to be sure you'd want to put the address in > the header from, too. How far do you take that? I have seen people put the "From:" address in their addressbook, then try to send email to that. You don't want to interpret their poor attempts at posting to be bounces. Bob From tkfkdgo69@hotmail.com Sat Dec 8 04:39:38 2001 From: tkfkdgo69@hotmail.com (ÀÓÁØÀÌ) Date: Sat, 8 Dec 2001 13:39:38 +0900 Subject: [Mailman-Developers] [±¤°í]¹Ì·¡ÀÇ ¸ð½ÀÀ» º¸±¸½Í³ª¿ä ¿©·¯ºÐ!!! Message-ID:

¾È³çÇϼ¼¿ä.

¹Ì·¡¿¡´Â(ÁÖ) »ç¾÷ÀÚ ÀÓÀç´ö ÀÔ´Ï´Ù.

ºÎ´ã¾øÀÌ Á¦Ç°ÁÖ¹®(24,000¿ø)ÇÏ½Ã°í ³×Æ®¿öÅ© ¸¶ÄÉÆÃ
»ç¾÷ÀÚ°¡ µÇ½Ê½Ã¿ä. ±×¸®°í ÁÖÀ§¿¡ ¼Ò°³ÇÏ½Ã¸é ´Ùµé
°æÁ¦ÀûÀÌ¶ó µ¿ÂüÇϽʴϴÙ

ÇöÀç ¸¹Àº ³×Æ®¿öũȸ»çµéÀÌ ³­¹«ÇÏ´Â °÷¿¡¼­ ¾öû³­
¼Óµµ·Î ¹ßÀüÀ» ÇÏ°íÀÖ´Â "¹Ì·¡¿¡´Â(ÁÖ)"¸¦ ¼Ò°³ÇÕ´Ï´Ù.

ÇöÀç ¹Ì·¡¿¡´ÂÀÌ Ãâ¹üÇÑÁö 4°³¿ù¸¸¿¡ ȸ¿øÀÌ 4,000¸íÀÌ
µÇ¾ú½À´Ï´Ù. ÇöÀç Ư¸éÀÇ Àαâ·Î ¸¹Àº ºÐµéÀÌ ¼Ó¼ÓÈ÷ ¹Ì
·¡¿¡´ÂÀ¸·Î ¸ô¸®°í ÀÖ½À´Ï´Ù.

´Ù¸¥ ¾î¶² ³×Æ®¿öÅ© ½Ã½ºÅÛº¸´Ù °­·ÂÇÏ°í ´©±¸¿¡°Ôµµ ÇÇ
ÇØ ÁÖÁö ¾Ê´Â Á¤Á÷ÇÑ ³×Æ®¿öÅ©ÀÔ´Ï´Ù.

º¸»óÇ÷£µµ °¡Àå Çö½ÇÀûÀÔ´Ï´Ù.

ÇÁ¸®¸ÖƼ·¹º§¹æ½ÄÀ¸·Î ÀÚ½ÅÀÇ ³ë·Â ¿©ÇÏ¿¡ µû¶ó¼­ ¼öÀÔÀ» ¾òÀ¸½Ç¼ö ÀÖ½À´Ï´Ù.

1´Ü°è: 10%

2´Ü°è~5´Ü°è: 5%

"¹Ì·¡¿¡´Â"ÀÇ ÀåÁ¡

1.¹Ì·¡¿¡´ÂÀÇ ¹Ì·¡Æ¯¸éÀº °­·ÂÇÑ ¼ÒºñÀç ÀÔ´Ï´Ù.

2.ÇöÀç ¿ÀÇÂÇÑÁö 4°³¿ùÁ¤µµ·Î ÀáÀçÀû ½ÃÀ强À» ³»Æ÷ÇÏ°íÀÖ½À´Ï´Ù.

3.´©±¸³ª ºÎ´ã¾øÀÌ Æ¯¸é Çѹڽº 24,000¿øÀ¸·Î »ç¾÷À» ½ÃÀÛÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù.

4.¹Ì·¡¿¡´ÂÀº ³»³â 3¿ùºÎÅÍ À§¼º¹æ¼Û»ç¾÷À» ½ÃÀÛÇÕ´Ï´Ù.

À§¼º¹æ¼ÛÀÇ ºñÁ¯Àº Á¤¸» ¾î¸¶¾î¸¶ ÇÕ´Ï´Ù. ³×Æ®¿öÅ©¸¦ ÇϽô ºÐµéÀº ¾Æ¸¶
´Ù ¾Æ½Ç °ÍÀÔ´Ï´Ù. ¾ÕÀ¸·Î´Â À§¼º¹æ¼ÛÀÇ ½Ã´ëÀÔ´Ï´Ù. ½Ã´ë¿¡ ¹ß¸¶Ã߾ ÇÏ
´Â ³×Æ®¿öÅ©°¡ ÁøÁ¤ÇÑ ¼º°øÀ» °ÅµÑ¼ö ÀÖ½À´Ï´Ù.

5.¹Ì·¡¿¡´Â Á¤È¸¿øÀÌ µÇ½Ã¸é È­»óÀüÈ­±â(¿ùµåÆù)À» °øÂ¥·Î µå¸³´Ï´Ù.
¿ùµåÆùÀ» »ç¿ëÇϴ ȸ¿øµé³¢¸®´Â °øÂ¥ÀÌ°í,±¹³»ÅëÈ­´Â Áö¿ª¿¡ »ó°ü¾øÀÌ ¹«Á¶
°Ç ½Ã³»¿ä±ÝÀÌ Àû¿ëÀÌ µË´Ï´Ù.(ºÐ´ç50¿ø)

ÀϹÝÇÚµåÆùÀÇ °æ¿ì 10ÃÊ´ç21-23¿øÀÇ ÅëÈ­·á°¡ Àû¿ëµÇÁö¸¸ ¿ùµåÆùÀ» »ç¿ëÇϸé
10ÃÊ¿¡ 15¿ø ¾à 60%Á¤µµÀÇ ÅëÈ­·á°¡ Àý°¨µË´Ï´Ù.

6.¹Ì·¡¿¡´ÂÀº ±¹³»È¸¿ø 5¸¸¸íÁ¤µµ¸é ÇØ¿Ü·Î ÁøÃâÀ» ÇÕ´Ï´Ù.
ÇØ¿ÜÁøÃâ½Ã¿¡´Â 7°³±¹¾ð¾î·Î ¹ø¿ªµÇ¾î¼­ ¼¼°è½ÃÀå¿¡ ÁøÃâÇÏ°Ô µË´Ï´Ù.
±×·¸°Ô µÇ¸é ¿ì¸®³ª¶ó¿¡¼­ º»´Ù¸é ¿ÜÈ­¸¦ ¹ú¾îµå¸±¼ö À־ ÁÁ°í ÀÚ½ÅÀÌ ¼¼
°è °¢±¹ÀÇ »ç¶÷µéÀ» ´Ù¿îÀ¸·Î ¸ð¾Æ¼­ ÀÚ½ÅÀÇ ¼öÀÍÀ» ±Ø´ëÈ­ ÇÒ¼ö ÀÖ½À´Ï´Ù.


°¡ÀÔÀº...ÇѶóÀÎÀ¸·Î ¿À¼Å¼­ µÑ·¯ º¸½Ã°í °¡ÀÔ Çϼŵµ ´ÊÁö ¾ÊÀ»°Ì´Ï´Ù.
ÇѶóÀÎ ÁÖ¼Ò http://hanline.fu.st
¹®ÀǸÞÀÏ :  dlaxorb@dreamwiz.com

ÀÏȮõ±ÝÀ» ±â´ëÇÏ½Ã°í »ç¾÷ ÇϽǺÐÀº ¹Ù¶óÁö ¾Ê½À´Ï´Ù. ¿©·¯ ȸ¿ø´Ô°ú °°ÀÌ
Çù·Â ÇÏ¿© 2~3³â ÈÄ ÀÚ½ÅÀÇ ´õ ³ªÀº »îÀ» ÇâÇؼ­ ²ÙÁØÈ÷, ¿­½ÉÈ÷ ÇÏ½Ç ºÐ¸¸
¸ð½Ê´Ï´Ù!!

ÀÚ¼¼ÇÑ ³»¿ëÀº ÇѶóÀο¡ ¿À½Ã¸é ¹Ì·¡¿¡´Â »ç¾÷¼³¸í µ¿¿µ»óÀÌ Áغñ µÇ¾îÀÖ½À´Ï´Ù.
»ç¾÷¼³¸íÀ» º¸½Ã¸é ÀüüÀûÀÎ ¹Ì·¡¿¡´ÂÀÇ »ç¾÷ÀÌÇظ¦ ÇϽǼö ÀÖÀ»°ÍÀÔ´Ï´Ù.

ÇѶóÀÎÀ¸·Î ¿À½Ê½Ã¿ä... ÇѶóÀο¡¼± Ãʺ¸´Ôµµ ÇÏÀ§ ȸ¿øÀÌ »ý±â´Â ½Ã½ºÅÆÀ¸·Î
¿î¿µµÇ°í ÀÖÀ¸¸ç Ÿ»çÀÌÆ®(ÆäÀÌÆ÷À¯) 1530¸íÀ» ¸ðÀº ¹æ¹ýÀ¸·Î »óÇÏÀ§ ȸ¿ø ¸ð
µÎ¿¡°Ô ±ÕµîÇÑ ÇýÅÃÀÌ °¡°Ô µÇ¾î ÀÖÀ» »Ó¸¸ ¾Æ´Ï¶ó ¸ðµç ȸ¿ø´ÔµéÀÌ Çù·ÂÇØ ³ª
°¡´Â °÷ÀÔ´Ï´Ù.

³Ý¸¶°ÔÆà ÇѶóÀÎÀ¸·Î ½ÃÀÛ ÇÏ½Ã¸é ½Ç¸Á ÇÏÁø ¾ÊÀ¸½Ç°Ì´Ï´Ù...


[¼ö½Å°ÅºÎ]

From claw@kanga.nu Sat Dec 8 04:56:53 2001 From: claw@kanga.nu (J C Lawrence) Date: Fri, 07 Dec 2001 20:56:53 -0800 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: Message from "Bob Puff@NLE" of "Fri, 07 Dec 2001 23:11:42 EST." <3C1192FE.6078F2AA@nleaudio.com> References: <3C1192FE.6078F2AA@nleaudio.com> Message-ID: <14321.1007787413@kanga.nu> On Fri, 07 Dec 2001 23:11:42 -0500 bob > wrote: > Chuq Von Rospach wrote: >> Unless, of course, the postmaster implements bounces using a "not >> here any more" mailbot, which will strip all of the headers, not >> return as a bounce, and probably not be parsable by anything but >> a human, and maybe not then. >> This is called "being helpful", of course. > I -just- experienced one of those! Had a bunch of them in my > mailman-owner mailbox from this one guy on an active list. Sigh. The ones I love even more are the, "User has not collected this message of Subject: Something and MessageID: SomethingElse for more than 30 days. You can gleefully unsubscribe them of course, but the mail system on the other end will gleefully go on reminding you of some number of messages from 6 months earlier and everything since... -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From spacey-mailman@lenin.nu Sat Dec 8 05:20:24 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Fri, 7 Dec 2001 21:20:24 -0800 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: <20011207232302.A12423@usa.net>; from peterw@usa.net on Fri, Dec 07, 2001 at 11:23:02PM -0500 References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <20011207143639.C4739@usa.net> <20011207184014.B30416@lenin.nu> <20011207232302.A12423@usa.net> Message-ID: <20011207212024.D30416@lenin.nu> On Fri, Dec 07, 2001 at 11:23:02PM -0500, Peter W wrote: > Right. That's what I'm suggesting, that maybe such a cookie plan should be > implemented. I like my idea of the cookie being a hash of both the > recipient address and something like a time value, so that "replay" > attacks are less feasible. You shouldn't be able to pick up a disk drive > that Barry W discarded a year earlier and get a cookie that still lets you > unsubscribe him from this list. :-) Throw in a saved secret per list or per test message, too. The recipient address is known, and time values can probably be guessed if you have a known config and the attacker is generating the "bounces". The attacker could probably brute force the right address within 300 messages (5 minute timespan). > > If you get a bounce to the address that has the > > proper hash, then you can pretty safely disable them (unless their > > postmaster is out to get them. But you can't save them from that). > > Or if someone gets to their saved messages, right. > > > If you > > don't get the message bounced back then that email address isn't really (or > > at least always) bouncing. > > Eaxctly. Sounds like we're in basic agrement about the potential value of > a cookie-laden envelope? It makes my life easier when I use ezmlm. I think it would be a good addition to mailman. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From spacey-mailman@lenin.nu Sat Dec 8 05:22:58 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Fri, 7 Dec 2001 21:22:58 -0800 Subject: [Mailman-Developers] MTA load, custom messages, bounces In-Reply-To: <3C1196C9.D85E1C85@nleaudio.com>; from bob@nleaudio.com on Fri, Dec 07, 2001 at 11:27:53PM -0500 References: <20011207184014.B30416@lenin.nu> <20011207200925.C30416@lenin.nu> <3C1196C9.D85E1C85@nleaudio.com> Message-ID: <20011207212258.E30416@lenin.nu> They put in the header from most of the time, don't they? If so, not a problem. On Fri, Dec 07, 2001 at 11:27:53PM -0500, Bob Puff@NLE wrote: > Peter C. Norton wrote: > > > Sure it will. The message will go back to the envelope sender, which will > > be a cookied address. I guess to be sure you'd want to put the address in > > the header from, too. > > How far do you take that? I have seen people put the "From:" address in their addressbook, then try to send email to that. You don't want to interpret their poor attempts at posting to be bounces. > > Bob > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From 111sjs111@hanmail.net Sat Dec 8 08:06:22 2001 From: 111sjs111@hanmail.net (gold) Date: Sat, 8 Dec 2001 17:06:22 +0900 Subject: [Mailman-Developers] ¸á¸¸¹ÞÀ¸¸éµ·ÁØ´ë¿ä¹«·á°¡ÀÔÈĵ·¹Þ¾Æ°¡¼¼¿ä Message-ID:

      ¸ÞÀÏÇÑÅë 50¿ø~6,000¿ø!!! ÃßõÀÎ 3´Ü°è!!!


***  ¸ÞÀÏ ÇÑÅë´ç  50¿ø ~ 6,000¿ø

***  ¸ÞÀÏ ¹Þ°í {È®ÀιöÆ°} ´©·ç¸é µ·ÀÌ Àû¸³µË´Ï´Ù.
      ´Üµ· 100¿øµµ »ç¿ë°¡´ÉÇϸç,( 1¸¸¿øÀû¸³½Ã ÅëÀåÀ¸·Î ¹ÞÀ½)

***  À¯·á»çÀÌÆ®¿¡  ÀÚ½ÅÀÇ Àû¸³±ÝÀ¸·Î  »ç¿ëÇÒ¼ö ÀÖ½À´Ï´Ù..(°ÔÀÓ , ¼ºÀλçÀÌÆ®.µî)

***  Ãßõ  3´Ü°è ===> 1´Ü°è, 2´Ü°è, 3´Ü°è.... ¸ðµÎ  10%Àû¸³

***  °¡Á·À̳ª ~ Ä£±¸ ~ ģô ~ ¸ðµÎ ÀÚ½ÅÀÇ ¹ØÀ¸·Î °¡ÀÔÀ» ½ÃÅ°¼¼¿ä..
       ¼öÀÍÀÌ Àå³­ÀÌ ¾Æ´Ï°í ~ Å« µ·À» ¹ú¼ö ÀÖ½À´Ï´Ù.

***  ºñÁ¯ ~~  ÇöÀç  °¢Áö¿ªº°·Î Áö»çÀ» ¸ðÁýÇÏ°í ÀÖ½À´Ï´Ù...
      º­·è½ÃÀå, °¡·Î¼ö, ±³Â÷·Î.. ó·³  Áö¿ªº°·Îµµ ¸ÞÀϱ¤°í°¡ °è¼Ó¹ß¼ÛµË´Ï´Ù.

http://www.santaemail.co.kr/c.asp?c=gold
&&&ÃßõÀÎ : gold

** ÀÌÁ¦ °áÁ¤Çϼ¼¿ä...^*^
   ÇÏÀ§È¸¿øÀÌ 6,000¿øÂ¥¸® ¸ÞÀÏÀ» ¹Þ¾ÒÀ¸¸é  ´ç½Å¿¡°Ô 600¿øÀÌ µé¾î¿É´Ï´Ù.
   ´ç½ÅÀÇ È¸¿øÀÌ 100¸íÀ̸é(1~3´Ü°è)  º»Àο¡°Ô  60,000¿ø + ³ª 6,000¿ø=66,000¿ø
   À» ¹Þ½À´Ï´Ù....  ¸ÞÀÏÇÑÅë¿¡    66,000¿ø   »¡¸® ÆÇ´ÜÇϼ¼¿ä...

   &&¶ÇÇÑ Àú¸¦ ÃßõÀÎÀ¸·Î ¾²½Ã¸é °¢Á¾ È«º¸¿¡ ÇÊ¿äÇÑ ÀÚ·á(À̸ÞÀÏÃàÃâ±â,È«º¸±Û, ¹ß¼Û±â,°¢Á¾ Á¤º¸µîµî) ´Ù µå¸³´Ï´Ù..&&

¢¹ ¹«·á°¡ÀÔÇϱ⠢·

 

 

´ÔÀÇ À̸ÞÀÏÁÖ¼Ò´Â ¿ì¿¬È÷ °Ô½ÃÆÇ À¥¼­ÇÎÁß ¹ß°ßÇÏ°Ô µÇ¾ú½À´Ï´Ù.

¼ö½Å°ÅºÎ¸¦ ÇÏ¿© ÁÖ½Ã¸é ´Ù½Ã´Â º¸³»Áö ¾Ê°Ú½À´Ï´Ù.Á˼ÛÇÕ´Ï´Ù.

[¼ö½Å°ÅºÎ] From salearea3@airticketauction.co.kr Sat Dec 8 13:07:00 2001 From: salearea3@airticketauction.co.kr (sky auction (ÁÖ)) Date: Sat, 8 Dec 2001 22:07:00 +0900 Subject: [Mailman-Developers] [±¤°í]"Ç×°ø±ÇÀ» °¡Àå ½Î°Ô »ç´Â ¹æ¹ýÀº Ç×°ø±Ç°æ¸Å·Î..." Message-ID: <3c120ef53c25ba9d@relay2.kornet.net> (added by relay2.kornet.net) ¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼­ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸ø

  ¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼­ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸ø
    ÇÕ´Ï´Ù.ÀÓÀÇÀûÀ¸·Î ó¸®ÇÑ ¸ÞÀÏ¿¡ ´ëÇؼ­´Â ¼ö½Å°ÅºÎÇÏ¿© ÁÖ½Ã¸é ¸ÞÀÏÀ» ¹ß¼ÛÇÏÁö ¾Êµµ·Ï
    ÇÏ°Ú½À´Ï´Ù.
¢Ñ ¼ö½Å°ÅºÎ

 

From barry@zope.com Sat Dec 8 16:13:07 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 8 Dec 2001 11:13:07 -0500 Subject: [Mailman-Developers] [ =?iso-2022-jp?B?GyRCMSQwbRsoQg==?= ] ... more korea crap. References: <20011209004045.N27301@ixp.jp> Message-ID: <15378.15379.39895.645733@anthem.wooz.org> >>>>> "PE" == Peter Evans writes: PE> Dear admin: PE> Close the bloody list. 3 of these in the same day is PE> tiring enough to cause mass unsubscription. Done. -Barry From spacey-mailman@lenin.nu Sat Dec 8 19:08:47 2001 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Sat, 8 Dec 2001 11:08:47 -0800 Subject: [Mailman-Developers] Help In-Reply-To: <01C16117.DB7F9C40.kadarcs@edasz.hu>; from kadarcs@edasz.hu on Tue, Oct 30, 2001 at 07:52:43AM +0100 References: <01C16117.DB7F9C40.kadarcs@edasz.hu> Message-ID: <20011208110847.J30416@lenin.nu> I think you want to ask this question on the mailman users list, which you can find in the same place you found this list. The answer to your question is probably to re-add the user without the space and without his/her name. Just use their email address. -Peter On Tue, Oct 30, 2001 at 07:52:43AM +0100, Kadar I. Csaba wrote: > Hi , > > I joined this group, because I own a mailman discussion group, and I have a question. > > When I added a person, I added his e-mail address followed with his name. > > In the membership page this user apear with e-mail address followed by his name. > > When I, or he would like to modify anythink in his data, the server answwer, that he aren't user. > > Please help me in solving this problem, because this man don't receive the messages. > > Thank in advance for your help, > > Csaba -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From jra@baylink.com Sat Dec 8 23:53:20 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 8 Dec 2001 18:53:20 -0500 Subject: [Mailman-Developers] Re: way to minimize IO load with MTAsupported VERP In-Reply-To: <200112080051.QAA13510@utopia.West.Sun.COM>; from Dan Mick on Fri, Dec 07, 2001 at 04:50:57PM -0800 References: <200112080051.QAA13510@utopia.West.Sun.COM> Message-ID: <20011208185320.55896@scfn.thpl.lib.fl.us> On Fri, Dec 07, 2001 at 04:50:57PM -0800, Dan Mick wrote: > > On Fri, Dec 07, 2001 at 01:21:00PM -0800, Dan Mick wrote: > > > > *I* think that sending a VERP template, with a spot marked for the > > > > destination MTA to put the destination email address, would be the most > > > > flexible approach. > > > > > > ? You're talking about some other ESMTP extension then? > > > > I was not aware that ESMTP already *had* an extension for VERP; so, > > "yes", I guess. :-) > > I'm sure you're clear on this, but just in case: no, I don't think > ESMTP *does* have any other extension, but there's clearly one > in some stage of proposal by the Courier guys, and apparently > Wietse latched on to it too. Ah; no, I was *not* clear on that; thanks for the clarification. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From srichter@cbu.edu Sun Dec 9 15:58:45 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 09 Dec 2001 09:58:45 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview Message-ID: <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> --=====================_645649564==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello everyone, I am proud to announce the first preview of the ZMailman product. It allows Zope to have access to the Mailman API and pretty much replaces Mailman's Web GUI. I also added the beginnings of a Mailman UserFolder. More info at: http://demo.iuveno-net.de/iuveno/Products/ZMailman/ Zope site: http://www.zope.org/Members/srichter/Products/ZMailman Note: ZMailman runs only on Zope 2.5+ and Mailman 2.1a3+. Please go and try it and don't forget to send us comments. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management --=====================_645649564==_.ALT Content-Type: text/html; charset="us-ascii" Hello everyone,

I am proud to announce the first preview of the ZMailman product. It allows Zope to have access to the Mailman API and pretty much replaces Mailman's Web GUI. I also added the beginnings of a Mailman UserFolder.

More info at: http://demo.iuveno-net.de/iuveno/Products/ZMailman/
Zope site: http://www.zope.org/Members/srichter/Products/ZMailman

Note: ZMailman runs only on Zope 2.5+ and Mailman 2.1a3+.

Please go and try it and don't forget to send us comments.

Regards,
Stephan

--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management --=====================_645649564==_.ALT-- From chuqui@plaidworks.com Sun Dec 9 19:34:53 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 09 Dec 2001 11:34:53 -0800 Subject: [Mailman-Developers] Masthead.txt? Message-ID: I'm trying to tweak the header on digests for a mail list (this is 2.0.5) I've modified ~mailman/lists/listname/masthead.txt Mailman is ignoring it. Looking at the code, the code seems to indicate it ought to be using this, but it doesn't seem to be. Huh? Barry, what should I be doing? Am I missing something? From dmick@utopia.West.Sun.COM Mon Dec 10 00:34:53 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Sun, 09 Dec 2001 16:34:53 -0800 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> Message-ID: <3C14032D.3754360B@utopia.west.sun.com> I don't understand Zope; can someone describe why I might want this, what it buys me, etc. (like a sales brochure)? Stephan Richter wrote: > > Hello everyone, > > I am proud to announce the first preview of the ZMailman product. It allows Zope to have access to the Mailman API and pretty much > replaces Mailman's Web GUI. I also added the beginnings of a Mailman UserFolder. > > More info at: http://demo.iuveno-net.de/iuveno/Products/ZMailman/ > Zope site: http://www.zope.org/Members/srichter/Products/ZMailman > > Note: ZMailman runs only on Zope 2.5+ and Mailman 2.1a3+. > > Please go and try it and don't forget to send us comments. > > Regards, > Stephan > > -- > Stephan Richter > CBU - Physics and Chemistry Student > Web2k - Web Design/Development & Technical Project Management From claw@kanga.nu Mon Dec 10 01:02:45 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 09 Dec 2001 17:02:45 -0800 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: Message from Dan Mick of "Sun, 09 Dec 2001 16:34:53 PST." <3C14032D.3754360B@utopia.west.sun.com> References: <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> Message-ID: <11307.1007946165@kanga.nu> On Sun, 09 Dec 2001 16:34:53 -0800 Dan Mick wrote: > I don't understand Zope; can someone describe why I might want > this, what it buys me, etc. (like a sales brochure)? Think a semi-OO based PHP setup where the OO as[ects extended not only to the internal language, but also to the construction of page elements and templates, and of course, instead of using PHP, use Python and much more cleanly abstracted DB interface. Probably the biggest other difference is that Zope natievly works off a single unified store rather than the filesystem. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From srichter@cbu.edu Mon Dec 10 01:48:56 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 09 Dec 2001 19:48:56 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <11307.1007946165@kanga.nu> References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> Message-ID: <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> At 05:02 PM 12/9/2001 -0800, J C Lawrence wrote: >On Sun, 09 Dec 2001 16:34:53 -0800 >Dan Mick wrote: > > > I don't understand Zope; can someone describe why I might want > > this, what it buys me, etc. (like a sales brochure)? > >Think a semi-OO based PHP setup where the OO as[ects extended not >only to the internal language, but also to the construction of page >elements and templates, and of course, instead of using PHP, use >Python and much more cleanly abstracted DB interface. Probably the >biggest other difference is that Zope natievly works off a single >unified store rather than the filesystem. Yes, that is pretty good, even though comparing Zope/Python to PHP is not really possible. First of all, the Python team and the Zope team work all for the same company Zope Corp. Then, Zope is a Python-based Web Application Server. It uses the ZODB, an object-oriented DB, that stores automatically all the objects. Since everything is saved there, security is built in from the beginning, so you do not have to worry about people breaking in into objects, just because you forgot to set permissions or hiding a link. Zope uses many advanced design patterns, such as Persistence, Acquisition, Page Templates, Component Architectures (Zope 3.0) and so on. If you like Python and need to do Web applications a lot, you should have a look at Zope (www.zope.org). It is a very nice software and does a lot of things for you. Furthermore, for the Mailman 3.0 release I would like to make a case for using the ZODB (not the entire Zope package!) for storing our data structures, since we will not have to worry about file locking and data storage in general anymore. Furthermore, we can then easily build adapters for other data storages. Again, this is just a suggestion... I still have to read the archives and proposals some more, before I can propose a design for the data structures to the list. As you might have noticed, this is really what I am interested in, because having tighter integrations between Web tools and Mailman, could give Mailman a huge boost in usage. In fact, the current ZMailman release does already some nice things, but it will be even better, once the data is stored in the ZODB. Unfortunately, the current data structures are not clean enough for this effort and I did not want to rewrite most of Mailman to make it work. ;-) Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From srichter@cbu.edu Mon Dec 10 02:06:09 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 09 Dec 2001 20:06:09 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <3C14032D.3754360B@utopia.west.sun.com> References: <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011209200315.02f2f7c0@mail.cbu.edu> At 04:34 PM 12/9/2001 -0800, Dan Mick wrote: >I don't understand Zope; can someone describe why I might want this, >what it buys me, etc. (like a sales brochure)? Okay, I just opened my development server at http://physics.cbu.edu:6080/manage Username: test Password: test You have full management rights to Zope, so please be considerate and do not destroy it to a point, where other people cannot look at it anymore. ;-) Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From lm@bitmover.com Mon Dec 10 02:14:48 2001 From: lm@bitmover.com (Larry McVoy) Date: Sun, 9 Dec 2001 18:14:48 -0800 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu>; from srichter@cbu.edu on Sun, Dec 09, 2001 at 07:48:56PM -0600 References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <11307.1007946165@kanga.nu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: <20011209181448.C32734@work.bitmover.com> On Sun, Dec 09, 2001 at 07:48:56PM -0600, Stephan Richter wrote: > Furthermore, for the Mailman 3.0 release I would like to make a case for > using the ZODB (not the entire Zope package!) for storing our data > structures, since we will not have to worry about file locking and data > storage in general anymore. I'm not sure this is on topic, but we've extended BitKeeper to support database operations. BitKeeper is a distributed revision control system (really distributed, you can et a workspace, disconnect, and do 100% of what you could do connected, it replicates the database). We added database records which are somewhat more flexible than you are used to, they are each key/value pairs and what structure you what is up to you, it can be as structured or unstructured as you want. We've added a query layer which is largely SQL compliant, you can do select from open where priority < 2 && severity < 2 && state == open types of things. You can also get at the raw data directly if you want. We use this to implement our bug database, which you can browse at http://bitkeeper.bitkeeper.com/bugs.html to get some idea of what it can do. All of this will come out in BK 3.0, sometime around February. It is an alternative to the Zope DB. In fact, several companies have asked us to replace the Zope DB with our DB so they can have revision controlled objects. Some day we will do something like that. If you are interested in this, let me know. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From bob@nleaudio.com Mon Dec 10 02:22:11 2001 From: bob@nleaudio.com (Bob Puff@NLE) Date: Sun, 09 Dec 2001 21:22:11 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <11307.1007946165@kanga.nu> Message-ID: <3C141C53.CA2D935@nleaudio.com> > > I don't understand Zope; can someone describe why I might want > > this, what it buys me, etc. (like a sales brochure)? > > Think a semi-OO based PHP setup where the OO as[ects extended not > only to the internal language, but also to the construction of page > elements and templates, and of course, instead of using PHP, use > Python and much more cleanly abstracted DB interface. Probably the > biggest other difference is that Zope natievly works off a single > unified store rather than the filesystem. ..... riiiighhht..... So what does that mean? For those of us no-zopers! :-) Bob From srichter@cbu.edu Mon Dec 10 02:48:47 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 09 Dec 2001 20:48:47 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <3C141C53.CA2D935@nleaudio.com> References: <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <11307.1007946165@kanga.nu> Message-ID: <5.1.0.14.2.20011209204355.02e6a608@mail.cbu.edu> > > Think a semi-OO based PHP setup where the OO as[ects extended not > > only to the internal language, but also to the construction of page > > elements and templates, and of course, instead of using PHP, use > > Python and much more cleanly abstracted DB interface. Probably the > > biggest other difference is that Zope natievly works off a single > > unified store rather than the filesystem. > >..... riiiighhht..... > >So what does that mean? For those of us no-zopers! :-) Alright, I guess I have to give some more context here: Originally the ZODB saves all its objects into one big file, basically a pickle. This way it does not have to worry about FS-based security and Object storage, but can do it all by itself; also it supports transactions, versioning and so on... However, some people think this 1 file storage is a bad thing. Therefore ZC developed several new storage types, such as OracleStorage and BerkleyDBStorage on which Barry Warsaw is actually working, so he will be able to give you much more detail than I can. I think you should just take 5 minutes and install Zope on your system and see it yourself; many of the concepts will become immediately obvious to an experienced Python programmer. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From dmick@utopia.West.Sun.COM Mon Dec 10 02:50:53 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Sun, 09 Dec 2001 18:50:53 -0800 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: <3C14230D.19571051@utopia.west.sun.com> JC and Stephan's points describe differences in internal implementation and organizational development, but I'm having a hard time seeing actual advantages there. Security is the one thing I see as "better with Zope". Surely there must be other compelling reasons; I mean, one could recode Mailman in Perl, but why?...one could change from native FS to Andrew FS, but why?...etc. Stephan Richter wrote: > > At 05:02 PM 12/9/2001 -0800, J C Lawrence wrote: > >On Sun, 09 Dec 2001 16:34:53 -0800 > >Dan Mick wrote: > > > > > I don't understand Zope; can someone describe why I might want > > > this, what it buys me, etc. (like a sales brochure)? > > > >Think a semi-OO based PHP setup where the OO as[ects extended not > >only to the internal language, but also to the construction of page > >elements and templates, and of course, instead of using PHP, use > >Python and much more cleanly abstracted DB interface. Probably the > >biggest other difference is that Zope natievly works off a single > >unified store rather than the filesystem. > > Yes, that is pretty good, even though comparing Zope/Python to PHP is not > really possible. > > First of all, the Python team and the Zope team work all for the same > company Zope Corp. > > Then, Zope is a Python-based Web Application Server. It uses the ZODB, an > object-oriented DB, that stores automatically all the objects. Since > everything is saved there, security is built in from the beginning, so you > do not have to worry about people breaking in into objects, just because > you forgot to set permissions or hiding a link. Zope uses many advanced > design patterns, such as Persistence, Acquisition, Page Templates, > Component Architectures (Zope 3.0) and so on. > > If you like Python and need to do Web applications a lot, you should have a > look at Zope (www.zope.org). It is a very nice software and does a lot of > things for you. > > Furthermore, for the Mailman 3.0 release I would like to make a case for > using the ZODB (not the entire Zope package!) for storing our data > structures, since we will not have to worry about file locking and data > storage in general anymore. Furthermore, we can then easily build adapters > for other data storages. Again, this is just a suggestion... I still have > to read the archives and proposals some more, before I can propose a design > for the data structures to the list. > > As you might have noticed, this is really what I am interested in, because > having tighter integrations between Web tools and Mailman, could give > Mailman a huge boost in usage. In fact, the current ZMailman release does > already some nice things, but it will be even better, once the data is > stored in the ZODB. Unfortunately, the current data structures are not > clean enough for this effort and I did not want to rewrite most of Mailman > to make it work. ;-) > > Regards, > Stephan > > -- > Stephan Richter > CBU - Physics and Chemistry Student > Web2k - Web Design/Development & Technical Project Management > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From srichter@cbu.edu Mon Dec 10 03:36:08 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 09 Dec 2001 21:36:08 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <3C14230D.19571051@utopia.west.sun.com> References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011209211616.02e2fe70@mail.cbu.edu> At 06:50 PM 12/9/2001 -0800, Dan Mick wrote: >JC and Stephan's points describe differences in internal implementation >and organizational development, but I'm having a hard time seeing actual >advantages there. Security is the one thing I see as "better with Zope". >Surely there must be other compelling reasons; I mean, one could recode >Mailman in Perl, but why?...one could change from native FS to Andrew FS, >but why?...etc. This is a good point, however I think the current mailman data structure looks like a big hack (I am sorry to say that, but you can clearly see that Mailman grew over the last years). So they need to be reimplemented again in anyway and I would have done that already, if it would not be such a huge task, but I hope to be able to do it soon with some help... maybe I get something prototypish done over Christmas, if not definitely something will happen after that... Having said that, I think that the data structures should be savable in any data source, be it an RDB, FS, ZODB or BK. I just think that natively (or the default) the ZODB would be a much better fit with Mailman, since they are both developed in Python. Please remember, I do not talk of Zope, but *only* about the ZODB. Here is one of my main arguments: Many people of the Python scene develop the ZODB (including Barry) and they solve many storage problems for us. So why would should Mailman worry about its own storage mechanism and put development resources on it, if we (Mailman Development Team) could "out-source" these expertise? BTW, calling Lock(), UnLock() and Save() all the time I made a change to a data structure in Mailman seems very clumsy to me, since I am very spoiled by the ZODB behavior. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From jra@baylink.com Mon Dec 10 04:10:50 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sun, 9 Dec 2001 23:10:50 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <3C14032D.3754360B@utopia.west.sun.com>; from Dan Mick on Sun, Dec 09, 2001 at 04:34:53PM -0800 References: <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> Message-ID: <20011209231050.56953@scfn.thpl.lib.fl.us> On Sun, Dec 09, 2001 at 04:34:53PM -0800, Dan Mick wrote: > I don't understand Zope; can someone describe why I might want this, > what it buys me, etc. (like a sales brochure)? It doesn't necessarily buy you anything, unless you already need Zope. This was more for Zopatistas who need to run mailing lists, rather than Mailman people, not that it isn't a cool hack. I think I like Zope, too; I just can't get it to stand still long enough to learn it. Maybe I'm getting old... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From srichter@cbu.edu Mon Dec 10 04:22:33 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 09 Dec 2001 22:22:33 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <20011209231050.56953@scfn.thpl.lib.fl.us> References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> Message-ID: <5.1.0.14.2.20011209221915.02c1dd80@mail.cbu.edu> At 11:10 PM 12/9/2001 -0500, Jay R. Ashworth wrote: > > I don't understand Zope; can someone describe why I might want this, > > what it buys me, etc. (like a sales brochure)? > >It doesn't necessarily buy you anything, unless you already need Zope. Right, ZMailman is not for people not using Zope. However, it makes the integration of Mailing List functionality into your Web Site so easy, that I thought some of you might be interested. >This was more for Zopatistas who need to run mailing lists, rather than >Mailman people, not that it isn't a cool hack. Yes, and I think quite some people need that. Just looking at all these CMS and community sites... >I think I like Zope, too; I just can't get it to stand still long >enough to learn it. Maybe I'm getting old... Well, try to get into Zope 3.0, which is being built at the moment. It makes use of the latest development and design patterns, so it is good to look at it in anyway, whether you are interested in Zope or not. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From claw@kanga.nu Mon Dec 10 04:52:52 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 09 Dec 2001 20:52:52 -0800 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: Message from Stephan Richter of "Sun, 09 Dec 2001 19:48:56 CST." <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: <12640.1007959972@kanga.nu> On Sun, 09 Dec 2001 19:48:56 -0600 Stephan Richter wrote: > At 05:02 PM 12/9/2001 -0800, J C Lawrence wrote: >> On Sun, 09 Dec 2001 16:34:53 -0800 Dan Mick >> wrote: >>> I don't understand Zope; can someone describe why I might want >>> this, what it buys me, etc. (like a sales brochure)? >> Think a semi-OO based PHP setup where the OO as[ects extended not >> only to the internal language, but also to the construction of >> page elements and templates, and of course, instead of using PHP, >> use Python and much more cleanly abstracted DB interface. >> Probably the biggest other difference is that Zope natievly works >> off a single unified store rather than the filesystem. > Yes, that is pretty good, even though comparing Zope/Python to PHP > is not really possible. True, but for a generally non-Web person (into which camp I believe Dan falls), I felt it was a reasonable give-him-a-basic-grok description. As with all such generalities, it suffers in the details. > First of all, the Python team and the Zope team work all for the > same company Zope Corp. Which doesn't really affect the definition of Zope as a product much at all, but whatever. > If you like Python and need to do Web applications a lot, you > should have a look at Zope (www.zope.org). It is a very nice > software and does a lot of things for you. Aye, Zope is a nice system. I spent quite a while looking at it for what I want to do before finally backing away. Its not that Zope was bad or inadequate, just that I want to take a much more laissez faire approach to inter component and system integration that Zope (at that time) would seem to encourage. (Things may have changed) > Furthermore, for the Mailman 3.0 release I would like to make a > case for using the ZODB (not the entire Zope package!) for storing > our data structures, since we will not have to worry about file > locking and data storage in general anymore. There's some good reason for this, but I suspect a better case could be made for moving to an even more platform and tool agnostic data storage system, making Mailman that much easier to integrate and tie in with other systems without having to add plugins, adaptors, or other potential-source-of-failure fiddly bits in the picture. I know Barry is excited by the ZODB prospect. > As you might have noticed, this is really what I am interested in, > because having tighter integrations between Web tools and Mailman, > could give Mailman a huge boost in usage. We should be careful over the distinction between "tighter integration with Zope" and "tighter integration with web tools". The two don't necessarily have to be different, and much of the work for Zope integration lends itself well to general integration, but I would like to see the interfaces there be kept extremely abstract and local system independent. Ever thought about queue manipulation and injection by external tools and processes? It gets really interesting once you start messing with very large mail systems or systems ala Chuq's. but, I've commented on this previously, its all in the archives (mostly in the early 2.1/3.0 design discussions between Chug, Barry, Nigel, (some others I shamefully forget) and myself) so I'll leave this here. > In fact, the current ZMailman release does already some nice > things, but it will be even better, once the data is stored in the > ZODB. Would making the ZODB transition also make it easier to move to LDAP? SQL? ODBC? XML/RPC? SOAP? Driving Mailman from an external queue processing system ala (eg) MQS? Those are the sorts of generic integrative data access things I'm interested in. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From jra@baylink.com Mon Dec 10 05:19:35 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 10 Dec 2001 00:19:35 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <5.1.0.14.2.20011209221915.02c1dd80@mail.cbu.edu>; from Stephan Richter on Sun, Dec 09, 2001 at 10:22:33PM -0600 References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <20011209231050.56953@scfn.thpl.lib.fl.us> <5.1.0.14.2.20011209221915.02c1dd80@mail.cbu.edu> Message-ID: <20011210001935.40439@scfn.thpl.lib.fl.us> On Sun, Dec 09, 2001 at 10:22:33PM -0600, Stephan Richter wrote: > At 11:10 PM 12/9/2001 -0500, Jay R. Ashworth wrote: > > > I don't understand Zope; can someone describe why I might want this, > > > what it buys me, etc. (like a sales brochure)? > > > >It doesn't necessarily buy you anything, unless you already need Zope. > > Right, ZMailman is not for people not using Zope. However, it makes the > integration of Mailing List functionality into your Web Site so easy, that > I thought some of you might be interested. Ok, good; I'm glad I pegged it. I'm one of those -- I propose to use Zope to build a bunch o'websites that are on my plate; I'll need this integration. Will it integrate directly with UserFolders, so users can do their mailing list stuff on their home page? > >This was more for Zopatistas who need to run mailing lists, rather than > >Mailman people, not that it isn't a cool hack. > > Yes, and I think quite some people need that. Just looking at all these CMS > and community sites... You bet. > >I think I like Zope, too; I just can't get it to stand still long > >enough to learn it. Maybe I'm getting old... > > Well, try to get into Zope 3.0, which is being built at the moment. It > makes use of the latest development and design patterns, so it is good to > look at it in anyway, whether you are interested in Zope or not. Alas all the books are still 2.2/2.4ish. Any decent non-zoo tutorials? (WADR to whomever wrote that particular tutorial track, it stinks.) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From srichter@cbu.edu Mon Dec 10 05:35:24 2001 From: srichter@cbu.edu (Stephan Richter) Date: Sun, 09 Dec 2001 23:35:24 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <20011210001935.40439@scfn.thpl.lib.fl.us> References: <5.1.0.14.2.20011209221915.02c1dd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <3C14032D.3754360B@utopia.west.sun.com> <20011209231050.56953@scfn.thpl.lib.fl.us> <5.1.0.14.2.20011209221915.02c1dd80@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011209232934.02ec63b0@mail.cbu.edu> > > Right, ZMailman is not for people not using Zope. However, it makes the > > integration of Mailing List functionality into your Web Site so easy, that > > I thought some of you might be interested. > >Ok, good; I'm glad I pegged it. I'm one of those -- I propose to use >Zope to build a bunch o'websites that are on my plate; I'll need this >integration. Cool, I am glad you can use the product right away for a project. >Will it integrate directly with UserFolders, so users can do their >mailing list stuff on their home page? Yes, there is a proof-of-concept (not working) ZMMUserFolder as part of the product. But simply by providing the Mailman API in Zope will help you with this task. But let's take that discussion to the ZMailman list, since it is inappropriate for this one... > > Well, try to get into Zope 3.0, which is being built at the moment. It > > makes use of the latest development and design patterns, so it is good to > > look at it in anyway, whether you are interested in Zope or not. > >Alas all the books are still 2.2/2.4ish. Any decent non-zoo tutorials? >(WADR to whomever wrote that particular tutorial track, it stinks.) Well, Zope 3.0 is in the early stages of development right now. So, it is not really ready for use yet. ZMailman still uses 2.5. What do you mean with non-zoo tutorials? Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From barry@zope.com Mon Dec 10 05:36:14 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Dec 2001 00:36:14 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: <15380.18894.385539.984111@anthem.wooz.org> >>>>> "SR" == Stephan Richter writes: SR> Furthermore, for the Mailman 3.0 release I would like to make SR> a case for using the ZODB (not the entire Zope package!) for SR> storing our data structures, since we will not have to worry SR> about file locking and data storage in general SR> anymore. I don't have a lot of time to respond to this thread (my band is in the studio for the last few days ;). So let me just mention that I've long thought ZODB was a good fit for Mailman. Here's why I think the story will be even better in the long(er) term. We (Pythonlabs) are taking over more responsibilities for the development of ZODB, especially w.r.t. ZODB4, the next generation. The idea is to componentize things enough so that we can provide a basic persistence service in standard Python, while parts like the transaction mechanism and the storages can all be pluggable. ZODB3 already goes a long way here, and we will soon have a standalone ZODB release that requires none of Zope (or at least provides the parts of Zope you need). ZODB4 will be completely independent of Zope, and should provide robust, transactional persistent storage for any Python application. This may even become part of the standard library for Python 2.3. Note that most of the interfaces in ZODB are well defined, especially beween the database and connection objects, and the storage. I am indeed responsible for the Berkeley-based storage. We've had some performance issues lately due to BDB's lack of large blob support, but I think I have an approach that will improve things. ZODB has many advantages for the Python application, not the least of which is near total transparency for the Python programmer. You don't have to think about much to add persistence to your Python app with ZODB. Note I don't say "database" here because IMHO that implies a bunch of other properties such as searching. Persistence fills all of Mailman's needs except archive searching, and there should be other components that can take care of this. Now, whether Mailman 3.0 will be organized around a set of API that hide ZODB, and ZODB lives underneath those APIs, or whether it's defined in terms of ZODB and external storages like LDAP are hooked in through ZODB's interfaces remains to be seen. I tend to the think the former will be best from an evolutionary standpoint. In any event it is a "requirement" that Mailman play nice with existing systems, web, authentication, etc., just like it plays nice with many different MTAs, web servers, and web browsers today. I likely wouldn't require ZODB unless it was provided by a standard, required version of Python. -Barry From barry@zope.com Mon Dec 10 05:38:08 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Dec 2001 00:38:08 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> <12640.1007959972@kanga.nu> Message-ID: <15380.19008.161363.541843@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> We should be careful over the distinction between "tighter JCL> integration with Zope" and "tighter integration with web JCL> tools". The two don't necessarily have to be different, and JCL> much of the work for Zope integration lends itself well to JCL> general integration, but I would like to see the interfaces JCL> there be kept extremely abstract and local system JCL> independent. Bingo. -Barry From barry@zope.com Mon Dec 10 05:41:40 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Dec 2001 00:41:40 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> <3C14230D.19571051@utopia.west.sun.com> Message-ID: <15380.19220.962186.832544@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Security is the one thing I see as "better with Zope". But that's irrelevant to the ZODB issue, since there is no security in ZODB. That's left to higher levels in the application. There may (someday) be (optional) support for quotas in some storages, just as today there is optional support for undo, versions, revisions, packless operation, etc. -Barry From barry@zope.com Mon Dec 10 05:47:22 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Dec 2001 00:47:22 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> <5.1.0.14.2.20011209211616.02e2fe70@mail.cbu.edu> Message-ID: <15380.19562.674547.362565@anthem.wooz.org> >>>>> "SR" == Stephan Richter writes: SR> This is a good point, however I think the current mailman data SR> structure looks like a big hack (I am sorry to say that, but SR> you can clearly see that Mailman grew over the last years). And it has. I've tried to clean some of it up through the MemberAdaptor interface. What Mailman needs is an API for the list-, vhost-, and site-specific data being slung around. SR> So they need to be reimplemented again in anyway and I would Not reimplemented, re-organized! But yes, Mailman's current state of disarray is a good example of how a non-transparent database can be wedged in to a Python application. ZODB provides a good example of how a transparent, language friendly solution can make life much easier. -Barry From srichter@cbu.edu Mon Dec 10 06:00:51 2001 From: srichter@cbu.edu (Stephan Richter) Date: Mon, 10 Dec 2001 00:00:51 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <15380.19562.674547.362565@anthem.wooz.org> References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> <5.1.0.14.2.20011209211616.02e2fe70@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011209235401.02ec4500@mail.cbu.edu> >And it has. I've tried to clean some of it up through the >MemberAdaptor interface. What Mailman needs is an API for the >list-, vhost-, and site-specific data being slung around. Yeah, the vhost- and site-specific info was already a problem in ZMailman. You simply need an object above mailing lists, which I called Mailman Folder (not the best name I know). There you can save all the specific site and host information and all the other default values. > SR> So they need to be reimplemented again in anyway and I would > >Not reimplemented, re-organized! Okay, if you want to call it like that. BTW, I think the MemberAdaptor is already a good step, but it still does not clean it up completely yet. I still saw the members' language setting being saved in a separate attribute 'language' inside the MailList object.... (just to name one) There is a lot of work to do with the data structure interface... I cross my fingers and hope I will have enough time to make a class design over break, similar to the one I started at http://demo.iuveno-net.de/iuveno/Products/ZMailman/Documentation. Then some of the real issues will become obvious. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From srichter@cbu.edu Mon Dec 10 06:09:16 2001 From: srichter@cbu.edu (Stephan Richter) Date: Mon, 10 Dec 2001 00:09:16 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <15380.18894.385539.984111@anthem.wooz.org> References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011210000540.02eba300@mail.cbu.edu> At 12:36 AM 12/10/2001 -0500, barry@zope.com wrote: >We (Pythonlabs) are taking over more responsibilities for the >development of ZODB, especially w.r.t. ZODB4, the next generation. >The idea is to componentize things enough so that we can provide a >basic persistence service in standard Python, while parts like the >transaction mechanism and the storages can all be pluggable. ZODB3 >already goes a long way here, and we will soon have a standalone ZODB >release that requires none of Zope (or at least provides the parts of >Zope you need). ZODB4 will be completely independent of Zope, and >should provide robust, transactional persistent storage for any Python >application. This may even become part of the standard library for >Python 2.3. Uhhh, that sounds exciting!!!! :-) >Now, whether Mailman 3.0 will be organized around a set of API that >hide ZODB, and ZODB lives underneath those APIs, or whether it's >defined in terms of ZODB and external storages like LDAP are hooked in >through ZODB's interfaces remains to be seen. I tend to the think the >former will be best from an evolutionary standpoint. I agree. >In any event it >is a "requirement" that Mailman play nice with existing systems, web, >authentication, etc., just like it plays nice with many different >MTAs, web servers, and web browsers today. Yes, I think that should be definitely priority #1. >I likely wouldn't require >ZODB unless it was provided by a standard, required version of Python. Interesting. That would make your first approach above not possible. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From barry@zope.com Mon Dec 10 14:27:57 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Dec 2001 09:27:57 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> <5.1.0.14.2.20011209211616.02e2fe70@mail.cbu.edu> <5.1.0.14.2.20011209235401.02ec4500@mail.cbu.edu> Message-ID: <15380.50797.875128.440537@anthem.wooz.org> >>>>> "SR" == Stephan Richter writes: SR> Okay, if you want to call it like that. BTW, I think the SR> MemberAdaptor is already a good step, but it still does not SR> clean it up completely yet. I still saw the members' language SR> setting being saved in a separate attribute 'language' inside SR> the MailList object.... (just to name one) Right, but that's a legacy implementation of an abstract interface. IOW, all of Mailman's access to user data[*] should go through the abstrace interface. The only existing /implementation/ of that interface is OldStyleMemberships.py because I don't want to have to deal with the data migration problem in MM2.1. So, you could provide a new implementation of the MemberAdapter.py interface where all the data was stored in ZODB (or elsewhere, like LDAP) and Mailman should still work. A fresh install of this wouldn't have the legacy data problem, so it could essentially just ignore OldStyleMemberships.py. That's the idea anyway. -Barry [*] There may still be one or two places where member data is sucked out of MailList attributes, and if so I want to know about it. I already know about bounce_info, and that will soon be converted over when I have time to finish the bounce processor rewrite. Note also that you'll have to hook in any external store's transactional boundaries with MailList.Save() and maybe MailList.Load(). Certainly MailList.Save() in a ZODB backed user database should contain a get_transaction().commit(). From barry@zope.com Mon Dec 10 14:30:27 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Dec 2001 09:30:27 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> <5.1.0.14.2.20011209211616.02e2fe70@mail.cbu.edu> <5.1.0.14.2.20011209235401.02ec4500@mail.cbu.edu> Message-ID: <15380.50947.221644.44676@anthem.wooz.org> >>>>> "SR" == Stephan Richter writes: >> And it has. I've tried to clean some of it up through the >> MemberAdaptor interface. What Mailman needs is an API for the >> list-, vhost-, and site-specific data being slung around. SR> Yeah, the vhost- and site-specific info was already a problem SR> in ZMailman. You simply need an object above mailing lists, SR> which I called Mailman Folder (not the best name I SR> know). There you can save all the specific site and host SR> information and all the other default values. I'd like to see a refactoring of configuration/authority levels in MM3.0 so that e.g. a site admin could set some variables and decide which can overridden by a vhost owner (or I think as JC once pointed out, more generally a group owner). The vhost owner could then decide what to delegate to list owners. Most of this has been discussed previously on this list. -Barry From barry@zope.com Mon Dec 10 14:36:07 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Dec 2001 09:36:07 -0500 Subject: [Mailman-Developers] ZMailman 2.1 preview References: <3C14032D.3754360B@utopia.west.sun.com> <5.1.0.14.2.20011209095639.00affd80@mail.cbu.edu> <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> <5.1.0.14.2.20011210000540.02eba300@mail.cbu.edu> Message-ID: <15380.51287.203344.471024@anthem.wooz.org> >>>>> "SR" == Stephan Richter writes: >> application. This may even become part of the standard library >> for Python 2.3. SR> Uhhh, that sounds exciting!!!! :-) Indeed, especially now that it's caught Guido's interest. :) SR> Yes, I think that should be definitely priority #1. >> I likely wouldn't require ZODB unless it was provided by a >> standard, required version of Python. SR> Interesting. That would make your first approach above not SR> possible. It all depends. Right now our external requirements are minimal I think, and the one forward compatibility issue is with the email package, which we can provide as a distutils thing. Some future Mailman will require at least Python 2.2 (/not/ MM2.1) and at that point we can stop distributing email as a separate package. If we can do the same thing with a future standard ZODB (maybe called PODB??? :), that's fine. I can almost guarantee that Python 2.2 at least will be required for that though since it requires new-style classes, replacing the role of what in classic Python is filled by ExtensionClass. That all that is waaayyy down the road. -Barry From Dan Mick Tue Dec 11 01:55:24 2001 From: Dan Mick (Dan Mick) Date: Mon, 10 Dec 2001 17:55:24 -0800 (PST) Subject: [Mailman-Developers] ZMailman 2.1 preview Message-ID: <200112110155.RAA22515@utopia.West.Sun.COM> > > > I don't understand Zope; can someone describe why I might want this, > > > what it buys me, etc. (like a sales brochure)? > > > >It doesn't necessarily buy you anything, unless you already need Zope. > > Right, ZMailman is not for people not using Zope. However, it makes the > integration of Mailing List functionality into your Web Site so easy, that > I thought some of you might be interested. > > >This was more for Zopatistas who need to run mailing lists, rather than > >Mailman people, not that it isn't a cool hack. Ah. OK. Never mind. From Nigel.Metheringham@VData.co.uk Tue Dec 11 10:15:06 2001 From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham) Date: 11 Dec 2001 10:15:06 +0000 Subject: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP In-Reply-To: References: <200112070201.SAA00466@utopia.West.Sun.COM> <22305.1007691387@kanga.nu> <15376.13339.661615.544307@anthem.wooz.org> <3C10AACC.D26D256C@west.sun.com> <1007726038.1219.8.camel@gaspode.localnet> <3C1115ED.DFB42D6B@nleaudio.com> Message-ID: <1008065706.9547.4.camel@gaspode.localnet> On Sat, 2001-12-08 at 03:16, John W Baxter wrote: > Exim's delayed delivery warnings are "orderly" enough that it would be > quite easy to ignore them in bounce processing. In several ways, they > don't look like failure messages. The other thing is that there is a condition on the generation of delay warning messages. The default configuration for this condition for a few years now has been that mailing list mail (identified by the Precedence: header) does not have delay warnings generated for it. See http://www.exim.org/exim-html-3.30/doc/html/spec_11.html#SEC206 If an admin is running an exim old enough that this conditional is not available or is not defaulted, then take a baseball bat to them until they see the error of their ways. If an admin has changed the condition such that it now sends delay warnings in response to mailing list mail, then add some nails to your baseball bat and wield it appropriately on said admin. Nigel. From marc_news@valinux.com Mon Dec 10 08:51:41 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 00:51:41 -0800 Subject: [Mailman-Developers] bin/update: "cannot import name SimpleCookie" in mailman cvs Message-ID: <20011210005141.A21219@magic.merlins.org> So, when updating from 2.0 to cvs, make install ran fine up to update: Compiling /var/local/mailman/Mailman/pythonlib/StringIO.py ... Compiling /var/local/mailman/Mailman/pythonlib/__init__.py ... Compiling /var/local/mailman/Mailman/pythonlib/cgi.py ... Compiling /var/local/mailman/Mailman/pythonlib/mailbox.py ... Compiling /var/local/mailman/Mailman/pythonlib/rfc822.py ... Compiling /var/local/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/var/local/mailman/Mailman/MailList.py", line 58, in ? from Mailman.SecurityManager import SecurityManager File "/var/local/mailman/Mailman/SecurityManager.py", line 62, in ? from Cookie import SimpleCookie as Cookie ImportError: cannot import name SimpleCookie make: *** [update] Error 1 I have python 2.1.1 I move the lists off, completed the install, brought a list back, ran update by hand, and it worked. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 08:54:24 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 00:54:24 -0800 Subject: [Mailman-Developers] Buglet in ./configure (mailman cvs) Message-ID: <20011210005424.B21219@magic.merlins.org> ./configure doesn't replace @PYTHON@ for scripts in mailman/contrib Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 08:56:02 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 00:56:02 -0800 Subject: [Mailman-Developers] Update for README.exim (cvs) Message-ID: <20011210005601.C21219@magic.merlins.org> Hopefully I got this right: --- README.EXIM.mailman Sun Dec 9 23:08:00 2001 +++ README.EXIM Mon Dec 10 00:19:44 2001 @@ -71,6 +71,8 @@ ## respectively ## Mailman is installed in MAILMAN_HOME ## Mailman is configured to be invoked as user exim + +# Mailman commands to run list_transport: driver = pipe command = MAILMAN_WRAP post ${lc:$local_part} @@ -79,66 +81,103 @@ user = MAILMAN_UID group = MAILMAN_GID -list_request_transport: +list_bounces_transport: + driver = pipe + command = MAILMAN_WRAP bounces ${lc:$local_part} + current_directory = MAILMAN_HOME + home_directory = MAILMAN_HOME + user = MAILMAN_UID + group = MAILMAN_GID + +list_join_transport: + driver = pipe + command = MAILMAN_WRAP join ${lc:$local_part} + current_directory = MAILMAN_HOME + home_directory = MAILMAN_HOME + user = MAILMAN_UID + group = MAILMAN_GID + +list_leave_transport: driver = pipe - command = MAILMAN_WRAP mailcmd ${lc:$local_part} + command = MAILMAN_WRAP leave ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID -list_admin_transport: +list_owner_transport: driver = pipe - command = MAILMAN_WRAP mailowner ${lc:$local_part} + command = MAILMAN_WRAP owner ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID +list_request_transport: + driver = pipe + command = MAILMAN_WRAP request ${lc:$local_part} + current_directory = MAILMAN_HOME + home_directory = MAILMAN_HOME + user = MAILMAN_UID + group = MAILMAN_GID ### end of transports section fragment Directors config file section ## Directors section [this deals with local addresses] ## -## First 2 directors rewrite list-owner or owner-list to list-admin -## This is only done if the list exists. ## List existence checks are done by seeing if the file -## MAILMAN_HOME/lists//config.pck -## exists. +## MAILMAN_HOME/lists//config.pck exists. -list_owner_director: +list_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck - suffix = "-owner" - new_address = "${lc:$local_part}-admin@${domain}" + transport = list_transport -owner_list_director: + +list_bounces_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck - prefix = "owner-" - new_address = "${lc:$local_part}-admin@${domain}" + suffix = "-bounces" + transport = list_bounces_transport -## -## Next 3 directors direct admin, request and list mail to the appropriate -## transport. List existence is checked as above. +list_join_director: + driver = smartuser + require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck + suffix = "-join" + transport = list_join_transport -list_admin_director: +list_leave_director: driver = smartuser - suffix = -admin require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck - transport = list_admin_transport + suffix = "-leave" + transport = list_leave_transport + +list_owner_director: + driver = smartuser + require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck + suffix = "-owner" + transport = list_owner_transport list_request_director: driver = smartuser - suffix = -request require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck + suffix = "-request" transport = list_request_transport -list_director: + +# The following two are optional, but nice for backward compatibility +owner_list_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck - transport = list_transport + prefix = "owner-" + new_address = "${lc:$local_part}-owner@${domain}" + +list_admin_director: + driver = smartuser + suffix = -admin + require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck + new_address = "${lc:$local_part}-bounces@${domain}" ## End of directors fragment ## End of config files bits -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 09:07:10 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 01:07:10 -0800 Subject: [Mailman-Developers] Patch: securelinux_fix update (now check_perms_grsecurity) Message-ID: <20011210010709.D21219@magic.merlins.org> I've updated the docs, updated my script to work with grsecurity and with the new scripts in mailman cvs, and I've renamed it to reflect the changes diff -urN mailman.orig/README.LINUX mailman/README.LINUX --- mailman.orig/README.LINUX Mon Dec 10 01:00:52 2001 +++ mailman/README.LINUX Mon Dec 10 01:03:19 2001 @@ -8,18 +8,12 @@ GNU/Linux seems to be the most popular platform on which to run Mailman. Here are some hints on getting Mailman to run on Linux: - If you are running secure_linux, you probably have restricted - hardlinks turned on. Gergely Madarasz says that this not only - restricts hardlinks in /tmp, but also in any non +t directory. This - can cause "Operation not permitted" errors in MailList.Save() -- you - will see a traceback. You must turn restricted hardlinks off. This - is also known under the name of Openwall Security Patches. - - There is a workaround for this problem, you can use securelinux_fix.py - in the contrib directory (see the README.securelinux_fix.py). Note - that the script will not work until you move it in your installed - Mailman tree in the bin directory. + If you are getting errors with hard link creations and/or you are using + a special secure kernel (securelinux/openwall/grsecurity), see + contrib/README.check_perms_grsecurity. + Note that if you are using Linux Mandrake in secure mode, you are probably + concerned by this Local Variables: diff -urN mailman.orig/contrib/README.check_perms_grsecurity mailman/contrib/README.check_perms_grsecurity --- mailman.orig/contrib/README.check_perms_grsecurity Wed Dec 31 16:00:00 1969 +++ mailman/contrib/README.check_perms_grsecurity Mon Dec 10 01:00:08 2001 @@ -0,0 +1,14 @@ +The check_perms_grsecurity.py script, if copied in your installed +~mailman/bin/ directory and run from there will modify permissions of +files so that Mailman with extra restrictions imposed by linux kernel security +patches like securelinux/openwall in 2.2.x or grsecurity in 2.4.x + +The way it works is that it makes sure that the UID of any script that +touches config.pck is `mailman'. What this means however is that +scripts in ~mailman/bin will now only work if run as user mailman or +root (the script then changes its UID and GID to mailman). +To make grsecurity happy, we remove the group writeable bit on a directories +that contain binaries + +Enjoy +Marc MERLIN / - 2001/12/10 diff -urN mailman.orig/contrib/README.securelinux_fix mailman/contrib/README.securelinux_fix --- mailman.orig/contrib/README.securelinux_fix Mon Mar 12 11:28:45 2001 +++ mailman/contrib/README.securelinux_fix Wed Dec 31 16:00:00 1969 @@ -1,12 +0,0 @@ -The securelinux_fix.py script, if copied in your installed -~mailman/bin/ directory and run from there will modify permissions of -files so that Mailman works despite the securelinux (aka openwall) -symbolic and hard link restrictions. - -The way it works is that it makes sure that the UID of any script that -touches config.db is `mailman'. What this means however is that -scripts in ~mailman/bin will now only work if run as user mailman or -root (the script then changes its UID and GID to mailman). - -Enjoy -Marc MERLIN / diff -urN mailman.orig/contrib/check_perms_grsecurity.py mailman/contrib/check_perms_grsecurity.py --- mailman.orig/contrib/check_perms_grsecurity.py Wed Dec 31 16:00:00 1969 +++ mailman/contrib/check_perms_grsecurity.py Mon Dec 10 00:56:55 2001 @@ -0,0 +1,173 @@ +#! @PYTHON@ +# +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version 2 +# of the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +"""Fixes for running Mailman under the `secure-linux' patch or grsecurity. + +Run check_perms -f and only then check_perms_grsecurity.py -f +Note that you will have to re-run this script after a mailman upgrade and +that check_perms will undo part of what this script does + +If you use Solar Designer's secure-linux patch, it prevents a process from +linking (hard link) to a file it doesn't own. +Grsecurity (http://grsecurity.net/) can have the same restriction depending +on how it was built, including other restrictions like preventing you to run +a program if it is located in a directory writable by a non root user. + +As a result Mailman has to be changed so that the whole tree is owned by +Mailman, and the CGIs and some of the programs in the bin tree (the ones +that lock config.pck files) are SUID Mailman. The idea is that config.pck +files have to be owned by the mailman UID and only touched by programs that +are UID mailman. +At the same time, We have to make sure that at least 3 directories under +~mailman aren't writable by mailman: mail, cgi-bin, and bin + +Binary commands that are changed to be SUID mailman are also made unreadable +and unrunnable by people who aren't in the mailman group. This shouldn't +affect much since most of those commands would fail work if you weren't part +of the mailman group anyway. +Scripts in ~mailman/bin/ are not made suid or sgid, they need to be run by +user mailman or root to work. + +Marc / +2000/10/27 - Initial version for secure_linux/openwall and mailman 2.0 +2001/12/09 - Updated version for grsecurity and mailman 2.1 +""" + +import sys +import os +import paths +import re +import glob +from Mailman import mm_cfg +from Mailman.mm_cfg import MAILMAN_UID, MAILMAN_GID +from stat import * + +# Directories that we don't want writable by mailman. +dirstochownroot= ( 'mail', 'cgi-bin', 'bin' ) + +# Those are the programs that we patch so that they insist being run under the +# mailman uid or as root. +binfilestopatch= ( 'add_members', 'change_pw', 'check_db', 'clone_member', + 'config_list', 'newlist', 'qrunner', 'remove_members', + 'rmlist', 'sync_members', 'update', 'withlist' ) + +def main(argv): + binpath = paths.prefix + '/bin/' + droplib = binpath + 'CheckFixUid.py' + + if len(argv) < 2 or argv[1] != "-f": + print __doc__ + sys.exit(1) + + print "Making select directories owned and writable by root only" + for dir in dirstochownroot: + dirpath = paths.prefix + '/' + dir + os.chown(dirpath, 0, MAILMAN_GID) + os.chmod(dirpath, 02755) + print dirpath + + print + + file = paths.prefix + '/data/last_mailman_version' + print "Making" + file + "owned by mailman (not root)" + os.chown(file, MAILMAN_UID, MAILMAN_GID) + print + + if not os.path.exists(droplib): + print "Creating " + droplib + fp = open(droplib, 'w', 0644) + fp.write("""import sys +import os +from Mailman.mm_cfg import MAILMAN_UID, MAILMAN_GID + +class CheckFixUid: + if os.geteuid() == 0: + os.setgid(MAILMAN_GID) + os.setuid(MAILMAN_UID) + if os.geteuid() != MAILMAN_UID: + print "You need to run this script as root or mailman because it was configured to run" + print "on a linux system with a security patch which restricts hard links" + sys.exit() +""") + fp.close() + else: + print "Skipping creation of " + droplib + + + print "\nMaking cgis setuid mailman" + cgis = glob.glob(paths.prefix + '/cgi-bin/*') + + for file in cgis: + print file + os.chown(file, MAILMAN_UID, MAILMAN_GID) + os.chmod(file, 06755) + + print "\nMaking mail wrapper setuid mailman" + file= paths.prefix + '/mail/wrapper' + os.chown(file, MAILMAN_UID, MAILMAN_GID) + os.chmod(file, 06755) + print file + + print "\nEnsuring that all config.db/pck files are owned by Mailman" + cdbs = glob.glob(paths.prefix + '/lists/*/config.db*') + cpcks = glob.glob(paths.prefix + '/lists/*/config.pck*') + + for file in cdbs + cpcks: + stat = os.stat(file) + if (stat[ST_UID] != MAILMAN_UID or stat[ST_GID] != MAILMAN_GID): + print file + os.chown(file, MAILMAN_UID, MAILMAN_GID) + + print "\nPatching mailman scripts to change the uid to mailman" + + for script in binfilestopatch: + filefd = open(script, "r") + file = filefd.readlines() + filefd.close() + + patched = 0 + try: + file.index("import CheckFixUid\n") + print "Not patching " + script + ", already patched" + except ValueError: + file.insert(file.index("import paths\n")+1, "import CheckFixUid\n") + for i in range(len(file)-1, 0, -1): + object=re.compile("^([ ]*)main\(").search(file[i]) + # Special hack to support patching of update + object2=re.compile("^([ ]*).*=[ ]*main\(").search(file[i]) + if object: + print "Patching " + script + file.insert(i, + object.group(1) + "CheckFixUid.CheckFixUid()\n") + patched=1 + break + if object2: + print "Patching " + script + file.insert(i, + object2.group(1) + "CheckFixUid.CheckFixUid()\n") + patched=1 + break + + if patched==0: + print "Warning, file "+script+" couldn't be patched." + print "If you use it, mailman may not function properly" + else: + filefd=open(script, "w") + filefd.writelines(file) + +main(sys.argv) diff -urN mailman.orig/contrib/securelinux_fix.py mailman/contrib/securelinux_fix.py --- mailman.orig/contrib/securelinux_fix.py Thu Oct 4 07:45:36 2001 +++ mailman/contrib/securelinux_fix.py Wed Dec 31 16:00:00 1969 @@ -1,134 +0,0 @@ -#! @PYTHON@ -# -# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. -# -# This program is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License -# as published by the Free Software Foundation; either version 2 -# of the License, or (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - -"""Fixes for running Mailman under the `secure-linux' patch. - -If you use Solar Designer's secure-linux patch, it prevents a process from -linking (hard link) to a file it doesn't own. As a result Mailman has to be -changed so that the whole tree is owned by Mailman, and the CGIs and some of -the programs in the bin tree (the ones that lock config.pck files) are SUID -Mailman. The idea is that config.pck files have to be owned by the mailman -UID and only touched by programs that are UID mailman. - -If you have to run check_perms -f, make sure to also run securelinux_fix.py --f, which applies the necessary permission fixes. - -As a result, to prevent anyone from running privileged Mailman commands (since -the scripts are suid), binary commands that are changed to be SUID are also -unreadable and unrunnable by people who aren't in the mailman group. This -shouldn't affect much since most of those commands would fail work if you -weren't part of the mailman group anyway. - -Marc / 2000/10/27 -""" - -import sys -import os -import paths -import re -import glob -from Mailman import mm_cfg -from Mailman.mm_cfg import MAILMAN_UID, MAILMAN_GID -from stat import * - -# Those are the programs that we patch so that they insist being run under the -# mailman uid or as root. -binfilestopatch= ( 'add_members', 'check_db', 'clone_member', - 'config_list', 'move_list', 'newlist', 'remove_members', 'rmlist', - 'sync_members', 'update', 'withlist' ) - -def main(argv): - binpath = paths.prefix + '/bin/' - droplib = binpath + 'CheckFixUid.py' - - if len(argv) < 2 or argv[1] != "-f": - print __doc__ - sys.exit(1) - - if not os.path.exists(droplib): - print "Creating " + droplib - fp = open(droplib, 'w', 0644) - fp.write("""import sys -import os -from Mailman.mm_cfg import MAILMAN_UID, MAILMAN_GID - -class CheckFixUid: - if os.geteuid() == 0: - os.setgid(MAILMAN_GID) - os.setuid(MAILMAN_UID) - if os.geteuid() != MAILMAN_UID: - print "You need to run this script as root or mailman because it was configured to run" - print "on a linux system with the secure-linux patch which restricts hard links" - sys.exit() -""") - fp.close() - else: - print "Skipping creation of " + droplib - - - print "\nMaking cgis setuid mailman" - cgis = glob.glob(paths.prefix + '/cgi-bin/*') - - for file in cgis: - print file - os.chown(file, MAILMAN_UID, MAILMAN_GID) - os.chmod(file, 06755) - - print "\nMaking mail wrapper setuid mailman" - os.chown(paths.prefix + '/mail/wrapper', MAILMAN_UID, MAILMAN_GID) - os.chmod(paths.prefix + '/mail/wrapper', 06755) - - print "\nEnsuring that all config.pck files are owned by Mailman" - cdbs = glob.glob(paths.prefix + '/lists/*/config.pck*') - - for file in cdbs: - stat = os.stat(file) - if (stat[ST_UID] != MAILMAN_UID or stat[ST_GID] != MAILMAN_GID): - print file - os.chown(file, MAILMAN_UID, MAILMAN_GID) - - print "\nPatching mailman scripts to change the uid to mailman" - - for script in binfilestopatch: - filefd = open(script, "r") - file = filefd.readlines() - filefd.close() - - patched = 0 - try: - file.index("import CheckFixUid\n") - print "Not patching " + script + ", already patched" - except ValueError: - file.insert(file.index("import paths\n")+1, "import CheckFixUid\n") - for i in range(len(file)-1, 0, -1): - object=re.compile("^([ ]*)main\(").search(file[i]) - if object: - print "Patching " + script - file.insert(i, - object.group(1) + "CheckFixUid.CheckFixUid()\n") - patched=1 - break - - if patched==0: - print "Warning, file "+script+" couldn't be patched." - print "If you use it, mailman may not function properly" - else: - filefd=open(script, "w") - filefd.writelines(file) - -main(sys.argv) -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 09:09:18 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 01:09:18 -0800 Subject: [Mailman-Developers] Documentation update needed for Default.py Message-ID: <20011210010917.E21219@magic.merlins.org> moremagic [mc]# ./rmlist test2 Not removing archives. Reinvoke with -a to remove them. Traceback (most recent call last): File "./rmlist", line 122, in ? main() File "./rmlist", line 100, in main __import__(modname) ImportError: No module named None Mmmh, aaah, ok: # MTA should name a module in Mailman/MTA which provides the MTA specific # functionality for creating and removing lists. Some MTAs like Exim can be # configured to automatically recognize new lists, in which case the MTA # variable should be set to None. Use 'Manual' to print new aliases to # standard out (or send an email to the site list owner) for manual twiddling # of an /etc/aliases style file. Use 'Postfix' if you are using the Postfix # MTA -- but then also see POSTFIX_STYLE_VIRTUAL_DOMAINS. MTA = 'None' The comments can be misleading, 'None' is really supposed to be '' I'm guessing others might get caught by this rmlist foo also says: re-invoque with -a to remove archives That said, if you re-run it with -a, the list is gone by then so it can't remove the archives. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 09:13:55 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 01:13:55 -0800 Subject: [Mailman-Developers] BUG in generation of List-Archive in mailman cvs Message-ID: <20011210011354.F21219@magic.merlins.org> I get the following headers: List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: The last header is entirely incorrect. The hostname should also be list.merlins.org, and the archives aren't in pipermail, they are in archives. The URL should be: List-Archive: as I have: PUBLIC_ARCHIVE_URL = 'http://%(hostname)s/archives/%(listname)s' in mm_cfg.py Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 09:19:07 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 01:19:07 -0800 Subject: [Mailman-Developers] Patch: newlist in mailman cvs Message-ID: <20011210011907.G21219@magic.merlins.org> There are two changes here: The first one is to introduce a hook to fail list creations if some test doesn't succeed. It might be better to roll than in the current MTA module as a separate option method, I just couldn't find how to test for the presence of a method in a class Why do I need this? On my systems at VA, I check that listname@lists.vasoftware.com doesn't conflict with an existing listname@vasoftware.com More explicitely, I do this: if Utils.list_exists(listname): usage(1, 'List already exists: ' + listname) fd=os.popen("expn " + listname + "@valinux.com") file=fd.read() tofind=re.compile("USER UNKNOWN") if not tofind.search(file): print "mail.valinux.com already has an email matching " + listname + "@v alinux.com" sys.exit() The second addition simply creates an empty dir for pipermail so that people stop telling me that the list archive link is broken when the list is empty. --- newlist.mailman Sun Dec 9 21:10:39 2001 +++ newlist Sun Dec 9 22:32:24 2001 @@ -130,6 +130,12 @@ listpasswd = listpasswd.strip() if not listpasswd: usage(1, _('The list password cannot be empty')) + + # Allow for check and a possible reject before the list is created. + if mm_cfg.MTA_PRECHECK: + modname = 'Mailman.MTA.' + mm_cfg.MTA_PRECHECK + __import__(modname) + sys.modules[modname].create(mlist) mlist = MailList.MailList() try: @@ -162,6 +168,12 @@ modname = 'Mailman.MTA.' + mm_cfg.MTA __import__(modname) sys.modules[modname].create(mlist) + + # Create an empty directory for pipermail (stops the URL not found when + # you try to view the archives of a list that hasn't had posts yet) + dirpath = paths.prefix + '/archives/private/' + listname + os.mkdir(dirpath) + os.chmod(dirpath, 02775) # And send the notice to the list owner if not quiet: Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 09:33:48 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 01:33:48 -0800 Subject: [Mailman-Developers] my top 3 wishlist for mailman cvs Message-ID: <20011210013348.H21219@magic.merlins.org> First, of all, I'd like to say that I really like many of the changes in improvements in mailman cvs, some of them will same me a lot of time with not having to deal with confused users anymore :-) I however, have 3 items left on my wishlist :-) #1 Very big feature request: The main list admin's cookie should be valid for all the lists. Having to retype the list password over and over again as I hop from list to list is very tiring. #2 Is there any way to have mailman still understand admin password in crypt/md5 format? It could read them and only generate the new kind. Resetting 16,000+ list admin passwords on sourceforge.net is going to be a major showstopper (I know, you can regenerate all of them and Email them automatically, but still...) #3 I'd really like to see a nomail field and a disabled field (one settable by the user, one set by mailman when it disables a member) Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@valinux.com Mon Dec 10 09:43:14 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Dec 2001 01:43:14 -0800 Subject: [Mailman-Developers] Re: my top 3 wishlist for mailman cvs In-Reply-To: <20011210013348.H21219@magic.merlins.org>; from marc_news@valinux.com on Mon, Dec 10, 2001 at 01:33:48AM -0800 References: <20011210013348.H21219@magic.merlins.org> Message-ID: <20011210014312.J21219@magic.merlins.org> On Mon, Dec 10, 2001 at 01:33:48AM -0800, Marc MERLIN wrote: > First, of all, I'd like to say that I really like many of the changes in > improvements in mailman cvs, some of them will same me a lot of time with > not having to deal with confused users anymore :-) > > I however, have 3 items left on my wishlist :-) > > #1 Very big feature request: > The main list admin's cookie should be valid for all the lists. Having to > retype the list password over and over again as I hop from list to list is > very tiring. I meant the site password. If I authenticate with the site password, I should get a magic cookie that lets me in all the lists. If some lists happen to share the same password and somehow by typing the list password on one, I can get on other ones if they share the same password, that would be even better, but I don't need that near as bad. Thanks :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Wed Dec 12 08:17:49 2001 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 12 Dec 2001 00:17:49 -0800 Subject: [Mailman-Developers] exceptions in new bin/arch CVS code Message-ID: <20011212001748.A10584@magic.merlins.org> --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've run a big list archive through arch, and I'm finding a few bugs: (I ran cleanarch on it first, and the same archive works with mm 2.0's archiver) #1 moremagic:/var/local/mailman/bin# ./arch svlug /tmp/mesg #00001 <199807080009.RAA06108@meg.mall-net.com> figuring article archives 1998-July Traceback (most recent call last): File "./arch", line 129, in ? main() File "./arch", line 118, in main archiver.processUnixMailbox(fp, Article) File "/var/local/mailman/Mailman/Archiver/pipermail.py", line 525, in processUnixMailbox m = mbox.next() File "/var/local/mailman/Mailman/pythonlib/mailbox.py", line 38, in next return self.factory(_Subfile(self.fp, start, stop)) File "/var/local/mailman/Mailman/Mailbox.py", line 77, in scrubber return mailbox.scrub(msg) File "/var/local/mailman/Mailman/Mailbox.py", line 97, in scrub return self._scrubber(self._mlist, msg) File "/var/local/mailman/Mailman/Handlers/Scrubber.py", line 154, in process url = save_attachment(mlist, part) File "/var/local/mailman/Mailman/Handlers/Scrubber.py", line 301, in save_attachment fp.write(decodedpayload) TypeError: argument must be string or read-only character buffer, not instance I've narrowed the message that triggers the bug down to: ---------------------------------------------------------------------------- >From owner-svlug@svlug.svlug.org Tue Jul 7 17:20:00 1998 From: Chris DiBona To: svlug@svlug.org Subject: foo Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=------------A5D4C271202F9966AFAA3659 Content-ID: --------------A5D4C271202F9966AFAA3659 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: --------------A5D4C271202F9966AFAA3659-- ---------------------------------------------------------------------------- #2 moremagic:/var/local/mailman/bin# ./arch svlug /tmp/mesg2 Traceback (most recent call last): File "./arch", line 129, in ? main() File "./arch", line 118, in main archiver.processUnixMailbox(fp, Article) File "/var/local/mailman/Mailman/Archiver/pipermail.py", line 525, in processUnixMailbox m = mbox.next() File "/var/local/mailman/Mailman/pythonlib/mailbox.py", line 38, in next return self.factory(_Subfile(self.fp, start, stop)) File "/var/local/mailman/Mailman/Mailbox.py", line 77, in scrubber return mailbox.scrub(msg) File "/var/local/mailman/Mailman/Mailbox.py", line 97, in scrub return self._scrubber(self._mlist, msg) File "/var/local/mailman/Mailman/Handlers/Scrubber.py", line 114, in process url = save_attachment(mlist, part, filter_html=0) File "/var/local/mailman/Mailman/Handlers/Scrubber.py", line 214, in save_attachment decodedpayload = msg.get_payload(decode=1) File "/usr/lib/python2.1/site-packages/email/Message.py", line 123, in get_payload return Utils._bdecode(payload) File "/usr/lib/python2.1/site-packages/email/Utils.py", line 56, in _bdecode value = base64.decodestring(s) File "/usr/lib/python2.1/base64.py", line 47, in decodestring decode(f, g) File "/usr/lib/python2.1/base64.py", line 31, in decode s = binascii.a2b_base64(line) binascii.Error: Incorrect padding The faulty message is attached (/tmp/mesg2) #3 Traceback (most recent call last): File "./arch", line 129, in ? main() File "./arch", line 118, in main archiver.processUnixMailbox(fp, Article) File "/var/local/mailman/Mailman/Archiver/pipermail.py", line 525, in processUnixMailbox m = mbox.next() File "/var/local/mailman/Mailman/pythonlib/mailbox.py", line 38, in next return self.factory(_Subfile(self.fp, start, stop)) File "/var/local/mailman/Mailman/Mailbox.py", line 77, in scrubber return mailbox.scrub(msg) File "/var/local/mailman/Mailman/Mailbox.py", line 97, in scrub return self._scrubber(self._mlist, msg) File "/var/local/mailman/Mailman/Handlers/Scrubber.py", line 154, in process url = save_attachment(mlist, part) File "/var/local/mailman/Mailman/Handlers/Scrubber.py", line 301, in save_attachment fp.write(decodedpayload) TypeError: argument must be string or read-only character buffer, not instance I don't know if the problem is like #1 or not (probably) ---------------------------------------------------------------------------- >From owner-svlug@svlug.svlug.org Thu Feb 11 13:12:28 1999 From: linux To: svlug@svlug.org Date: Thu, 11 Feb 1999 11:57:38 -0800 Subject: [svlug] X-mailer: Phoenix Mail 0.92 Standard Edition MIME-Version: 1.0 Content-type: multipart/mixed; boundary=-----Phoenix-Boundary-07081998- Content-Length: 1801 Lines: 35 -------Phoenix-Boundary-07081998- Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Hello all, I am brand new to Linux and to networking. I would like to get some opinions from experienced Linux users on a configuration of three systems. Here is how it brakes down: (...) -------Phoenix-Boundary-07081998--- ---------------------------------------------------------------------------- -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mesg2 >From owner-svlug@svlug.svlug.org Fri Dec 18 17:54:07 1998 From: "Hyouck Kim" To: "Linux Usergroup" Subject: [svlug] I Think MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01BE2B34.E5B83120" Content-Length: 2676 Lines: 49 This is a multi-part message in MIME format. ------=_NextPart_000_0081_01BE2B34.E5B83120 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGkuDQoNCkkgdGhpbmsgbGludXggbmVlcyB2aXN1YWwgbW9kZWxpbmcgdG9vbHMgbGlrZSByYXRp b25hbCByb3NlLg0KDQpJIGtub3cgdGhhdCB0aGVyZSBhcmUgc2V2ZXJhbCBqYXZhIHZlcnNpb25z LiBCdXQgaXQgaXMgbm90IGFzIHBvd2VyZnVsIGFzIHJhdGlvbmFsJ3MuDQoNCk5vd2FkYXlzIEkg ZGV2ZWxvcCBhIHVuaXggYXBwbGljYXRpb24gb24gbXkgbGludXggc3lzdGVtLiBCdXQgdG8gZGVz aWduIGEgbW9kZWwsDQoNCkkgbXVzdCB0dXJuIHRvIFdpbmRvd3MgYW5kIGF0IHRoYXQgdGltZSwg SSBmZWVsIGV4dHJlbWVseSB1bmNvdmVuaWVudC4NCg0KRG8geW91IGtub3cgYW55IHByb2plY3Qg YWJvdXQgbGludXggdmlzdWFsIG1vZGVsaW5nIHRvb2w/DQoNClRoYW5rIHlvdS4NCg0KDQo= ------=_NextPart_000_0081_01BE2B34.E5B83120 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5IaS48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkkgdGhpbmsgbGludXggbmVlcyB2aXN1YWwgbW9kZWxpbmcgdG9vbHMgbGlrZSBy YXRpb25hbCANCnJvc2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBrbm93IHRoYXQgdGhlcmUgYXJlIHNldmVy YWwgamF2YSB2ZXJzaW9ucy4gQnV0IGl0IGlzIG5vdCBhcyANCnBvd2VyZnVsIGFzIHJhdGlvbmFs J3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+Tm93YWRheXMgSSBkZXZlbG9wIGEgdW5peCBhcHBsaWNhdGlvbiBv biBteSBsaW51eCBzeXN0ZW0uIEJ1dCANCnRvIGRlc2lnbiBhIG1vZGVsLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PkkgbXVzdCB0dXJuIHRvIFdpbmRvd3MgYW5kIGF0IHRoYXQgdGltZSwgSSBmZWVsIGV4dHJlbWVs eSANCnVuY292ZW5pZW50LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRvIHlvdSBrbm93IGFueSBwcm9qZWN0IGFi b3V0IGxpbnV4IHZpc3VhbCBtb2RlbGluZyANCnRvb2w/PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmsgeW91 LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0081_01BE2B34.E5B83120-- --DocE+STaALJfprDB-- From Nigel.Metheringham@dev.InTechnology.co.uk Wed Dec 12 09:48:16 2001 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 12 Dec 2001 09:48:16 +0000 Subject: [Mailman-Developers] Update for README.exim (cvs) In-Reply-To: <20011210005601.C21219@magic.merlins.org> References: <20011210005601.C21219@magic.merlins.org> Message-ID: <1008150496.11962.2.camel@gaspode.localnet> On Mon, 2001-12-10 at 08:56, Marc MERLIN wrote: > Hopefully I got this right: should be ok for now, although the grand master plan (tm) is actually to reduce the whole of this to a total of 2 directors and 2 transports - possibly only one :-) I have a plan to do this stuff and hopefully make life easier for other MTA people too. Unfortunately (for Mailman - good from other points of view) its panto[1] season (this is English/UK ethnic stuff at its strange best), and I'm doing theatre stuff every evening right now. Nigel. [1] From Telsa Gwynne's diary:- > Attempted to explain the Great British Pantomime to an American > friend. There appear to be no good explanations of this for the > panto-deprived on the net. Someone needs to write one before I do. > (Note: it has nothing to do with people with white make-up making > gestures without speaking. No.) Maybe try http://gouk.about.com/library/weekly/aa121800a.htm?terms=pantomime -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From marc_news@vasoftware.com Wed Dec 12 17:13:54 2001 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 12 Dec 2001 09:13:54 -0800 Subject: [Mailman-Developers] update of my remove_members patch against CVS version Message-ID: <20011212091353.G10584@magic.merlins.org> Barry, this never made it into 2.0.x Any chance it could make it into CVS? (I've updated https://sourceforge.net/tracker/index.php?func=detail&aid=413257&group_id=103&atid=300103 ) Marc --- remove_members.mailman Wed Dec 12 08:57:41 2001 +++ remove_members Wed Dec 12 08:57:38 2001 @@ -37,6 +37,8 @@ Print this help message and exit. listname is the name of the mailing list to use. + (_alllists_' is a special list name that checks all the lists for the + Emails to remove) addr1 ... are additional addresses to remove. @@ -47,6 +49,7 @@ import paths from Mailman import MailList +from Mailman import Utils from Mailman import Errors from Mailman.i18n import _ @@ -84,7 +87,12 @@ if len(args) < 1: usage(1) - listname = args[0].lower().strip() + rlistname = args[0].lower().strip() + if rlistname == "_alllists_": + listnames = Utils.list_names() + else: + listnames = [] + listnames.append(rlistname) addresses = args[1:] filename = None all = 0 @@ -103,26 +111,32 @@ except IOError: print _('Could not open file for reading: %(filename)s.') - try: - # open locked - mlist = MailList.MailList(listname) - except Errors.MMListError, e: - print _('No such list: %(listname)s') - sys.exit(1) - - if all: - addresses = mlist.getMembers() - - try: - for addr in addresses: - try: - mlist.ApprovedDeleteMember(addr) - except Errors.MMNoSuchUserError: - print _("User `%(addr)s' not found.") - finally: - # Hmm, should it be all or nothing? - mlist.Save() - mlist.Unlock() + for listname in listnames: + try: + # open locked + mlist = MailList.MailList(listname) + except Errors.MMListError, e: + print 'Error opening list "%s": %s... skipping.' % (listname, e) + continue + + if all: + addresses = mlist.GetMembers() + mlist.GetDigestMembers() + + try: + for addr in addresses: + try: + mlist.DeleteMember(addr) + except Errors.MMNoSuchUserError: + if rlistname != "_alllists_": + print "User `%s' not found." % addr + else: + if rlistname == "_alllists_": + print "User `%s' removed from list `%s'" % (addr, listname) + + finally: + # Hmm, should it be all or nothing? + mlist.Save() + mlist.Unlock() -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From roger@infomed.sld.cu Wed Dec 12 22:13:11 2001 From: roger@infomed.sld.cu (=?ISO-8859-1?Q?Roger_Pe=F1a_Escobio?=) Date: Wed, 12 Dec 2001 17:13:11 -0500 (CST) Subject: [Mailman-Developers] hi, i have an unconfortable error with mailman 2.0.8 Message-ID: yesterday i upgrade mailman 2.0.6 to 2.0.8 and since then i started getting this behavior: when i use the admin web interface, after authenticated, any other page that i try to see i get this messages: "Error decoding authorization cookie" i use koqueror, the version that came with redhat-7.2, but if i use IE or lynx everything goes fine :-( i try to find what change from 2.0.6 to 2.0.8 make this possible but i couldn't find anything understandable by me anybody with the same problem? thank for any tip roger From jon@latchkey.com Wed Dec 12 22:26:43 2001 From: jon@latchkey.com (Jon Stevens) Date: Wed, 12 Dec 2001 14:26:43 -0800 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: on 12/9/01 5:48 PM, "Stephan Richter" wrote: > Furthermore, for the Mailman 3.0 release I would like to make a case for > using the ZODB (not the entire Zope package!) for storing our data > structures, since we will not have to worry about file locking and data > storage in general anymore. Furthermore, we can then easily build adapters > for other data storages. Except that I have seen at least 5-10 bugtraq postings about security holes in Zope over the last year... -jon From srichter@cbu.edu Wed Dec 12 22:34:41 2001 From: srichter@cbu.edu (Stephan Richter) Date: Wed, 12 Dec 2001 16:34:41 -0600 Subject: [Mailman-Developers] ZMailman 2.1 preview In-Reply-To: References: <5.1.0.14.2.20011209193231.02d2dee0@mail.cbu.edu> Message-ID: <5.1.0.14.2.20011212163315.027978b0@mail.cbu.edu> At 02:26 PM 12/12/2001 -0800, Jon Stevens wrote: >Except that I have seen at least 5-10 bugtraq postings about security holes >in Zope over the last year... Well, yes. But did you read the type and nature of the bug. Unless you got some rights, there is usually no chance to get it. Zope is more secure than most other platforms out there. Please take these security warnings with a grain of salt; they are usually not even affecting the normal Zope user. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From Dan Mick Thu Dec 13 01:27:13 2001 From: Dan Mick (Dan Mick) Date: Wed, 12 Dec 2001 17:27:13 -0800 (PST) Subject: [Mailman-Developers] hi, i have an unconfortable error with mailman 2.0.8 Message-ID: <200112130127.RAA19427@utopia.West.Sun.COM> > yesterday i upgrade mailman 2.0.6 to 2.0.8 and since then i started > getting this behavior: > > when i use the admin web interface, after authenticated, any other page > that i try to see i get this messages: > "Error decoding authorization cookie" > > i use koqueror, the version that came with redhat-7.2, but if i use IE or > lynx everything goes fine :-( > > i try to find what change from 2.0.6 to 2.0.8 make this possible but i > couldn't find anything understandable by me Konqueror has cookie issues. It's been discussed on mailman-users, which is where this question should have gone. From barry@zope.com Thu Dec 13 02:11:28 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 12 Dec 2001 21:11:28 -0500 Subject: [Mailman-Developers] hi, i have an unconfortable error with mailman 2.0.8 References: <200112130127.RAA19427@utopia.West.Sun.COM> Message-ID: <15384.3664.157446.712387@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Konqueror has cookie issues. It's been discussed on DM> mailman-users, which is where this question should have gone. Right. Actually, IIRC it's the version of Cookie.py that's distributed with Mailman 2.0.8 that doesn't handle the unquoting of cookie data correctly. NS, MSIE, and Moz don't seem to quote the data so they aren't affected. Konq does,... and is. ;) MM2.1 won't be affected because it uses Python's standard (updated) Cookie module, which handles all this correctly. I've tested it with Konq 2.1.1 and it works just fine. -Barry From marc_news@vasoftware.com Thu Dec 13 07:15:35 2001 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 12 Dec 2001 23:15:35 -0800 Subject: [Mailman-Developers] [Patch] SMTPDirect.py wrongly closing the connection Message-ID: <20011212231535.N15120@magic.merlins.org> So, I have my mailman alpha 3 cvs with python 2.1 seemingly working, and when I move a list with more than one subscriber to it, I started getting: Dec 12 22:11:33 2001 (18247) delivery to aregnier@yahoo.com failed with code 501 : size=3426: malformed address: size=3426 may not follow Apparently smtplib.py makes a delivery attempt without doing EHLO or HELO first, and then users the size extention, which is illegal before EHLO has been used. I have the following defaults: SMTP_MAX_RCPTS = 500 MAX_DELIVERY_THREADS = 0 SMTPHOST = 'localhost' SMTPPORT = 0 My exim debug logs show: This one is good: SMTP>> 220 mail2.merlins.org ESMTP Exim 3.31-VA-mm2 #1 Wed, 12 Dec 2001 22:28:08 SMTP<< ehlo moremagic.merlins.org SMTP>> 250-mail2.merlins.org Hello mailman at localhost [127.0.0.1] 250-SIZE 52428800 250-EXPN 250-PIPELINING 250-STARTTLS 250 HELP SMTP<< mail FROM: size=3426 SMTP>> 250 is syntactically correct SMTP<< rcpt TO: SMTP>> 250 is syntactically correct SMTP<< rcpt TO: SMTP>> 250 is syntactically correct SMTP<< data SMTP>> 354 Enter message, ending with "." on a line by itself (message follows) SMTP>> 250 OK id=16EPLk-0000fZ-00 SMTP<< quit SMTP>> 221 mail2.merlins.org closing connection But here's what happens afterwards. LOG: 4 MAIN SMTP connection from localhost [127.0.0.1] SMTP>> 220 mail2.merlins.org ESMTP Exim 3.31-VA-mm2 #1 Wed, 12 Dec 2001 22:28:08 -0800 - mm1 SMTP<< mail FROM: size=3426 LOG: 4 MAIN SMTP syntax error in "mail FROM: size=342 6" H=localhost [127.0.0.1] U=mailman: malformed address: size=3426 may not follo w SMTP>> 501 size=3426: malformed address: s ize=3426 may not follow SMTP<< rset SMTP>> 250 Reset OK SMTP<< quit So here, mailman becomes rude, and doesn't say EHLO, and yet tries to use SIZE... (one hoyr later) Aaaah, I think I get it. moremagic:/var/local/mailman/logs# diff -u /var/local/src/mailman/Mailman/Handlers/SMTPDirect.py ../Mailman/Handlers/SMTPDirect.py --- /var/local/src/mailman/Mailman/Handlers/SMTPDirect.py Wed Nov 21 14:57:27 2001 +++ ../Mailman/Handlers/SMTPDirect.py Wed Dec 12 23:05:02 2001 @@ -274,7 +274,8 @@ # constructor if SMTPHOST is false refused = conn.sendmail(envsender, recips, msgtext) finally: - conn.quit() + 1 + #conn.quit() except smtplib.SMTPRecipientsRefused, e: refused = e.recipients # MTA not responding, or other socket problems, or any other kind of I'm not 100% sure it was meant to work that way, it looked like the code meant to send all the deliveries in one connection, which is why it didn't say helo in the second batch. So, I've removed the part that closes the connection after the first chunk is out. Barry, was this right? (I didn't check if it breaks the threaded code path) Marc PS: Don't make fun of me for sticking a '1' in there, I don't really claim to know python, and the parser was getting upset if I commented out conn.quit, or that plus the finally: I was watching Buffy on my tivo before all this happened, and I'd like to see the end of the episode :-) (see, just Like Niguel, I have a worthy excuse :-D) -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Thu Dec 13 13:20:06 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 13 Dec 2001 08:20:06 -0500 Subject: [Mailman-Developers] [Patch] SMTPDirect.py wrongly closing the connection References: <20011212231535.N15120@magic.merlins.org> Message-ID: <15384.43782.491430.265868@anthem.wooz.org> MM> I'm not 100% sure it was meant to work that way, it looked MM> like the code meant to send all the deliveries in one MM> connection, which is why it didn't say helo in the second MM> batch. So, I've removed the part that closes the connection MM> after the first chunk is out. | Barry, was this right? | (I didn't check if it breaks the threaded code path) MM> PS: Don't make fun of me for sticking a '1' in there, I don't MM> really claim to know python, and the parser was getting upset MM> if I commented out conn.quit, or that plus the finally: I was MM> watching Buffy on my tivo before all this happened, and I'd MM> like to see the end of the episode :-) (see, just Like Niguel, MM> I have a worthy excuse :-D) Actually using pass instead of 1 would be the Pythonically correct thing to do (pass is essentially a noop). I /think/ changing conn.quit() to conn.close() is the right change, but I'm not 100% sure and I don't have time to test it right now. Can you give it a try and see if that works for you? -Barry From marc_news@vasoftware.com Thu Dec 13 16:17:46 2001 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 13 Dec 2001 08:17:46 -0800 Subject: [Mailman-Developers] [Patch] SMTPDirect.py wrongly closing the connection In-Reply-To: <15384.43782.491430.265868@anthem.wooz.org>; from barry@zope.com on Thu, Dec 13, 2001 at 08:20:06AM -0500 References: <20011212231535.N15120@magic.merlins.org> <15384.43782.491430.265868@anthem.wooz.org> Message-ID: <20011213081746.I28313@magic.merlins.org> On Thu, Dec 13, 2001 at 08:20:06AM -0500, Barry A. Warsaw wrote: > Actually using pass instead of 1 would be the Pythonically correct > thing to do (pass is essentially a noop). Ah, yeah. Thanks. > I /think/ changing conn.quit() to conn.close() is the right change, Nope. 2001-12-13 08:13:34 SMTP connection from localhost (moremagic.merlins.org) [127. 0.0.1] lost 2001-12-13 08:13:35 SMTP connection from localhost [127.0.0.1] 2001-12-13 08:13:35 SMTP syntax error in "mail FROM: size=2215" H=localhost [127.0.0.1] U=mailman: malformed address: size=2215 m ay not follow 2001-12-13 08:13:35 SMTP connection from localhost [127.0.0.1] lost > but I'm not 100% sure and I don't have time to test it right now. Can > you give it a try and see if that works for you? Sorry, it doesn't. I put back a pass instead, and I'm leaving for a snowboard trip today, so I think I'll leave the lists alone until I come back sunday :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From rodolfo@linux.org.uy Thu Dec 13 22:03:07 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 13 Dec 2001 19:03:07 -0300 Subject: [Mailman-Developers] create error in link Message-ID: <1008280987.1305.13.camel@claudia> I have Mailman 2.1a3 and Pyton 2.0. I refer to $prefix/cgi-bin/create ELF binary. I have point through the Apache as http://mysite/cgi-bin/create but it has the following FORM action:

I also have $prefix/Mailman/mm_cfg.py with this line: DEFAULT_URL = 'http://mysite/cgi-bin/' Can you tell me how to have *create* with a line like this: ^^^^^^^ Of course, the create cgi do not work propertly. Thank you! -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From barry@zope.com Fri Dec 14 08:08:20 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 14 Dec 2001 03:08:20 -0500 Subject: [Mailman-Developers] [Patch] SMTPDirect.py wrongly closing the connection References: <20011212231535.N15120@magic.merlins.org> Message-ID: <15385.45940.956750.851077@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> So, I have my mailman alpha 3 cvs with python 2.1 seemingly MM> working, and when I move a list with more than one subscriber MM> to it Exactly how many subscribers are on your list? Is it more than SMTP_MAX_RCPTS? I hope your answer is "yes"! MM> Apparently smtplib.py makes a delivery attempt without doing MM> EHLO or HELO first, and then users the size extention, which MM> is illegal before EHLO has been used. Here's my theory, which only holds true if the #of subscribers > SMTP_MAX_RCPTS. If it's fewer, then I'm perplexed. Let's forget about threaded delivery for now, which doesn't enter into your picture anyway. SMTPDirect tries to reuse a connection to the smtpd when delivering multiple chunks. The code in deliver() as it currently stands will do the following: - On the first chunk, it finds its socket isn't connected, so it connects, doing the EHLO/HELO dance - Then it calls conn.sendmail() which does the MAIL FROM/RCPT TO/DATA dance - Then the finally clause executes and a QUIT is issued. The server closes the connection, as it must (RFC 2821). - Now the next chunk comes along and we find the socket is not connected, so we re-connect. Note that we're using the same smtplib.SMTP object, but we're getting a new socket connection - The state in the SMTP object thinks it's already issued an EHLO and so doesn't issue it again. Instead, when this time it calls sendmail() it jumps right to MAIL FROM and boom, you're hosed. Your patch eliminates the QUIT in the finally clause and so when the the first transaction in the session completes, the session won't be QUIT, the socket won't be closed, and the second sendmail() call succeeds. Interestingly enough, it looks like Postfix isn't bothered by the lack of EHLO/HELO at the start of the second session. This behavior appears to be controlled by the smtpd_helo_required config variable which seems to default to "no". Can you guess why I never noticed this bug before? :) Your patch clearly gets to the heart of the matter: in a multiple transaction session, we mustn't issue a QUIT until the session is over. So SMTPDirect.py is broken. I'm not sure your patch is entirely correct -- I need to trace the code through both the non-threaded and threaded delivery paths and think about the error conditions. Probably the whole try/finally bit can be removed, and .quit() needs to be called when we're really done with the connection. Attached is a patch that I think will do the trick, but I haven't tested it yet. Now, if you tell me that the # of recips is < SMTP_MAX_RCPTS, then none of this analysis is relevant, and I can't see how you're getting this problem. ;) MM> I put back a pass instead, and I'm leaving for a snowboard MM> trip today, so I think I'll leave the lists alone until I come MM> back sunday :-) Oh sure, rub it in! We're still unseasonably warm here in DC, even if we have gotten below 70 deg F the last few days. No sign of snow so far, so I hope you think about Mailman on all the lifts up the mountain. :) 'Course, if we get some decent snow in February when I'm supposed to go, then I take it all back! warm-ly y'rs, -Barry P.S. Python 2.2 rc 1 release tomorrow, er, later today. Hopefully some Mailman catch up time this weekend. -------------------- snip snip -------------------- Index: SMTPDirect.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/SMTPDirect.py,v retrieving revision 2.10 diff -u -r2.10 SMTPDirect.py --- SMTPDirect.py 2001/11/21 22:57:27 2.10 +++ SMTPDirect.py 2001/12/14 07:58:31 @@ -98,7 +98,7 @@ conn = smtplib.SMTP() for chunk in chunks: deliver(envsender, msgtext, chunk, refused, conn) - conn.close() + conn.quit() # Log the successful post t1 = time.time() d = MsgSafeDict(msg, {'time' : t1-t0, @@ -242,7 +242,7 @@ for t, (threadfailures, conn) in threads.items(): t.join() failures.update(threadfailures) - conn.close() + conn.quit() # All threads have exited threads.clear() @@ -269,12 +269,8 @@ # connected or not. :( if not getattr(conn, 'sock', 0): conn.connect(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) - try: - # make sure the connect happens, which won't be done by the - # constructor if SMTPHOST is false - refused = conn.sendmail(envsender, recips, msgtext) - finally: - conn.quit() + # Send the message + refused = conn.sendmail(envsender, recips, msgtext) except smtplib.SMTPRecipientsRefused, e: refused = e.recipients # MTA not responding, or other socket problems, or any other kind of From bagnara@cs.unipr.it Fri Dec 14 15:30:45 2001 From: bagnara@cs.unipr.it (Roberto Bagnara) Date: Fri, 14 Dec 2001 16:30:45 +0100 Subject: [Mailman-Developers] Illegal command: mailcmd Message-ID: <3C1A1B25.6C2CA5B0@cs.unipr.it> Hi there, we are experimenting with Mailman 2.1 (we absolutely need the Italian version) and we have problems with email confirmation of subscriptions. Here is the kind of message people trying to confirm receive in response: > Date: Wed, 12 Dec 2001 13:19:44 +0100 > From: Mail Delivery Subsystem > To: pescetti@math.unipr.it > Subject: Returned mail: see transcript for details > > The original message was received at Wed, 12 Dec 2001 13:19:44 +0100 > from prmat.math.unipr.it [160.78.64.1] > > ----- The following addresses had permanent fatal errors ----- > "|/home/mailman/mail/wrapper mailcmd comunicazioni-ufficiali" > (reason: 6) > (expanded from: ) > > ----- Transcript of session follows ----- > Illegal command: mailcmd > 554 5.3.0 unknown mailer error 6 Does this mean that "mailcmd" should be added to the array initializer starting at line 35 in src/mail-wrapper.c, now reading const char *VALID_COMMANDS[] = { "bounces", "join", "leave", "post", "owner", "request", NULL /* Sentinel, don't remove */ }; Or "mailcmd" is indeed an illegal command and the culprit is somewhere else? Thanks a lot, and keep up the great work. Roberto -- Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it From barry@zope.com Sat Dec 15 04:18:06 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 14 Dec 2001 23:18:06 -0500 Subject: [Mailman-Developers] Illegal command: mailcmd References: <3C1A1B25.6C2CA5B0@cs.unipr.it> Message-ID: <15386.52990.896091.881785@anthem.wooz.org> >>>>> "RB" == Roberto Bagnara writes: RB> we are experimenting with Mailman 2.1 (we absolutely need the RB> Italian version) and we have problems with email confirmation RB> of subscriptions. Here is the kind of message people trying RB> to confirm receive in response: You need to update your aliases file. There have been some renaming of command scripts for more consistency. E.g. mailcmd -> request. Running bin/genaliases should do the trick. -Barry From barry@zope.com Sun Dec 16 04:54:53 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 15 Dec 2001 23:54:53 -0500 Subject: [Mailman-Developers] Having more than 16,000 lists References: <87hesmbysl.fsf@nausicaa.interq.or.jp> <20011026181219.O12632@magic.merlins.org> <15322.8042.967043.536680@anthem.wooz.org> <20011109173447.B32688@gandalf.merlins.org> <20011122110601.A1279@gandalf.merlins.org> Message-ID: <15388.10525.551542.522330@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I haven't yet had the time to work on this, but I wanted to MM> know what your preference was between a hack that optionally MM> creates mailman/foo/l/li/listname dirs at the time the list is MM> created, and then sets symlinks back to where the rest of the MM> mailman code expects to see the files and dirs, or a bigger MM> change to teach all of mailman about the new file and dir MM> location (no more symlinks) Of course, if we go with the no MM> symlink route, making the deep subdir config optional would be MM> a bit more work. MM> What's your take on this, and which route would you prefer? At this point, whatever causes the least disruption of the code base the better. ;) -Barry From spertus@mills.edu Sun Dec 16 06:23:58 2001 From: spertus@mills.edu (Ellen Spertus) Date: Sat, 15 Dec 2001 22:23:58 -0800 Subject: [Mailman-Developers] ScriptURL with aolserver Message-ID: <5.1.0.14.0.20011215161626.03c77d28@ella.mills.edu> I think I've figured out what's behind the problems with links from administration pages that some users have reported [http://sourceforge.net/tracker/?group_id=103&atid=100103&func=detail&aid=214037 and http://sourceforge.net/tracker/?group_id=103&atid=100103&func=detail&aid=452200]. For an example of the problem, see http://javamlm.mills.edu/mailman/admin/test/ and try following any link. I am using aolserver 3.2, which seems to set nonstandard values for the environment variables SCRIPT_NAME and PATH_INFO. When I do a GET on "http://javamlm.mills.edu/mailman/admin/test", the values are: SCRIPT_NAME: /mailman/admin/test PATH_INFO: /test When Utils.ScriptURL concatenates these, the result is the bogus fullpath "/mailman/admin/test/test", which leads to the bogus relative path "../../../admin". Workarounds: - Use a behaving web server - Use absolute URLs [which would probably break something else], e.g., - change MailList.GetScriptURL - change Utils.ScriptURL - Have a special case for noncompliant web servers - require a flag for aolserver users - infer that something's wrong if SCRIPT_NAME and PATH_INFO end in the same string I'd be happy to code a patch but could use advice on the best way to proceed without breaking something else (or perhaps people don't care about supporting aolserver). I've also sent a query to the aolserver discussion list asking whether the behavior is a bug or a feature. Ellen From barry@zope.com Sun Dec 16 06:25:34 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 16 Dec 2001 01:25:34 -0500 Subject: [Mailman-Developers] [Patch] SMTPDirect.py wrongly closing the connection References: <20011212231535.N15120@magic.merlins.org> <15385.45940.956750.851077@anthem.wooz.org> <20011215214509.A16047@moremagic.merlins.org> Message-ID: <15388.15966.732164.824333@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> The answer is "No". The reason mailman does two chunks is the MM> new code that splits per top tld. I did a test with foo.org MM> and bar.com, which caused to chunks and two separate MM> deliveries to the MTA D'oh! > non-threaded and threaded delivery paths and think about the error > conditions. Probably the whole try/finally bit can be removed, and > .quit() needs to be called when we're really done with the > connection. Attached is a patch that I think will do the trick, but I > haven't tested it yet. MM> I tried it, and it seems to work fine. I now also get: MM> 2001-12-15 21:45:07 SMTP connection from localhost MM> (moremagic.merlins.org) [127.0.0.1] closed by QUIT Cool. I've done some testing myself and I'm more confident about the patch. I've checked it in (it might be slightly modified from what I sent you). MM> Kirkwood in California current has the deepest snow base in MM> all of the US (185 inches, but who's counting :-D) We're actually getting some rain now (whoopee). MM> (typing in the car on the way back) Ummh, sure, I was thinking MM> about the patch while wrestling with the deep fresh powder MM> :-))) :) Sounds like you had a fun time! Thanks, -Barry From barry@zope.com Sun Dec 16 20:32:56 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 16 Dec 2001 15:32:56 -0500 Subject: [Mailman-Developers] ScriptURL with aolserver References: <5.1.0.14.0.20011215161626.03c77d28@ella.mills.edu> Message-ID: <15389.1272.836984.156646@anthem.wooz.org> >>>>> "ES" == Ellen Spertus writes: ES> I am using aolserver 3.2, which seems to set nonstandard ES> values for the environment variables SCRIPT_NAME and ES> PATH_INFO. When I do a GET on ES> "http://javamlm.mills.edu/mailman/admin/test", the values are: ES> SCRIPT_NAME: /mailman/admin/test PATH_INFO: /test I believe this is not compliant with the CGI spec. SCRIPT_NAME should be /mailman/admin and PATH_INFO should be test. I vaguely remember a similar issue with (I think) thttpd which has subsequently been fixed, but I don't remember the details. ES> Workarounds: - Use a behaving web server ...or fix your broken one. :) I'm not in favor of adding official workarounds for broken web servers (or mtas, or web browsers... etc) What do the aolserver folks have to say about this? -Barry From rodolfo@linux.org.uy Wed Dec 19 12:58:39 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 19 Dec 2001 09:58:39 -0300 Subject: [Mailman-Developers] MAILMAN_SITE_LIST Message-ID: <1008766720.759.0.camel@claudia> Hello developers: Ok, I understand that this list is for development purposes, but I posted this question at mailman-users and did not receive any reply, perhaps because I use the latest development version of MM. -----Mensaje reenviado----- From: Rodolfo Pilas To: mailman-users@python.org Subject: [Mailman-Users] MAILMAN_SITE_LIST Date: 14 Dec 2001 10:39:56 -0300 I use MM 2.1a3 with Python 2.0 I have MAILMAN_SITE_LIST='mailman' in my $prefix/Mailman/Default.py in accordance to the item 4 of the INSTALL document: Create a "site-wide" mailing list. This is the one that password reminders will appear to come from. Usually this should be the "mailman" mailing list, but if you need to change this, be sure to change the MAILMAN_SITE_LIST variable in mm_cfg.py (see below). I also have DEFAULT_HOST_NAME='mysite.net' in my $prefix/Mailman/mm_cfg.py But the list is showed as mailman@www.mysite.net (whit "www") additionally, when I create a new list the host_name by default is showed as www.mysite.net (of course, I chage it to mysite.net). I see this problem since I upgraded from 2.1a2 to 2.1a3. Can you tell me how to have mailman@mysite.net (without "www") and a default host_name "mysite.net" again? Thank you. -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 ------------------------------------------------------ Mailman-Users maillist - Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users From rodolfo@linux.org.uy Wed Dec 19 20:06:26 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 19 Dec 2001 17:06:26 -0300 Subject: [Mailman-Developers] bsddb python module Message-ID: <1008792388.759.20.camel@claudia> Another question for developers... (please, accept my apologies to post this question here, but I need a tip about this problem) -----Mensaje reenviado----- From: Rodolfo Pilas To: mailman-users@python.org Subject: [Mailman-Users] bsddb python module Date: 18 Dec 2001 18:57:09 -0300 I have a MM 2.1a3 with Pyton 2.0 + Postfix working very well. By the other way I try to install MM 2.1a3 with Pyton 2.1.1 but I can not create lists because I do not have the module bsddb (required by dbhash). Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 96, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/create.py", line 55, in main process_request(doc, cgidata) File "/usr/lib/mailman/Mailman/Cgi/create.py", line 199, in process_request __import__(modname) File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 25, in ? import dbhash File "/var/tmp/python-root//usr/lib/python2.1/dbhash.py", line 5, in ? import bsddb ImportError: No module named bsddb In the first system I can not locate the bsddb* module file, but an import bsddb works. I downloaded bsddb3-3.3.0 and try to install (python setup.py install) but I can not compile it. Can anybody help me to have bsddb installed? (My sistem is a SuSE 7.3 Professional and I do not understand Python language) -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 ------------------------------------------------------ Mailman-Users maillist - Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users From claw@kanga.nu Thu Dec 20 09:05:18 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 20 Dec 2001 01:05:18 -0800 Subject: [Mailman-Developers] External subscriber lists in 2.1 Message-ID: <9031.1008839118@kanga.nu> Barry, In 2.1 when used with external subscriber storage (eg SQL), will the new equivalent of qrunner request and load the entire subscriber DB onto the heap prior to broadcast? <> Reason: This poses scaling problems for lists with very large numbers of subscribers. I'd suggest paging thru the set in blocks. ObExcuse: Chap on -users asking about millions of subscribers. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From R.Barrett@ftel.co.uk Thu Dec 20 14:00:39 2001 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Thu, 20 Dec 2001 14:00:39 +0000 Subject: [Mailman-Developers] MAILMAN_SITE_LIST In-Reply-To: <1008766720.759.0.camel@claudia> Message-ID: <5.1.0.14.2.20011220135926.03187da8@pop.ftel.co.uk> At 09:58 19/12/2001 -0300, Rodolfo Pilas wrote: >Hello developers: > >Ok, I understand that this list is for development purposes, but I >posted this question at mailman-users and did not receive any reply, >perhaps because I use the latest development version of MM. > > >-----Mensaje reenviado----- > >From: Rodolfo Pilas >To: mailman-users@python.org >Subject: [Mailman-Users] MAILMAN_SITE_LIST >Date: 14 Dec 2001 10:39:56 -0300 > >I use MM 2.1a3 with Python 2.0 > >I have MAILMAN_SITE_LIST='mailman' in my $prefix/Mailman/Default.py in >accordance to the item 4 of the INSTALL document: > > Create a "site-wide" mailing list. This is the one that > password reminders will appear to come from. Usually this > should be the "mailman" mailing list, but if you need to change > this, be sure to change the MAILMAN_SITE_LIST variable in > mm_cfg.py (see below). > >I also have DEFAULT_HOST_NAME='mysite.net' in my >$prefix/Mailman/mm_cfg.py > >But the list is showed as mailman@www.mysite.net (whit "www") >additionally, when I create a new list the host_name by default is >showed as www.mysite.net (of course, I chage it to mysite.net). > >I see this problem since I upgraded from 2.1a2 to 2.1a3. > >Can you tell me how to have mailman@mysite.net (without "www") and a >default host_name "mysite.net" again? > >Thank you. sorry, I have no idea what created your problem but two questions: 1. do you get the same problem with a newly created lists? 2. what is the effect of resetting the list's host_name attribute on the General Options page of the admin web GUI for the list? From rodolfo@linux.org.uy Thu Dec 20 14:45:10 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: 20 Dec 2001 11:45:10 -0300 Subject: [Mailman-Developers] MAILMAN_SITE_LIST In-Reply-To: <5.1.0.14.2.20011220135926.03187da8@pop.ftel.co.uk> References: <5.1.0.14.2.20011220135926.03187da8@pop.ftel.co.uk> Message-ID: <1008859511.2476.8.camel@claudia> El Thu, 20-12-2001 a las 11:00, Richard Barrett escribi? > >Can you tell me how to have mailman@mysite.net (without "www") and a > >default host_name "mysite.net" again? > 1. do you get the same problem with a newly created lists? I have just create a new list, both problems are there: - listinfo shows testlist@www.mysite.net as address of the list - host_name shows www.mysite.net > 2. what is the effect of resetting the list's host_name attribute on the > General Options page of the admin web GUI for the list? Ok, I have just change it to mysite.net and now listinfo and host_name has mysite.net only. This resolves a particular list, but the"site-wide" mailing list ("mailman") are grong displayed at general listinfo page. You can see my site at: - General listinfo page: http://www.espaciolibre.net/cgi-bin/listinfo where you see mailman@www.espaciolibre.net - Particular list mailman: http://www.espaciolibre.net/cgi-bin/listinfo/mailman where I modified the host_name attribute to espaciolibre.net and you see mailman@espaciolibre.net I confirm you again that this problem is into the MM 2.1a3 and not into 2.1a2. Please, confirm me if your require additional test. -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From R.Barrett@ftel.co.uk Thu Dec 20 16:07:09 2001 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Thu, 20 Dec 2001 16:07:09 +0000 Subject: [Mailman-Developers] MAILMAN_SITE_LIST In-Reply-To: <1008859511.2476.8.camel@claudia> References: <5.1.0.14.2.20011220135926.03187da8@pop.ftel.co.uk> <5.1.0.14.2.20011220135926.03187da8@pop.ftel.co.uk> Message-ID: <5.1.0.14.2.20011220153528.03187da8@pop.ftel.co.uk> Looking at the Defaults.py on my MM 2.1a3 test installation I notice that it reads as follows: # Site-specific settings DEFAULT_EMAIL_HOST = 'mymachine.mydomain.co.uk' DEFAULT_URL_HOST = 'mymachine.mydomain.co.uk' DEFAULT_URL_PATTERN = 'http://%s/mailman/' # For backwards compatibility. Note: DEFAULT_URL_PATTERN must end in a slash! DEFAULT_HOST_NAME = DEFAULT_EMAIL_HOST DEFAULT_URL = DEFAULT_URL_PATTERN % DEFAULT_URL_HOST Adding a definition for DEFAULT_EMAIL_HOST='mysite.net' to your mm_cfg.py may be worthwhile. If you are creating your new lists through the web rather than with bin/newlist I think you also need a call to add_virtualhost (see comments in Defaults.py) or redefine VIRTUAL_HOSTS = {} in mm_cfg.py Hope this helps At 11:45 20/12/2001 -0300, Rodolfo Pilas wrote: >El Thu, 20-12-2001 a las 11:00, Richard Barrett escribi? > > > >Can you tell me how to have mailman@mysite.net (without "www") and a > > >default host_name "mysite.net" again? > > > 1. do you get the same problem with a newly created lists? > >I have just create a new list, both problems are there: >- listinfo shows testlist@www.mysite.net as address of the list >- host_name shows www.mysite.net > > > 2. what is the effect of resetting the list's host_name attribute on the > > General Options page of the admin web GUI for the list? > >Ok, I have just change it to mysite.net and now listinfo and >host_name has mysite.net only. This resolves a particular list, but >the"site-wide" mailing list ("mailman") are grong displayed at general >listinfo page. > >You can see my site at: >- General listinfo page: http://www.espaciolibre.net/cgi-bin/listinfo >where you see mailman@www.espaciolibre.net > >- Particular list mailman: >http://www.espaciolibre.net/cgi-bin/listinfo/mailman >where I modified the host_name attribute to espaciolibre.net and you see >mailman@espaciolibre.net > > >I confirm you again that this problem is into the MM 2.1a3 and not into >2.1a2. Please, confirm me if your require additional test. > >-- > > Rodolfo Pilas Quien los puso a estos tipos donde estan, > rodolfo@linux.org.uy Quien los deja seguir en su lugar, > http://rodolfo.pilas.net Quien los baja ahora de su altar, > ICQ #17461636 Quien les paga para que hagan lo que haran > http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- > > Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 > key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From barry@zope.com Sun Dec 23 06:44:58 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 23 Dec 2001 01:44:58 -0500 Subject: [Mailman-Developers] MAILMAN_SITE_LIST References: <5.1.0.14.2.20011220135926.03187da8@pop.ftel.co.uk> <5.1.0.14.2.20011220153528.03187da8@pop.ftel.co.uk> Message-ID: <15397.32106.967528.499103@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas writes: RP> Ok, I understand that this list is for development purposes, RP> but I posted this question at mailman-users and did not RP> receive any reply, perhaps because I use the latest RP> development version of MM. Yes, all Mailman 2.1 discussion should be held here, on the -developers list. >>>>> "RB" == Richard Barrett writes: RB> Adding a definition for DEFAULT_EMAIL_HOST='mysite.net' to RB> your mm_cfg.py may be worthwhile. Exactly right. We really need to split the domain part for the email (i.e. @mysite.net) from the domain part for the web page url. That's what DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST are for, respectively. Note that configure tries to guess some default values for these variables, but it's a difficult and error prone process. RB> If you are creating your new lists through the web rather than RB> with bin/newlist I think you also need a call to RB> add_virtualhost (see comments in Defaults.py) or redefine RB> VIRTUAL_HOSTS = {} in mm_cfg.py Right again! add_virtualhost() creates the mapping between the email hostname and the url hostname. This is especially import for list creation ttw because otherwise, there's no way to know that urls with www.dom.ain should be associated with email @dom.ain. Cheers, -Barry From barry@zope.com Sun Dec 23 06:56:04 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 23 Dec 2001 01:56:04 -0500 Subject: [Mailman-Developers] Re: External subscriber lists in 2.1 References: <9031.1008839118@kanga.nu> Message-ID: <15397.32772.522564.275695@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> In 2.1 when used with external subscriber storage (eg SQL), JCL> will the new equivalent of qrunner request and load the JCL> entire subscriber DB onto the heap prior to broadcast? That's really up to the implementation of the MemberAdaptor interface for SQL (but fwiw, I'm not aware of such a beast). Mailman's CalcrRecips module loops through all the member addresses in a list comprehension, but all other information is requested a member at a time. Note that if it was too expensive for getRegularMemberKeys() to return an in-memory list, it could (if you use Python 2.2) return an iterator object that implemented things in a more efficient manner, e.g. by paging through blocks. I believe that any place where we expect a Python sequence (list) we could probably accept an iterator. JCL> ObExcuse: Chap on -users asking about millions of JCL> subscribers. Cool! :) -Barry From twchiou@ms6.hinet.net Mon Dec 24 07:52:17 2001 From: twchiou@ms6.hinet.net (hinet) Date: Mon, 24 Dec 2001 15:52:17 +0800 Subject: [Mailman-Developers] Mailman VS. Base64 encoding Message-ID: RGVhciBhbGwsDQoNCkl0IHNlZW1zIE1haWxtYW4gMi4wLjYgY2FuJ3QgcHJvY2VzcyB0aGUgYmFz ZTY0IGVuY29kZWQgZS1tYWlsLA0Kc28gdGhlIEZvb3RlciBjYW4ndCBiZSBhcHBlbmRlZCB0byB0 aGUgZS1tYWlsIGNvcnJlY3RseSwgYW5kIHRoZSBhcmNoaXZlcyBhcmUNCmFsc28gYmFzZTY0IGVu Y29kZWQsICBkb2VzIGFueW9uZSBoYXZlIGFueSBzdWdnZXN0dGlvbj8NCg0KcmVnYXJkcw0KDQpD YWxlYg0K From marc_news@vasoftware.com Mon Dec 24 08:09:48 2001 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 24 Dec 2001 09:09:48 +0100 Subject: [Mailman-Developers] Mailman VS. Base64 encoding In-Reply-To: ; from twchiou@ms6.hinet.net on Mon, Dec 24, 2001 at 03:52:17PM +0800 References: Message-ID: <20011224090948.B11543@merlins.org> On Mon, Dec 24, 2001 at 03:52:17PM +0800, hinet wrote: > Dear all, > > It seems Mailman 2.0.6 can't process the base64 encoded e-mail, > so the Footer can't be appended to the e-mail correctly, and the archives are > also base64 encoded, does anyone have any suggesttion? 1) post to mailman-users, your question doesn't belong here 2) mm 2.0 doesn't support mime fully, the the archiver not at all. Use stripmime to remove attachments before they hit the list Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From fil@rezo.net Mon Dec 24 11:30:34 2001 From: fil@rezo.net (Fil) Date: Mon, 24 Dec 2001 12:30:34 +0100 Subject: [Mailman-Developers] ~mailman/bin/mailmanctl -s start Message-ID: <20011224123033.D12041@orwell.bok.net> (using Mailman 2.1a3) What happens when the computer crashes then starts again? If the pidfile stays there, mailctl start will fail. If we use mailmanctl -s start, it will fail if the pidfile is not there... What we need is a start command that does not fail, even if a pid file is already here. Or am I missing something? Furthermore, it seems buggy on my installation: # ~mailman/bin/mailmanctl -s start Starting Mailman's master qrunner. Traceback (most recent call last): File "/home/mailman/bin/mailmanctl", line 492, in ? main() File "/home/mailman/bin/mailmanctl", line 364, in main lock._transfer_to(pid) File "/home/mailman/Mailman/LockFile.py", line 357, in _transfer_to os.link(self.__lockfile, self.__tmpfname) OSError: [Errno 2] No such file or directory -- Fil From fil@rezo.net Mon Dec 24 13:47:04 2001 From: fil@rezo.net (Fil) Date: Mon, 24 Dec 2001 14:47:04 +0100 Subject: [Mailman-Developers] "continuation" bug in 2.1a3 (or in "email" package) Message-ID: <20011224144704.H12041@orwell.bok.net> My error log fills up with this message, one each time a message is snt to a list, apparently. What ca I do? Downgrade the email package? # python Python 2.1 (#1, Jun 1 2001, 23:51:21) [GCC 2.95.3 20010125 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import email >>> email.__version__ '0.96' logs/error: Dec 24 13:41:11 2001 qrunner(319): Traceback (most recent call last): Dec 24 13:41:11 2001 qrunner(319): File "/home/mailman/bin/qrunner", line 265, in ? Dec 24 13:41:11 2001 qrunner(319): main() Dec 24 13:41:11 2001 qrunner(319): File "/home/mailman/bin/qrunner", line 225, in main Dec 24 13:41:11 2001 qrunner(319): qrunner.run() Dec 24 13:41:11 2001 qrunner(319): File "/home/mailman/Mailman/Queue/Runner.py", line 58, in run Dec 24 13:41:11 2001 qrunner(319): filecnt = self.__oneloop() Dec 24 13:41:11 2001 qrunner(319): File "/home/mailman/Mailman/Queue/Runner.py", line 87, in __oneloop Dec 24 13:41:11 2001 qrunner(319): msg, msgdata = self._switchboard.dequeue(filebase) Dec 24 13:41:11 2001 qrunner(319): File "/home/mailman/Mailman/Queue/Switchboard.py", line 156, in dequeue Dec 24 13:41:11 2001 qrunner(319): msg = email.message_from_file(msgfp, Message.Message) Dec 24 13:41:11 2001 qrunner(319): File "/usr/local/lib/python2.1/site-packages/email/__init__.py", line 35, in message_from_file Dec 24 13:41:11 2001 qrunner(319): return _Parser(_class).parse(fp) Dec 24 13:41:11 2001 qrunner(319): File "/usr/local/lib/python2.1/site-packages/email/Parser.py", line 40, in parse Dec 24 13:41:11 2001 qrunner(319): self._parsebody(root, fp) Dec 24 13:41:11 2001 qrunner(319): File "/usr/local/lib/python2.1/site-packages/email/Parser.py", line 133, in _parsebody Dec 24 13:41:11 2001 qrunner(319): msgobj = self.parsestr(part) Dec 24 13:41:11 2001 qrunner(319): File "/usr/local/lib/python2.1/site-packages/email/Parser.py", line 44, in parsestr Dec 24 13:41:11 2001 qrunner(319): return self.parse(StringIO(text)) Dec 24 13:41:11 2001 qrunner(319): File "/usr/local/lib/python2.1/site-packages/email/Parser.py", line 40, in parse Dec 24 13:41:11 2001 qrunner(319): self._parsebody(root, fp) Dec 24 13:41:11 2001 qrunner(319): File "/usr/local/lib/python2.1/site-packages/email/Parser.py", line 144, in _parsebody Dec 24 13:41:11 2001 qrunner(319): self._parseheaders(blockmsg, fp) Dec 24 13:41:11 2001 qrunner(319): File "/usr/local/lib/python2.1/site-packages/email/Parser.py", line 80, in _parseheaders Dec 24 13:41:11 2001 qrunner(319): raise Errors.HeaderParseError( Dec 24 13:41:11 2001 qrunner(319): email.Errors . HeaderParseError : Not a header, not a continuation -- Fil From claw@kanga.nu Mon Dec 24 19:50:35 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 24 Dec 2001 11:50:35 -0800 Subject: [Mailman-Developers] ~mailman/bin/mailmanctl -s start In-Reply-To: Message from Fil of "Mon, 24 Dec 2001 12:30:34 +0100." <20011224123033.D12041@orwell.bok.net> References: <20011224123033.D12041@orwell.bok.net> Message-ID: <8177.1009223435@kanga.nu> On Mon, 24 Dec 2001 12:30:34 +0100 fil wrote: > What happens when the computer crashes then starts again? If the > pidfile stays there, mailctl start will fail. Then your system init scripts are broken. pidfiles go in /var/run -- which should be cleaned out by the system on initial boot, thus preventing the problem. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Mon Dec 24 20:46:31 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 24 Dec 2001 15:46:31 -0500 Subject: [Mailman-Developers] "continuation" bug in 2.1a3 (or in "email" package) References: <20011224144704.H12041@orwell.bok.net> Message-ID: <15399.37927.661955.232903@anthem.wooz.org> >>>>> "F" == Fil writes: F> My error log fills up with this message, one each time a F> message is snt to a list, apparently. What ca I do? Downgrade F> the email package? There ought to be a .pck file in qfiles/shunt which represents the offending message. Please send that to me. -Barry From fil@rezo.net Mon Dec 24 23:31:12 2001 From: fil@rezo.net (Fil) Date: Tue, 25 Dec 2001 00:31:12 +0100 Subject: [Mailman-Developers] ~mailman/bin/mailmanctl -s start In-Reply-To: <8177.1009223435@kanga.nu>; from claw@kanga.nu on Mon, Dec 24, 2001 at 11:50:35AM -0800 References: <20011224123033.D12041@orwell.bok.net> <8177.1009223435@kanga.nu> Message-ID: <20011225003112.A20256@orwell.bok.net> @ J C Lawrence (claw@kanga.nu) : > On Mon, 24 Dec 2001 12:30:34 +0100 > fil wrote: > > > What happens when the computer crashes then starts again? If the > > pidfile stays there, mailctl start will fail. > > Then your system init scripts are broken. pidfiles go in /var/run > -- which should be cleaned out by the system on initial boot, thus > preventing the problem. a 'grep pid' in the source directory gives me : misc/mailman:# pidfile: /home/mailman/data/qrunner.pid misc/mailman.in:# pidfile: @prefix@/data/qrunner.pid so how does mailman know to put its pidfile into /var/run/ ?? I just can find /home/mailman/data/qrunner.pid ; and there is a lock file at /home/mailman/locks/master-qrunner.miel.667 -- Fil, who's just put the presents under the tree. From mhz@alt-linux.org Tue Dec 25 22:58:23 2001 From: mhz@alt-linux.org (Mikhail Zabaluev) Date: Wed, 26 Dec 2001 01:58:23 +0300 Subject: [Mailman-Developers] Mailman VS. Base64 encoding In-Reply-To: <20011224090948.B11543@merlins.org> References: <20011224090948.B11543@merlins.org> Message-ID: <20011225225823.GB2014@localhost.localdomain> Hello Marc, On Mon, Dec 24, 2001 at 09:09:48AM +0100, Marc MERLIN wrote: > > On Mon, Dec 24, 2001 at 03:52:17PM +0800, hinet wrote: > > Dear all, > > > > It seems Mailman 2.0.6 can't process the base64 encoded e-mail, > > so the Footer can't be appended to the e-mail correctly, and the archives are > > also base64 encoded, does anyone have any suggesttion? > > 1) post to mailman-users, your question doesn't belong here > 2) mm 2.0 doesn't support mime fully, the the archiver not at all. > Use stripmime to remove attachments before they hit the list Some messages have text bodies encoded into base64; they are currently decorated with header and footer, plain and wrong. I have posted a patch earlier. As for solutions, one could employ the 'email' module, which has been included in Python 2.2. -- Stay tuned, MhZ JID: mookid@jabber.org ___________ Men who cherish for women the highest respect are seldom popular with them. -- Joseph Addison From fil@rezo.net Wed Dec 26 09:51:11 2001 From: fil@rezo.net (Fil) Date: Wed, 26 Dec 2001 10:51:11 +0100 Subject: [Mailman-Developers] ~mailman/bin/mailmanctl -s start In-Reply-To: <20011225003112.A20256@orwell.bok.net>; from fil@rezo.net on Tue, Dec 25, 2001 at 12:31:12AM +0100 References: <20011224123033.D12041@orwell.bok.net> <8177.1009223435@kanga.nu> <20011225003112.A20256@orwell.bok.net> Message-ID: <20011226105111.C4173@orwell.bok.net> > a 'grep pid' in the source directory gives: > misc/mailman:# pidfile: /home/mailman/data/qrunner.pid > misc/mailman.in:# pidfile: @prefix@/data/qrunner.pid > so how does mailman know to put its pidfile into /var/run/ ?? Unfortunately it seems there is no option in 'configure' to send the pidfile to /var/run/ ?? -- Fil From fil@rezo.net Wed Dec 26 10:02:29 2001 From: fil@rezo.net (Fil) Date: Wed, 26 Dec 2001 11:02:29 +0100 Subject: [Mailman-Developers] ~mailman/bin/mailmanctl -s start In-Reply-To: <20011226105111.C4173@orwell.bok.net>; from fil@rezo.net on Wed, Dec 26, 2001 at 10:51:11AM +0100 References: <20011224123033.D12041@orwell.bok.net> <8177.1009223435@kanga.nu> <20011225003112.A20256@orwell.bok.net> <20011226105111.C4173@orwell.bok.net> Message-ID: <20011226110229.E4173@orwell.bok.net> > Unfortunately it seems there is no option in 'configure' to send the pidfile > to /var/run/ ?? Oops! Sorry it was in Mailman/Defaults.py, so I could modify it in mm_cfg.py: PIDFILE = '/var/run/mailman.pid' -- Fil From claw@kanga.nu Wed Dec 26 10:04:34 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 26 Dec 2001 02:04:34 -0800 Subject: [Mailman-Developers] ~mailman/bin/mailmanctl -s start In-Reply-To: Message from Fil of "Wed, 26 Dec 2001 10:51:11 +0100." <20011226105111.C4173@orwell.bok.net> References: <20011224123033.D12041@orwell.bok.net> <8177.1009223435@kanga.nu> <20011225003112.A20256@orwell.bok.net> <20011226105111.C4173@orwell.bok.net> Message-ID: <18634.1009361074@kanga.nu> On Wed, 26 Dec 2001 10:51:11 +0100 fil wrote: >> a 'grep pid' in the source directory gives: misc/mailman:# >> pidfile: /home/mailman/data/qrunner.pid misc/mailman.in:# >> pidfile: @prefix@/data/qrunner.pid so how does mailman know to >> put its pidfile into /var/run/ ?? > Unfortunately it seems there is no option in 'configure' to send > the pidfile to /var/run/ ?? IIRC Debian accomplishes by patching the sources (or via handy sym-link). Unfortunately I can't check right now. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From bagnara@cs.unipr.it Thu Dec 13 20:17:54 2001 From: bagnara@cs.unipr.it (Roberto Bagnara) Date: Thu, 13 Dec 2001 21:17:54 +0100 Subject: [Mailman-Developers] Illegal command: mailcmd Message-ID: <3C190CF2.5EB568F4@cs.unipr.it> Hi there, we are experimenting with Mailman 2.1 (we absolutely need the Italian version) and we have problems with email confirmation of subscriptions. Here is the kind of message people trying to confirm receive in response: > Date: Wed, 12 Dec 2001 13:19:44 +0100 > From: Mail Delivery Subsystem > To: pescetti@math.unipr.it > Subject: Returned mail: see transcript for details > > The original message was received at Wed, 12 Dec 2001 13:19:44 +0100 > from prmat.math.unipr.it [160.78.64.1] > > ----- The following addresses had permanent fatal errors ----- > "|/home/mailman/mail/wrapper mailcmd comunicazioni-ufficiali" > (reason: 6) > (expanded from: ) > > ----- Transcript of session follows ----- > Illegal command: mailcmd > 554 5.3.0 unknown mailer error 6 Does this mean that "mailcmd" should be added to the array initializer starting at line 35 in src/mail-wrapper.c, now reading const char *VALID_COMMANDS[] = { "bounces", "join", "leave", "post", "owner", "request", NULL /* Sentinel, don't remove */ }; Or "mailcmd" is indeed an illegal command and the culprit is somewhere else? Thanks a lot, and keep up the great work. Roberto -- Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it From cns@Redbrick.dcu.ie Sat Dec 15 19:00:24 2001 From: cns@Redbrick.dcu.ie (Cillian Sharkey) Date: Sat, 15 Dec 2001 19:00:24 +0000 Subject: [Mailman-Developers] marshal.load() and error handling Message-ID: <20011215190024.R21964@prodigy.Redbrick.DCU.IE> I'd been getting EOF errors for some time now, both in log/error and from cron/checkdbs, e.g: Traceback (most recent call last): File "/local/mailman/cron/checkdbs", line 92, in ? main() File "/local/mailman/cron/checkdbs", line 43, in main count = mlist.NumRequestsPending() File "/local/mailman/Mailman/ListAdmin.py", line 96, in NumRequestsPending self.__opendb() File "/local/mailman/Mailman/ListAdmin.py", line 69, in __opendb self.__db = marshal.load(fp) EOFError: EOF read where object expected So I decided to track it down: the problem was lists with corrupt request.dbs. I think the solution would be to handle the EOFError exception in ListAdmin.py in __opendb. I don't know Python, but perhaps something along the lines of: def __opendb(self): if self.__db is None: assert self.Locked() and self.__filename try: fp = open(self.__filename) self.__db = marshal.load(fp) fp.close() except IOError, e: if e.errno <> errno.ENOENT: raise self.__db = {} + except EOFError, e: + self.__db = {} In addition to this, it may be worthwhile handling other errors (ValueError, TypeError etc.) which indicate corrupt databases. Some of the other mailman code which uses marshal.load does this. Perhaps all uses of marshal.load should be checked for extra error handling? There was no easy way to find out which request database was corrupt (there doesn't appear to be any script similar to check_db to do the same for the request.db file) so I just wrote a script based on check_db to help find corrupt request.dbs. I think something like this (cleaned up of course) should be added to the distribution.. bin/check_request_db ------------8<------------ #! /usr/bin/env python """Check the raw request.db for a mailing list. Usage: %(program)s listname """ import sys import os import string import marshal import paths from Mailman import mm_cfg program = sys.argv[0] def testfile(filename): try: fp = open(filename) except IOError, (code, msg): print filename, 'cannot be opened:\n\t', msg return 1 else: try: d = marshal.load(fp) except (EOFError, ValueError, TypeError), msg: print filename, 'is corrupted:\n\t', msg return 1 else: print filename, 'is fine' return 0 def main(): if len(sys.argv) == 2: listname = string.lower(sys.argv[1]) else: print __doc__ % globals() sys.exit(1) listpath = os.path.join(mm_cfg.LIST_DATA_DIR, listname) configdb = os.path.join(listpath, 'request.db') testfile(configdb) if __name__ == '__main__': main() ------------>8------------ Regards, -- Cillian [PS: please CC me on any replies] From marc_news@valinux.com Sun Dec 16 05:45:09 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Sat, 15 Dec 2001 21:45:09 -0800 Subject: [Mailman-Developers] [Patch] SMTPDirect.py wrongly closing the connection In-Reply-To: <15385.45940.956750.851077@anthem.wooz.org>; from barry@zope.com on Fri, Dec 14, 2001 at 03:08:20AM -0500 References: <20011212231535.N15120@magic.merlins.org> <15385.45940.956750.851077@anthem.wooz.org> Message-ID: <20011215214509.A16047@moremagic.merlins.org> On Fri, Dec 14, 2001 at 03:08:20AM -0500, Barry A. Warsaw wrote: > > >>>>> "MM" == Marc MERLIN writes: > > MM> So, I have my mailman alpha 3 cvs with python 2.1 seemingly > MM> working, and when I move a list with more than one subscriber > MM> to it > > Exactly how many subscribers are on your list? Is it more than > SMTP_MAX_RCPTS? I hope your answer is "yes"! The answer is "No". The reason mailman does two chunks is the new code that splits per top tld. I did a test with foo.org and bar.com, which caused to chunks and two separate deliveries to the MTA > SMTPDirect tries to reuse a connection to the smtpd when delivering > multiple chunks. Yes > The code in deliver() as it currently stands will do > the following: > > - On the first chunk, it finds its socket isn't connected, so it > connects, doing the EHLO/HELO dance > - Then it calls conn.sendmail() which does the MAIL FROM/RCPT TO/DATA > dance > - Then the finally clause executes and a QUIT is issued. The server > closes the connection, as it must (RFC 2821). > - Now the next chunk comes along and we find the socket is not > connected, so we re-connect. Note that we're using the same > smtplib.SMTP object, but we're getting a new socket connection > - The state in the SMTP object thinks it's already issued an EHLO and > so doesn't issue it again. Instead, when this time it calls > sendmail() it jumps right to MAIL FROM and boom, you're hosed. Yes, that's where I'm seeing the problem, and confirmed with running exim in debug mode. The when the second batch is about to be delivered, the first thing exim sees on the new connection is MAIL FROM (no EHLO). > Your patch eliminates the QUIT in the finally clause and so when the > the first transaction in the session completes, the session won't be > QUIT, the socket won't be closed, and the second sendmail() call > succeeds. Yes, that's what I intended to do :-) > Interestingly enough, it looks like Postfix isn't bothered by the lack > of EHLO/HELO at the start of the second session. This behavior > appears to be controlled by the smtpd_helo_required config variable > which seems to default to "no". Can you guess why I never noticed > this bug before? :) Yeah, I figured that most MTAs would allow the mail anyway (probably exim too if you turn off the paranoia checks) > Your patch clearly gets to the heart of the matter: in a multiple > transaction session, we mustn't issue a QUIT until the session is > over. So SMTPDirect.py is broken. I'm not sure your patch is > entirely correct -- I need to trace the code through both the Neither am I. Mailman just works a lot better with it on my system, but I knew there was something cleaner (especially because my mailman doesn't really close the connection, it just drops the socket when the program ends) > non-threaded and threaded delivery paths and think about the error > conditions. Probably the whole try/finally bit can be removed, and > .quit() needs to be called when we're really done with the > connection. Attached is a patch that I think will do the trick, but I > haven't tested it yet. I tried it, and it seems to work fine. I now also get: 2001-12-15 21:45:07 SMTP connection from localhost (moremagic.merlins.org) [127.0.0.1] closed by QUIT > Now, if you tell me that the # of recips is < SMTP_MAX_RCPTS, then > none of this analysis is relevant, and I can't see how you're getting > this problem. ;) It's all right, you forgot the code that splits by TLDs :-) > Oh sure, rub it in! We're still unseasonably warm here in DC, even if > we have gotten below 70 deg F the last few days. No sign of snow so Kirkwood in California current has the deepest snow base in all of the US (185 inches, but who's counting :-D) > far, so I hope you think about Mailman on all the lifts up the (typing in the car on the way back) Ummh, sure, I was thinking about the patch while wrestling with the deep fresh powder :-))) > P.S. Python 2.2 rc 1 release tomorrow, er, later today. Hopefully > some Mailman catch up time this weekend. Good to hear that :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From fil@rezo.net Sun Dec 23 00:29:15 2001 From: fil@rezo.net (Fil) Date: Sun, 23 Dec 2001 01:29:15 +0100 Subject: [Mailman-Developers] bug in pipermail ? Message-ID: <20011223012915.A11204@orwell.bok.net> Her's the traceback: # bin/arch listes ... figuring article archives 2001-July Traceback (most recent call last): File "bin/arch", line 129, in ? main() File "bin/arch", line 118, in main archiver.processUnixMailbox(fp, Article) File "/home/mailman/Mailman/Archiver/pipermail.py", line 525, in processUnixMailbox m = mbox.next() File "/home/mailman/Mailman/pythonlib/mailbox.py", line 38, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman/Mailman/Mailbox.py", line 77, in scrubber return mailbox.scrub(msg) File "/home/mailman/Mailman/Mailbox.py", line 97, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 154, in process url = save_attachment(mlist, part) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 301, in save_attachment fp.write(decodedpayload) TypeError: argument must be string or read-only character buffer, not instance (I'm using latest cvs) -- Fil From barry@zope.com Thu Dec 27 05:44:04 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 27 Dec 2001 00:44:04 -0500 Subject: [Mailman-Developers] Getting Mailman and Postfix to play nice in virtual domains Message-ID: <15402.46372.451366.722145@anthem.wooz.org> I've been playing around with support for virtual domains in Mailman, trying to make them play nice with Postfix. For the record, I'm using Postfix 20010228-pl08 on a RH6.1-ish Linux box. I'm using the latest Mailman 2.1 alpha cvs snapshots. I'm not sure I understand how Postfix expands addresses in virtual tables, so let me explain how things are currently set up. Let's say I have two domains that I want my Postfix to answer to dom1.ain and dom2.ain. I am going to have mailing lists and plain users in both domains. In my main.cf file I have myhostname = mail.dom1.ain mydomain = dom1.ain myorigin = $myhostname alias_maps = ..., hash:/usr/local/mailman/data/aliases virtual_maps = ..., hash:/usr/local/etc/postfix/virtual-dom1, hash:/usr/local/etc/postfix/virtual-dom2, hash:/usr/local/mailman/data/virtual-mailman In virtual-dom1 I have dom1.ain IGNORE @dom1.ain @mail.dom1.ain and in virtual-dom2 I have dom2.ain IGNORE # lots of addresses which are only visible in dom2.ain... Note that the two files /usr/local/mailman/data/* are written by Mailman when a mailing list is created or deleted, and they must be set up a priori with the proper permissions (i.e. must be owned by `mailman') so that the mail programs they refer to will get executed with the proper uid. In /usr/local/mailman/data/aliases{,.db} I'll have entries such as: list1: "|/usr/local/mailman/mail/mailman post list1" list1-admin: "|/usr/local/mailman/mail/mailman bounces list1 list1-bounces: "|/usr/local/mailman/mail/mailman bounces list1" list1-join: "|/usr/local/mailman/mail/mailman join list1" list1-leave: "|/usr/local/mailman/mail/mailman leave list1" list1-owner: "|/usr/local/mailman/mail/mailman owner list1" list1-request: "|/usr/local/mailman/mail/mailman request list1" list2: "|/usr/local/mailman/mail/mailman post list2" list2-admin: "|/usr/local/mailman/mail/mailman bounces list2 list2-bounces: "|/usr/local/mailman/mail/mailman bounces list2" list2-join: "|/usr/local/mailman/mail/mailman join list2" list2-leave: "|/usr/local/mailman/mail/mailman leave list2" list2-owner: "|/usr/local/mailman/mail/mailman owner list2" list2-request: "|/usr/local/mailman/mail/mailman request list2" and in /usr/local/mailman/data/virtual-mailman{,.db} I'll have entries such as list1@dom1.ain list1 list1-admin@dom1.ain list1-admin list1-bounces@dom1.ain list1-bounces list1-join@dom1.ain list1-join list1-leave@dom1.ain list1-leave list1-owner@dom1.ain list1-owner list1-request@dom1.ain list1-request list2@dom2.ain list2 list2-admin@dom2.ain list2-admin list2-bounces@dom2.ain list2-bounces list2-join@dom2.ain list2-join list2-leave@dom2.ain list2-leave list2-owner@dom2.ain list2-owner list2-request@dom2.ain list2-request That is, list1 should only be visible in dom1.ain and list2 should only be visible in dom2.ain. Note that these are all Postfix-style virtual domains. With the current setup, I must set myorigin to mail.dom1.ain and not dom1.ain, otherwise mail to list1@dom1.ain will bounce with an "unknown user". I believe the reason for this is because unqualified bare names on the right-hand side of a virtual map entry will get $myorigin appended to them. Further, I believe that Postfix's recursive expansion rules state that if the right hand side is the same as the left hand side, expansion stops. So, when a message is received for list1@dom1.ain, this gets expanded to list1+$myorigin, and if $myorigin is dom1.ain, then Postfix stops and tries to deliver to list1@dom1.ain. Postfix ignores the @dom1.ain -> @mail.dom1.ain mapping in the virtual-dom1 file because (I believe) this is a more general mapping and the more specific mapping trumps. So Postfix doesn't know where to deliver list1@dom1.ain and so it bounces it. However, if $myorigin is mail.dom1.ain, then list1@dom1.ain expands to list1@mail.dom1.ain, and because this is the default $mydestination, Postfix stops, consults its local aliases table, and successfully delivers the message to the intended program. Delivery to list2 works for by $myorigin = dom1.ain and $myorigin = mail.dom1.ain, and breaks down like so. When $myorigin = dom1.ain, mail comes in addressed to list2@dom2.ain, which expands to list2@dom1.ain. Postfix continues expansion of this address, sees the mapping from dom1.ain -> mail.dom1.ain in virtual-dom1, and expands this to list2@mail.dom1.ain. Then it sees the default $mydestination after the @y, looks this up in the alias table, and delivers it to the intended program. When $myorigin = mail.dom1.ain, it also works, simply shortcircuiting one level of expansion. I.e. list2@dom2.ain -> list2@mail.dom1.ain directly. To sum up, here are my questions: 1. When a "bare" address appears on the right hand side of a virtual table entry, is it true that $myorigin gets appended during the address expansion phase? 2. If not, how does Postfix actually deal with a bare address on the right hand side of a virtual table entry? 3. Is it correct that if list1@dom1.ain expands to list1+$myorigin in a virtual map, and $myorigin = dom1.ain, expansion will stop here without seeing the mapping of dom1.ain -> mail.dom1.ain in the virtual-dom1 map? And thus delivery will fail? Apologies for such a long ramble, but I really want Mailman and Postfix to play nicely w.r.t. virtual domains. It would be more difficult to hack Mailman to include the fully qualified expansion on the right hand side of its virtual table, e.g. list2@dom2.ain list2@mail.dom1.ain but I may have to do this. I'd like to better understand exactly what Postfix is doing though before I propose a solution for Mailman, so part of the purpose of this email is as a sanity check. Aside: all this is further complicated by the fact that to use hash: tables, the version of BerkeleyDB that Postfix is linked against must match the version that Python is linked against, otherwise Mailman may write hash tables that Postfix can't read. It doesn't help that I think BerkeleyDB support in Python 2.2 is broken. :( All this is starting to feel too complicated and error prone so I might have to punt and try a different approach. Thanks, -Barry From barry@zope.com Thu Dec 27 07:16:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 27 Dec 2001 02:16:46 -0500 Subject: [Mailman-Developers] Illegal command: mailcmd References: <3C190CF2.5EB568F4@cs.unipr.it> Message-ID: <15402.51934.741346.850610@anthem.wooz.org> >>>>> "RB" == Roberto Bagnara writes: RB> we are experimenting with Mailman 2.1 (we absolutely need the RB> Italian version) and we have problems with email confirmation RB> of subscriptions. Here is the kind of message people trying RB> to confirm receive in response: RB> Does this mean that "mailcmd" should be added to the array RB> initializer starting at line 35 in src/mail-wrapper.c, now RB> reading RB> Or "mailcmd" is indeed an illegal command and the culprit RB> is somewhere else? RB> Thanks a lot, and keep up the great work. If you're using the current cvs snapshot, you'll need to regenerate your aliases using bin/genaliases. In an effort to make sane the mapping between list aliases, wrapper programs, and the qrunners their associated with, mailcmd has been renamed to request. There have been other changes to the wrapper scripts, e.g. it's now called `mailman' instead of `wrapper' so as to avoid collisions with other `M' list management software. Anybody upgrading from 2.1a3 to 2.1a4 (yeah, yeah, RSN :) will have to also regenerate their aliases. Should be easy with bin/genaliases, although we'll probably need updated Exim recipes. -Barry From donal.hunt2@mail.dcu.ie Thu Dec 27 21:03:32 2001 From: donal.hunt2@mail.dcu.ie (donal.hunt2@mail.dcu.ie) Date: Thu, 27 Dec 2001 21:03:32 +0000 Subject: [Mailman-Developers] http://www.list.org/MM21/install-final.html Message-ID: <3C29E4A8000001A7@hawk.dcu.ie> Just though i'ld point out that the info on http://www.list.org/MM21/inst= all-final.html is outdated and needs to be changed so that it's inline with the INSTALL file from the tar.gz distribution. ie a mailman list needs to be created instead of the method used in Mailm= an 2.0.x and before... Regards Donal From fil@rezo.net Fri Dec 28 00:15:26 2001 From: fil@rezo.net (Fil) Date: Fri, 28 Dec 2001 01:15:26 +0100 Subject: [Mailman-Developers] a problem in upgrading with moderated lists Message-ID: <20011228011526.F2576@orwell.bok.net> Hi, when you upgrade Mailman to 2.1a3 from 2.0, moderated lists correctly take on the attributes generic_nonmember_action = Hold default_member_moderation = Yes However the latter is valid only for NEW subscribers. Subscribers already registered have their moderation bit set to 0 (not moderated) whereas it should be set to 1 (moderated) to conform to the previous settings. And, by the way, these settings are not given through config_list -o -- Fil From barry@zope.com Fri Dec 28 22:40:15 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 28 Dec 2001 17:40:15 -0500 Subject: [Mailman-Developers] ADMINDB_PAGE_TEXT_LIMIT = -1 does not work References: <200110172152.OAA12468@utopia.West.Sun.COM> Message-ID: <15404.62671.394359.193199@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: >> putting ADMINDB_PAGE_TEXT_LIMIT = -1 in mm_cfg.py to view all >> the message to be approved, seems to not work properly. DM> ...in 2.1 CVS. Yup, seems to be the case. I've filed a bug DM> with a fix that works for me (to be made much more elegant DM> by Barry :) And at long last, I've added Dan's fix. ;) I was putting this off until I finished the admindb.py rewrite, but that's now almost complete. I should be checking in the new admindb.py code shortly. The nicest bit about the new stuff is that it now shows just an overview of the old messages, sorted by sender. You can then drill down into all the messages held by that sender, or a specific held message (for now, getting the old list view). The overview stuff is integrated with the sender filters so you can do stuff like discard all the messages from a particular sender, at the same time, adding them to the auto-discard sender filter. Should be very cool! Cheers, -Barry From tollef@add.no Sat Dec 29 14:50:20 2001 From: tollef@add.no (Tollef Fog Heen) Date: 29 Dec 2001 15:50:20 +0100 Subject: [Mailman-Developers] [] Bug#125858: mailman: newlist command line Message-ID: <87sn9ucc7n.fsf@arabella.dep.no> --=-=-= What do people think? Just adding a comma or something between the email addresses does not seem to work (because of ValidateEmail). Or is this fixed in a better way in 2.1? --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: debbugs@master.debian.org Wed Dec 19 21:39:39 2001 Return-Path: Delivered-To: tfheen@localhost.pvv.org Received: from localhost (localhost [127.0.0.1]) by arabella.pvv.org (Postfix) with ESMTP id 4B30D971E2 for ; Wed, 19 Dec 2001 21:39:39 +0100 (CET) Delivered-To: tollef@add.no Received: from localhost [127.0.0.1] by localhost with POP3 (fetchmail-5.9.3) for tfheen@localhost (single-drop); Wed, 19 Dec 2001 21:39:39 +0100 (CET) Received: (qmail 4698 invoked from network); 19 Dec 2001 20:27:31 -0000 Received: from unknown (HELO master.debian.org) (unknown) by unknown with SMTP; 19 Dec 2001 20:27:31 -0000 Received: from debbugs by master.debian.org with local (Exim 3.12 1 (Debian)) id 16GnOj-0005S9-00; Wed, 19 Dec 2001 14:33:05 -0600 X-Loop: owner@bugs.debian.org Subject: Bug#125858: mailman: newlist command line Reply-To: , 125858@bugs.debian.org Resent-From: Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: Tollef Fog Heen Resent-Date: Wed, 19 Dec 2001 20:33:04 GMT Resent-Message-ID: X-Debian-PR-Message: report 125858 X-Debian-PR-Package: mailman X-Debian-PR-Keywords: Received: via spool by submit@bugs.debian.org id=B.100879341317322 (code B ref -1); Wed, 19 Dec 2001 20:33:04 GMT From: To: submit@bugs.debian.org X-Mailer: bug 3.3.10 Message-Id: <20011219202514.0171E23AE91@amaya.homeip.net> Date: Wed, 19 Dec 2001 21:25:14 +0100 (CET) Delivered-To: submit@bugs.debian.org Resent-Sender: Debian BTS Lines: 21 Xref: arabella.intern.opera.no in-2001-12:923 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Package: mailman Version: N/A Severity: wishlist Dear friend, It would be really nice if while adding lists with the /usr/lib/mailman/bin/newlist command one could specify several listadmin-addr in a certain format. Please forward this wishlist upstream to see if it could be taken into account. Thank you very much for your work in Debian. -- System Information Debian Release: 3.0 Kernel Version: Linux aenima 2.4.14 #1 Tue Nov 20 22:42:50 CET 2001 i686 unknown --=-=-= -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. --=-=-=-- From dmick@utopia.West.Sun.COM Sun Dec 30 11:35:58 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Sun, 30 Dec 2001 03:35:58 -0800 Subject: [Mailman-Developers] New Bounce system Message-ID: <3C2EFC1E.4DCE7C2F@utopia.west.sun.com> looks interesting, but a warning: when you upgrade, all your previous "nomails" will appear to revert to "off". Not exactly what I expected. (the value is actually "UNKNOWN", which still disables delivery...but it doesn't show up.) Barry, do you plan to change the option display in the membership list and/or personal pages to something multivalued?... From reed@icpdas.com Mon Dec 31 07:47:30 2001 From: reed@icpdas.com (Reed Lai) Date: Mon, 31 Dec 2001 15:47:30 +0800 Subject: [Mailman-Developers] decoding bug of non-ascii MIME encoded subject Message-ID: <20011231154730.A3114@dan.icpdas.com> --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Pipermail 0.05 (Mailman edition) does not seem to decode non-ascii MIME subject correctly under some conditions, even the "Prefix for subject line of list postings" has been emptied. Attached ma1 files are captured before ma2 files. The messages sent by Reed Lai are subjected with iso-8859-1 encoding for big5 characters. The messages sent by SunnyCat are subjected with big5 encoding for big5 characters. The decoding seems to be determined by last message. -- Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ --mP3DRpeJDSE+ciuQ Content-Type: image/png Content-Disposition: attachment; filename="ma1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAYEAAAFxCAIAAAAaqYNqAAAABGdBTUEAALGPC/xhBQAAAAZi S0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB9EMHwMqGkhzROkA ACAASURBVHic7Z3bkqUgk4Wxo594Yp5g4r+cmFd2Lqyi2XlYJKCC7vVFR8cuhcwUIU0O4rbv e/pl27b8uzxektN4CYJpypTVZFUJgBHhE4nci9sYv01xLQfBmhNJeSmX3qZq3Raql6ozHtrI P+Y5/edxpKyL+c/WNCLlIPu+i+LefzlX0c0sWIeuLsYFL7nKPTZ7lXyKMYNoI398kFm9zIOH CHy1OM1tTsEL8UgTLLq5gLb2CKdT5U8qIm3TuR6AcKYpTVXRudANncs6ZXhnLZpI9QJfUAI/ cVB5JS+4KkLIU/ibWsb/vLP7vkfSdNg3TmmbNqM6jNedQB83UwbHEatDsFUzxD0K3o4cI1cj oLiiuBl9Zesdj0+/6MgdGGlmxAG4Lk9TRVBvpNp4Jg3erGBBYSF/0rdSDp+b9XgwAXB2IjtI o4+buSJmBHVV8TJGFFWLVKc05eDh2LKPpn9EbqsQEsS7TXo42TPyRIIFOHKz9AX2VXLkg76w UxZ/2jclOOKvstpFxuAyHWMfphl9Ayi5zTRl6YgdTCEdBnsxUSRLdwSUoMFAznWtrKl2BWXq ghLVo+NuGj5onXHH64h3bboTlLTWy6ocryoEhQSr3WBNMN1uGiixjizVR/elluACvLShtZo9 crM8TCFaoBsHfWEQhOkIB15ApGEPCr+6SPvk607EWcSHw1bmxHv3V/yd+wjjokeo3v6zLGyq Z5c2yEFuMGMPjEx3yDxX2mHhVpsDAV0GMSZyloVXlN4NAJuD4V4V6YM8ZVVTImmmo80YN2zZ SxskN+Zzxd5JX4W8zg2VPKVgwbWLrlb3FX34IB0EXXQDqpyo9Ck3e0H0XSjHoRZxvh4jEf3V bmiR3sYIpwwYHcj3xR5dLpi+ntR4gns414xLL2qFsViwJiDLOb0tPLFxnXKzsBD5vtj2SU7n FR8e8cbHbwB0+800pnfvS3AFWvvNZnjqRvLe6cTvseHEGGEWrQXlrQWJpPwL5HrKqqNrwTQi fdyGIPEJiJun6luJlOeJZtzjFK4rsVxWVcneE0VkjMdW1dsUt20pwM3S12s251KCXDDROpYc qTo4zblD14MzaFU/1Z1AGGaO24GD+bhIU3WCETMAID0OKuOKrisxIWrcBixE64q3jqaqHgnn dbKRAjRleurMGhtJeRxZfWSRkJfxxDjoUr73fTFCbiM4uvqd0AcRci2zBuCfAn0QITfBXpgJ fRAh1xJZv/LNcEyaEDITxkGEkJnQBxFCZkIfRAiZCX0QIWQm9EGEkJnQBxFCZkIfRAiZCX0Q IWQm9EGEkJnQBxFCZkIfRAiZCX0QIWQm9EGEkJnQBxFCZkIfRAiZCX0QIWQm9EGEkJnQBxFC ZkIfRAiZCX0QIWQm9EGEkJn8naU48sHvL//mh/fx8shHzWPy06+czrxmxm3rEWjKN1WMmG2K GpEzYue49qCixZkWB1Xbz4sdUPBjm14JnFgy+95Zcc+9Obo8sGHdZgt141cxYmdVe/CbrIOl MR32xe7m9V/7fXR7IPczrS92sO/7tm3b9vOpxeOHbqW696G7bJEjyXIBIjFQYZpUNcC7Iq0I GGlSZhTahczWrwyXkULZZdDdB3HE/NPMIuSf0jER6kzLTXXedZXZc94T7awary9hXPtqXBIH bQWnSNv3vWxLuUWJRguOeBlL34dTCpMi6krhpbryR6vqkjKjkFz+38rR3nLWUoaQl4d+PF9z yClbb25UQv54h6KUrH0KUKevAjivEwehTFcuFOVkZmG+g4X6YmVDKg+C9Mkaz87NL9gCm1TE zwpMe87tl+lwDGsHBNtbbidAzvFP54rIb6Jsrq0ZtTHxgx1oCRHjzcJ8AfN9EGg5GRFSBXsx TbFYVYW2uWp2kLMCRiGze+i6ryV7ovK/Gzia6EO7KlXjby7M25jvgyLsBfnI8cNzQ2aPJvs7 HcJEVAiTwNkIpeVCdTcRhx6Tk9JJbug2RBfyWTza+EEu8UGtjao6eJEblfAvIkFTt0gkrqrQ iUdchjkmfd2UWVOoZXbEyiFSMz0QJX6bB08BmNeqqC/XiPCqruvKbS79EfuoYjVxo5/hI0eE Cm+KqkmgNt5UVxUiRqyDlgsDdjX5Jc5qg9VB+8HrDTCnz6HZsiD1ULQQVaYBB70x74jZwnIx 0rxbE3ylGeKq8Z8Rk/rs9IxPTrlF1C3ONB80Bdyreg3BwaCLau2JYlvb9ixWsHPBYgkyeX3Q /XhdsHcw93Ke2wzIRL4rDkqqlb7s8uMDVc/yvWY/bkFWsPNxNfrrfBAhZCmeMTdPCHkr88aD wLSKefwsjVWZeArkCoDGbpuDGQmZzbw4qNo8prSfO5vuic6uQ8LiIyvka/imebGmhnq1Gwq6 gG4zcEY6ILIMs33QsR6rXJK1q/eCde9Mr5OrriQTK8DEb5FdrxszZQLbtHAzl57NNu0JGqPl mxmBdkJuZ/m9O3KbNNeN6vW53ptOZcpy0ESLTcrTeTKBbVq4aYy3Llg7L6ELgzN62gmZwUrz Yn2P5X1gS5VLG2HftWC6h6s4RE1WZQEf5AULHWxv3F7loHv12wrL5gjxWcAHncj+wB1W4q7h CjdEx0Rms8TeHT+NZNxxlKOtjyDe/byiF1YOP5VFZ/4m5Brmvauh52682Z/IEe+gVlcCuoGn zIvpP3VeMLvnga8OjI6ZY9XB34RcA98XI4TM5F3jQYSQp7HG+2JkcRgsk8uY54NYrQkh7IsR QuZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFk JvRBhJCZ0AcRQmZCH0QImQl9ECFkJj/7B5UfI9z3fdvO3OP1EH7uprHm1xM9FfpydPYR87I0 UwuwSpwVVumM4jY1KfISmPe66YriBwnR/E2quoiW0OePzvViGu0owTddtSUi+/FJ2D6DhRz9 22vk4mz1cjwLg4rMBGahNV2Rp/0oYS2cEIHRFws2bIB+nt/wPBxRcXpe7NHMs6LYgyZVU7aa 4WWpOjhC+vi3l2tZn/KTTZzSfYEcQ3nP7TKq17+94EvLN4V7v4VVHY0H9C9Mgdr4bMlgKxVX J7R7iiIXeHqn2zObEMCf9OkIzBEH4Q60d9D+K/8QDSYrKoUIySkWmGy/lAdzu9Lag+R+Wek0 y4Mgo/ZZfe7PC0/0kyAoM/leO5KFQRC5jp++WNm6vP5XtUsV73PF6y6QaTqa1nAAmOeNEEe6 KqeMLpnqIm4OJ8OepSqZkHP5+K5GfvKD4c+b7IKYYVdfdnFExGVeeiww/1nt7Ay286AiMBTd 0VeNxET0XyTOz7xY2aS9uZKcIIWdUbAuHkrjoy1BdSNBULfSEa5ouiCwAk8aehByGz99MexT +ipla679FyFkMPiqXpr2XDqjeTBZA8beWVN11WNqvcEwpGpexAEFr4g+i4zwMXWV0RVahD/x XKYLqEoTzcBsYJHGALohQIh3OTp93Gydq2kAGxuAu5baPE9d6xWBg/o4ISZLPMGAnyKEvJt5 33r+BMcXhJC3skQclAJdJELIK1nFBxFCvhPu3UEImcm/9+Y1kRDJXDd0bmx10eQLntfrFhiZ ORrPclaufDY4P9hk8xWVgbyPj/fF9oJg/htqGFAxoj2vMM7XOzIQvqlXzKoWmlk8OeKsmcu7 BC9XPtuqKGgzvQ+JcHJfrMl/NWE2uRMZFNia3bsELAdHMV7eqh9sVRSRQEgQY24+P9aStYxQ LFoTGUXiYEbcj9s+9wDJf+LIXyyS7Gg8HX3AyCLJCJEl1K1CvATXORG6JxLhIw7atg0sky09 RW6fZSUzf1czjlfTw2ztNNNA69X9i/IgtiEi30sZlINHcCK5gtaWBcsgiFzBhw8CPanuqhbP GOnH4b6DiB2atJsCPY+sxXqjLR16qwMrohD23zd+RTKQC3sWTxEhV2D0xUYiiNOpPn6BnU0P cC9eq2ppNb4jTTV99ZZ5XdfkO+smafrgIvWHrM/d72rsA9t0BAc4huxLKS08oXOWK6z6VnoQ chv2vNh4nwKz/yKUYr3gsZw+bRZ9DSxWd2REjAAOiuOt7VYEdKYc87i2oS9X1QHpouPAEDkX 1ET3z+mtVJv58oR4GcsEOY3ZkPZi+kbHUGZG8KjHoy2mCu+gZwBOj7PgTqIwu9qTAhcLfJCZ pclmrY4Qk7sfX6a3Yk0l5GuZsHcHjkoIIV/FhG58tStECPkeOJRICJkJ9+4ghMwETZqYxx/B 4CJpQsht/Kk21Me1ZDogQh7EKnvanwUXyxHyLH58kHjv0Vte7K0PLA9GjiRrSh4vQTQP4pc5 CSHr0zAmval9hbIj0K7BO+JlLH0fTlk1svrOByFkHQwf5L0Q5Inw3rHYf/fTiLuPuArzdbOk nB0hZHH++aBI0xUhhu4umR2optikqgIgoipCyPq0rQ/aC/KR44fnhszOVPZ3XoCDVRBCXoPc RzHBIELsX4F7YVWErwmqyGfBkDm9FSFPwZjDik9vtU6B7cUO82AniqrA5PimR6+rJOQ7mTOZ zR08CCEH09YoghCGEPI9TFvUxx08CCGJe3cQQubCvTsIITOhDyKEzIQ+iBAyE/ogQshM6IMI ITOhDyKEzIQ+iBAyE/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM6IMIITNZyAdtW+ImQoR8 Gwv5oBPRvuxwcFf4uKpY+lZCAGt96zmyl9HRnuMpgXyR4DhbHszphdJtQwaIs/v+zw0FN2vy PkLbB957O/71N241Ra5g0TjorNgBOx2RplS677a/CBo2GHaVn4c8GNnr1vQd1W+oRIQQMs78 OKhsXPGGZoYwONkRj4hcnqfQsYyWk9PoAMqzCgdQF8EQhqzMfB90cDTssjGDEMZLht0ZdnDZ AC+j6JeZEkSWoKPUCK+h/0xO3yr+rTfgmMrvL5WfY4paT0gLl/igK77zlb2DF54kFY+Ufi1Z MYj2WV5nrSNA85xjWI77pTbzS3D6YOTj3abSw+9kCYM9QUIwq4wHZRcAanvpYoKDMlmmSC+G flItSCndUHhceWhUqBwS0sfxFyJFjNP0GNDjROzKkUuZ3xcrO0HVqg5GcA6Ep9CuJxXjzaU7 q86vm7+BkekzEDvMjk3nfQQgIggSPSP8ReyqCu8g/Q65jfk+KLUMlOBcZcs3h5+BIm9cGaiL DISbf3a3bjDD5VjS40rKIIvOiFzNJX2xclL5XMkiHtGOJivMv/GgtZ6YF1GS/hH3Vrr71tov E2MxZW8LHwTHNZ7TiUsgpJuFnnIgQDAnmPRMmRBldojSZ1/JUyEU6SyedjBsFBlR0ksHxZCz OAsOelNaYAEkHucm5AoWql4dnRRv8luIwrNjQGCC/iIlw5dhWtMT8nqWGA/qpqMxB+e/gpKb pu3jYgn5HqbFQRxhSHRJhEyMgxZqfuwgETKPVdYovgQd3Y2sU6zqqi5qYrRJlufZ40GnEVs7 2JYSyI/P8+nZODyiLt5k2do2DeGeIeR+GAd9clbsgJ2OSLOtsmkI9wwh9/PFcVDT+xdeysiK Jj15Bl450bGMlrM9Y9MQhjAkwtt8UPNGE+YSxk+JH4nNZNidYQe3L7RpCPcMIffzKh+kd644 AXPJkBAu4pH9wZuGcM8QcjPvGQ8q/U5D9c0uoPoCGHAWQKZIv62+aQj3DCE386o4qI2dm4YI VdwzhEzgPT6obDnRqtxX3c0R3/TmTUO4Zwi5jvf0xZIaUDgTEY9oR5M17m/YNIR7hpDb4NMG BgjmBJOeKROizA5R+uwreSqEIp3F0w6GjQIjStwzhMyCt7mrk+JNfm/cNISQNt4zHnQrHY05 OP8VlNw0bR8XS8jtfF8cxCGGRJdEFuL74iA2P0JW4lXzYoSQx7FkHGSu9zOneyIDt1pUcqaZ vFPV0Em8pQHkmFNdwOa+seeg2ZGM2vgRLVlmpKC65UttH6+hDUqL6Dq4R+MLWC8OOiro8e+s 2ZxyqruUnE/l46lYvqwTY/n6/1Q40NZ2pRcZVfHWGXVnNI3v1iLQF5iPNBU+5PAC97x6lp1d 1ogdEFc/Hazng+JUg6DSs5wiM4KOzsrli5G8rTb36QpmNI93a9G5ml5GGeCGCOiKD+p9A+v1 xaqLaMwOmtk7EGki9aO60q/ak8J9RiDW/NNMZvYfTd+nez3mbwA2HqfPf2qlZcgjbA4qage/ 7p+K1eHeQfMsVndgbktSGvDNXBIHbQUjUozanKxWKqp1xmuxurluxYvm+lQp2RwT8cSWuUBR VG3WSstwqVqJva5iNXvE+KrqjidBpmP5qNQve2Hg3TfzvX+xH4MpB2+KpF9j9DYn+E7m9cW2 zfhXnjU7Bd49089V4TiA5GSNB3WY4UUW3tDJpt5o92wWSs3o7yI841uFJP/e5QE4fby8UlBb Ksrlu2/auQS3Z+uD25Jg5vXFzr0H4IEZ7HR0JPayex4qqa6NpytiRtOAvWlYPMrQxpvGiN8R 4fqxAQzoJTJCHAyFMhE/wm1JIszzQV7IIH5E2Fs+INEquRXR2nE7Bz4Loy9WizKdTmrxs61O qimLNsyTGUlgiESO42aPwG1JAJf0xfYCkMj4l/EaCR5VMSXolgnQ3SUzARYiGnlpCVbq2Wwm M3tkQBceCfIymserV9SE11MTvVFQWxy84UixN4hwTOBgKQHsCgASc1sSzXrzYh4iYs++QDdF cQRXVu1TcPrdmhcTxog/dXejTJCDuPKUGb+YSrVtTV2hakZtfJMWfZtupPQdok9k7jNldtnE QZBG69rVjpQXbnH1WF5RFtU+yEWKlmVxOxc3rwY9yLk8eY1iybm9g6cjQpV1WNCkMKKPRs5i XoE+uTqS5bi+Gp81VU8EKzn1pslmQsgreEtfTGDOZ13UPamKXbNbRMgaLDYvFgmC4uGSNz/t JShnpkR6PR0ODNjU6me9fKlj9qroDnAbCvIaFvNBmbP6ZXqpjpaZ00Rm6OOr+4Cccq1geJJI vGB5KWLsI7INBT0U6WMBH2QufmvKlWIuQ68PBvNHOpbRcsoVQKbx5ro7sUqw3aFcvRsOHQq5 kwV80MFufY2rRAcp3lpB/ds7YhrgZTTXJQsJIovnKIdbOLehIK9h4b07BGYDFpVeLOHPscbu bHOhfZZpcFPT2j6/m4rfKmgpH25DQV7JMvNi2QWAZiledGiSKdLrtw1wE9KvLES0RybjWpou t6Eg72MBHyTGR3Ds4I28ZEpPYQ7HlEFKmaU6v27+Bkamz4vSGbteWYgMBnEbCvIgFvBBqXd8 xHQxqfBTeggJe7dqKFQ9UppR/ml2+sJXbTodbkNB3sG8vTv6EI1ZD/qWMYjuZGlfUEZDIkTK icWPaiymR69xzBXoV3IbCvJWVnqOgdDAnGACy3nKGS5zxg3PqWlFOounHQwbRdyWhfAdeP5L 95hAN8rrmhV2GYlN1YT08RAfBLKUlA5C+AXvFBaYKt7B8GWY1vQXw84Umc4y64P66Gg/wfmv oOS9cZHhGg0+B1Z0QGQ63LtjPa6/I+xDkXXgk5AQMpM15uYJId/KkuNBYmrJG6CpjmF7r5gl Z3rLO1UNFcuUQMX++UqaKVbYDK5doycHsfHY1OqfEYG9cJeS72G9OGj7/dpE6/AwoJxiLyXn U+Xi7HINoUiM5ev/U+EITPcUlOklAAsvI0Xnrbos11iBP7XGeIlBDi9w9fYAWVcqVrRFdim5 2qRvY8k4KEg1COqbNRusZFpv2Yarb4Sc8gRuklOun1oM7lLyDazng6p9B7ODZq4YFGkita26 wrDak8J9xmrAgjtfQA5YAAXKDVsOaF1I1Qt3KXk9C+/d4a0z9JY4656CGMXwJKffFzXM9rmp jcriYstcwUXSpnCg1GT7fF9fywcGxNmdTVGGoyruUvJVzBsP2jbjX3nW7NF4tz+f1QM9KVUk J2s8qMMMr6tlSk6/JaAdhE5cHRsqZQKNkbxBzAg0qSXp4BZXxHOXkm9hXl/s3NsJnr1NQzyD 40FgbEWEUVjXiBnx4adxjXjk+4xoCDd77lLyAub5IDy73HTjd+vDFSBxk+RWhBvCHRPgs9bH LHDdRxbAi8WOg7uUvJJ5e3fsu/Ev4z2T8aiKKUGPKwF0z8JMgIWImKK0BCv1bMbZq9LKP3EB mmdNgd6cgOhCglvsmm9byF1K3sqq3h04DjHS4Y2emCOyWLJOb46Le4PipuoyCzZeJ9MW6muJ pxdagDpPS7Kcjjg1FtZxl5IvZFUf1ITpKW5QRJ4DO1PLst466T6q/R3ylYg+GlkQ7t1B5nF9 3WMfan34fIjOpxFCruAtfbG1qa7Oa1m+R8irWO99sRk0rUAOJsDj13qBtF7hBCbEfLHSk43E uWAhclwyx2IIhnHQB6fEI0Eh+O2F7I/02gNA+U7T+PYX4C2tuFuhAyKY742DzFWETbmS/zZo XnyzqTdeBeZSxDJLKe1mGMKQG3ibD2qdBylfljB7W97iRzMZWMFXSijTeE6tb8ETXpgXfMkT lyF+3TwV73lxTopEeJUPuuLFInNdtJbdFKpUlzeLg02XYq79xfvvJKvomjpxpfcpN7vgyw2k ynvGg8SWMcHan4MR/B5VcsIWkcx7PwRox6NCe/vOqN42N6ZnEQfNF9Bb9eYj7MqRCK+Kg5oo 3+WqtpRy3sqjaYBJvLaV3ZxpTNBIEYCIIEj0jMyDVaobYtDvkFbe44PKhhdsCX2NBeQy3YeJ cFL6z3MbMpjhMulzJdzsgnTwnr5YUuMRJyJiHB3miPfVqhPqevRaHCm1dAyq7GofQvHDOwiO azynw80uSBw+rFDQYU5amUsHN2tXD2+RIRg2Kk81rVHUSwfFkLM4Cw56U1pgASQe5yYEwFrS 0/EBq4S8xHEVHXNhhDyX94wH3UmTg2if2Go1h5AH83Vx0DsGKL7sppE383VxEFsvIUvxqnkx QsjjoA8ihMyEPogQMhP6IELITOiDCCEzoQ8ihMyEPogQMhP6IELITOiDCCEzoQ8ihMyEPogQ MhP6IELITOiDCCEzoQ8ihMyEPogQMhPja1PfjLnF8hUqvK2au/WCzZ5HBFY/ynpKlrNy5bPm B4jiijouhHTzp/wu4Iigd3xBIVgIIxcLVIzcgvLThh0fShUczVh/KrL6OSD9PQ9Tjjhr5vIu wcuVz7YqCtpM73MR5/TF3uGAgpxysVd/imtQYGt27xKwHBzFeHk7PovWFC7R19xMZS9X8PHy fND7UnD6DID1p2bwd2a06siRZPkI8H0b80rNg0KI+TktfUVeLRdyvKLTH+rBYvUlYHtaOzXd 3z7Unw8aFOIluM6J0D1dBIqDcq0tm584mIrqq+9Q2YSyEB1p5+gXaKkeweZpFeBKgXx9sVhy B2YRlVfRLVD4vtJyYENEvpcyKAeP4ERyBa0tC5ZB0CIgH+RV0NQ+Plem9B7FES3lEWCeKaeV iHwgOZjdTJMvUCjqbiGmi8QPj90ZxGnVq+Xg2Gp3PpYLcmHP4ikii2D3xfRzOJOr1Ll3VFdT ocXU29RIOlpUMEtccvXxC0q16QEu7qDu2fXFU91etSl91aF4XdfkO+smafog/dd1oPGg8naW zQy4oe5bZVZE7IZM8/JTVIttNcy7fJGgQ3LOjjOeVe+XbTxnucKqb6UHWRmjL4af6qBTMHKn xXMM98Kq7L8AFYOY4VgpuXSFnpGeZC2qDA2qN0g/w03z9EFxvMNrm2XiGePFs/gSQK5qtdRF x4Gh6aDhjKTiCzPNjyA47SIkeL+1XnDENM8bfTCzm6aaosywC0v23GiWpksYZASPevN6vUvD Bz0DcHqcBXcShdnVnhS4WOCDzCxNNmt15Cze5u/NGOFl10jIm3jht55xmEAIWYq3xUEp0Dch hKzDC30QIeRBcO8OQshMPsaDmua/dUYzb7fMquSzuGgqBE8jdguMzOOMZLktl1fCrdNVDOSf zjlx0HX14IYaBlSMaM/rKvNKpZHR8a1rQwnzbGRh5B7bzqLbvJw+oqjv2slT+OeDzl3Cl8kt cHHMNYEnMijwtjLsWLDXUVxeZNShnTydj76YftSYq/US7KqY6/d2tRCxKrDqCsE6RrGkUBsm 5JT25D9x5C9Kpq/p6ozVpYDekj9PRcSwVrHnpumG7ukd/MRB2COIm51j46Q8hVjPWubKv3Mn RcgvM+bs1ZEOU523rLaPbdu8Zc19zSALFL6vLAdgw6UIRVcEQWZ2BkFfy784qHqzI626r0G2 ZqnSMQ6SjQF5hcsIygQWegMcWuyIywsa06po3BK6GJJKH9ThCzpGAfJjVsdWrdpPofr4Be2k 6QEuIikvcBs3Hp8dafatMVGHeeBUk3DyIP4m65F+W+SfWaE+Xd3vyKxwsXOhByGZn/Gg1grR PYnmxQ7dAuMcjrVqm5kxfRomRjGwWO3QzYv1SkAMlgNFfWi9wTAEJ8AawcwDB4a+DbQhhsBM 4I3UVrN7FVpr2Z25p7gZ3jC5UGHm8jKCbpQ3ymPqxQc9A3D6JhXaI5iKvK5lh3le+TRp94ST x8HHCyFkJnxfjBAyE/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM6IMIITOhDyKEzIQ+iBAy E/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM/taTXIO5 hzQ4/oV4uyaftZtyLukOMUdeM+O29Qg05ZsqRsw2RY3IGbFzXHtQ0eJMi4Nu+ITesgS/HYK/ a3YK+95Zcc+9Obo8sGHdZgt141cxYmdVe/ATM4OlMR32xe5m1tccb+PR7YHcz7S+2EH55dXk f67L+95OeTByJFkuAH/SRxzUJlUN8K7I/IqRZ6SJ/vyR/tP7rlFNchb10WXQ3QdxxPzTzCLk n9IxEepMy0113nWV2XPeE+2sGq8vYVz7alwSB20Fp0jb9938ULL+NJV3xMtYG1G2QgAAByFJ REFU+j6cUpgUUac/6Kh/tKouKTMKyeX/rRztLWctZQh5eejH8zWHnLL15kYl5I93KErJ2qcA dfoqgPM6cRDKdOVCUU5mFuY7WKgv5n1gE6RP1nh2bn7BFtikIn5WYNpzbr9Mh2NYOyDY3nI7 AXKOfzpXRH4TZXNtzaiNiR/sQEuIGG8W5guY74NAy8mIkCrYi2mKxaoqtM1Vs4OcFTAKmd1D 130t2ROV/93A0UQf2lWpGn9zYd7GfB8UYS/IR44fnhsyezTZ3+kQJqJCmATORigtF6q7iTj0 mJyUTnJDtyG6kM/i0cYPcokPam1U1cGL3KiEfxEJmrpFInFVhU484jLMMenrpsyaQi2zI1YO kZrpgSjx2zx4CsC8VkV9uUaEV3VdV25zmfa9eT1xo5/hI0eECm+KqkmgNt5UVxUiRqyDlgsD djX5Jc5qg9VB+8HrDTCnz6HZsiD1ULQQVaYBB70x74jZwnIx0rxbE3ylGeKq8Z8Rk/rs9IxP TrlF1C3ONB80Bdyreg3BwaCLau2JYlvb9ixWsHPBYgkyeX3Q/XhdsHcw93Ke2wzIRL4rDkqq lb7s8uMDVc/yvWY/bkFWsPNxNfrrfBAhZCmeMTdPCHkr88aDwLSKefwsjVWZeArkCoDGbpuD GQmZzbw4qNo8prSfO5vuic6uQ8LiIyvka/imebGmhnq1Gwq6gG4zcEY6ILIMs33QsR6rXJK1 q/eCde9Mr5OrriQTK8DEb5FdrxszZQLbtHAzl57NNu0JGqPlmxmBdkJuZ/m9O3KbNNeN6vW5 3ptOZcpy0ESLTcrTeTKBbVq4aYy3Llg7L6ELgzN62gmZwUrzYn2P5X1gS5VLG2HftWC6h6s4 RE1WZQEf5AULHWxv3F7loHv12wrL5gjxWcAHncj+wB1W4q7hCjdEx0Rms8TeHT+NZNxxlKOt jyDe/byiF1YOP5VFZ/4m5Brmvauh52682Z/IEe+gVlcCuoGnzIvpP3VeMLvnga8OjI6ZY9XB 34RcA98XI4TM5F3jQYSQp7HG+2JkcRgsk8uY54NYrQkh7IsRQuZCH0QImQl9ECFkJvRBhJCZ 0AcRQmZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9 ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFkJvRBhJCZ/E0p/e///e9sMwghX8rPdzX++7/+e64d hJDv5McH/ed//jPXDkLId8JvPRNCZsIxaULITOiDCCEzoQ8ihMyEPogQMhP6IELITOiDCCEz oQ8ihMyEPogQMpO/KaVt2/SJY+3icUqvY9y2qxY33q/xTZil5xVpVU5JmX3Wvch6QSUxj3tn y8s0c5VXCsoWKA1afgNCNbiJHfd3pEr8xEH7vh8i8o983Mx2XSHer3F9zIeEiVlKHUVXVoaD anO9gawX+AthKjibj4g6L7Jo7cCwPsvvQaj2fLFOGRQer6WCP6bKb27wj8Z8HL0vhNRXhK/x xBIoW9rN8cIgy1aDf+NBoPpu21Y+PcRtEEdE9uOU+B9IABqrZnjaU1F1vIwigfcs1WeBQCFE p6zao82LSDYxSwBcqdn50ldXLXlxLWUBRsoKaBkHiN1qbm77rag6WdXywULAZlfrhlkBqjbo 9GfdkfqY9OZHpNtvNGvm2oqKm2P7MktOg2+2GceW3drNCcJxt860EF9R2WP1VAuBwEivNESJ paKDbMrxLj+fzWk2NRiBY4eMvgWiuESdBldaXgsuK10O5fXqWwMuxDxbWuLlbSJu+UgheJcT rxu6AoiKbdpQpscF3gryQbrKeuq9e5xqtUfX6aBG3TA6apK2UBsGbDBVm5fgpTRLI1JiopJ5 ZueDHTVGuIwmdQleqSgir6xwOZxFn1hcHyKW9xUCNjhYN8rj+taYHipuQwd/Td3CCHC26iDA PejQqIWklnIxHzvCnQUfqkC1fsRVjQyWWNPFRqjevlZpKWahFwVEyqFqQ+T2tQppqudBLR2F 4LWO0+sGuITTQ6G/TanNxzKwBj/2+zSKg3FXFTxlXtHe2JHRMrVe4Gi8NK2ta7xJR6Th29F9 36t6Z1F1c2bKDsubQvtg3YgHQdXjrWk83L6Y8Mq6u1EtIHG1ZgIhEGvUYrWQ6oUAC7GrEr0S U7V3CVUjTXt0Fk8OkA9u1rh3aLJEKMW3O1gOnnAzjSe2tRDird2zvKMQQEqgDpsRSW+a5Nmg pUX4kOU5RfO3mcs0NznBhZAQ8dZVIcAMzwGVFnqivCISB4HZICW2B2tMnxXCs7wjEIvcVp2s eqXmHQEVrNo98S5Tl3+1JM28IjEogbjlHYUQLAGzEMTlm3YGC63ptgaZH9muT/X2P5GRC3lN IXi8/gLPZbC4+L7YdyH6AoRMh3UxBA7dH4TXNWuVMChkfeimg4wX1P8DQCpM0hAe5l4AAAAA SUVORK5CYII= --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="ma1.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dandelion.icpdas.com id fBVATmh28315 >From reed@icpdas.com Fri Dec 28 07:58:24 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 15:58:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D Message-ID: <20011228155824.A30856@dan.icpdas.com> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From reed@icpdas.com Fri Dec 28 08:02:40 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 16:02:40 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D In-Reply-To: <20011228155824.A30856@dan.icpdas.com>; from reed@icpdas.com= on Fri, Dec 28, 2001 at 03:58:24PM +0800 References: <20011228155824.A30856@dan.icpdas.com> Message-ID: <20011228160240.A30900@dan.icpdas.com> again On Fri, Dec 28, 2001 at 03:58:24PM +0800, Reed Lai wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 > --=20 > Reed Lai (key #1) http://w3.icpdas.com/reed/ > Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 > ICP DAS Co., Ltd. http://www.icpdas.com/ --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From sunny@icpdas.com Fri Dec 28 08:50:16 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 16:50:16 +0800 Subject: =3D?big5?B?pKSk5bzQw0S0+rjV?=3D Message-ID: <00b401c18f7c$ac55b7e0$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 >From sunny@icpdas.com Fri Dec 28 09:11:09 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 17:11:09 +0800 Subject: =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 Message-ID: <00c401c18f7f$96e51a60$0e1ea8c0@ICPDAS.COM> This is a multi-part message in MIME format. ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/plain; charset=3D"big5" Content-Transfer-Encoding: 8bit =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/html; charset=3D"big5" Content-Transfer-Encoding: quoted-printable
=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3DB8=3DD52
------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0-- >From sunny@icpdas.com Mon Dec 31 03:01:33 2001 From: sunny@icpdas.com (SunnyCat) Date: Mon, 31 Dec 2001 11:01:33 +0800 Subject: =3D?big5?B?pKSk5bT6uNUz?=3D Message-ID: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >From reed@icpdas.com Mon Dec 31 03:29:24 2001 From: reed@icpdas.com (Reed Lai) Date: Mon, 31 Dec 2001 11:29:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DB4=3DFA=3DB8=3DD53?=3D In-Reply-To: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM>; from sunny@icpd= as.com on Mon, Dec 31, 2001 at 11:01:33AM +0800 References: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> Message-ID: <20011231112924.A2706@dan.icpdas.com> Reply test. On Mon, Dec 31, 2001 at 11:01:33AM +0800, SunnyCat wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >=20 > ___________________________________________ > ICPDAS Test mailing list -- Test@icpdas.com > http://www.icpdas.com/mailman/listinfo/test --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ --mP3DRpeJDSE+ciuQ Content-Type: image/png Content-Disposition: attachment; filename="ma2.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAicAAAGACAIAAAD5w1VBAAAABGdBTUEAALGPC/xhBQAAAAZi S0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB9EMHwUwNCAFz08A ACAASURBVHic7Z1bkuwqrkDtE3vEN3oEHf3Zcafs/sgqNikJITDGpHOt2HFOFgZJYIzMy+zH cWy/7PuefufhOSlOKUIwTh6zGq0qweGM8BuJ3ItpnL9NcS0vgjUnEvNSLr1N1botVC9VZ0p8 hJFwKf+kX6KK6xq/73ve+qQ/W+OImCc5jkPU3eOXsYoms+ADeXUxLpjlKnNsLlXyW4w5yUcY CZfy43XMBsUMfFUav+r4caa5gVI3Dpqg6O7FedZoweET+WfLxk/MF6gXTpelKU5V0VhwPGNZ pwxn1qIbqWbw8SUAz+Onr5PXXeoxAABcxJ+tZea2dPU4jkicDvvOk9umzajObXZH0OFmzODk anXyvGqGuEfB25H6wdVeTlxR3Iy+si2FxxfO6N65Y6SZ0O9k6/I0VQT1RqpNyaSTNytYUKwg gJx/6lEeSr7wwWy5TkZw3JtI7sTR4WaqiBlBXVVKCSOKqkWqY5py/In0fORN/4jcViEkSOk2 6YUAJSMHEizAMzdLZ/BMJYfvwfM6X/hWEn+jb4rw6mPlDU1kLi3RMYdhmtE3EZJayaYkHf0D U0iHwaV+TyRJdy9ncw125Fz3lDXVrqBMXVCiegy/m/A8DK/zDS8j8QGr7gg5rS1RVU7p4Q8K CT7/J2uC6Wi3EyXWkaT6en6pJX4BXvqgtZp95maVMIXgeKDY16FyCDpe+R9ApCk/KfzqIu2T r4eGRvGMSY7vfBxgCH/E32nk5w5jpBkOoyxsalkubYJPMsGMI7CmoEPmWGkvC/fa6hVnIEjM bYyy8IrSm4Bjc7BLByCQXsfEf2DSW0+kgt6LNuO8Yctm7SSp+R4rdiZ9FfI6x5PzKQXr5F0M oH1KjuB23ryO7uhc9MhVGaiUh6EbfRfy+aRF3G2JM732qx3PIiMKZxgy8QPfifwO24PrUN/4 2PkIcxhrxqWZWmEW3VmxneQMfxY+8eEacrMWeUZgEeR32PZ3UrzSAxNZnXLjw+YM35txzDe4 vghXoLVPNqOk7kzamU3SHBse0A9oLajSSv1gTPgq/myN9WAPf4kgvmx0wtB5cG55zkLqViLl OdCMOe3CdSWWyqoqufQOIRLG+0/V2xS3bSmcm6Xzaz7OuQQcz5dTeU782lMU6sYZu+jg5Gq3 qmfqjiAMM2dcncAULuJU3V7EDAcnvt9xjCu6rsSEqPM2+EK0rvjT0VTVI112He1MAZoyS+rM GhuJ6auGp7L6nDDAw/jEvg7AQL73O2wA0wjOkgJ8A3gdgGu5a+kEwJrgdQAmwdgawIbXAbia yO4CgO+B1QQAADAP+joAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAAMA+8DgAAzAOvAwAA88Dr AADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAA MA+8DgAAzAOvAwAA88DrAADAPPA6AAAwjz93Kd73Pf0+jqMa/oWkohDlUApvl7/9yulMaybc 9x6BpnxTxRmzTVFn5Jyx87z2oCKApbitr1NtMR/scnLP6lAqgYElcxydTdXYm6PLwzes22yh 7nwuzthZ1R6rJmdLA2AyjLDNJuhyPhdaQABwuG2E7cVxHPu+7/v+en9//dDtsh5T0gNxkZDN avRFZEeFaVLVgFKOtCLHSJM8odAuZCZLImK3995APhCkB4VEiPmnmUTIHzLcJNSZlpvqSvnK k6e0A+2sGq+zcF47wL1c0tfZM4ZIO44jbz1TGyqaaSeklDD3dn5MYVJEXS48V5f/aFWdkycU kvP/tvJqYVPSXIaQl6ZwSt7lJSdvr1MzKuSfHybKJWsv4qjTuXDc1cDJJNN5C0UpmlmYAJ/I QiNsedOZBzrxN2slQmpwg21uk4r4VYFpz9jRNt3l8rU7BFvY1DI6cl7/dKqI/CbyBro1oTYm HtiBlhAx3ixMgI/jfq/jtJUJ0W0Kjk019beqKrTNVbODjOoUCpndiw762u6SqPRvAq9G+UMH oKrGTy5MgIu43+tEODJSyOtHyfGY41TJw+luSkSFMMm5GiG3XKjuJuLCY3K2bZDjmYYYGPws Ptp4gCYu8TqtzWh1EiI1o8KjiAhNg10iclWFjnzGSZirCa5b3tbUnTKH1/LJbTO+I0r8NgOH 4JjXqqgv1RnhVV3XlRvATPrHYc4qVous9Hv6mRChorScrEmgNt5UVxUi1hoELRcGHGqhmriq DVaB9st1aWnA9j6pnhekXkQgROVxnMDSaoWI2cJysUbgsBbj5WaIXPt/Rkzqs7Nk/FYot4g6 gKW4zevcgj9W9hiCkzoXtVMDxba25nexgp0LFguAyc37deZTGlh7Bvdmh4YPAKp8V19nU+3y w7Ifn3D6LG9rjs4tyAp2PqtGwwP5Oq8DAAA38hkrpwEA4BncN6/jLIEyw0dprMr0lytdgaOx 2+ZgQgCAudzX16k2iLe0mDMb64HurUPC4jMkAPBQvmkNW1PTfLXjCTb63Wb4CXE5AHATd3ud 1464fFPcob6pq8fc9E7F6l4+sQdP/BbJ9c49U6ZjmxZuptJrjU17gsZo+WZCRzsAwMUsf9JB aoXNvdp6T3zpC2J5zHzyQ4vdlG8ryXRs08JNY0p78bW7Erp8/IQl7QAA17PSGra+V+/jxJEj lza7fXnx6Z52YnEBAKzBAl6n1CHoYH/u8SPd+w9X2LgIAPDLAl5nIMcHnkASdwZXOB5cEQDM ZYmTDn6axfOuIp8n/wjig4pXjK3l00h50Zm/AQBGcN8XcfQ6q9JKrUhIKVCry3EG94asYdN/ 6rTOSrwSfu6cWS5zlUHwNwDACPgOGwAAzONZ8zoAALA2a3yHDRaHDjEADOI+r0NDBgDwfTDC BgAA88DrAADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAA wDzwOgAAMA+8DgAAzAOvAwAA88DrAADAPPA6AAAwj5/zdfbsjLXjOPZ95MnWL+Fjj8rerUPh Sip0dnTyM+YlaaYWxypxVVilE4rb1KSoFMG81005igcCAPzZVAMh2r4+DzTWb2m0azT9UIrs J9/3vdtgIUf/LjXr4mo1OyULg4rMCGahNeWopP1Vwlo4AHw5xghbsCl30O/sE955z6gYntb3 YeZVUexBk6oxW80oJam6NACACH9PsM5bkPT2Ki7pEZ7UTyq9m+djNfp3qYOl5ZvCS7+FVR3N pTNqZArUxidLTrbLIndCe0lRJIPDh1JLZgMAJP7Z3pt+c+ZAOADtD7THSj9EE5kU5UKE5C3W +dh/yQNTS6q1B0mjbbmbzAOdhNpL9Tm8UhdE+/6gzK3spyNJ6OgAwCh+Rtjy9rQ0qlYdKIuP pMVbK0em6VpaX/kd80pz+5EBqCGzRKa6iGPzo/m+pCoZAOAMf/I/0tu9M3E9yS4Xs2vVl1yE iL5XKb4vMP1ZHcI62bIHFTmLCDpGICP9HjwWAJT4WcOWN+KldU0pwhZ2P8HW56U0PmsSVHem o9Ot9AxXNNZO58l5t8BnAMBF/Iyw+V6krxlqTXX8IoSc7GBVs6Z9lU5oBm7WVH/pqqm66iO1 3mBXo2pexOUEc4SXAoA4b8vMEroJE12ceCqz0a9KEw2f2aRGmj9ncMkRUsqOjh83W6dqWnrg G+APGGrzSupac+QE6nAAgO3lde62we6OrGAYAACM5U89yhT8PgQAADyDJfo6W2DgCwAAHsAq XgcAAL4BTjoAAIB5/P3mtCbSDTL38YztP120UMpfg9ctMLLK63wSbXC15Ft1ta6aa80IAHwn b99hOzKC6Se0KY6KM9rTrv6U3zNLGHb16baqhWaSkhxxVdwjP1WHrlxRNUlH3gHgaxk8wtbk sZrQzdxY+ScFtiYvZaHDjGppdGztLPV+WuUAAAiMldPp1XWzNnKKbYMioYgcTOiPzu3vJyak P/3xHLFNtaO57BjZi2xTjeB8tiA+bFX1K6WSHAUOCQA0b32dfd+drem5b0htX96smL+rCc83 TC+ztZvcTjT6etQoD/RtiMgvxfTl6LeBvo5O8Or2fvvo6ADAed68jjM+1t24xBNGRuf8gSnR P2jSbgos+WAt1p9WadJbnSAJZuqMN4rHAQBooniC9SJfB6i+Yvs9g4gEEZL6ZGKk8YoZl27J faJ0x8XxlH6HrFqkeCwAMJn9RZzjxKEGJ0eT4tBc4jMA4CLsNWxXd3SOX4RSX6/z6r292yxe 6n2xeiolnzXxA0V4a0utlwloOVpvsKvhRwgGnpEDAKDxGuXjfSnaVlulVhJSSphHSHHMpvPI llrpfpKZ0BmC82dNTBWlwJIBfnw/iT/015qqSZewXKhrstk0FQBg9iuq6Z9omwAAvoQbTjrw ex4AAPBgbhiOrw5wAQDAU2ESGAAA5sFJBwAAMI/iYFc+DvYR/SE9P/QRZgMAfBV/qttZPqjt 9jesAADA7TxnhI3PsQAArM/Pyun0oRp/S39ph2YeGAnZygNiERWbu8kRAACWpaGvI76GuWVN v3YGpZBSwtzb+TGDdsbzBQAA0zC8TulDWyURpS/ZpK8aB31Ak4omPwQAAIvw1+vo0TCN+ECn HgQzh8X2XyIGVVVUk+ONAACWpW01wZGRQl4/So7HHCJLHq7UifFVAADAhyLPEt3cKXrx1X1/ bK2K8C5BFelq8CP8AACwDsZ6s/hStNblamldnF4g1yRwK3gjvA4AwOLc00xz3gEAwHdyw0kH LzjvAADgC7ltSIrzDgAAvhAmQgAAYB7P+Q4bAACsD14HAADmgdcBAIB54HUAAGAeeB0AAJgH XgcAAOaB1wEAgHngdQAAYB54HQAAmAdeBwAA5oHXAQCAeeB1AABgHngdAACYB14HAADmgdcB AIB53HaWqEM67y0d/bPv28BjgLT8amAK1yFBjVVdjvBS/CalTVfXl2aePZtXGB0YlOPflKrl jlVNhlUN8Ctnk5ZqIWwjbkpcTtCw4HMRtEpc6nvoLO1S/ZkjzV7SSgcxByXv+83Hqi3X13lV yte/K061fskUFcsMzMkvvWwrxdTqRLRSBkvCryiQsQV7i7RXKaWSKT1E1YdLyBEG5DclUv5J iCmwr/6YBpiifO2+2X6qsTclTqQwq+Y1FUu6Ouqhe7XvR4b2Q63SSirOCJnJcl7HZGwppSro B+Y1T1sSNKnp2WsV7vAyfqCXWlZaIu/odLd6+lXavPt9ArfGW+wbEBHVV5EGPm5mR6f71lef 2TNWDXGTV3N7N2UIy3kdXaSiu/D60w/xMWOWAq9rHIUi/UTpRmcIw4crV5Cm3837bpxINSRr A9tZM9wvtA7tZu+8g+HPTl8PzESPNPQNnlcRfkL/qbs+OtCMVpJpJkz/PdPTGsUl8zp5xro9 c6rrYmCh1NF+1ZvIiEqqYfnbog40xZqj6n20Pszx+KLo9Pt7E4tLM4nXBy3HT3L7i6bfGzuD WQgDb4pz6zsMKz2zfZQqzJCXKrM9zGdoktsoBeZXm5S+BvSShJPje6O4bTWBmXfduJsJzVGv 4Dtd7jby3zowF5uU5u9EZ6rjGZfjF10V/Vx9rjSzTPSNa5ITuTUnszlKlKi9JxWVCmHITRlu mH5mu0tSV5ikbshD92rr9fu36UtEoEjY9BKvPc0iA3S3eZ2+vAffYSNVxKym1UCzFg5sgyJ0 NzFmuX26NCfm0T5KGXx3GXhzR72nR3r5TQK3C27K+ZcS5/EcVZKlSx2ITobo6IgFaWZgXEUp cBFPk7NoX8cppYjjubqQhfYOdaYLzAMdFa3dxNIrW+QNcWVpcbrllAxuEujX1TMlFiHvEziK IuaduSlORm65y61+evibpbMazaTPeeQdqXXczyVeJ5K3amfFjJCPdInA+HClGV8H6r78Nm4k 3cyg8xw6Ix5xTK/2GGnm2EurHDFSVxpy6RO4Wbe46QVLJHdabTM7rTaPvcUlThZmpCQjcjb1 VA556BK6uyOmbUqBW3nATaOl5V2oiIQJ3G+BifkKXKphrdUuKKQU0toU5jjvsJvbRgTfcCO5 iAv8CGk58QbdkaONKV1qsqpDmp9Eh5/p0lVT9d3iUnjwHvmGdQsJymntViq9+6/YIw8RMzem d9HL3vz9oQnTgeVKV2jwlzACck7WdQCAlVluvw4c7yvlAACexFqrCSCHIgL4FBifiPNhK6cB AOCjYYQNAADmseJJB7dhLrUZ2CmLr8Dz1yc1LRENLtYxhXcsStVKm66uL81fERW/Ta2L56qW O1Y1GVY1YOXFc46opqoyZ/Hc5hbmuZZn5RMW6Ov8sl9wooCQv6mKVd12IXZnVDdo5OrMXQk6 gyXhVxTI2IK9RVratHK4nymuPodCjjAgvymR8j/cr/n31R/TAFOUr90320819qbEiRRm1bym YklXBz10K5+wgNdxGTv7lKqgH5jXPG1J0KSmZ69VuMO+8KEIY6Ul8o5Od6unX6XNu98ncGu8 xb4BEVF9FWng42Z2dLpvffWZPWPVEDd5MWM3+jzN6/R/yluX6c4RC0MZPly5gjT9bt5340Sq IVkb2M6a4X6hdWg3e+cdDH92+npgJnqkoW/wvMbKJyw8al6n9D2JVil/32XEcNNmdbR3jlhQ MY8lD0UYK80kXh+0HD/J7a/Dfm/sDGYhDLwpzq3vMKz0zPZRqjAjXqqWPWHhOV4n9zSlT4u/ 4hmBunE3E5qjXsF3utxt5L91YC42Kd05YmElaWaZ6BvXJCdya05mc5QoUXtPKioVwpCbMtww /cx2l6SuMEndiIdu2RMWnuN1ovQ9osF32EgVMatpNdCshQPboAjdTYxZbp8uzYl5tI9SBt9d Bt7cUe/pkV5+k8Dtgpty/qXEeTxHlWTpUjuLn7DwHK+Tl683wubXP6fQI47nuhb/hdDeoc50 gXmgo6K1m1h6ZYu8Ia4sLU63nJLBTQL9unqmxCLkfQJHUcS8MzfFycgtd7nVT49+s1zhhIXn eJ0t69N5xVTtrJgR8pEuERgf9DTj60Ddl9/GjaSbGXSeQ2fEI47p1R4jzRx7aZUjRupKQy59 AjfrFje9YInkTqttZqfV5rG3uMTJwoyUZETOpp7KIQ/dLwuesMA3p98xX4FLNay12gWFlEJa m8Ic5x12c9uI4BtuJBdxgR8hLSfeoDtytDGlS01WdUjzk+jwM126aqq+W1wKD94j37BuIUE5 rd1KqXb/lXrkIeucsIDXgV/O1XUAgAhP268D/RzvK+UAAC7gUfM6IWhVq1BEAJ/CB45PrOR1 Rk2Y+3zgTQIAeAwPHWEz12JdNHxUFcuwFQDALyv1dbaWdS/Dlwlt1oKc0ioyf+JdXM3nS8I9 rfzDElev+BBfzpigEQC+lsW8TmLUaFtpK4wZJ7K6NNhr6VjL/5a65wtIfeiNyvGF+QAArSzg dYRX6Ei1xZzEoXZoOqu2dH9FyxH710ZtPngTcOpUjCq4EACYzAJe58WhDiusbprT0XwH5jff yYBSQr3RTEsQSYKu0cX/KOymvsigA82rvrrfTLyN8sU3KgMAlLhkNcGeMUyo+YkI0fYdhW9C H9mhfu+Gyt/du6xzOclLHZ1HNukujvP1JPPrsOIL3Kac6vEYQlR+OmFrjgAAXiyzhi01+o6j yrs4EX+WyxTxd3VwgN+SHu2fXUp6u1yvcDylrydthY9VnHcM+nhaujgAcJ4FvE7e6Ff7B853 n17kvsGcVsk7InmS6upn87dj5PaeqUhCKaY+qRPs7iQiniP4uXIAgA4W8Dpb71o106lsmWfS U0G+P6t2d6ohuRn5n2GnZbqZMWektuN/rhwAoINLvM6RMVi0aL71dH3ez9BDZ7r1z3s8ohuU Iosf1Y6LXndQXYmQUerf5JP5m3JFTmAuwfl2rBNZqAYA6GalF1hnVXF8O2cuKjkJvTrOX/+m FekkJe3O9E9gZkh4C3+tWvDMDPPPFJhlwohsqgYA6OZDvI6TJCd3CcITlC75AjfPQ/yNHze7 Nf44GCIDgBVYZr9OHx3NaHCtWlDy0XKWaFzsOFLnCZcDACtwX2PEDME2wwkxMgYAS7HSK/B9 o08AADCHNVZOD8f8qk3vhs26rupeHzp2AADbti03rxPp6MS7RNWlAfGlcXoBm78kIb96WCcd tH7p4CfR24fR4gk74PgDALiCxbxOYtRo27HkSQf5Au7wyj2OPwCAB7CA12n62EwpZsRJ6PVm x30nHaT/trsQjj8AgM9lAa/zwtzLmaM7Iv5OT3NqJ2JAKWH1+wLakpJrPN2mc/wBAHwonHTw /tv5QkGQveWkg5by4fgDAHgAy6xhS41+9ftmjntwZIr4+zInHbQ01hx/AACfzgJeR8xz+P2D 0gxKIvcN5rRK3hHJk1RXP5u/HSO390zphB1fAIpN6nD8AQAsywJeZ+ud5zCdypZ5Jj0V5Puz anenGpKbkf9pDuWFc83xBwDwGDjpIOvxiG5Qiix+VPtbet2B368KjBZy/AEAPIOV3lWd139z MZizvWZf+6SDkqICHH8AAI/hQ7yOkyQndwnCE5Qu+QK3ij8wvJdPa/yLYYgMACazzH6dPjpa zOBataDkY/WTDkw4/gAA7oKTDtbj+jvCyBgA3MVKb7uLjT4BAMBw1lg5PY3qns1qBAAAOMFi XifS0Wn1HPHtn1u2aE0v0W50SOmDQHM+EZ1/goilzACwLKuuJhgy2hZsfP1P3eidpwGrOJUA AMBkAa/T9LGZUsy8GRW/xbcASns8ze01Yp9p64o1TiUAAHhnAa/zwtzLmaN3ZTrRzL2cQp1I UnJjpX0/YTiVAAAg8ayTDswQhz18KkF4bO3XCk4lAAAwWGY1QepwVD8bY3ZNRDR/qsbU7q8X eDmkFifKqQQAAJoFvE4+d1Ltc5RmZXKaJopEF+oonEqQ4pxwPKU4W6C7k+BUAgD4aBbwOtu4 kw6cS87Qmfizb3XD3xScSgAAUORZJx3kEcSK5xJ63YEIybXEnBCnEgAAlFjp/deZri/t5RQh SYizkk2vXtusnlB+qZTctpRTCQAAinyI13GS5PjJW3eeLvZdOIbIAOABLLNfp4+mVrh1j+ca TTynEgDAk+Ckg3NcX3qMjAHAk+ANGgAA5rHGymkAAPgOPnxeZyjm2umBXUFzxZwfuLnr9SIa I0v2Opb4xZU2XV1fWmn3sL4aWdpiChloT1xO0LBglQhaJS6VFqVGNFbRewbODPM4XxWJS/7a yVr6Oj+8nsz2D980yN/U01XdU5Rf8j+boNXp/a9mBkvCryiQsQV7i7Smb2jE5WgDxtoTxzEs uAVuy6qTk0Gh0ayHAyth/hHCF2f2rjmfVYw7ku90ORtex2dsrUjPoR+YP2nakqBJTQ1Qq3CH fLvUeVaWlhA9476mf2BNMzs63bmuVtczVp2s5Dfytd2UITzN63R/6Noc39BfQvBDarY1BF7X OApFulm5aJ/S8OHKFaTpDkrfjTM7puflnKevB2aiO9nO0G63eyvh77k22w0d6Dcv1W/Ab7+j cIO/x/9pPGpeZ8jnzvIaL4abNmu0YY+dgZBibu/vdDrQFKsN6GbsXIgZ8zhkqg6zF5dmEq8P Wk5+r0fZ4+S6w7BSde3DLKuS8CEvGeaHPPyDrzarVWlyGPnHQfIzR/A6T0AcSFNyPM70yeZW 7jQmIFIFhy9yt5H/1oG52KQ0fzE88/idcTl+0VXRYyyfK80sE33jmuTkRT3EHoc+w3R17S52 XVZ5uHZFQyphqVkwfYkINL8KH0R7mi8foHuO1wnSd6+D77CRR8J8VquB5lN3sqltJSK5NGCo 0366NCfm0T5KmZIMt+e8P3Zq5qgejxlYKtsORCdDdHTEgjQzMK6iFPjlnibnOV4nr0/uAKuZ Vv4w41Qdz9WVSmjvUGe6wNJ7pYjf2k0svaJGXpNXlhanT84oe5xc35LB7lGyeCXsEm4kdtxD n/PgzJGc53idLevDOje12lkxI+QjXSIwPjxrxteBekBjK493t2Jm0GmMnGGfOKZXe4w0cwCq VY45fHo+dyU6DMtN6hjsNeVsqu6Z9XBIJUzo7k7wG/BbecBNo6XlXaiIhAfzvTk3MV+BS49Z 67MXFFIKaW0Kc5y3fhHZ6RNE1Dm5iAv8CGk5oq1sKjEhpNsenRcRHjTPN6xbSEROqR52d5J+ k++/Mt/G0MTMjeld9LI3f39oZr/hwHKl39zwfnXmIefksw0AEOFp+3Wgm+N9pRwAwBU8al4n Aq1qFYoIPhf66+uzkNcZNWHuQ6UEALiRZ46wmWuxLho+qopl2AoAILFQX2drWfwzZJmQudDL XEgjlPoT73rLy17+jkjTHH7+dY2rl4GIz4d8+aobABjFWl4nMWq0rbQVxozjLCAWhlU5s8C0 HLnnM1B96N3a8d0JAAAO93sd4RU6Um0xJ6F3aDqrtnR/RcsRm/hG7cCocvWnA3EhAHAd93ud F0f2aRazo6M7Ijqa78D8hjoZUEqod9tpCSKJ7xpL6iL4X8bd1GcadKB51Vf3a/bbKB97rQGg iUtWE+wZo2San8QQrdxR+Cb0kZ1s+G6n/F3dU10ln8I5ymd8dRSM7uI4n5AyP5ErPsttyqme ESJE5Uc0NmcJAL6PVdawpUbfaY7zLk6k1c5livi7OjjAbzOP9m9PJb2RvlEQ4XhKn5DaCl/s OO8Y9Bm9dHEAoIn7vU7e6Pv9g+3d8ZjkvsGcVsk7InmS6upn87dj5PaeqTzhmdmdyKROsLuT iHgOvtkOAENYYl6nrwUzncpWWCNwlE/syKVVe1p+SG6G/2d1Zd17Es9VTPYBfLMdAM5wSV/n yBgrWTTW2rXk/Qw9dKa7LHmPR3SD8q6JThLxT3pQzpzyiRRSqX+TT+ZvyhU5gbkE5wO6TmSh GgAgwhJ9nSrOdk5nZ09pnfTxfhJiycfotHkSZ8LGNKl7udpv8r/eQp/boT2Hr7ZYvwAADhZJ REFUua9TBDpxtC7zVBJTNQCAw0JNRsdsR2lpshC178VLvsCt1hFxfN6Q+FeDzwCAyXxGX6dE 1zKwytUmx9Dag1mkhU89FVwOAEzmtnaHuYASE27IqIXUAACt8LYLAADzuH+/DgAAfA94HQAA mAdeBwAA5oHXAQCAeeB1AABgHngdAACYB14HAADmgdcBAIB54HUAAGAeeB0AAJgHXgcAAOaB 1wEAgHngdQAAYB54HQAAmAdeBwAA5vF2thpn7ey/h81dVxTmiWrn9e7qmLyTWXDsLEnuTqIN rp4716qrVMJxORyFBzCEf9JTNKSR+nSChXAms46KM7fglfb4ZTtn5Otw69cp10ELzSQlOeJq sjmSqkNXrqiapCPvABBnzAjbM1xOkCGZ1c3ceZk5JwW2Ji9locOMammYEfxUpd5PqxwAOM8f /7I5ACIC05/6ic2HNfIBCj1YoQdAtOpIyGZ5BRHZH4EpBQoheWZNyaUBmVdCIadUdEKFKEYt VmfBt6daJjr+eUeiiy4is+pXSiU5ChwSwBC8vk5qEfIGVwRuWZOhn8m8cUlC8t/5VV9LNcQ3 T6twcurI15n1JXdgFlGei26Bwtvlljs2ROSXYvpydLn1dXSCV7f3ekhHB+AWPK9TapK29pnV PGbpdTuiJQ9xzDPltBKR70gOJjfjpAwKRd1toukU/deFozyt0qRXyxHqgpk6443icQDgauwR Nv2unUiNyNhnWDdMQoupt6lZ7GhDg0nikquv2H7PICJBhIguYFVLq/EdcUap0x2XozzC5nfI qkWKxwIYhTevkzdVYoaj5Hi6H07zddt3PKZ5r3BzuqLVsFL2RYQOySn5+ff3CDSX+AyAdTBG 2Pw3d2eo58yznY/sm1qahpiOXxwVJzG7XLnk3PmVjCxJ1qLyl/rqDdLv6aZ5OlCEd/hps0x8 Y4JdDT9CMPCMHAAYgjctsak+hBnnR5C7REpIKP3Wep0Q07zSLIKZ3DTVFGV2rXzJJceZpOkS dhI6g2P+rImpohRYMsCP7yfxh/5aUzXpEpYLdU02m6YCQAdPe6cz+wEPyyMAwOdS2a/zifhd AQAAuJGn9XW2wIgTAADcxQO9DgAALAsnHQAAwDze5nWaVifrhGbabplVyaO4aNmSv+SvW2B8 7VZfkjzapbpa17B1ZwQAlmJMX+e6J39Cm+KoOKM97WxNO4fOrGvYuz6/b16NZEpv4kkGxM0r 2ZxfiiTpyzsArMlfrzN2E2XCaaqWwtyVOZCTAmeWod6h6d/Ejo2Wpd5PqxwA+DjeRtj066S5 X3IrD49s7+MezlbQqsCq83N2kopNndowISe3J/3pj+eIkuloLvs2YzrbJyPxq0JK2Q8Kn8nt BgBABz99Hd8HOC+/2kvl4Xmq9DsNPQn5ecKUvDqLYKrTG+DPkMaXtlrJtAoU3s7pVeQ2XEfJ 1760B5OUAv3kdHQAvoS/fZ3q4x1px/ua4NYkVc7MZzhphZMIynQsLE1UaLFnnFzcGFOL9uUl I1vBqQB8IX+9Tkfr39pkHL8fhNZjOFf4ngjVV2ynZWx6SRe9pVLn7Lzx/tVqkvxHq0lNGh1L InLwWAAfyp/NamLmjOfkrNCCRGZihti5QmY1J11gE/gMgK/lZ16n461W/AhS6h90C4zjTE7k tpkJt3fDxGCUL1a7cDOzpRLIw69oqUszcyJCtW8a7+iIrmS3HAD4RLzjAwRmhNIcezV5qQnT Wo7COrG4GaUFDkKFmaqU0OkZlGZrTL1+YMkAP36TiurIVUm7Uz6lQGGGMCYux887AKwMr5AA ADAPvsMGAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAAMA+8DgAAzAOvAwAA 88DrAADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAAwDz+ 3KV43/f0Oz9FuxT+haSiEOVQCm+Xv/3K6UxrJtz3HoGmfFPFGbNNUWfknLHzvPagIoCluK2v U20xH+xycs/qUCqBgSVzHJ1N1dibo8vDN6zbbKHufC7O2FnVHqsmZ0sDYDKMsM0m6HI+F1pA AHC4bYTtxXEc+77v+/56f3/90O2yHlPSA3GRkM1q9EVkR4VpUtWAUo60IsdIkzyh0C5kJksi Yrf33kA+EKQHhUSI+aeZRMgfMtwk1JmWm+pK+cqTp7QD7awar7NwXjvAvVzS19kzhkg7jiNv PVMbKpppJ6SUMPd2fkxhUkRdLjxXl/9oVZ2TJxSS8/+28mphU9JchpCXpnBK3uUlJ2+vUzMq 5J8fJsolay/iqNO5cNzVwMkk03kLRSmaWZgAn8hCI2x505kHOvE3ayVCanCDbW6TivhVgWnP 2NE23eXytTsEW9jUMjpyXv90qoj8JvIGujWhNiYe2IGWEDHeLEyAj+N+r+O0lQnRbQqOTTX1 t6oqtM1Vs4OM6hQKmd2LDvra7pKo9G8Cr0b5QwegqsZPLkyAi7jf60Q4MlLI60fJ8ZjjVMnD 6W5KRIUwybkaIbdcqO4m4sJjcrZtkOOZhhgY/Cw+2niAJi7xOq3NaHUSIjWjwqOICE2DXSJy VYWOfMZJmKsJrlve1tSdMofX8sltM74jSvw2A4fgmNeqqC/VGeFVXdeVG8BM+sdhzipWi6z0 e/qZEKGitJysSaA23lRXFSLWGgQtFwYcaqGauKoNVoH2y3VpacD2PqmeF6ReRCBE5XGcwNJq hYjZwnKxRuCwFuPlZohc+39GTOqzs2T8Vii3iDqApbjN69yCP1b2GIKTOhe1UwPFtrbmd7GC nQsWC4DJzft15lMaWHsG92aHhg8AqnxXX2dT7fLDsh+fcPosb2uOzi3ICnY+q0bDA/k6rwMA ADfyGSunAQDgGdw3r+MsgTLDR2msyvSXK12Bo7Hb5mBCAIC53NfXqTaIt7SYMxvrge6tQ8Li MyQA8FC+aQ1bU9N8teMJNvrdZvgJcTkAcBN3e53Xjrh8U9yhvqmrx9z0TsXqXj6xB0/8Fsn1 zj1TpmObFm6m0muNTXuCxmj5ZkJHOwDAxSx/0kFqhc292npPfOkLYnnMfPJDi92UbyvJdGzT wk1jSnvxtbsSunz8hCXtAADXs9Iatr5X7+PEkSOXNrt9efHpnnZicQEArMECXqfUIehgf+7x I937D1fYuAgA8MsCXmcgxweeQBJ3Blc4HlwRAMxliZMOfprF864inyf/COKDileMreXTSHnR mb8BAEZw3xdx9Dqr0kqtSEgpUKvLcQb3hqxh03/qtM5KvBJ+7pxZLnOVQfA3AMAI+A4bAADM 41nzOgAAsDZrfIcNFocOMQAM4j6vQ0MGAPB9MMIGAADzwOsAAMA88DoAADAPvA4AAMwDrwMA APPA6wAAwDzwOgAAMA+8DgAAzAOvAwAA88DrAADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA8 8DoAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAAMA+8DgAAzOPPtm3//f//3m0GAAB8BX9e//vX //3rXjsAAOAb+PE6//n3f+61AwAAvoH9OI67bQAAgG+B1QQAADAPvA4AAMwDrwMAAPPA6wAA wDzwOgAAMA+8DgAAzAOvAwAA88DrAADAPP5s27bvu77w2j36uqR3ku77VdtL52t8EmbplYq0 KicnT37XvUh6nUpihpeu5tk0U+U5dcrWURq0fAJCtXMTO+4vjyfE+enrHMfxqjTpRwo3k11X w+ZrXB/ztcDELKWOossrw4tqAz2BpNfxEMJU52oKEXVeJNHaHcP6LJ+DUF3yvjpmUHi8lsKX 889mVbJvbuI/GvOV83nvoTpHfh4HlkDetn5Wn+B51QA+lL/zOk6Dte97/oYoHjwRIpK/Lon/ OhIcjVUzStq3rLEoJRQRSu/L+qojUAjRMav2aPMikk3MEnByag6p6dxVS17kJS/ASFk5Ws7j iN1rjm3/rag6WtXyk4Xgm12tG2YFqNqg419xR+AbqK8m2MvjDPvvGIWZas+aqjRikydJcfzH 2xydyIen98LQij9YZ1ro5ygfhyypFgIdI0ulIUpsy4Y9TTml7KerKc6uJhX8/kFC3wJRXKIV c3Ka58UvK10OeX71rXEyYl7NLSmlbSJu+ZlCKGUnXjd0BRAV27Qhj+8XOICP53V0I7UVKlzp qd5q7YVuxYIadVPY0XZoC7Vhjg2majMLpZhmaURKTDQrJbNTYEcbIZxEk7rNzakoolJZ+eUw ij6xfn2IWN5XCL7BwbqRh+tbY/qkuA0AVX7O16m2qqWrVZfgPHUdGrWQreVJMF8thQMLvjg7 qvVrbNXIYIk1ZTZC9fa1SttiFpbe9CPlULUhcvtahTTV86CWjkIoPR3D64aTBbo7cJI/TbHN V2+n/vmv9n0aRWDcOQUvmTk6GoentEyt13EtpTit7en5Rjwizb8d3fe9qvcuqo7NjNlheVP3 PVg34h2danhrHIAXxRE28ealB5Gqj4So32YEIdDXqMVqIdWMOBb6zkmMNZmqS1moGmnao5OU 5DjynZt13h80WSKU+rc7WA4l4WacktjWQoi37yXLOwrBiemo882IxDdNKtmgpQFo3mpP6cXH /G2m0slTF8Fs9HMJkTeyqhDHjJLLyS0siSoVkQh0zHZi+vb4Grf3JqBkeUdnK3JbdbRqTs07 4lSw6qBTKZu6/KslaaYVkZ0SiFveUQjBEjALQWTftDNYaE23FcCEKlKn+sB/Imcy8phCKPH4 DI6F4oIm+A7bdyFGeAAAJkPrE8IfkPkgSgNurRJOClkfHHMQCgpa+R8OGeCI1imrLAAAAABJ RU5ErkJggg== --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="ma2.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dandelion.icpdas.com id fBVATmh28315 >From reed@icpdas.com Fri Dec 28 07:58:24 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 15:58:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D Message-ID: <20011228155824.A30856@dan.icpdas.com> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From reed@icpdas.com Fri Dec 28 08:02:40 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 16:02:40 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D In-Reply-To: <20011228155824.A30856@dan.icpdas.com>; from reed@icpdas.com= on Fri, Dec 28, 2001 at 03:58:24PM +0800 References: <20011228155824.A30856@dan.icpdas.com> Message-ID: <20011228160240.A30900@dan.icpdas.com> again On Fri, Dec 28, 2001 at 03:58:24PM +0800, Reed Lai wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 > --=20 > Reed Lai (key #1) http://w3.icpdas.com/reed/ > Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 > ICP DAS Co., Ltd. http://www.icpdas.com/ --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From sunny@icpdas.com Fri Dec 28 08:50:16 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 16:50:16 +0800 Subject: =3D?big5?B?pKSk5bzQw0S0+rjV?=3D Message-ID: <00b401c18f7c$ac55b7e0$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 >From sunny@icpdas.com Fri Dec 28 09:11:09 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 17:11:09 +0800 Subject: =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 Message-ID: <00c401c18f7f$96e51a60$0e1ea8c0@ICPDAS.COM> This is a multi-part message in MIME format. ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/plain; charset=3D"big5" Content-Transfer-Encoding: 8bit =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/html; charset=3D"big5" Content-Transfer-Encoding: quoted-printable
=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3DB8=3DD52
------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0-- >From sunny@icpdas.com Mon Dec 31 03:01:33 2001 From: sunny@icpdas.com (SunnyCat) Date: Mon, 31 Dec 2001 11:01:33 +0800 Subject: =3D?big5?B?pKSk5bT6uNUz?=3D Message-ID: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >From reed@icpdas.com Mon Dec 31 03:29:24 2001 From: reed@icpdas.com (Reed Lai) Date: Mon, 31 Dec 2001 11:29:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DB4=3DFA=3DB8=3DD53?=3D In-Reply-To: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM>; from sunny@icpd= as.com on Mon, Dec 31, 2001 at 11:01:33AM +0800 References: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> Message-ID: <20011231112924.A2706@dan.icpdas.com> Reply test. On Mon, Dec 31, 2001 at 11:01:33AM +0800, SunnyCat wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >=20 > ___________________________________________ > ICPDAS Test mailing list -- Test@icpdas.com > http://www.icpdas.com/mailman/listinfo/test --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From sunny@icpdas.com Mon Dec 31 03:50:08 2001 From: sunny@icpdas.com (SunnyCat) Date: Mon, 31 Dec 2001 11:50:08 +0800 Subject: =3D?big5?B?pKSk5bzQw0S0+rjVNA=3D=3D?=3D Message-ID: <003701c191ae$3daefde0$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D54 --mP3DRpeJDSE+ciuQ-- From reed@icpdas.com Mon Dec 31 07:47:30 2001 From: reed@icpdas.com (Reed Lai) Date: Mon, 31 Dec 2001 15:47:30 +0800 Subject: [Mailman-Developers] decoding bug of non-ascii MIME encoded subject Message-ID: <20011231154730.A3114@dan.icpdas.com> --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Pipermail 0.05 (Mailman edition) does not seem to decode non-ascii MIME subject correctly under some conditions, even the "Prefix for subject line of list postings" has been emptied. Attached ma1 files are captured before ma2 files. The messages sent by Reed Lai are subjected with iso-8859-1 encoding for big5 characters. The messages sent by SunnyCat are subjected with big5 encoding for big5 characters. The decoding seems to be determined by last message. -- Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ --mP3DRpeJDSE+ciuQ Content-Type: image/png Content-Disposition: attachment; filename="ma1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAYEAAAFxCAIAAAAaqYNqAAAABGdBTUEAALGPC/xhBQAAAAZi S0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB9EMHwMqGkhzROkA ACAASURBVHic7Z3bkqUgk4Wxo594Yp5g4r+cmFd2Lqyi2XlYJKCC7vVFR8cuhcwUIU0O4rbv e/pl27b8uzxektN4CYJpypTVZFUJgBHhE4nci9sYv01xLQfBmhNJeSmX3qZq3Raql6ozHtrI P+Y5/edxpKyL+c/WNCLlIPu+i+LefzlX0c0sWIeuLsYFL7nKPTZ7lXyKMYNoI398kFm9zIOH CHy1OM1tTsEL8UgTLLq5gLb2CKdT5U8qIm3TuR6AcKYpTVXRudANncs6ZXhnLZpI9QJfUAI/ cVB5JS+4KkLIU/ibWsb/vLP7vkfSdNg3TmmbNqM6jNedQB83UwbHEatDsFUzxD0K3o4cI1cj oLiiuBl9Zesdj0+/6MgdGGlmxAG4Lk9TRVBvpNp4Jg3erGBBYSF/0rdSDp+b9XgwAXB2IjtI o4+buSJmBHVV8TJGFFWLVKc05eDh2LKPpn9EbqsQEsS7TXo42TPyRIIFOHKz9AX2VXLkg76w UxZ/2jclOOKvstpFxuAyHWMfphl9Ayi5zTRl6YgdTCEdBnsxUSRLdwSUoMFAznWtrKl2BWXq ghLVo+NuGj5onXHH64h3bboTlLTWy6ocryoEhQSr3WBNMN1uGiixjizVR/elluACvLShtZo9 crM8TCFaoBsHfWEQhOkIB15ApGEPCr+6SPvk607EWcSHw1bmxHv3V/yd+wjjokeo3v6zLGyq Z5c2yEFuMGMPjEx3yDxX2mHhVpsDAV0GMSZyloVXlN4NAJuD4V4V6YM8ZVVTImmmo80YN2zZ SxskN+Zzxd5JX4W8zg2VPKVgwbWLrlb3FX34IB0EXXQDqpyo9Ck3e0H0XSjHoRZxvh4jEf3V bmiR3sYIpwwYHcj3xR5dLpi+ntR4gns414xLL2qFsViwJiDLOb0tPLFxnXKzsBD5vtj2SU7n FR8e8cbHbwB0+800pnfvS3AFWvvNZnjqRvLe6cTvseHEGGEWrQXlrQWJpPwL5HrKqqNrwTQi fdyGIPEJiJun6luJlOeJZtzjFK4rsVxWVcneE0VkjMdW1dsUt20pwM3S12s251KCXDDROpYc qTo4zblD14MzaFU/1Z1AGGaO24GD+bhIU3WCETMAID0OKuOKrisxIWrcBixE64q3jqaqHgnn dbKRAjRleurMGhtJeRxZfWSRkJfxxDjoUr73fTFCbiM4uvqd0AcRci2zBuCfAn0QITfBXpgJ fRAh1xJZv/LNcEyaEDITxkGEkJnQBxFCZkIfRAiZCX0QIWQm9EGEkJnQBxFCZkIfRAiZCX0Q IWQm9EGEkJnQBxFCZkIfRAiZCX0QIWQm9EGEkJnQBxFCZkIfRAiZCX0QIWQm9EGEkJnQBxFC ZkIfRAiZCX0QIWQm9EGEkJn8naU48sHvL//mh/fx8shHzWPy06+czrxmxm3rEWjKN1WMmG2K GpEzYue49qCixZkWB1Xbz4sdUPBjm14JnFgy+95Zcc+9Obo8sGHdZgt141cxYmdVe/CbrIOl MR32xe7m9V/7fXR7IPczrS92sO/7tm3b9vOpxeOHbqW696G7bJEjyXIBIjFQYZpUNcC7Iq0I GGlSZhTahczWrwyXkULZZdDdB3HE/NPMIuSf0jER6kzLTXXedZXZc94T7awary9hXPtqXBIH bQWnSNv3vWxLuUWJRguOeBlL34dTCpMi6krhpbryR6vqkjKjkFz+38rR3nLWUoaQl4d+PF9z yClbb25UQv54h6KUrH0KUKevAjivEwehTFcuFOVkZmG+g4X6YmVDKg+C9Mkaz87NL9gCm1TE zwpMe87tl+lwDGsHBNtbbidAzvFP54rIb6Jsrq0ZtTHxgx1oCRHjzcJ8AfN9EGg5GRFSBXsx TbFYVYW2uWp2kLMCRiGze+i6ryV7ovK/Gzia6EO7KlXjby7M25jvgyLsBfnI8cNzQ2aPJvs7 HcJEVAiTwNkIpeVCdTcRhx6Tk9JJbug2RBfyWTza+EEu8UGtjao6eJEblfAvIkFTt0gkrqrQ iUdchjkmfd2UWVOoZXbEyiFSMz0QJX6bB08BmNeqqC/XiPCqruvKbS79EfuoYjVxo5/hI0eE Cm+KqkmgNt5UVxUiRqyDlgsDdjX5Jc5qg9VB+8HrDTCnz6HZsiD1ULQQVaYBB70x74jZwnIx 0rxbE3ylGeKq8Z8Rk/rs9IxPTrlF1C3ONB80Bdyreg3BwaCLau2JYlvb9ixWsHPBYgkyeX3Q /XhdsHcw93Ke2wzIRL4rDkqqlb7s8uMDVc/yvWY/bkFWsPNxNfrrfBAhZCmeMTdPCHkr88aD wLSKefwsjVWZeArkCoDGbpuDGQmZzbw4qNo8prSfO5vuic6uQ8LiIyvka/imebGmhnq1Gwq6 gG4zcEY6ILIMs33QsR6rXJK1q/eCde9Mr5OrriQTK8DEb5FdrxszZQLbtHAzl57NNu0JGqPl mxmBdkJuZ/m9O3KbNNeN6vW53ptOZcpy0ESLTcrTeTKBbVq4aYy3Llg7L6ELgzN62gmZwUrz Yn2P5X1gS5VLG2HftWC6h6s4RE1WZQEf5AULHWxv3F7loHv12wrL5gjxWcAHncj+wB1W4q7h CjdEx0Rms8TeHT+NZNxxlKOtjyDe/byiF1YOP5VFZ/4m5Brmvauh52682Z/IEe+gVlcCuoGn zIvpP3VeMLvnga8OjI6ZY9XB34RcA98XI4TM5F3jQYSQp7HG+2JkcRgsk8uY54NYrQkh7IsR QuZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFk JvRBhJCZ0AcRQmZCH0QImQl9ECFkJj/7B5UfI9z3fdvO3OP1EH7uprHm1xM9FfpydPYR87I0 UwuwSpwVVumM4jY1KfISmPe66YriBwnR/E2quoiW0OePzvViGu0owTddtSUi+/FJ2D6DhRz9 22vk4mz1cjwLg4rMBGahNV2Rp/0oYS2cEIHRFws2bIB+nt/wPBxRcXpe7NHMs6LYgyZVU7aa 4WWpOjhC+vi3l2tZn/KTTZzSfYEcQ3nP7TKq17+94EvLN4V7v4VVHY0H9C9Mgdr4bMlgKxVX J7R7iiIXeHqn2zObEMCf9OkIzBEH4Q60d9D+K/8QDSYrKoUIySkWmGy/lAdzu9Lag+R+Wek0 y4Mgo/ZZfe7PC0/0kyAoM/leO5KFQRC5jp++WNm6vP5XtUsV73PF6y6QaTqa1nAAmOeNEEe6 KqeMLpnqIm4OJ8OepSqZkHP5+K5GfvKD4c+b7IKYYVdfdnFExGVeeiww/1nt7Ay286AiMBTd 0VeNxET0XyTOz7xY2aS9uZKcIIWdUbAuHkrjoy1BdSNBULfSEa5ouiCwAk8aehByGz99MexT +ipla679FyFkMPiqXpr2XDqjeTBZA8beWVN11WNqvcEwpGpexAEFr4g+i4zwMXWV0RVahD/x XKYLqEoTzcBsYJHGALohQIh3OTp93Gydq2kAGxuAu5baPE9d6xWBg/o4ISZLPMGAnyKEvJt5 33r+BMcXhJC3skQclAJdJELIK1nFBxFCvhPu3UEImcm/9+Y1kRDJXDd0bmx10eQLntfrFhiZ ORrPclaufDY4P9hk8xWVgbyPj/fF9oJg/htqGFAxoj2vMM7XOzIQvqlXzKoWmlk8OeKsmcu7 BC9XPtuqKGgzvQ+JcHJfrMl/NWE2uRMZFNia3bsELAdHMV7eqh9sVRSRQEgQY24+P9aStYxQ LFoTGUXiYEbcj9s+9wDJf+LIXyyS7Gg8HX3AyCLJCJEl1K1CvATXORG6JxLhIw7atg0sky09 RW6fZSUzf1czjlfTw2ztNNNA69X9i/IgtiEi30sZlINHcCK5gtaWBcsgiFzBhw8CPanuqhbP GOnH4b6DiB2atJsCPY+sxXqjLR16qwMrohD23zd+RTKQC3sWTxEhV2D0xUYiiNOpPn6BnU0P cC9eq2ppNb4jTTV99ZZ5XdfkO+smafrgIvWHrM/d72rsA9t0BAc4huxLKS08oXOWK6z6VnoQ chv2vNh4nwKz/yKUYr3gsZw+bRZ9DSxWd2REjAAOiuOt7VYEdKYc87i2oS9X1QHpouPAEDkX 1ET3z+mtVJv58oR4GcsEOY3ZkPZi+kbHUGZG8KjHoy2mCu+gZwBOj7PgTqIwu9qTAhcLfJCZ pclmrY4Qk7sfX6a3Yk0l5GuZsHcHjkoIIV/FhG58tStECPkeOJRICJkJ9+4ghMwETZqYxx/B 4CJpQsht/Kk21Me1ZDogQh7EKnvanwUXyxHyLH58kHjv0Vte7K0PLA9GjiRrSh4vQTQP4pc5 CSHr0zAmval9hbIj0K7BO+JlLH0fTlk1svrOByFkHQwf5L0Q5Inw3rHYf/fTiLuPuArzdbOk nB0hZHH++aBI0xUhhu4umR2optikqgIgoipCyPq0rQ/aC/KR44fnhszOVPZ3XoCDVRBCXoPc RzHBIELsX4F7YVWErwmqyGfBkDm9FSFPwZjDik9vtU6B7cUO82AniqrA5PimR6+rJOQ7mTOZ zR08CCEH09YoghCGEPI9TFvUxx08CCGJe3cQQubCvTsIITOhDyKEzIQ+iBAyE/ogQshM6IMI ITOhDyKEzIQ+iBAyE/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM6IMIITNZyAdtW+ImQoR8 Gwv5oBPRvuxwcFf4uKpY+lZCAGt96zmyl9HRnuMpgXyR4DhbHszphdJtQwaIs/v+zw0FN2vy PkLbB957O/71N241Ra5g0TjorNgBOx2RplS677a/CBo2GHaVn4c8GNnr1vQd1W+oRIQQMs78 OKhsXPGGZoYwONkRj4hcnqfQsYyWk9PoAMqzCgdQF8EQhqzMfB90cDTssjGDEMZLht0ZdnDZ AC+j6JeZEkSWoKPUCK+h/0xO3yr+rTfgmMrvL5WfY4paT0gLl/igK77zlb2DF54kFY+Ufi1Z MYj2WV5nrSNA85xjWI77pTbzS3D6YOTj3abSw+9kCYM9QUIwq4wHZRcAanvpYoKDMlmmSC+G flItSCndUHhceWhUqBwS0sfxFyJFjNP0GNDjROzKkUuZ3xcrO0HVqg5GcA6Ep9CuJxXjzaU7 q86vm7+BkekzEDvMjk3nfQQgIggSPSP8ReyqCu8g/Q65jfk+KLUMlOBcZcs3h5+BIm9cGaiL DISbf3a3bjDD5VjS40rKIIvOiFzNJX2xclL5XMkiHtGOJivMv/GgtZ6YF1GS/hH3Vrr71tov E2MxZW8LHwTHNZ7TiUsgpJuFnnIgQDAnmPRMmRBldojSZ1/JUyEU6SyedjBsFBlR0ksHxZCz OAsOelNaYAEkHucm5AoWql4dnRRv8luIwrNjQGCC/iIlw5dhWtMT8nqWGA/qpqMxB+e/gpKb pu3jYgn5HqbFQRxhSHRJhEyMgxZqfuwgETKPVdYovgQd3Y2sU6zqqi5qYrRJlufZ40GnEVs7 2JYSyI/P8+nZODyiLt5k2do2DeGeIeR+GAd9clbsgJ2OSLOtsmkI9wwh9/PFcVDT+xdeysiK Jj15Bl450bGMlrM9Y9MQhjAkwtt8UPNGE+YSxk+JH4nNZNidYQe3L7RpCPcMIffzKh+kd644 AXPJkBAu4pH9wZuGcM8QcjPvGQ8q/U5D9c0uoPoCGHAWQKZIv62+aQj3DCE386o4qI2dm4YI VdwzhEzgPT6obDnRqtxX3c0R3/TmTUO4Zwi5jvf0xZIaUDgTEY9oR5M17m/YNIR7hpDb4NMG BgjmBJOeKROizA5R+uwreSqEIp3F0w6GjQIjStwzhMyCt7mrk+JNfm/cNISQNt4zHnQrHY05 OP8VlNw0bR8XS8jtfF8cxCGGRJdEFuL74iA2P0JW4lXzYoSQx7FkHGSu9zOneyIDt1pUcqaZ vFPV0Em8pQHkmFNdwOa+seeg2ZGM2vgRLVlmpKC65UttH6+hDUqL6Dq4R+MLWC8OOiro8e+s 2ZxyqruUnE/l46lYvqwTY/n6/1Q40NZ2pRcZVfHWGXVnNI3v1iLQF5iPNBU+5PAC97x6lp1d 1ogdEFc/Hazng+JUg6DSs5wiM4KOzsrli5G8rTb36QpmNI93a9G5ml5GGeCGCOiKD+p9A+v1 xaqLaMwOmtk7EGki9aO60q/ak8J9RiDW/NNMZvYfTd+nez3mbwA2HqfPf2qlZcgjbA4qage/ 7p+K1eHeQfMsVndgbktSGvDNXBIHbQUjUozanKxWKqp1xmuxurluxYvm+lQp2RwT8cSWuUBR VG3WSstwqVqJva5iNXvE+KrqjidBpmP5qNQve2Hg3TfzvX+xH4MpB2+KpF9j9DYn+E7m9cW2 zfhXnjU7Bd49089V4TiA5GSNB3WY4UUW3tDJpt5o92wWSs3o7yI841uFJP/e5QE4fby8UlBb Ksrlu2/auQS3Z+uD25Jg5vXFzr0H4IEZ7HR0JPayex4qqa6NpytiRtOAvWlYPMrQxpvGiN8R 4fqxAQzoJTJCHAyFMhE/wm1JIszzQV7IIH5E2Fs+INEquRXR2nE7Bz4Loy9WizKdTmrxs61O qimLNsyTGUlgiESO42aPwG1JAJf0xfYCkMj4l/EaCR5VMSXolgnQ3SUzARYiGnlpCVbq2Wwm M3tkQBceCfIymserV9SE11MTvVFQWxy84UixN4hwTOBgKQHsCgASc1sSzXrzYh4iYs++QDdF cQRXVu1TcPrdmhcTxog/dXejTJCDuPKUGb+YSrVtTV2hakZtfJMWfZtupPQdok9k7jNldtnE QZBG69rVjpQXbnH1WF5RFtU+yEWKlmVxOxc3rwY9yLk8eY1iybm9g6cjQpV1WNCkMKKPRs5i XoE+uTqS5bi+Gp81VU8EKzn1pslmQsgreEtfTGDOZ13UPamKXbNbRMgaLDYvFgmC4uGSNz/t JShnpkR6PR0ODNjU6me9fKlj9qroDnAbCvIaFvNBmbP6ZXqpjpaZ00Rm6OOr+4Cccq1geJJI vGB5KWLsI7INBT0U6WMBH2QufmvKlWIuQ68PBvNHOpbRcsoVQKbx5ro7sUqw3aFcvRsOHQq5 kwV80MFufY2rRAcp3lpB/ds7YhrgZTTXJQsJIovnKIdbOLehIK9h4b07BGYDFpVeLOHPscbu bHOhfZZpcFPT2j6/m4rfKmgpH25DQV7JMvNi2QWAZiledGiSKdLrtw1wE9KvLES0RybjWpou t6Eg72MBHyTGR3Ds4I28ZEpPYQ7HlEFKmaU6v27+Bkamz4vSGbteWYgMBnEbCvIgFvBBqXd8 xHQxqfBTeggJe7dqKFQ9UppR/ml2+sJXbTodbkNB3sG8vTv6EI1ZD/qWMYjuZGlfUEZDIkTK icWPaiymR69xzBXoV3IbCvJWVnqOgdDAnGACy3nKGS5zxg3PqWlFOounHQwbRdyWhfAdeP5L 95hAN8rrmhV2GYlN1YT08RAfBLKUlA5C+AXvFBaYKt7B8GWY1vQXw84Umc4y64P66Gg/wfmv oOS9cZHhGg0+B1Z0QGQ63LtjPa6/I+xDkXXgk5AQMpM15uYJId/KkuNBYmrJG6CpjmF7r5gl Z3rLO1UNFcuUQMX++UqaKVbYDK5doycHsfHY1OqfEYG9cJeS72G9OGj7/dpE6/AwoJxiLyXn U+Xi7HINoUiM5ev/U+EITPcUlOklAAsvI0Xnrbos11iBP7XGeIlBDi9w9fYAWVcqVrRFdim5 2qRvY8k4KEg1COqbNRusZFpv2Yarb4Sc8gRuklOun1oM7lLyDazng6p9B7ODZq4YFGkita26 wrDak8J9xmrAgjtfQA5YAAXKDVsOaF1I1Qt3KXk9C+/d4a0z9JY4656CGMXwJKffFzXM9rmp jcriYstcwUXSpnCg1GT7fF9fywcGxNmdTVGGoyruUvJVzBsP2jbjX3nW7NF4tz+f1QM9KVUk J2s8qMMMr6tlSk6/JaAdhE5cHRsqZQKNkbxBzAg0qSXp4BZXxHOXkm9hXl/s3NsJnr1NQzyD 40FgbEWEUVjXiBnx4adxjXjk+4xoCDd77lLyAub5IDy73HTjd+vDFSBxk+RWhBvCHRPgs9bH LHDdRxbAi8WOg7uUvJJ5e3fsu/Ev4z2T8aiKKUGPKwF0z8JMgIWImKK0BCv1bMbZq9LKP3EB mmdNgd6cgOhCglvsmm9byF1K3sqq3h04DjHS4Y2emCOyWLJOb46Le4PipuoyCzZeJ9MW6muJ pxdagDpPS7Kcjjg1FtZxl5IvZFUf1ITpKW5QRJ4DO1PLst466T6q/R3ylYg+GlkQ7t1B5nF9 3WMfan34fIjOpxFCruAtfbG1qa7Oa1m+R8irWO99sRk0rUAOJsDj13qBtF7hBCbEfLHSk43E uWAhclwyx2IIhnHQB6fEI0Eh+O2F7I/02gNA+U7T+PYX4C2tuFuhAyKY742DzFWETbmS/zZo XnyzqTdeBeZSxDJLKe1mGMKQG3ibD2qdBylfljB7W97iRzMZWMFXSijTeE6tb8ETXpgXfMkT lyF+3TwV73lxTopEeJUPuuLFInNdtJbdFKpUlzeLg02XYq79xfvvJKvomjpxpfcpN7vgyw2k ynvGg8SWMcHan4MR/B5VcsIWkcx7PwRox6NCe/vOqN42N6ZnEQfNF9Bb9eYj7MqRCK+Kg5oo 3+WqtpRy3sqjaYBJvLaV3ZxpTNBIEYCIIEj0jMyDVaobYtDvkFbe44PKhhdsCX2NBeQy3YeJ cFL6z3MbMpjhMulzJdzsgnTwnr5YUuMRJyJiHB3miPfVqhPqevRaHCm1dAyq7GofQvHDOwiO azynw80uSBw+rFDQYU5amUsHN2tXD2+RIRg2Kk81rVHUSwfFkLM4Cw56U1pgASQe5yYEwFrS 0/EBq4S8xHEVHXNhhDyX94wH3UmTg2if2Go1h5AH83Vx0DsGKL7sppE383VxEFsvIUvxqnkx QsjjoA8ihMyEPogQMhP6IELITOiDCCEzoQ8ihMyEPogQMhP6IELITOiDCCEzoQ8ihMyEPogQ MhP6IELITOiDCCEzoQ8ihMyEPogQMhPja1PfjLnF8hUqvK2au/WCzZ5HBFY/ynpKlrNy5bPm B4jiijouhHTzp/wu4Iigd3xBIVgIIxcLVIzcgvLThh0fShUczVh/KrL6OSD9PQ9Tjjhr5vIu wcuVz7YqCtpM73MR5/TF3uGAgpxysVd/imtQYGt27xKwHBzFeHk7PovWFC7R19xMZS9X8PHy fND7UnD6DID1p2bwd2a06siRZPkI8H0b80rNg0KI+TktfUVeLRdyvKLTH+rBYvUlYHtaOzXd 3z7Unw8aFOIluM6J0D1dBIqDcq0tm584mIrqq+9Q2YSyEB1p5+gXaKkeweZpFeBKgXx9sVhy B2YRlVfRLVD4vtJyYENEvpcyKAeP4ERyBa0tC5ZB0CIgH+RV0NQ+Plem9B7FES3lEWCeKaeV iHwgOZjdTJMvUCjqbiGmi8QPj90ZxGnVq+Xg2Gp3PpYLcmHP4ikii2D3xfRzOJOr1Ll3VFdT ocXU29RIOlpUMEtccvXxC0q16QEu7qDu2fXFU91etSl91aF4XdfkO+smafog/dd1oPGg8naW zQy4oe5bZVZE7IZM8/JTVIttNcy7fJGgQ3LOjjOeVe+XbTxnucKqb6UHWRmjL4af6qBTMHKn xXMM98Kq7L8AFYOY4VgpuXSFnpGeZC2qDA2qN0g/w03z9EFxvMNrm2XiGePFs/gSQK5qtdRF x4Gh6aDhjKTiCzPNjyA47SIkeL+1XnDENM8bfTCzm6aaosywC0v23GiWpksYZASPevN6vUvD Bz0DcHqcBXcShdnVnhS4WOCDzCxNNmt15Cze5u/NGOFl10jIm3jht55xmEAIWYq3xUEp0Dch hKzDC30QIeRBcO8OQshMPsaDmua/dUYzb7fMquSzuGgqBE8jdguMzOOMZLktl1fCrdNVDOSf zjlx0HX14IYaBlSMaM/rKvNKpZHR8a1rQwnzbGRh5B7bzqLbvJw+oqjv2slT+OeDzl3Cl8kt cHHMNYEnMijwtjLsWLDXUVxeZNShnTydj76YftSYq/US7KqY6/d2tRCxKrDqCsE6RrGkUBsm 5JT25D9x5C9Kpq/p6ozVpYDekj9PRcSwVrHnpumG7ukd/MRB2COIm51j46Q8hVjPWubKv3Mn RcgvM+bs1ZEOU523rLaPbdu8Zc19zSALFL6vLAdgw6UIRVcEQWZ2BkFfy784qHqzI626r0G2 ZqnSMQ6SjQF5hcsIygQWegMcWuyIywsa06po3BK6GJJKH9ThCzpGAfJjVsdWrdpPofr4Be2k 6QEuIikvcBs3Hp8dafatMVGHeeBUk3DyIP4m65F+W+SfWaE+Xd3vyKxwsXOhByGZn/Gg1grR PYnmxQ7dAuMcjrVqm5kxfRomRjGwWO3QzYv1SkAMlgNFfWi9wTAEJ8AawcwDB4a+DbQhhsBM 4I3UVrN7FVpr2Z25p7gZ3jC5UGHm8jKCbpQ3ymPqxQc9A3D6JhXaI5iKvK5lh3le+TRp94ST x8HHCyFkJnxfjBAyE/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM6IMIITOhDyKEzIQ+iBAy E/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM6IMIITOhDyKEzIQ+iBAyE/ogQshM/taTXIO5 hzQ4/oV4uyaftZtyLukOMUdeM+O29Qg05ZsqRsw2RY3IGbFzXHtQ0eJMi4Nu+ITesgS/HYK/ a3YK+95Zcc+9Obo8sGHdZgt141cxYmdVe/ATM4OlMR32xe5m1tccb+PR7YHcz7S+2EH55dXk f67L+95OeTByJFkuAH/SRxzUJlUN8K7I/IqRZ6SJ/vyR/tP7rlFNchb10WXQ3QdxxPzTzCLk n9IxEepMy0113nWV2XPeE+2sGq8vYVz7alwSB20Fp0jb9938ULL+NJV3xMtYG1G2QgAAByFJ REFU+j6cUpgUUac/6Kh/tKouKTMKyeX/rRztLWctZQh5eejH8zWHnLL15kYl5I93KErJ2qcA dfoqgPM6cRDKdOVCUU5mFuY7WKgv5n1gE6RP1nh2bn7BFtikIn5WYNpzbr9Mh2NYOyDY3nI7 AXKOfzpXRH4TZXNtzaiNiR/sQEuIGG8W5guY74NAy8mIkCrYi2mKxaoqtM1Vs4OcFTAKmd1D 130t2ROV/93A0UQf2lWpGn9zYd7GfB8UYS/IR44fnhsyezTZ3+kQJqJCmATORigtF6q7iTj0 mJyUTnJDtyG6kM/i0cYPcokPam1U1cGL3KiEfxEJmrpFInFVhU484jLMMenrpsyaQi2zI1YO kZrpgSjx2zx4CsC8VkV9uUaEV3VdV25zmfa9eT1xo5/hI0eECm+KqkmgNt5UVxUiRqyDlgsD djX5Jc5qg9VB+8HrDTCnz6HZsiD1ULQQVaYBB70x74jZwnIx0rxbE3ylGeKq8Z8Rk/rs9IxP TrlF1C3ONB80Bdyreg3BwaCLau2JYlvb9ixWsHPBYgkyeX3Q/XhdsHcw93Ke2wzIRL4rDkqq lb7s8uMDVc/yvWY/bkFWsPNxNfrrfBAhZCmeMTdPCHkr88aDwLSKefwsjVWZeArkCoDGbpuD GQmZzbw4qNo8prSfO5vuic6uQ8LiIyvka/imebGmhnq1Gwq6gG4zcEY6ILIMs33QsR6rXJK1 q/eCde9Mr5OrriQTK8DEb5FdrxszZQLbtHAzl57NNu0JGqPlmxmBdkJuZ/m9O3KbNNeN6vW5 3ptOZcpy0ESLTcrTeTKBbVq4aYy3Llg7L6ELgzN62gmZwUrzYn2P5X1gS5VLG2HftWC6h6s4 RE1WZQEf5AULHWxv3F7loHv12wrL5gjxWcAHncj+wB1W4q7hCjdEx0Rms8TeHT+NZNxxlKOt jyDe/byiF1YOP5VFZ/4m5Brmvauh52682Z/IEe+gVlcCuoGnzIvpP3VeMLvnga8OjI6ZY9XB 34RcA98XI4TM5F3jQYSQp7HG+2JkcRgsk8uY54NYrQkh7IsRQuZCH0QImQl9ECFkJvRBhJCZ 0AcRQmZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFkJvRBhJCZ0AcRQmZCH0QImQl9 ECFkJvRBhJCZ0AcRQmZCH0QImQl9ECFkJvRBhJCZ/E0p/e///e9sMwghX8rPdzX++7/+e64d hJDv5McH/ed//jPXDkLId8JvPRNCZsIxaULITOiDCCEzoQ8ihMyEPogQMhP6IELITOiDCCEz oQ8ihMyEPogQMpO/KaVt2/SJY+3icUqvY9y2qxY33q/xTZil5xVpVU5JmX3Wvch6QSUxj3tn y8s0c5VXCsoWKA1afgNCNbiJHfd3pEr8xEH7vh8i8o983Mx2XSHer3F9zIeEiVlKHUVXVoaD anO9gawX+AthKjibj4g6L7Jo7cCwPsvvQaj2fLFOGRQer6WCP6bKb27wj8Z8HL0vhNRXhK/x xBIoW9rN8cIgy1aDf+NBoPpu21Y+PcRtEEdE9uOU+B9IABqrZnjaU1F1vIwigfcs1WeBQCFE p6zao82LSDYxSwBcqdn50ldXLXlxLWUBRsoKaBkHiN1qbm77rag6WdXywULAZlfrhlkBqjbo 9GfdkfqY9OZHpNtvNGvm2oqKm2P7MktOg2+2GceW3drNCcJxt860EF9R2WP1VAuBwEivNESJ paKDbMrxLj+fzWk2NRiBY4eMvgWiuESdBldaXgsuK10O5fXqWwMuxDxbWuLlbSJu+UgheJcT rxu6AoiKbdpQpscF3gryQbrKeuq9e5xqtUfX6aBG3TA6apK2UBsGbDBVm5fgpTRLI1JiopJ5 ZueDHTVGuIwmdQleqSgir6xwOZxFn1hcHyKW9xUCNjhYN8rj+taYHipuQwd/Td3CCHC26iDA PejQqIWklnIxHzvCnQUfqkC1fsRVjQyWWNPFRqjevlZpKWahFwVEyqFqQ+T2tQppqudBLR2F 4LWO0+sGuITTQ6G/TanNxzKwBj/2+zSKg3FXFTxlXtHe2JHRMrVe4Gi8NK2ta7xJR6Th29F9 36t6Z1F1c2bKDsubQvtg3YgHQdXjrWk83L6Y8Mq6u1EtIHG1ZgIhEGvUYrWQ6oUAC7GrEr0S U7V3CVUjTXt0Fk8OkA9u1rh3aLJEKMW3O1gOnnAzjSe2tRDird2zvKMQQEqgDpsRSW+a5Nmg pUX4kOU5RfO3mcs0NznBhZAQ8dZVIcAMzwGVFnqivCISB4HZICW2B2tMnxXCs7wjEIvcVp2s eqXmHQEVrNo98S5Tl3+1JM28IjEogbjlHYUQLAGzEMTlm3YGC63ptgaZH9muT/X2P5GRC3lN IXi8/gLPZbC4+L7YdyH6AoRMh3UxBA7dH4TXNWuVMChkfeimg4wX1P8DQCpM0hAe5l4AAAAA SUVORK5CYII= --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="ma1.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dandelion.icpdas.com id fBV7lUN03141 >From reed@icpdas.com Fri Dec 28 07:58:24 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 15:58:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D Message-ID: <20011228155824.A30856@dan.icpdas.com> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From reed@icpdas.com Fri Dec 28 08:02:40 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 16:02:40 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D In-Reply-To: <20011228155824.A30856@dan.icpdas.com>; from reed@icpdas.com= on Fri, Dec 28, 2001 at 03:58:24PM +0800 References: <20011228155824.A30856@dan.icpdas.com> Message-ID: <20011228160240.A30900@dan.icpdas.com> again On Fri, Dec 28, 2001 at 03:58:24PM +0800, Reed Lai wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 > --=20 > Reed Lai (key #1) http://w3.icpdas.com/reed/ > Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 > ICP DAS Co., Ltd. http://www.icpdas.com/ --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From sunny@icpdas.com Fri Dec 28 08:50:16 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 16:50:16 +0800 Subject: =3D?big5?B?pKSk5bzQw0S0+rjV?=3D Message-ID: <00b401c18f7c$ac55b7e0$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 >From sunny@icpdas.com Fri Dec 28 09:11:09 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 17:11:09 +0800 Subject: =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 Message-ID: <00c401c18f7f$96e51a60$0e1ea8c0@ICPDAS.COM> This is a multi-part message in MIME format. ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/plain; charset=3D"big5" Content-Transfer-Encoding: 8bit =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/html; charset=3D"big5" Content-Transfer-Encoding: quoted-printable
=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3DB8=3DD52
------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0-- >From sunny@icpdas.com Mon Dec 31 03:01:33 2001 From: sunny@icpdas.com (SunnyCat) Date: Mon, 31 Dec 2001 11:01:33 +0800 Subject: =3D?big5?B?pKSk5bT6uNUz?=3D Message-ID: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >From reed@icpdas.com Mon Dec 31 03:29:24 2001 From: reed@icpdas.com (Reed Lai) Date: Mon, 31 Dec 2001 11:29:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DB4=3DFA=3DB8=3DD53?=3D In-Reply-To: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM>; from sunny@icpd= as.com on Mon, Dec 31, 2001 at 11:01:33AM +0800 References: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> Message-ID: <20011231112924.A2706@dan.icpdas.com> Reply test. On Mon, Dec 31, 2001 at 11:01:33AM +0800, SunnyCat wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >=20 > ___________________________________________ > ICPDAS Test mailing list -- Test@icpdas.com > http://www.icpdas.com/mailman/listinfo/test --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ --mP3DRpeJDSE+ciuQ Content-Type: image/png Content-Disposition: attachment; filename="ma2.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAicAAAGACAIAAAD5w1VBAAAABGdBTUEAALGPC/xhBQAAAAZi S0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB9EMHwUwNCAFz08A ACAASURBVHic7Z1bkuwqrkDtE3vEN3oEHf3Zcafs/sgqNikJITDGpHOt2HFOFgZJYIzMy+zH cWy/7PuefufhOSlOKUIwTh6zGq0qweGM8BuJ3ItpnL9NcS0vgjUnEvNSLr1N1botVC9VZ0p8 hJFwKf+kX6KK6xq/73ve+qQ/W+OImCc5jkPU3eOXsYoms+ADeXUxLpjlKnNsLlXyW4w5yUcY CZfy43XMBsUMfFUav+r4caa5gVI3Dpqg6O7FedZoweET+WfLxk/MF6gXTpelKU5V0VhwPGNZ pwxn1qIbqWbw8SUAz+Onr5PXXeoxAABcxJ+tZea2dPU4jkicDvvOk9umzajObXZH0OFmzODk anXyvGqGuEfB25H6wdVeTlxR3Iy+si2FxxfO6N65Y6SZ0O9k6/I0VQT1RqpNyaSTNytYUKwg gJx/6lEeSr7wwWy5TkZw3JtI7sTR4WaqiBlBXVVKCSOKqkWqY5py/In0fORN/4jcViEkSOk2 6YUAJSMHEizAMzdLZ/BMJYfvwfM6X/hWEn+jb4rw6mPlDU1kLi3RMYdhmtE3EZJayaYkHf0D U0iHwaV+TyRJdy9ncw125Fz3lDXVrqBMXVCiegy/m/A8DK/zDS8j8QGr7gg5rS1RVU7p4Q8K CT7/J2uC6Wi3EyXWkaT6en6pJX4BXvqgtZp95maVMIXgeKDY16FyCDpe+R9ApCk/KfzqIu2T r4eGRvGMSY7vfBxgCH/E32nk5w5jpBkOoyxsalkubYJPMsGMI7CmoEPmWGkvC/fa6hVnIEjM bYyy8IrSm4Bjc7BLByCQXsfEf2DSW0+kgt6LNuO8Yctm7SSp+R4rdiZ9FfI6x5PzKQXr5F0M oH1KjuB23ryO7uhc9MhVGaiUh6EbfRfy+aRF3G2JM732qx3PIiMKZxgy8QPfifwO24PrUN/4 2PkIcxhrxqWZWmEW3VmxneQMfxY+8eEacrMWeUZgEeR32PZ3UrzSAxNZnXLjw+YM35txzDe4 vghXoLVPNqOk7kzamU3SHBse0A9oLajSSv1gTPgq/myN9WAPf4kgvmx0wtB5cG55zkLqViLl OdCMOe3CdSWWyqoqufQOIRLG+0/V2xS3bSmcm6Xzaz7OuQQcz5dTeU782lMU6sYZu+jg5Gq3 qmfqjiAMM2dcncAULuJU3V7EDAcnvt9xjCu6rsSEqPM2+EK0rvjT0VTVI112He1MAZoyS+rM GhuJ6auGp7L6nDDAw/jEvg7AQL73O2wA0wjOkgJ8A3gdgGu5a+kEwJrgdQAmwdgawIbXAbia yO4CgO+B1QQAADAP+joAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAAMA+8DgAAzAOvAwAA88Dr AADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAA MA+8DgAAzAOvAwAA88DrAADAPPA6AAAwjz93Kd73Pf0+jqMa/oWkohDlUApvl7/9yulMaybc 9x6BpnxTxRmzTVFn5Jyx87z2oCKApbitr1NtMR/scnLP6lAqgYElcxydTdXYm6PLwzes22yh 7nwuzthZ1R6rJmdLA2AyjLDNJuhyPhdaQABwuG2E7cVxHPu+7/v+en9//dDtsh5T0gNxkZDN avRFZEeFaVLVgFKOtCLHSJM8odAuZCZLImK3995APhCkB4VEiPmnmUTIHzLcJNSZlpvqSvnK k6e0A+2sGq+zcF47wL1c0tfZM4ZIO44jbz1TGyqaaSeklDD3dn5MYVJEXS48V5f/aFWdkycU kvP/tvJqYVPSXIaQl6ZwSt7lJSdvr1MzKuSfHybKJWsv4qjTuXDc1cDJJNN5C0UpmlmYAJ/I QiNsedOZBzrxN2slQmpwg21uk4r4VYFpz9jRNt3l8rU7BFvY1DI6cl7/dKqI/CbyBro1oTYm HtiBlhAx3ixMgI/jfq/jtJUJ0W0Kjk019beqKrTNVbODjOoUCpndiw762u6SqPRvAq9G+UMH oKrGTy5MgIu43+tEODJSyOtHyfGY41TJw+luSkSFMMm5GiG3XKjuJuLCY3K2bZDjmYYYGPws Ptp4gCYu8TqtzWh1EiI1o8KjiAhNg10iclWFjnzGSZirCa5b3tbUnTKH1/LJbTO+I0r8NgOH 4JjXqqgv1RnhVV3XlRvATPrHYc4qVous9Hv6mRChorScrEmgNt5UVxUi1hoELRcGHGqhmriq DVaB9st1aWnA9j6pnhekXkQgROVxnMDSaoWI2cJysUbgsBbj5WaIXPt/Rkzqs7Nk/FYot4g6 gKW4zevcgj9W9hiCkzoXtVMDxba25nexgp0LFguAyc37deZTGlh7Bvdmh4YPAKp8V19nU+3y w7Ifn3D6LG9rjs4tyAp2PqtGwwP5Oq8DAAA38hkrpwEA4BncN6/jLIEyw0dprMr0lytdgaOx 2+ZgQgCAudzX16k2iLe0mDMb64HurUPC4jMkAPBQvmkNW1PTfLXjCTb63Wb4CXE5AHATd3ud 1464fFPcob6pq8fc9E7F6l4+sQdP/BbJ9c49U6ZjmxZuptJrjU17gsZo+WZCRzsAwMUsf9JB aoXNvdp6T3zpC2J5zHzyQ4vdlG8ryXRs08JNY0p78bW7Erp8/IQl7QAA17PSGra+V+/jxJEj lza7fXnx6Z52YnEBAKzBAl6n1CHoYH/u8SPd+w9X2LgIAPDLAl5nIMcHnkASdwZXOB5cEQDM ZYmTDn6axfOuIp8n/wjig4pXjK3l00h50Zm/AQBGcN8XcfQ6q9JKrUhIKVCry3EG94asYdN/ 6rTOSrwSfu6cWS5zlUHwNwDACPgOGwAAzONZ8zoAALA2a3yHDRaHDjEADOI+r0NDBgDwfTDC BgAA88DrAADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAA wDzwOgAAMA+8DgAAzAOvAwAA88DrAADAPPA6AAAwj5/zdfbsjLXjOPZ95MnWL+Fjj8rerUPh Sip0dnTyM+YlaaYWxypxVVilE4rb1KSoFMG81005igcCAPzZVAMh2r4+DzTWb2m0azT9UIrs J9/3vdtgIUf/LjXr4mo1OyULg4rMCGahNeWopP1Vwlo4AHw5xghbsCl30O/sE955z6gYntb3 YeZVUexBk6oxW80oJam6NACACH9PsM5bkPT2Ki7pEZ7UTyq9m+djNfp3qYOl5ZvCS7+FVR3N pTNqZArUxidLTrbLIndCe0lRJIPDh1JLZgMAJP7Z3pt+c+ZAOADtD7THSj9EE5kU5UKE5C3W +dh/yQNTS6q1B0mjbbmbzAOdhNpL9Tm8UhdE+/6gzK3spyNJ6OgAwCh+Rtjy9rQ0qlYdKIuP pMVbK0em6VpaX/kd80pz+5EBqCGzRKa6iGPzo/m+pCoZAOAMf/I/0tu9M3E9yS4Xs2vVl1yE iL5XKb4vMP1ZHcI62bIHFTmLCDpGICP9HjwWAJT4WcOWN+KldU0pwhZ2P8HW56U0PmsSVHem o9Ot9AxXNNZO58l5t8BnAMBF/Iyw+V6krxlqTXX8IoSc7GBVs6Z9lU5oBm7WVH/pqqm66iO1 3mBXo2pexOUEc4SXAoA4b8vMEroJE12ceCqz0a9KEw2f2aRGmj9ncMkRUsqOjh83W6dqWnrg G+APGGrzSupac+QE6nAAgO3lde62we6OrGAYAACM5U89yhT8PgQAADyDJfo6W2DgCwAAHsAq XgcAAL4BTjoAAIB5/P3mtCbSDTL38YztP120UMpfg9ctMLLK63wSbXC15Ft1ta6aa80IAHwn b99hOzKC6Se0KY6KM9rTrv6U3zNLGHb16baqhWaSkhxxVdwjP1WHrlxRNUlH3gHgaxk8wtbk sZrQzdxY+ScFtiYvZaHDjGppdGztLPV+WuUAAAiMldPp1XWzNnKKbYMioYgcTOiPzu3vJyak P/3xHLFNtaO57BjZi2xTjeB8tiA+bFX1K6WSHAUOCQA0b32dfd+drem5b0htX96smL+rCc83 TC+ztZvcTjT6etQoD/RtiMgvxfTl6LeBvo5O8Or2fvvo6ADAed68jjM+1t24xBNGRuf8gSnR P2jSbgos+WAt1p9WadJbnSAJZuqMN4rHAQBooniC9SJfB6i+Yvs9g4gEEZL6ZGKk8YoZl27J faJ0x8XxlH6HrFqkeCwAMJn9RZzjxKEGJ0eT4tBc4jMA4CLsNWxXd3SOX4RSX6/z6r292yxe 6n2xeiolnzXxA0V4a0utlwloOVpvsKvhRwgGnpEDAKDxGuXjfSnaVlulVhJSSphHSHHMpvPI llrpfpKZ0BmC82dNTBWlwJIBfnw/iT/015qqSZewXKhrstk0FQBg9iuq6Z9omwAAvoQbTjrw ex4AAPBgbhiOrw5wAQDAU2ESGAAA5sFJBwAAMI/iYFc+DvYR/SE9P/QRZgMAfBV/qttZPqjt 9jesAADA7TxnhI3PsQAArM/Pyun0oRp/S39ph2YeGAnZygNiERWbu8kRAACWpaGvI76GuWVN v3YGpZBSwtzb+TGDdsbzBQAA0zC8TulDWyURpS/ZpK8aB31Ak4omPwQAAIvw1+vo0TCN+ECn HgQzh8X2XyIGVVVUk+ONAACWpW01wZGRQl4/So7HHCJLHq7UifFVAADAhyLPEt3cKXrx1X1/ bK2K8C5BFelq8CP8AACwDsZ6s/hStNblamldnF4g1yRwK3gjvA4AwOLc00xz3gEAwHdyw0kH LzjvAADgC7ltSIrzDgAAvhAmQgAAYB7P+Q4bAACsD14HAADmgdcBAIB54HUAAGAeeB0AAJgH XgcAAOaB1wEAgHngdQAAYB54HQAAmAdeBwAA5oHXAQCAeeB1AABgHngdAACYB14HAADmgdcB AIB53HaWqEM67y0d/bPv28BjgLT8amAK1yFBjVVdjvBS/CalTVfXl2aePZtXGB0YlOPflKrl jlVNhlUN8Ctnk5ZqIWwjbkpcTtCw4HMRtEpc6nvoLO1S/ZkjzV7SSgcxByXv+83Hqi3X13lV yte/K061fskUFcsMzMkvvWwrxdTqRLRSBkvCryiQsQV7i7RXKaWSKT1E1YdLyBEG5DclUv5J iCmwr/6YBpiifO2+2X6qsTclTqQwq+Y1FUu6Ouqhe7XvR4b2Q63SSirOCJnJcl7HZGwppSro B+Y1T1sSNKnp2WsV7vAyfqCXWlZaIu/odLd6+lXavPt9ArfGW+wbEBHVV5EGPm5mR6f71lef 2TNWDXGTV3N7N2UIy3kdXaSiu/D60w/xMWOWAq9rHIUi/UTpRmcIw4crV5Cm3837bpxINSRr A9tZM9wvtA7tZu+8g+HPTl8PzESPNPQNnlcRfkL/qbs+OtCMVpJpJkz/PdPTGsUl8zp5xro9 c6rrYmCh1NF+1ZvIiEqqYfnbog40xZqj6n20Pszx+KLo9Pt7E4tLM4nXBy3HT3L7i6bfGzuD WQgDb4pz6zsMKz2zfZQqzJCXKrM9zGdoktsoBeZXm5S+BvSShJPje6O4bTWBmXfduJsJzVGv 4Dtd7jby3zowF5uU5u9EZ6rjGZfjF10V/Vx9rjSzTPSNa5ITuTUnszlKlKi9JxWVCmHITRlu mH5mu0tSV5ikbshD92rr9fu36UtEoEjY9BKvPc0iA3S3eZ2+vAffYSNVxKym1UCzFg5sgyJ0 NzFmuX26NCfm0T5KGXx3GXhzR72nR3r5TQK3C27K+ZcS5/EcVZKlSx2ITobo6IgFaWZgXEUp cBFPk7NoX8cppYjjubqQhfYOdaYLzAMdFa3dxNIrW+QNcWVpcbrllAxuEujX1TMlFiHvEziK IuaduSlORm65y61+evibpbMazaTPeeQdqXXczyVeJ5K3amfFjJCPdInA+HClGV8H6r78Nm4k 3cyg8xw6Ix5xTK/2GGnm2EurHDFSVxpy6RO4Wbe46QVLJHdabTM7rTaPvcUlThZmpCQjcjb1 VA556BK6uyOmbUqBW3nATaOl5V2oiIQJ3G+BifkKXKphrdUuKKQU0toU5jjvsJvbRgTfcCO5 iAv8CGk58QbdkaONKV1qsqpDmp9Eh5/p0lVT9d3iUnjwHvmGdQsJymntViq9+6/YIw8RMzem d9HL3vz9oQnTgeVKV2jwlzACck7WdQCAlVluvw4c7yvlAACexFqrCSCHIgL4FBifiPNhK6cB AOCjYYQNAADmseJJB7dhLrUZ2CmLr8Dz1yc1LRENLtYxhXcsStVKm66uL81fERW/Ta2L56qW O1Y1GVY1YOXFc46opqoyZ/Hc5hbmuZZn5RMW6Ov8sl9wooCQv6mKVd12IXZnVDdo5OrMXQk6 gyXhVxTI2IK9RVratHK4nymuPodCjjAgvymR8j/cr/n31R/TAFOUr90320819qbEiRRm1bym YklXBz10K5+wgNdxGTv7lKqgH5jXPG1J0KSmZ69VuMO+8KEIY6Ul8o5Od6unX6XNu98ncGu8 xb4BEVF9FWng42Z2dLpvffWZPWPVEDd5MWM3+jzN6/R/yluX6c4RC0MZPly5gjT9bt5340Sq IVkb2M6a4X6hdWg3e+cdDH92+npgJnqkoW/wvMbKJyw8al6n9D2JVil/32XEcNNmdbR3jlhQ MY8lD0UYK80kXh+0HD/J7a/Dfm/sDGYhDLwpzq3vMKz0zPZRqjAjXqqWPWHhOV4n9zSlT4u/ 4hmBunE3E5qjXsF3utxt5L91YC42Kd05YmElaWaZ6BvXJCdya05mc5QoUXtPKioVwpCbMtww /cx2l6SuMEndiIdu2RMWnuN1ovQ9osF32EgVMatpNdCshQPboAjdTYxZbp8uzYl5tI9SBt9d Bt7cUe/pkV5+k8Dtgpty/qXEeTxHlWTpUjuLn7DwHK+Tl683wubXP6fQI47nuhb/hdDeoc50 gXmgo6K1m1h6ZYu8Ia4sLU63nJLBTQL9unqmxCLkfQJHUcS8MzfFycgtd7nVT49+s1zhhIXn eJ0t69N5xVTtrJgR8pEuERgf9DTj60Ddl9/GjaSbGXSeQ2fEI47p1R4jzRx7aZUjRupKQy59 AjfrFje9YInkTqttZqfV5rG3uMTJwoyUZETOpp7KIQ/dLwuesMA3p98xX4FLNay12gWFlEJa m8Ic5x12c9uI4BtuJBdxgR8hLSfeoDtytDGlS01WdUjzk+jwM126aqq+W1wKD94j37BuIUE5 rd1KqXb/lXrkIeucsIDXgV/O1XUAgAhP268D/RzvK+UAAC7gUfM6IWhVq1BEAJ/CB45PrOR1 Rk2Y+3zgTQIAeAwPHWEz12JdNHxUFcuwFQDALyv1dbaWdS/Dlwlt1oKc0ioyf+JdXM3nS8I9 rfzDElev+BBfzpigEQC+lsW8TmLUaFtpK4wZJ7K6NNhr6VjL/5a65wtIfeiNyvGF+QAArSzg dYRX6Ei1xZzEoXZoOqu2dH9FyxH710ZtPngTcOpUjCq4EACYzAJe58WhDiusbprT0XwH5jff yYBSQr3RTEsQSYKu0cX/KOymvsigA82rvrrfTLyN8sU3KgMAlLhkNcGeMUyo+YkI0fYdhW9C H9mhfu+Gyt/du6xzOclLHZ1HNukujvP1JPPrsOIL3Kac6vEYQlR+OmFrjgAAXiyzhi01+o6j yrs4EX+WyxTxd3VwgN+SHu2fXUp6u1yvcDylrydthY9VnHcM+nhaujgAcJ4FvE7e6Ff7B853 n17kvsGcVsk7InmS6upn87dj5PaeqUhCKaY+qRPs7iQiniP4uXIAgA4W8Dpb71o106lsmWfS U0G+P6t2d6ohuRn5n2GnZbqZMWektuN/rhwAoINLvM6RMVi0aL71dH3ez9BDZ7r1z3s8ohuU Iosf1Y6LXndQXYmQUerf5JP5m3JFTmAuwfl2rBNZqAYA6GalF1hnVXF8O2cuKjkJvTrOX/+m FekkJe3O9E9gZkh4C3+tWvDMDPPPFJhlwohsqgYA6OZDvI6TJCd3CcITlC75AjfPQ/yNHze7 Nf44GCIDgBVYZr9OHx3NaHCtWlDy0XKWaFzsOFLnCZcDACtwX2PEDME2wwkxMgYAS7HSK/B9 o08AADCHNVZOD8f8qk3vhs26rupeHzp2AADbti03rxPp6MS7RNWlAfGlcXoBm78kIb96WCcd tH7p4CfR24fR4gk74PgDALiCxbxOYtRo27HkSQf5Au7wyj2OPwCAB7CA12n62EwpZsRJ6PVm x30nHaT/trsQjj8AgM9lAa/zwtzLmaM7Iv5OT3NqJ2JAKWH1+wLakpJrPN2mc/wBAHwonHTw /tv5QkGQveWkg5by4fgDAHgAy6xhS41+9ftmjntwZIr4+zInHbQ01hx/AACfzgJeR8xz+P2D 0gxKIvcN5rRK3hHJk1RXP5u/HSO390zphB1fAIpN6nD8AQAsywJeZ+ud5zCdypZ5Jj0V5Puz anenGpKbkf9pDuWFc83xBwDwGDjpIOvxiG5Qiix+VPtbet2B368KjBZy/AEAPIOV3lWd139z MZizvWZf+6SDkqICHH8AAI/hQ7yOkyQndwnCE5Qu+QK3ij8wvJdPa/yLYYgMACazzH6dPjpa zOBataDkY/WTDkw4/gAA7oKTDtbj+jvCyBgA3MVKb7uLjT4BAMBw1lg5PY3qns1qBAAAOMFi XifS0Wn1HPHtn1u2aE0v0W50SOmDQHM+EZ1/goilzACwLKuuJhgy2hZsfP1P3eidpwGrOJUA AMBkAa/T9LGZUsy8GRW/xbcASns8ze01Yp9p64o1TiUAAHhnAa/zwtzLmaN3ZTrRzL2cQp1I UnJjpX0/YTiVAAAg8ayTDswQhz18KkF4bO3XCk4lAAAwWGY1QepwVD8bY3ZNRDR/qsbU7q8X eDmkFifKqQQAAJoFvE4+d1Ltc5RmZXKaJopEF+oonEqQ4pxwPKU4W6C7k+BUAgD4aBbwOtu4 kw6cS87Qmfizb3XD3xScSgAAUORZJx3kEcSK5xJ63YEIybXEnBCnEgAAlFjp/deZri/t5RQh SYizkk2vXtusnlB+qZTctpRTCQAAinyI13GS5PjJW3eeLvZdOIbIAOABLLNfp4+mVrh1j+ca TTynEgDAk+Ckg3NcX3qMjAHAk+ANGgAA5rHGymkAAPgOPnxeZyjm2umBXUFzxZwfuLnr9SIa I0v2Opb4xZU2XV1fWmn3sL4aWdpiChloT1xO0LBglQhaJS6VFqVGNFbRewbODPM4XxWJS/7a yVr6Oj+8nsz2D980yN/U01XdU5Rf8j+boNXp/a9mBkvCryiQsQV7i7Smb2jE5WgDxtoTxzEs uAVuy6qTk0Gh0ayHAyth/hHCF2f2rjmfVYw7ku90ORtex2dsrUjPoR+YP2nakqBJTQ1Qq3CH fLvUeVaWlhA9476mf2BNMzs63bmuVtczVp2s5Dfytd2UITzN63R/6Noc39BfQvBDarY1BF7X OApFulm5aJ/S8OHKFaTpDkrfjTM7puflnKevB2aiO9nO0G63eyvh77k22w0d6Dcv1W/Ab7+j cIO/x/9pPGpeZ8jnzvIaL4abNmu0YY+dgZBibu/vdDrQFKsN6GbsXIgZ8zhkqg6zF5dmEq8P Wk5+r0fZ4+S6w7BSde3DLKuS8CEvGeaHPPyDrzarVWlyGPnHQfIzR/A6T0AcSFNyPM70yeZW 7jQmIFIFhy9yt5H/1oG52KQ0fzE88/idcTl+0VXRYyyfK80sE33jmuTkRT3EHoc+w3R17S52 XVZ5uHZFQyphqVkwfYkINL8KH0R7mi8foHuO1wnSd6+D77CRR8J8VquB5lN3sqltJSK5NGCo 0366NCfm0T5KmZIMt+e8P3Zq5qgejxlYKtsORCdDdHTEgjQzMK6iFPjlnibnOV4nr0/uAKuZ Vv4w41Qdz9WVSmjvUGe6wNJ7pYjf2k0svaJGXpNXlhanT84oe5xc35LB7lGyeCXsEm4kdtxD n/PgzJGc53idLevDOje12lkxI+QjXSIwPjxrxteBekBjK493t2Jm0GmMnGGfOKZXe4w0cwCq VY45fHo+dyU6DMtN6hjsNeVsqu6Z9XBIJUzo7k7wG/BbecBNo6XlXaiIhAfzvTk3MV+BS49Z 67MXFFIKaW0Kc5y3fhHZ6RNE1Dm5iAv8CGk5oq1sKjEhpNsenRcRHjTPN6xbSEROqR52d5J+ k++/Mt/G0MTMjeld9LI3f39oZr/hwHKl39zwfnXmIefksw0AEOFp+3Wgm+N9pRwAwBU8al4n Aq1qFYoIPhf66+uzkNcZNWHuQ6UEALiRZ46wmWuxLho+qopl2AoAILFQX2drWfwzZJmQudDL XEgjlPoT73rLy17+jkjTHH7+dY2rl4GIz4d8+aobABjFWl4nMWq0rbQVxozjLCAWhlU5s8C0 HLnnM1B96N3a8d0JAAAO93sd4RU6Um0xJ6F3aDqrtnR/RcsRm/hG7cCocvWnA3EhAHAd93ud F0f2aRazo6M7Ijqa78D8hjoZUEqod9tpCSKJ7xpL6iL4X8bd1GcadKB51Vf3a/bbKB97rQGg iUtWE+wZo2San8QQrdxR+Cb0kZ1s+G6n/F3dU10ln8I5ymd8dRSM7uI4n5AyP5ErPsttyqme ESJE5Uc0NmcJAL6PVdawpUbfaY7zLk6k1c5livi7OjjAbzOP9m9PJb2RvlEQ4XhKn5DaCl/s OO8Y9Bm9dHEAoIn7vU7e6Pv9g+3d8ZjkvsGcVsk7InmS6upn87dj5PaeqTzhmdmdyKROsLuT iHgOvtkOAENYYl6nrwUzncpWWCNwlE/syKVVe1p+SG6G/2d1Zd17Es9VTPYBfLMdAM5wSV/n yBgrWTTW2rXk/Qw9dKa7LHmPR3SD8q6JThLxT3pQzpzyiRRSqX+TT+ZvyhU5gbkE5wO6TmSh GgAgwhJ9nSrOdk5nZ09pnfTxfhJiycfotHkSZ8LGNKl7udpv8r/eQp/boT2Hr7ZYvwAADhZJ REFUua9TBDpxtC7zVBJTNQCAw0JNRsdsR2lpshC178VLvsCt1hFxfN6Q+FeDzwCAyXxGX6dE 1zKwytUmx9Dag1mkhU89FVwOAEzmtnaHuYASE27IqIXUAACt8LYLAADzuH+/DgAAfA94HQAA mAdeBwAA5oHXAQCAeeB1AABgHngdAACYB14HAADmgdcBAIB54HUAAGAeeB0AAJgHXgcAAOaB 1wEAgHngdQAAYB54HQAAmAdeBwAA5vF2thpn7ey/h81dVxTmiWrn9e7qmLyTWXDsLEnuTqIN rp4716qrVMJxORyFBzCEf9JTNKSR+nSChXAms46KM7fglfb4ZTtn5Otw69cp10ELzSQlOeJq sjmSqkNXrqiapCPvABBnzAjbM1xOkCGZ1c3ceZk5JwW2Ji9locOMammYEfxUpd5PqxwAOM8f /7I5ACIC05/6ic2HNfIBCj1YoQdAtOpIyGZ5BRHZH4EpBQoheWZNyaUBmVdCIadUdEKFKEYt VmfBt6daJjr+eUeiiy4is+pXSiU5ChwSwBC8vk5qEfIGVwRuWZOhn8m8cUlC8t/5VV9LNcQ3 T6twcurI15n1JXdgFlGei26Bwtvlljs2ROSXYvpydLn1dXSCV7f3ekhHB+AWPK9TapK29pnV PGbpdTuiJQ9xzDPltBKR70gOJjfjpAwKRd1toukU/deFozyt0qRXyxHqgpk6443icQDgauwR Nv2unUiNyNhnWDdMQoupt6lZ7GhDg0nikquv2H7PICJBhIguYFVLq/EdcUap0x2XozzC5nfI qkWKxwIYhTevkzdVYoaj5Hi6H07zddt3PKZ5r3BzuqLVsFL2RYQOySn5+ff3CDSX+AyAdTBG 2Pw3d2eo58yznY/sm1qahpiOXxwVJzG7XLnk3PmVjCxJ1qLyl/rqDdLv6aZ5OlCEd/hps0x8 Y4JdDT9CMPCMHAAYgjctsak+hBnnR5C7REpIKP3Wep0Q07zSLIKZ3DTVFGV2rXzJJceZpOkS dhI6g2P+rImpohRYMsCP7yfxh/5aUzXpEpYLdU02m6YCQAdPe6cz+wEPyyMAwOdS2a/zifhd AQAAuJGn9XW2wIgTAADcxQO9DgAALAsnHQAAwDze5nWaVifrhGbabplVyaO4aNmSv+SvW2B8 7VZfkjzapbpa17B1ZwQAlmJMX+e6J39Cm+KoOKM97WxNO4fOrGvYuz6/b16NZEpv4kkGxM0r 2ZxfiiTpyzsArMlfrzN2E2XCaaqWwtyVOZCTAmeWod6h6d/Ejo2Wpd5PqxwA+DjeRtj066S5 X3IrD49s7+MezlbQqsCq83N2kopNndowISe3J/3pj+eIkuloLvs2YzrbJyPxq0JK2Q8Kn8nt BgBABz99Hd8HOC+/2kvl4Xmq9DsNPQn5ecKUvDqLYKrTG+DPkMaXtlrJtAoU3s7pVeQ2XEfJ 1760B5OUAv3kdHQAvoS/fZ3q4x1px/ua4NYkVc7MZzhphZMIynQsLE1UaLFnnFzcGFOL9uUl I1vBqQB8IX+9Tkfr39pkHL8fhNZjOFf4ngjVV2ynZWx6SRe9pVLn7Lzx/tVqkvxHq0lNGh1L InLwWAAfyp/NamLmjOfkrNCCRGZihti5QmY1J11gE/gMgK/lZ16n461W/AhS6h90C4zjTE7k tpkJt3fDxGCUL1a7cDOzpRLIw69oqUszcyJCtW8a7+iIrmS3HAD4RLzjAwRmhNIcezV5qQnT Wo7COrG4GaUFDkKFmaqU0OkZlGZrTL1+YMkAP36TiurIVUm7Uz6lQGGGMCYux887AKwMr5AA ADAPvsMGAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAAMA+8DgAAzAOvAwAA 88DrAADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA88DoAADAPvA4AAMwDrwMAAPPA6wAAwDz+ 3KV43/f0Oz9FuxT+haSiEOVQCm+Xv/3K6UxrJtz3HoGmfFPFGbNNUWfknLHzvPagIoCluK2v U20xH+xycs/qUCqBgSVzHJ1N1dibo8vDN6zbbKHufC7O2FnVHqsmZ0sDYDKMsM0m6HI+F1pA AHC4bYTtxXEc+77v+/56f3/90O2yHlPSA3GRkM1q9EVkR4VpUtWAUo60IsdIkzyh0C5kJksi Yrf33kA+EKQHhUSI+aeZRMgfMtwk1JmWm+pK+cqTp7QD7awar7NwXjvAvVzS19kzhkg7jiNv PVMbKpppJ6SUMPd2fkxhUkRdLjxXl/9oVZ2TJxSS8/+28mphU9JchpCXpnBK3uUlJ2+vUzMq 5J8fJsolay/iqNO5cNzVwMkk03kLRSmaWZgAn8hCI2x505kHOvE3ayVCanCDbW6TivhVgWnP 2NE23eXytTsEW9jUMjpyXv90qoj8JvIGujWhNiYe2IGWEDHeLEyAj+N+r+O0lQnRbQqOTTX1 t6oqtM1Vs4OM6hQKmd2LDvra7pKo9G8Cr0b5QwegqsZPLkyAi7jf60Q4MlLI60fJ8ZjjVMnD 6W5KRIUwybkaIbdcqO4m4sJjcrZtkOOZhhgY/Cw+2niAJi7xOq3NaHUSIjWjwqOICE2DXSJy VYWOfMZJmKsJrlve1tSdMofX8sltM74jSvw2A4fgmNeqqC/VGeFVXdeVG8BM+sdhzipWi6z0 e/qZEKGitJysSaA23lRXFSLWGgQtFwYcaqGauKoNVoH2y3VpacD2PqmeF6ReRCBE5XGcwNJq hYjZwnKxRuCwFuPlZohc+39GTOqzs2T8Vii3iDqApbjN69yCP1b2GIKTOhe1UwPFtrbmd7GC nQsWC4DJzft15lMaWHsG92aHhg8AqnxXX2dT7fLDsh+fcPosb2uOzi3ICnY+q0bDA/k6rwMA ADfyGSunAQDgGdw3r+MsgTLDR2msyvSXK12Bo7Hb5mBCAIC53NfXqTaIt7SYMxvrge6tQ8Li MyQA8FC+aQ1bU9N8teMJNvrdZvgJcTkAcBN3e53Xjrh8U9yhvqmrx9z0TsXqXj6xB0/8Fsn1 zj1TpmObFm6m0muNTXuCxmj5ZkJHOwDAxSx/0kFqhc292npPfOkLYnnMfPJDi92UbyvJdGzT wk1jSnvxtbsSunz8hCXtAADXs9Iatr5X7+PEkSOXNrt9efHpnnZicQEArMECXqfUIehgf+7x I937D1fYuAgA8MsCXmcgxweeQBJ3Blc4HlwRAMxliZMOfprF864inyf/COKDileMreXTSHnR mb8BAEZw3xdx9Dqr0kqtSEgpUKvLcQb3hqxh03/qtM5KvBJ+7pxZLnOVQfA3AMAI+A4bAADM 41nzOgAAsDZrfIcNFocOMQAM4j6vQ0MGAPB9MMIGAADzwOsAAMA88DoAADAPvA4AAMwDrwMA APPA6wAAwDzwOgAAMA+8DgAAzAOvAwAA88DrAADAPPA6AAAwD7wOAADMA68DAADzwOsAAMA8 8DoAADAPvA4AAMwDrwMAAPPA6wAAwDzwOgAAMA+8DgAAzOPPtm3//f//3m0GAAB8BX9e//vX //3rXjsAAOAb+PE6//n3f+61AwAAvoH9OI67bQAAgG+B1QQAADAPvA4AAMwDrwMAAPPA6wAA wDzwOgAAMA+8DgAAzAOvAwAA88DrAADAPP5s27bvu77w2j36uqR3ku77VdtL52t8EmbplYq0 KicnT37XvUh6nUpihpeu5tk0U+U5dcrWURq0fAJCtXMTO+4vjyfE+enrHMfxqjTpRwo3k11X w+ZrXB/ztcDELKWOossrw4tqAz2BpNfxEMJU52oKEXVeJNHaHcP6LJ+DUF3yvjpmUHi8lsKX 889mVbJvbuI/GvOV83nvoTpHfh4HlkDetn5Wn+B51QA+lL/zOk6Dte97/oYoHjwRIpK/Lon/ OhIcjVUzStq3rLEoJRQRSu/L+qojUAjRMav2aPMikk3MEnByag6p6dxVS17kJS/ASFk5Ws7j iN1rjm3/rag6WtXyk4Xgm12tG2YFqNqg419xR+AbqK8m2MvjDPvvGIWZas+aqjRikydJcfzH 2xydyIen98LQij9YZ1ro5ygfhyypFgIdI0ulIUpsy4Y9TTml7KerKc6uJhX8/kFC3wJRXKIV c3Ka58UvK10OeX71rXEyYl7NLSmlbSJu+ZlCKGUnXjd0BRAV27Qhj+8XOICP53V0I7UVKlzp qd5q7YVuxYIadVPY0XZoC7Vhjg2majMLpZhmaURKTDQrJbNTYEcbIZxEk7rNzakoolJZ+eUw ij6xfn2IWN5XCL7BwbqRh+tbY/qkuA0AVX7O16m2qqWrVZfgPHUdGrWQreVJMF8thQMLvjg7 qvVrbNXIYIk1ZTZC9fa1SttiFpbe9CPlULUhcvtahTTV86CWjkIoPR3D64aTBbo7cJI/TbHN V2+n/vmv9n0aRWDcOQUvmTk6GoentEyt13EtpTit7en5Rjwizb8d3fe9qvcuqo7NjNlheVP3 PVg34h2danhrHIAXxRE28ealB5Gqj4So32YEIdDXqMVqIdWMOBb6zkmMNZmqS1moGmnao5OU 5DjynZt13h80WSKU+rc7WA4l4WacktjWQoi37yXLOwrBiemo882IxDdNKtmgpQFo3mpP6cXH /G2m0slTF8Fs9HMJkTeyqhDHjJLLyS0siSoVkQh0zHZi+vb4Grf3JqBkeUdnK3JbdbRqTs07 4lSw6qBTKZu6/KslaaYVkZ0SiFveUQjBEjALQWTftDNYaE23FcCEKlKn+sB/Imcy8phCKPH4 DI6F4oIm+A7bdyFGeAAAJkPrE8IfkPkgSgNurRJOClkfHHMQCgpa+R8OGeCI1imrLAAAAABJ RU5ErkJggg== --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="ma2.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dandelion.icpdas.com id fBV7lUN03141 >From reed@icpdas.com Fri Dec 28 07:58:24 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 15:58:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D Message-ID: <20011228155824.A30856@dan.icpdas.com> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From reed@icpdas.com Fri Dec 28 08:02:40 2001 From: reed@icpdas.com (Reed Lai) Date: Fri, 28 Dec 2001 16:02:40 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3D= B8=3DD5?=3D In-Reply-To: <20011228155824.A30856@dan.icpdas.com>; from reed@icpdas.com= on Fri, Dec 28, 2001 at 03:58:24PM +0800 References: <20011228155824.A30856@dan.icpdas.com> Message-ID: <20011228160240.A30900@dan.icpdas.com> again On Fri, Dec 28, 2001 at 03:58:24PM +0800, Reed Lai wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 > --=20 > Reed Lai (key #1) http://w3.icpdas.com/reed/ > Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 > ICP DAS Co., Ltd. http://www.icpdas.com/ --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From sunny@icpdas.com Fri Dec 28 08:50:16 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 16:50:16 +0800 Subject: =3D?big5?B?pKSk5bzQw0S0+rjV?=3D Message-ID: <00b401c18f7c$ac55b7e0$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D5 >From sunny@icpdas.com Fri Dec 28 09:11:09 2001 From: sunny@icpdas.com (SunnyCat) Date: Fri, 28 Dec 2001 17:11:09 +0800 Subject: =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 Message-ID: <00c401c18f7f$96e51a60$0e1ea8c0@ICPDAS.COM> This is a multi-part message in MIME format. ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/plain; charset=3D"big5" Content-Transfer-Encoding: 8bit =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D52 ------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0 Content-Type: text/html; charset=3D"big5" Content-Transfer-Encoding: quoted-printable
=3DA4=3DA4=3DA4=3DE5=3DBC=3DD0=3DC3D=3DB4=3DFA=3DB8=3DD52
------=3D_NextPart_000_00C0_01C18FC2.A4D5FFC0-- >From sunny@icpdas.com Mon Dec 31 03:01:33 2001 From: sunny@icpdas.com (SunnyCat) Date: Mon, 31 Dec 2001 11:01:33 +0800 Subject: =3D?big5?B?pKSk5bT6uNUz?=3D Message-ID: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >From reed@icpdas.com Mon Dec 31 03:29:24 2001 From: reed@icpdas.com (Reed Lai) Date: Mon, 31 Dec 2001 11:29:24 +0800 Subject: =3D?iso-8859-1?Q?=3DA4=3DA4=3DA4=3DE5=3DB4=3DFA=3DB8=3DD53?=3D In-Reply-To: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM>; from sunny@icpd= as.com on Mon, Dec 31, 2001 at 11:01:33AM +0800 References: <002d01c191a7$744db460$0e1ea8c0@ICPDAS.COM> Message-ID: <20011231112924.A2706@dan.icpdas.com> Reply test. On Mon, Dec 31, 2001 at 11:01:33AM +0800, SunnyCat wrote: > =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D53 >=20 > ___________________________________________ > ICPDAS Test mailing list -- Test@icpdas.com > http://www.icpdas.com/mailman/listinfo/test --=20 Reed Lai (key #1) http://w3.icpdas.com/reed/ Fingerprint 7EB3 6A2B 3C32 64E9 232C D7F7 61BF F5B2 7199 EAD3 ICP DAS Co., Ltd. http://www.icpdas.com/ >From sunny@icpdas.com Mon Dec 31 03:50:08 2001 From: sunny@icpdas.com (SunnyCat) Date: Mon, 31 Dec 2001 11:50:08 +0800 Subject: =3D?big5?B?pKSk5bzQw0S0+rjVNA=3D=3D?=3D Message-ID: <003701c191ae$3daefde0$0e1ea8c0@ICPDAS.COM> =A4=A4=A4=E5=BC=D0=C3D=B4=FA=B8=D54 --mP3DRpeJDSE+ciuQ-- From dmick@utopia.West.Sun.COM Mon Dec 31 13:02:31 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Mon, 31 Dec 2001 05:02:31 -0800 Subject: [Mailman-Developers] New Bounce system References: <3C2EFC1E.4DCE7C2F@utopia.west.sun.com> Message-ID: <3C3061E6.22E0328D@utopia.west.sun.com> Dan Mick wrote: > > looks interesting, but a warning: when you upgrade, all your previous > "nomails" will appear to revert to "off". Not exactly what I expected. > (the value is actually "UNKNOWN", which still disables delivery...but it > doesn't show up.) Actually, it was worse; the upgrade just cleared everyone's nomail flag (set them to "ENABLED"). D'oh!.. > Barry, do you plan to change the option display in the membership list and/or > personal pages to something multivalued?... From dmick@utopia.West.Sun.COM Mon Dec 31 13:08:34 2001 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Mon, 31 Dec 2001 05:08:34 -0800 Subject: [Mailman-Developers] [Fwd: Bug in Bounce.py] Message-ID: <3C306352.6C16E478@utopia.west.sun.com> This is a multi-part message in MIME format. --------------40A491BE61F1F834BFBF76C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sent this to Barry late last night, but haven't seen a fix or a note here, so: in case anyone else is having the same problem: --------------40A491BE61F1F834BFBF76C3 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <3C2EFA28.BBB78AE2@utopia.west.sun.com> Date: Sun, 30 Dec 2001 03:27:36 -0800 From: Dan Mick X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bwarsaw@zope.com Subject: Bug in Bounce.py Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I don't know if this is the correct fix, but using the GUI to change bounce parameters has a problem without it: Index: Bounce.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Gui/Bounce.py,v retrieving revision 2.2 diff -r2.2 Bounce.py 119c119 < def convert(varname, func, mlist=mlist, cgidata=cgidata, doc=doc): --- > def convert(self, varname, func, mlist=mlist, cgidata=cgidata, doc=doc ): 126,130c126,130 < convert('bounce_processing', int) < convert('bounce_score_threshold', float) < convert('bounce_info_stale_after', to_days) < convert('bounce_you_are_disabled_warnings', int) < convert('bounce_you_are_disabled_warnings_interval', to_days) --- > convert(self, 'bounce_processing', int) > convert(self, 'bounce_score_threshold', float) > convert(self, 'bounce_info_stale_after', to_days) > convert(self, 'bounce_you_are_disabled_warnings', int) > convert(self, 'bounce_you_are_disabled_warnings_interval', to_days) --------------40A491BE61F1F834BFBF76C3-- From barry@zope.com Mon Dec 31 21:09:06 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 31 Dec 2001 16:09:06 -0500 Subject: [Mailman-Developers] [Fwd: Bug in Bounce.py] References: <3C306352.6C16E478@utopia.west.sun.com> Message-ID: <15408.54258.891280.738725@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Sent this to Barry late last night, but haven't seen a fix or DM> a note here, so: in case anyone else is having the same DM> problem: DM> I don't know if this is the correct fix, but using the GUI to DM> change bounce parameters has a problem without it: Ah yes. Python 2.2 has nested scopes turned on by default and I've been testing with that version lately. The code didn't go far enough to work around for Python 2.1. Try this patch (slightly simpler, but essentially the same as Dan's). Thanks! (still having trouble reproducing the other problem, but I'm going to try now with Python 2.1). -Barry -------------------- snip snip -------------------- Index: Bounce.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Gui/Bounce.py,v retrieving revision 2.2 diff -u -r2.2 Bounce.py --- Bounce.py 2001/12/27 07:06:39 2.2 +++ Bounce.py 2001/12/31 21:08:15 @@ -116,7 +116,8 @@ error(doc, varname, value) def HandleForm(self, mlist, cgidata, doc): - def convert(varname, func, mlist=mlist, cgidata=cgidata, doc=doc): + def convert(varname, func, + self=self, mlist=mlist, cgidata=cgidata, doc=doc): self.__convert(mlist, cgidata, varname, doc, func) def to_days(value): From barry@zope.com Mon Dec 31 21:29:21 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 31 Dec 2001 16:29:21 -0500 Subject: [Mailman-Developers] New Bounce system References: <3C2EFC1E.4DCE7C2F@utopia.west.sun.com> Message-ID: <15408.55473.621435.526360@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> looks interesting, but a warning: when you upgrade, all your DM> previous "nomails" will appear to revert to "off". Not DM> exactly what I expected. (the value is actually "UNKNOWN", DM> which still disables delivery...but it doesn't show up.) [...and later...] DM> Actually, it was worse; the upgrade just cleared everyone's DM> nomail flag (set them to "ENABLED"). D'oh!.. I'm having a hard time reproducing this, so I need more information. Exactly how did you do the upgrade? Which version of Python are you using? Do you see any errors in logs/error that might be relevant? Try using bin/dumpdb on both the (old) config.db value and the (new) config.pck value and check attributes like `data_version', and `delivery_status'. Below is the process I'm using to upgrade a list, see how that compares. I'm going to go ahead and release alpha4 today anyway, so I'm sure if this is a real problem we'll get lots of complaints ;}. DM> Barry, do you plan to change the option display in the DM> membership list and/or personal pages to something DM> multivalued?... In the personal options page, you'll just see some prose describing the reason your membership has been disabled. The user shouldn't care though, if they want to re-enable their membership it doesn't make a difference why they were disabled. I thought about it for the membership list admin pages, but I couldn't think of a good u/i that wouldn't clutter up that page even more. And I'm not sure it's worth it. If the admin enables, then re-disables a member's delivery, the flag will change from to BYADMIN. This could potentially disrupt disable warning notifications, but I don't think its worth cluttering up that page to deal with what ought to be a rare occurance (and besides, I'd eventually like cron/disabled to handle UNKNOWN, BYADMIN, and BYUSER disables). -Barry From barry@zope.com Mon Dec 31 23:58:41 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 31 Dec 2001 18:58:41 -0500 Subject: [Mailman-Developers] RELEASE Mailman 2.1 alpha 4 Message-ID: <15408.64433.621204.651734@anthem.wooz.org> Hi all, Just wanted to let you know that I've released Mailman 2.1 alpha 4. Below is the big list of changes with this release. This will be the last alpha release for 2.1, but this still leaves open the possibility of a few new features in MM2.1. I've got everything in that I intend to get in. If you've got a pet new feature -- and have code that implements it -- please do remind me about it now and I'll work on getting in what I can for the first beta. Apologies for falling so far behind in the mailing list traffic. This is admittedly a bit of a rushed release. I really wanted to get this out before the end of the year (in my timezone at least ;). Depending on my other real-job commitments, I'll be spending all my spare time getting bugs fixed and moving toward the 2.1 final release. I'm shooting for release by the Python conference in February, but I don't know if I'll make it. Cheers, and happy new year to you all. I-swear-the-X-Oblique-Strategy-was-chosen-random-ly y'rs, -Barry -------------------- snip snip -------------------- 2.1 alpha 4 (31-Dec-2001) - The administrative requests database page (admindb) has been redesigned for better usability when there are lots of held postings. Changes include: o A summary page which groups held messages by sender email address. On this page you can dispose of all the sender's messages in one action. You can also view the details of all the sender's messages, or the details of a single message. You can also add the sender to one of the list's sender filters. o A details page where you can view all messages, just those for a particular sender, or just a single held message. This details page is laid out the same as the old admindb page. o The instructions have been shorted on the summary and details page, with links to more detailed explanations. - Bounce processing o Mailman now keeps track of the reason a member's delivery has been disabled: explicitly by the administrator, explicitly by the user, by the system due to excessive bounces, or for (legacy) unknown reasons. o A new bounce processing algorithm has been implemented (we might actually understand this one ;). When an address starts bouncing, the member gets a "bounce score". Hard (fatal) bounces score 1.0, while soft (transient) bounces score 0.5. List administrators can specify a bounce threshold above which a member gets disabled. They can also specify a time interval after which, if no bounces are received from the member, the member's bounce score is considered stale and is thrown away. o A new cron script, cron/disabled, periodically sends notifications to members who are bounce disabled. After a certain number of warnings the member is deleted from the list. List administrators can control both the number of notifications and the amount of time between notifications. Notifications include a confirmation cookie that the member can use to re-enable their subscription, via email or web. o New configuration variables to support the bounce processing are DEFAULT_BOUNCE_SCORE_THRESHOLD, DEFAULT_BOUNCE_INFO_STALE_AFTER, DEFAULT_BOUNCE_YOU_ARE_DISABLED_WARNINGS, DEFAULT_BOUNCE_YOU_ARE_DISABLED_WARNINGS_INTERVAL. - Privacy and security o Sender filters can now be regular expressions. If a line starts with ^ it is taken as a (raw string) regular expression, otherwise it is a literal email address. o Fixes in 2.0.8 ported forward: prevent cross-site scripting exploits. - Mail delivery o Aliases have all been changed so that there's more consistency between the alias a message gets delivered to, and the script & queue runner that handles the message. I've also renamed the mail wrapper script to `mailman' from `wrapper' to avoid collisions with other MLM's. You /will/ need to regenerate your alias files with bin/genaliases, and you may need to update your smrsh (Sendmail) configs.a Bounces always go to listname-bounces now, since administration has been separated from bounce processing. listname-admin is obsolete. o VERP support! This greatly improves the accuracy of bounce detection. Configuration variables which control this feature include VERP_DELIVERY_INTERVAL, VERP_PERSONALIZED_DELIVERIES, VERP_PASSWORD_REMINDERS, VERP_REGEXP, and VERP_FORMAT. The latter two must be tuned to your MTA. o A new alias mailman-loop@dom.ain is added which directs all output to the file $prefix/data/owner-bounces.mbox. This is used when sending messages to the site list owners, as the final fallback for bouncing messages. o New configuration variable POSTFIX_STYLE_VIRTUAL_DOMAINS which should be set if you are using the Postfix MTA and want Mailman to play nice with Postfix-style virtual domains. - Miscellaneous o Better interoperability with Python 2.2. o MailList objects now record the date (in seconds since epoch) that they were created. This is in a hidden attribute `created_at'. o bin/qrunner grows a -s/--subproc switch which is usually used only when it's started from mailmanctl. o bin/newlist grows a -l/--language option so that the list's preferred language can be set from the command line. o cron changes: admin reminders go out at 8am local time instead of 10pm local time. - Pipermail archiver o MIME attachments are scrubbed out into separate files which can be viewed by following a link in the original article. Article contains an indication of the size of the attachment, its type, and other useful information. o New script bin/cleanarch which can be used to `clean' an .mbox archive file by fixing unescaped embedded Unix From_ lines. o New configuration variable ARCHIVE_SCRUBBER in Defaults.py.in which names the module that Pipermail should use to scrub articles of MIME attachments. o New configuration variable ARCHIVE_HTML_SANITIZER which describes how the scrubber should handle text/html attachments. o PUBLIC_ARCHIVE_URL has change its semantics. It is now an absolute url, with the hostname and listname parts interpolated into it on a per-list basis. o Pipermail should now provide the proper character set in the Content-Type: header for archived articles. - Internationalization o Czech translations by Dan Ohnesorg. o The Hungarian charset has be fixed to be iso-8859-2. o The member options login page now has a language selection widget. - Building, configuration o email-0.96 package is required (see the misc directory). o New recipes for integrating Mailman and Sendmail, contributed by David Champion.