Mailman 3 December 2000 - Mailman-Developers

Subject with Umlauts(üöä) in them
by Thomas Gross 22 Dec '00

22 Dec '00

Hi, i have noticed a Problem with German Umlauts and replying to emails. If i write an email which contains Umlauts in the subject mailman Archives it as something like this in the archive pages: [Nasen] =?iso-8859-1?Q?Re:_[Nasen]_Der_Sosolhiffeemfeng=E4?= this has been fixed with 2.0, the special Character are now displayed correctly on the archive pages. But another more annoying problem is still there. If i reply to such an email each replay gets another [<listname>] added. You can see this in the line above. On a busy mailinglist the subjects just explode. I have seen a bug report in the bugdatabase on sourceforge that is from september that could relay to this problem but cannot get to the full descriptions because sourceforge only gives me timeouts when i trie to get to the full report. Has anyone a fix for this? thanx thomas

1 0

Users, Bounces, and Virtual Domains (was (no subject))
by Dave Klingler 21 Dec '00

21 Dec '00

Hi folks. I've been lurking on this thread for a little while and I thought I might have something relevant to add. I'd normally send it to the users list but I thought it might lead to some useful discussion. I'm attempting to bring up several lists on one of my servers using virtfs. For those not familiar with virtfs, it's an easy way of using chroot to create several "virtual machines" on one server, each answering to its own IP address and each behaving like it's a standalone machine. In my installation, all of my "virtual" machines sit off on a big raid partition, so they look like /storage/virtual/domainA.com,/storage/virtual/domainB.net, and so on. The advantages are 1. It's easy to manage. I can pop into any machine whether or not it has shell access and move files around easily. I can also create a new domain from a template in under thirty seconds and start adding users and email accounts. 2. It's more secure. I'm moving everything to virtual domains because the chrooted virtual machines don't have to have any of the tools I'd normally need just to manage a machine, i.e. su, compilers, etc. If someone managed to gain root, it's still hard to get past the chrooted environment. 3. Email is really easy to manage, because instead of using sendmail's mechanism for multiple domains (sorta clumsy compared to the elegant mechanism in apache, for instance), I can just create recklessly and wickedly create users, willy nilly ha ha! Ignore that last indiscression. The disadvantages are: 1. It takes a little more storage. Each machine occupies a few megs of drive space. 2. Getting mailman up and running properly has tied my face in unsightly knots. So I'm an example of the situation that's come up hypothetically the last few days in the discussion of virtual domains. I'd love to be able to have a robust mailing list manager, with an MTA that will lovingly listen to any IP I choose, that will manage users across lists and domains opaquely to them and transparently to me. Alternately, I might want some day for them or me to be able to manage their own accounts across domains just the same way they might manage their own accounts in one domain. I want separate domains that behave as separate domains in their entirety because they're often easier to manage that way, and more secure. I want I want I want... If anyone wants to play, this is what I've done: 1. I set up several virtual domains on a separate storage server, with their own copies of sendmail called by a daemon that in turn is called by inetd that's part of the virtfs package. 2. I set up separate copies of mailman in each, and because they will be called/used by both apache (which doesn't use chroot) and sendmail (which does) I created a nice long symbolic link from a directory hung off the virtual root called /storage/virtual/domainA/home/mailman to the virtual /home/mailman directory. That way both apache and the chrooted sendmail can find their way to the mailman files, which have been set up with the --prefix= /storage/virtual/domainA/home/mailman option in configure. 3. I've spent many hours trying to figure out why it doesn't work this way. I need to go buy the O'Reilly Python book, I guess. Somehow mail to test-request(a)domainA.net gets black-holed with "operating system error" and I haven't figured out why. There you have it. I hope my concrete example of one of your hypothetical situations helps, and if anyone takes pity on me and figures out why I'm dysfunctional I'd be really grateful. Thanks! Dave Klingler

1 0

Archives not quite right
by Devon Sean McCullough 20 Dec '00

20 Dec '00

Perhaps your archives should be arranged by ENVELOPE date postmark i.e., the local RECEIVED: header, instead of the MESSAGE DATE header? ------- Start of forwarded message ------- Date: Wed, 20 Dec 2000 13:32:16 -0500 (EST) From: Devon Sean McCullough <devon(a)ai.mit.edu> To: webmaster(a)python.org Subject: http://mail.python.org/pipermail/mailman-users I see your archives go back to 1970 and forward to 2024 amazing! ------- End of forwarded message -------

1 0

Re: I want to learn python and help
by Ralph Corderoy 19 Dec '00

19 Dec '00

Hi, > I just finished the 'learning python' book a few monthes ago. I am > the kind to learn by doing. I would like to help out any way I can. > My day job is qa testing. Is there a simple coding project I could > learn on for you guys ? Is there a particuler way you need this to > be tested so I can learn how the code works? I just want to get my > hands dirty and become a good python coder. That's a co-incidence. I've been interested in Python for a few months and read the User and Reference guide back then. I've done nothing on it since apart from browsing comp.lang.python. Over Christmas, whilst staying at the in-laws, I was planning to read through the source of Mailman on the laptop. What I'm after is learning Python idioms and typical ways of structuring code with Python's packages. I know C and Unix inside out, plus many others languages like Ada, PostScript, Perl, and Fortran. Does the list think that Mailman is a good example of idiomatic Python code? I've assumed so given Barry's closeness to Guido. Thanks for any guidance, Ralph.

2 1

FW: I want to learn python and help
by Johnson, Chris 19 Dec '00

19 Dec '00

> Hello every one: > > I just finished the 'learning python' book a few monthes ago. I am the > kind to learn by doing. > > I would like to help out any way I can. My day job is qa testing. > > Is there a simple coding project I could learn on for you guys ? > > Is there a particuler way you need this to be tested so I can learn how > the code works? > > I just want to get my hands dirty and become a good python coder. > > Just let me know. I saw the wish list. > > > > > > > >

1 0

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 19 Dec '00

19 Dec '00

On Mon, 18 Dec 2000 20:37:57 -0800 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > At 4:57 PM -0800 12/18/00, J C Lawrence wrote: >> Gecause groups are a logical construct and may be both larger and >> smaller than virtual domains. > hmm. I'm just not convinced we need it. I see where you're headed, > but is it worth it? I dunno. In which case: Its easy to do/add now, but it will be an absolute bitch later. >> I had a tough time coming up with good examples. > that's usually a good indication of a solution in search of a > problem.. (giggle) >> (it was an open posting list). > I'm sorry, no sympathy. Open posting lists are like smelling gas > in the house, but waiting until Monday to call a plumber so you > don't pay weekend rates. It's a smart strategy, as long as it > works, but it stops working at a time not of your choosing, in a > way that's never good. I'm hardly compaining -- my anatomical impossibility folder gree quite a bit. -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

1 0

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 19 Dec '00

19 Dec '00

On Sun, 17 Dec 2000 22:56:50 -0800 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: >> Okay, let's split this out. There are five levels and a >> pseudonymous sixth: >> >> 1) Site owner -- SysAdm for the host 2) Group owner -- Sets group >> defaults > If the group owner manages a virtual site , why not call it that? Gecause groups are a logical construct and may be both larger and smaller than virtual domains. A group may consist of the lists assigned to a particular list owner, lists sharing a common topic, a virtual domain, or any other structure of divide you may care to consider. > If we want to get technical, you have the owner of the mailman > instance (since a given machine can have multple ones), the owner > of the virtual host (which may be the only user of the mailman, or > may share it), the list owner, the list moderator, and the list > user. I don't see any advantage to breaking it out into finer > gradiations, or generalizing the functionality beyond that. The idea of the above group concept is that groups could be used for virtual hosts, or any other grouping desired. It really doesn't matter. Consider Python.Org: All the python lists could share a group and therefore a set of common templates, CSS files etc for their own unique/shared configs. All the pythonic app lists could share another group, the SIG lists another group, etc. In my case I'd group lists into those run by me, and those run by others (ie not "offocial representatives of Me (tm)". >> The Group owner runs, say, a vhost and defines the default for a >> class of lists as well as handling creation of lists within that >> class. Vhosts are merely the simplest way of tagging the group concept so people can grab it and relate it to something they already know and understand. > Also UI and graphic definitions for the site, since each site is > going to wrap a different (do I dare use the term? I dare) skin > over mailman, and we need to make sure we support that properly. Quite. This would be done at the group level. >> -- Write an arbitrary note that is then associated with a member >> such that any moderator for that list will see that note when >> presented with data concerning that member (eg a post held for >> moderation). > you know, you just wandered down something I've played with in the > past but keep forgetting about (mostly, i want it while I'm > dealing with a problem, but not enough to create it the rest of > the time) -- the problem/case book. Needs to be list-specific for > privacy reasons, but there needs to be a way for admins to track > users and issues, and a generalized note-taking/history-keeping > function attached to a user_ID and a list would be great for > this. ("what do you mean you never start fights, last January, > you...") I've got some ideas there, mostly centered about tacking a CRM tool off the side, linked to the AccountID I discussed earlier. Entries in the CRM would be tagged with a ListID and would be flagged as public (can be viewed by other list moderators) or private to the ListID. This would exist in parallel to Mailman per se, linked only by a tag that some module inserts into the Mailman genned HTML... >> There are of course exceptions: >> >> I want to hand moderate all his posts from his work address >> because they auto-append legal cruft I want to delete. >> >> He only posts from Yahoo when he's drunk -- unsubscribe that >> address. > I expect these situations rare enough I wonder if it's worth even > considering in the design. I had a tough time coming up with good examples. Okay, better: "Hey moderator, yesterday was my last day at XXX and I forgot to unsubscribe. Sorry about that, but would you mind unsubscribing me? In the mean time I'm reading through my home address on the same account." > I'm trying to think the last time I might have used something like > this, and I can't think of one. they're a nice addition, but I > think it's solving a problem I'm not convinced shows up often > enough to worry about. Which? By email address or by account? > but the hotmail attack thing is an indication of just how complex > and gnarly email is on the net these days, because there really > isn't much of an easy way to stop something like > that. Fortunately, it's fairly rare. One of the programming lists I'm on just had someone take a hotmail account which they'd already subscribed to 20+ daily porn picture services, and set it to auto-forward to the list I'm on. Asides from the fact that there are some very able photoshop people out there who should have better things to do with their time, it was quite difficult finding the account to remove/block (it was an open posting list). -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

2 1

Patience please - admindb.py question
by Ken Kyler 18 Dec '00

18 Dec '00

When handling administrative requests for a list, the text of a message is displayed in TEXTAREA form elements. After looking through the code in admindb.py, it appears that any edits to the message are discarded. Correct? I'm just now starting to poke through the code. I'm just now starting to learn Python. I'll try to limit my dumb questions as much as possible. Is there a design document publicly available? Ken -- ken(a)kyler.com http://www.kyler.com

1 0

Random HTML archiving failures possibly solved
by Georg Mischler 18 Dec '00

18 Dec '00

Hi all, There have been a number of reports about the HTML archiving to fail misteriously, which were apparently impossible to reproduce for the experts. I think I have just found a bug in Mailbox.py from 2.0 that can cause this behaviour. Since I'm CVS challenged, I am unable check if it has already been fixed since then, but here it goes anyway. The pattern that checks for the unix style "From " lines fails when it encounters a negative timezone: _fromlinepattern = r'From \s*\S+\s+\w\w\w\s+\w\w\w\s+\d\d?\s+' \ r'\d\d?:\d\d(:\d\d)?(\s+\S+)?\s+\d\d\d\d\s*$' The consequence is, that when a mailbox file has a message from such a timezone at the beginning, then Mailman will think it contains no messages at all. A more robust approach (assuming that a plus sign in front of the timezone is also legal) would probably look similar to this: _fromlinepattern = r'From \s*\S+\s+\w\w\w\s+\w\w\w\s+\d\d?\s+' \ r'\d\d?:\d\d(:\d\d)?(\s+\S+)?\s+[+-]?\d\d\d\d\s*$' At least this fixes the problem on my system here... On another thought, wouldn't it be even better to use rfc822.parsedate_tz() here as well? I realize this implies some processing overhead, but I'd prefer robustness before the last two percent of increased performance. Have fun! -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch.com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

1 0

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 18 Dec '00

18 Dec '00

On Fri, 15 Dec 2000 20:39:19 -0800 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > At 2:52 PM -0800 12/15/00, J C Lawrence wrote: >> At the general level list owners/moderators deal with accounts, >> not email addresses. They set moderation controls etc on >> accounts. It is an account that subscribes to a list, resulting >> in every address on that account being a "member" etc. > I disagree with this. The way I see it is this: > -- Site admin: he has overall control of the mailman installation, > and manages the system. He has CLI access, and admin access to all > lists. Basically, he's god. > -- List admin: manages a list on the site. He controls > subscription policies and configuration setups for that list, > unless the site admin has locked a value (for instance, teh site > admin can lock reply-to coercion for a site-wide standard). > -- list moderator: handles message approval or denial. May be list > admin, but it's a separate function. you may not want a moderator > to ahve access to list configuration options. > -- list user: manages an individual account. > list admins don't deal with accounts, per se. They set list > defaults that are adopted by the user when they subscribe, and > whcih can be modified by the user, unless a list admin locks a > value (no digest, for instance). List admins have address > maintenance duties,but I think that's different than what you're > implying here. List admins dn't act on a user or account 9except > to fix something on request), the act on lists. Okay, let's split this out. There are five levels and a pseudonymous sixth: 1) Site owner -- SysAdm for the host 2) Group owner -- Sets group defaults 3) List owner -- Sets list defaults 4) List moderator -- Controls day-to-day operation of list 5) Member account -- Individual humans 6) Email address The site owner has CLI access etc. The Group owner runs, say, a vhost and defines the default for a class of lists as well as handling creation of lists within that class. The List owner configures and defines a given list. The list moderator implements the human side of enforcing list policy and handles the day to day chores of running a list (post approval etc). A member account subscribes to a given list with one or more of its email addresses, each of which has a configuration for that list which is unique to that email address. But, this is slightly confusing and deceptive. A list moderator in the course of their normal duties may do the following (among other things): -- Kick someone off a list -- State that all future posts from a given member will not be hand moderated -- State that the next N posts from a specific member will be hand moderated -- State that all future posts from a given member will not be hand moderated and will be automatically posted. -- Write an arbitrary note that is then associated with a member such that any moderator for that list will see that note when presented with data concerning that member (eg a post held for moderation). In each case what the list moderator sees in terms of the definition of the member, and what they define the above actions against, is an email address. They flag email address XXX as being hand moderated from here out. They do something else to email address YYY. My point however is that in the general case for these commands, the list owner is actually not interested in a specific email address, but in the account. When the moderator decides to auto-approve a specific account for autoposting, he generally is intending to approve the human and not just the one email address. Yes, that Chuq guy posts signal. Please auto-post everything he writes. That claw guy however is a dweeb and keeps argiung about stoopid things. I want to hand moderate all his posts from here on. While moderatator decisions are typically phrased in terms of email addresses, the actual intent is typically in terms of humans. There are of course exceptions: I want to hand moderate all his posts from his work address because they auto-append legal cruft I want to delete. He only posts from Yahoo when he's drunk -- unsubscribe that address. And a host of others. Of course account groupings (dealing by human above) can be approximated by just issueing enough commands for every intersection of an account and a list (should you know the intersections), but that's a royal pain. If I as moderator decide that Bubba is just a source of noice and really needs to be kicked from my list I want all of his addresses kicked, not just the one, and in fact I want my list config to remember that fact so that should Bubba try and re-join he's either auto-refused or his subscription is held for moderator approval (depsite the fact that everyone else gets let thru automatically). We need to be able to implement moderator rulings at both the address and account levels. This does not mean that a moderator should be able to query, "show me all the addresses that re part of account XXX", but that he should be able to issue a command which summates to: Do XXX to every intersection of the account that owns email address EEE and this list. Where XXX and EEE are arbitrary. >> Of course. We don't reveal that data to the list owner. However >> the decisions that the list owner makes in regard to a given >> address are applied to the account, not the address. > I'm not sure I agree. here's why. Let's go back to my "subscribe N > addresses to a list from account M", to allow them to be > configured differently. The relationship for the list is to the > email address, not the acccount, but the API has to have a > function that allows you to query whether this address is a valid > address. For privacy reasons, I don't think you hand over the > addresses that aren't subscribed, but instead, you hand off an > address and ask whether it can be allowed to post. I think you > create a data leak by linking to the account that you don't want > here, and you remove the ability to multiply subscribe to a list > -- and while there aren't a lot of people who do this, I *do* know > people who are subscribed both to messages and digests to lists, > and want that option. (I do, too, when I'm developing or testing > MLM stufff.....) While there is a data leak, yes, there isn't in the general case, and should that fact be of sufficient concern the admin command processing ionterface (which I'm looking at in exactly the same replaceable compnonent manner as members, and everything else) can be replaced with something that will *ONLY* process addresses (and which quite likely removes all concept of member accounts in the first place. My intent above is not to build a system that approaches a Grecian Ideal, but to build something that is maximally workable for both list members and list moderators, and which can be adapted towards local definitions of "ideal". >>> Second, it opens you up to mailforward attacks (create a hotmail >>> account. Sign up for 900 lists. Forward that account to someone >>> you hate. disappear). At least with validations, a user sees it >>> coming, and knowing they'll get warning, it'll only get used by >>> stupid users... >> I don't see this as our problem, simply because its not one we >> either have control over or can defend against. > It is, because we're the tool being used. By validating the > address when it's added to the list, you simplify the user > experience, make it easier on Mailman, and inhibit this attack > significantly because the luser will (we hope) know he'll get > flagged immediately and so not use us for the attack, and failing > that, the attack-ee will be warned early that something is > happening and hopefully be able to stop it before it hits hard. I'm not arguing against mailback validation. I consider that's actually a very good thing (as it demonstrates control of the address and some level of ackknowledgemnt of the change). I think we're talking across each other. There is nothing that can prevent the following: I create a hotmail account. I subscribe that hotmail account to 500 lists of various flavours. I now configure that hotmail account to auto-forward all received messages to <person_I_don't_like> There is nothing we can do about this because the forwarding decision is outside of our control or purview. The subscriptions were perfectly legitimate from our stance -- they were acknowledged and everything. Its the forwarding decision that was bad, and that we had nothing to do with. For those interested the reverse vector of this just happened to a list I'm on. Some fine fellow got a Hotmail account, subscribed it to several dozen porn lists and then forwarded that account to the list I was on (which had open posting). We can't stop it. We can't eevn impede it other than by applying standard authentication rules to incoming posts (envelope, From:, whatever). -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

3 2

Mailman-Developers December 2000