From bootc@worldnet.fr Sun Apr 1 12:11:19 2001 From: bootc@worldnet.fr (Chris Boot) Date: Sun, 01 Apr 2001 13:11:19 +0200 Subject: [Mailman-Developers] Contribution: Procmail mail filter format Message-ID: Hi, I installed Mailman on my system yesterday--a very nice piece of code! I have an account on a host which gives me a virtual e-mail address, as in everything that goes to @my.domain.com is forwarded to my account, and I can't just add things to /etc/aliases, or the whole system would go belly up (I don't even have privs to anything in /etc). So what I use to sort through mail is Procmail, which works very nicely. I got Mailman to run in this one-user setup using Procmail quite simply. What I've done is added some code to bin/newlist which will generate the Procmail filtering rules for me. I'm not sure how to submit my changes, but here they are. I did these changes on a pretty vanilla Mailman-2.0.3 distribution. First, the definition of the alias style: PROCMAIL_ALIAS_STYLE = """ :0 * $^To:.*%(listname)s | %(wrapper)s post %(listname)s :0 * $^To:.*%(listname)s+(-owner|-admin) | %(wrapper)s mailowner %(listname)s :0 * $^To:.*%(listname)s-request | %(wrapper)s mailcmd %(listname)s """ And now checking the config for the procmail identifier: elif style == 'procmail': ALIASTEMPLATE = PROCMAIL_ALIAS_STYLE STDOURMSG = 'To create list aliases, add this to your procmailrc:' All you need to do is set the MTA style to 'procmail' and it will generate the Procmail filter rules. I did all of this with no previous knowledge of Python whatsoever, so there probably are some mistakes, despite the small size of this code... Thanks for Mailman. Now I'm paying back. ;-) -- Chris Boot bootc@worldnet.fr "Modem error handling really su~c%dk,s.^D^D&x@R*cCKo#?CB,*o#?C!!b %o#? NO CARRIER From claw@kanga.nu Sun Apr 1 19:18:47 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 01 Apr 2001 11:18:47 -0700 Subject: [Mailman-Developers] Contribution: Procmail mail filter format In-Reply-To: Message from Chris Boot of "Sun, 01 Apr 2001 13:11:19 +0200." References: Message-ID: <15393.986149127@kanga.nu> On Sun, 01 Apr 2001 13:11:19 +0200 Chris Boot wrote: > What I've done is added some code to bin/newlist which will > generate the Procmail filtering rules for me. I'm not sure how to > submit my changes, but here they are. I did these changes on a > pretty vanilla Mailman-2.0.3 distribution. Your procmail rules miss two interesting cases: messages CC'ed or BCC to the list. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From bootc@worldnet.fr Sun Apr 1 20:05:26 2001 From: bootc@worldnet.fr (Chris Boot) Date: Sun, 01 Apr 2001 21:05:26 +0200 Subject: [Mailman-Developers] Contribution: Procmail mail filter format In-Reply-To: <15393.986149127@kanga.nu> Message-ID: > On Sun, 01 Apr 2001 13:11:19 +0200 > Chris Boot wrote: >=20 >> What I've done is added some code to bin/newlist which will >> generate the Procmail filtering rules for me. I'm not sure how to >> submit my changes, but here they are. I did these changes on a >> pretty vanilla Mailman-2.0.3 distribution. >=20 > Your procmail rules miss two interesting cases: messages CC'ed or > BCC to the list. Ah, yes, you're right. I don't know how you can take care of BCC's (they'r= e _meant_ to be hidden, aren't they?), but here's the fix for the CC problem: PROCMAIL_ALIAS_STYLE =3D """ :0 * $^TO_%(listname)s | %(wrapper)s post %(listname)s :0 * $^TO_%(listname)s+(-owner|-admin) | %(wrapper)s mailowner %(listname)s :0=20 * $^TO_%(listname)s-request | %(wrapper)s mailcmd %(listname)s """ The TO_ is a built-in Procmail rule which expands to: (=96((Original-)?(Resent-)?(To|Cc|Bcc)| (X-Envelope|Apparently(-Resent)?)-To):(.*[=96-a-zA-Z0-9_.])?) --=20 Chris Boot bootc@worldnet.fr All your base are belong to us! From ralph@inputplus.demon.co.uk Sun Apr 1 21:18:49 2001 From: ralph@inputplus.demon.co.uk (Ralph Corderoy) Date: Sun, 01 Apr 2001 21:18:49 +0100 Subject: [Mailman-Developers] Problem with mailman-2.1a1, syntax error in bin/update : print >> sys.stderr ... In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 28 Mar 2001 21:45:08 CDT." <15042.41396.797377.993500@anthem.wooz.org> Message-ID: <200104012018.VAA23498@inputplus.demon.co.uk> Hi Barry, > I'm not even sure what "make altinstall" does. ;) These error sure > point to Mailman finding an earlier version of Python than 2.0. Couldn't some of the make targets check that the version of Python available is sufficiently recent? This seems to crop up a lot as Mailman is using recent Python features. Ralph. From barry@digicool.com Sun Apr 1 21:30:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 1 Apr 2001 16:30:31 -0400 Subject: [Mailman-Developers] Problem with mailman-2.1a1, syntax error in bin/update : print >> sys.stderr ... References: <15042.41396.797377.993500@anthem.wooz.org> <200104012018.VAA23498@inputplus.demon.co.uk> Message-ID: <15047.36839.404427.802619@anthem.wooz.org> >>>>> "RC" == Ralph Corderoy writes: >> I'm not even sure what "make altinstall" does. ;) These error >> sure point to Mailman finding an earlier version of Python than >> 2.0. RC> Couldn't some of the make targets check that the version of RC> Python available is sufficiently recent? This seems to crop RC> up a lot as Mailman is using recent Python features. The configure script is supposed to enforce this, but it hadn't been updated. I've just checked in the fix for this. -Barry From claw@kanga.nu Sun Apr 1 21:51:31 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 01 Apr 2001 13:51:31 -0700 Subject: [Mailman-Developers] Contribution: Procmail mail filter format In-Reply-To: Message from Chris Boot of "Sun, 01 Apr 2001 21:05:26 +0200." References: Message-ID: <21197.986158291@kanga.nu> On Sun, 01 Apr 2001 21:05:26 +0200 Chris Boot wrote: > Ah, yes, you're right. I don't know how you can take care of > BCC's (they're _meant_ to be hidden, aren't they?), but here's the > fix for the CC problem: The way to track BCC's (given that you have everything running to a common mailbox) is to have an MTA further up the pipe record the destination address (ie original RCPT_TO value) in one of the headers so that you can then filter off that (this may already be happening). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From jj-list@mail.dk Sun Apr 1 22:08:15 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Sun, 01 Apr 2001 23:08:15 +0200 Subject: [Mailman-Developers] Sender field Message-ID: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> Why is the 'sender' header field set to the list admin address? E.g.: Sender: mailman-developers-admin@python.org I'm asking because I haven't seen this elsewhere. Elsewhere being LISTSERV and eGroups. I probably wouldn't have noticed if it wasn't because Outlook 2000 (maybe other versions) shows this information as the 'from' address in the preview pane separator. This is probably a flaw in Outlook - I don't know - maybe it's on purpose. The "correct" 'from' address is shown elsewhere in the program. Anyway, back to my question, is Mailman doing this to conform with some rfc, or would it be safe to either remove the 'sender' header field og simply insert the "correct" 'from' address instead? All the best, Jesper. From claw@kanga.nu Sun Apr 1 22:54:43 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 01 Apr 2001 14:54:43 -0700 Subject: [Mailman-Developers] Sender field In-Reply-To: Message from Jesper Jensen of "Sun, 01 Apr 2001 23:08:15 +0200." <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> Message-ID: <17744.986162083@kanga.nu> On Sun, 01 Apr 2001 23:08:15 +0200 Jesper Jensen wrote: > Why is the 'sender' header field set to the list admin address? > E.g.: Sender: mailman-developers-admin@python.org I'd imagine its to better handle bounces from broken MTAs. > I probably wouldn't have noticed if it wasn't because Outlook 2000 > (maybe other versions) shows this information as the 'from' > address in the preview pane separator. This is probably a flaw in > Outlook... Minimally it is Broken As Designed -- a characteristic we've all beome very familiar with with Outlook. > Anyway, back to my question, is Mailman doing this to conform with > some rfc, or would it be safe to either remove the 'sender' header > field og simply insert the "correct" 'from' address instead? I'm not aware of an RFC mandate which covers this area. That said its worth realising that Sender is an unreliable header and may be re-written by the first MTA (depends on how the message was delivered). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From barry@digicool.com Mon Apr 2 03:30:44 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 1 Apr 2001 22:30:44 -0400 Subject: [Mailman-Developers] Sender field References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> <17744.986162083@kanga.nu> Message-ID: <15047.58452.802942.133727@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> Anyway, back to my question, is Mailman doing this to conform >> with some rfc, or would it be safe to either remove the >> 'sender' header field og simply insert the "correct" 'from' >> address instead? JCL> I'm not aware of an RFC mandate which covers this area. That JCL> said its worth realising that Sender is an unreliable header JCL> and may be re-written by the first MTA (depends on how the JCL> message was delivered). RFC 822, section 4.4.2 says: 4.4.2. SENDER / RESENT-SENDER This field contains the authenticated identity of the AGENT (person, system or process) that sends the message. It is intended for use when the sender is not the author of the mes- sage, or to indicate who among a group of authors actually sent the message. If the contents of the "Sender" field would be completely redundant with the "From" field, then the "Sender" field need not be present and its use is discouraged (though still legal). In particular, the "Sender" field MUST be present if it is NOT the same as the "From" Field. The Sender mailbox specification includes a word sequence which must correspond to a specific agent (i.e., a human user or a computer program) rather than a standard address. This indicates the expectation that the field will identify the single AGENT (person, system, or process) responsible for sending the mail and not simply include the name of a mailbox from which the mail was sent. For example in the case of a shared login name, the name, by itself, would not be adequate. The local-part address unit, which refers to this agent, is expected to be a computer system term, and not (for example) a generalized person reference which can be used outside the network text message context. August 13, 1982 - 21 - RFC #822 Standard for ARPA Internet Text Messages Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer pro- gram generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mail- box specification. My interpretation of this section is that since regular deliveries use the From: field supplied by the original author, but it is Mailman's responsibility for sending the mail through the system, the Sender: field ought to be the human responsible for list maintenance, e.g. list-owner or list-admin. It has proved to be more practical to point Sender: at list-admin so that bounce processing can take first crack at the message, sending it on to the list moderators if that fails. -Barry From jra@baylink.com Mon Apr 2 05:15:55 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 2 Apr 2001 00:15:55 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: <15047.58452.802942.133727@anthem.wooz.org>; from "Barry A. Warsaw" on Sun, Apr 01, 2001 at 10:30:44PM -0400 References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> <17744.986162083@kanga.nu> <15047.58452.802942.133727@anthem.wooz.org> Message-ID: <20010402001555.10352@scfn.thpl.lib.fl.us> On Sun, Apr 01, 2001 at 10:30:44PM -0400, Barry A. Warsaw wrote: > My interpretation of this section is that since regular deliveries use > the From: field supplied by the original author, but it is Mailman's > responsibility for sending the mail through the system, the Sender: > field ought to be the human responsible for list maintenance, > e.g. list-owner or list-admin. It has proved to be more practical to > point Sender: at list-admin so that bounce processing can take first > crack at the message, sending it on to the list moderators if that > fails. I concur entirely, both with your interpretation, and your implementation. For whatever *that's* worth. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Mon Apr 2 06:38:11 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 01:38:11 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? References: <3AC4D141.D3ED6A84@nleaudio.com> Message-ID: <15048.4163.987252.660652@anthem.wooz.org> I've just finished implementing a more general confirmation scheme for Mailman 2.1. There are two aspects to this. When an operation requiring confirmation is performed, a confirmation email message is sent as before. However, the confirmation message will include both a confirming email command and a URL with a unique cookie, and the operation can be performed either by replying to the message or visiting the specified URL. Currently only two confirmable operations are defined: subscribing and removing. The above works regardless of e.g. whether the removal request is coming from cgi or from an email command. This means a user can send the message "unsubscribe" to mylist-request with no address and no password, and they will receive a confirmation message. A reply to that message, or a hit on the URL will remove the user. (Note that if the user actually knows their password, they can include it in the web page or email command for immediate removal.) (Note also that the architecture is general enough that other confirmable operations could be added in the future.) While this isn't exactly password-less accounts, I think it accomplishes basically the same intent. And it strikes a good balance between convenience and security. It means in practice that a user can get removed from a list without having to remember their password (or how to get it!), and the two-step removal in that case isn't too onerous (since most MUAs I suspect would let them click directly on the URL in the mail message). Acks go to Les Niles who implemented a rough cut at this. My implementation was different, but similar in spirit. -Barry From jra@baylink.com Mon Apr 2 06:46:27 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 2 Apr 2001 01:46:27 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? In-Reply-To: <15048.4163.987252.660652@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Apr 02, 2001 at 01:38:11AM -0400 References: <3AC4D141.D3ED6A84@nleaudio.com> <15048.4163.987252.660652@anthem.wooz.org> Message-ID: <20010402014627.21738@scfn.thpl.lib.fl.us> On Mon, Apr 02, 2001 at 01:38:11AM -0400, Barry A. Warsaw wrote: > While this isn't exactly password-less accounts, I think it > accomplishes basically the same intent. And it strikes a good balance > between convenience and security. It means in practice that a user > can get removed from a list without having to remember their password > (or how to get it!), and the two-step removal in that case isn't too > onerous (since most MUAs I suspect would let them click directly on > the URL in the mail message). Two edged sword. I'm trying to remember whose message it is, Slashdot's, I think, that says "don't get your panties in a twist because we included your password in clear". This completely fails to take into account the "I use the same password many places" people. Getting the passwords out of the mail is a good thing... but mail is *still* sniffable. Depends how much security you want people to have... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Mon Apr 2 07:14:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 02:14:30 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? References: <3AC4D141.D3ED6A84@nleaudio.com> <15048.4163.987252.660652@anthem.wooz.org> <20010402014627.21738@scfn.thpl.lib.fl.us> Message-ID: <15048.6342.401162.637705@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Two edged sword. JRA> I'm trying to remember whose message it is, Slashdot's, I JRA> think, that says "don't get your panties in a twist because JRA> we included your password in clear". JRA> This completely fails to take into account the "I use the JRA> same password many places" people. JRA> Getting the passwords out of the mail is a good thing... but JRA> mail is *still* sniffable. Depends how much security you JRA> want people to have... The last step (to be added /eventually/) is to allow users to suppress password containing emails unless they specifically hit "Email My Password To Me". This means 1) allowing them to inhibit monthly reminders on a per-user basis; 2) allowing them to suppress the password in the welcome message; 3) adding confirmation emails for things like changing their options. Shouldn't be hard to do, just takes time. Still, we /tell/ users not to use important passwords for their Mailman accounts, but I understand the Pinball Machine Rule[1] applies here. -Barry [1] The PMR is the observation that it doesn't matter a wit if the instructions are printed clearly for all to see, nobody will read them. They'll just drop their quarter(s) and start pushing buttons like a Tommy. From jra@baylink.com Mon Apr 2 15:30:14 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 2 Apr 2001 10:30:14 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? In-Reply-To: <15048.6342.401162.637705@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Apr 02, 2001 at 02:14:30AM -0400 References: <3AC4D141.D3ED6A84@nleaudio.com> <15048.4163.987252.660652@anthem.wooz.org> <20010402014627.21738@scfn.thpl.lib.fl.us> <15048.6342.401162.637705@anthem.wooz.org> Message-ID: <20010402103014.04269@scfn.thpl.lib.fl.us> [Filtered back to -devel] On Mon, Apr 02, 2001 at 02:14:30AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > > JRA> Two edged sword. > > JRA> I'm trying to remember whose message it is, Slashdot's, I > JRA> think, that says "don't get your panties in a twist because > JRA> we included your password in clear". > > JRA> This completely fails to take into account the "I use the > JRA> same password many places" people. > > JRA> Getting the passwords out of the mail is a good thing... but > JRA> mail is *still* sniffable. Depends how much security you > JRA> want people to have... > > The last step (to be added /eventually/) is to allow users to suppress > password containing emails unless they specifically hit "Email My > Password To Me". This means 1) allowing them to inhibit monthly > reminders on a per-user basis; 2) allowing them to suppress the > password in the welcome message; 3) adding confirmation emails for > things like changing their options. > > Shouldn't be hard to do, just takes time. My favorite approach was always "ask the user for a challenge question that describes their password *to them*, in addition to the password, and then send them *that* if they can't remember it". > Still, we /tell/ users not to use important passwords for their > Mailman accounts, but I understand the Pinball Machine Rule[1] applies > here. > > [1] The PMR is the observation that it doesn't matter a wit if the > instructions are printed clearly for all to see, nobody will read > them. They'll just drop their quarter(s) and start pushing buttons > like a Tommy. Classic. Whence cometh that one? If there's enough reference for it in the Real World, I'll be Submitting It To Eric. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jj-list@mail.dk Mon Apr 2 21:31:20 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Mon, 02 Apr 2001 22:31:20 +0200 Subject: [Mailman-Developers] Sender field In-Reply-To: <15047.58452.802942.133727@anthem.wooz.org> References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> <17744.986162083@kanga.nu> Message-ID: <5.0.2.1.0.20010402213457.0378a008@pop3.mail.dk> Barry A. Warsaw wrote: >My interpretation of this section is that since regular deliveries use >the From: field supplied by the original author, but it is Mailman's >responsibility for sending the mail through the system, the Sender: >field ought to be the human responsible for list maintenance, >e.g. list-owner or list-admin. It has proved to be more practical to >point Sender: at list-admin so that bounce processing can take first >crack at the message, sending it on to the list moderators if that >fails. Thanks, very helpful. Jesper. From marc_news@valinux.com Tue Apr 3 00:10:42 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 2 Apr 2001 16:10:42 -0700 Subject: [Mailman-Developers] patch to remove_member for mass unsubscribes Message-ID: <20010402161042.J29491@magic.merlins.org> I submitted: https://sourceforge.net/tracker/index.php?func=detail&aid=413257&group_id=103&atid=300103 Basically it adds a special list name: _alllists_ which does this: usw-sf-list1:/var/local/mailman/bin# time ./remove_members -f /tmp/badmails _alllists_ User `gb@viscomvisual.com' removed from list `berlin-fresco' User `jprice@chiinc.com' removed from list `foxgui-announce' User `bmcgroarty@high-voltage.com' removed from list `freenet-announce' User `Wilhelm.Pastoors@vetmed.uni-giessen.de' removed from list `gump-develop' User `oscu@sina.com' removed from list `linux-usb-devel' User `mehdi-laurent.akkar@fr.delarue.com' removed from list `madchat-annonces' User `ras@colltech.com' removed from list `sendpage-devel' User `mkimball@pdi.com' removed from list `utah-glx-cvs' User `mkimball@pdi.com' removed from list `utah-glx-dev' User `mkimball@pdi.com' removed from list `utah-glx-users' User `brianp@pdi.com' removed from list `vacm-develop' User `guido@comlog.nl' removed from list `wxwindows-users' User `frekytah@jono.com' removed from list `solar-empire-developer' User `dan@dar.net' removed from list `xemacs-winnt' real 7m26.294s user 1m9.120s sys 1m10.640s It ran in 7mn on 10,000+ lists, which ain't that bad considering. Hopefully it will make it in the next mailman. Enjoy, 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 barry@digicool.com Tue Apr 3 03:30:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 22:30:35 -0400 Subject: [Mailman-Developers] Headers and footers for MIME messages References: <15042.46824.976889.309145@anthem.wooz.org> <20010330022005.4687128593@wawura.off.connect.com.au> Message-ID: <15049.13771.337011.738446@anthem.wooz.org> >>>>> "AM" == Andrew McNamara writes: AM> You'll soon end up with a complex language for specifying AM> things like "accept binary attachments only if preceeded by a AM> text/plain", etc.. 8-) Ug. It's probably inevitable, but I really don't want Mailman to become a hypergeneralized MIME slicer-n-dicer. AM> BTW, I think there's a special mime type for headers and AM> footers - text/plain isn't the right one. Can't remember off AM> the top of my head. I'm not aware of it, so I'd appreciate pointers. Maybe you're thinking of multipart/digest or message/* types? Neither is exactly appropriate in this context. AM> The safest rules would be: AM> - if it's not a mime message, do the old thing. Agreed. AM> - if it's AM> mime, and it's not already a multipart/mixed, create a AM> text/multipart with header/original mime/footer. I think you mean "create a multipart/mixed with 3 subparts, the header, the original article, and the footer". AM> - it it's AM> mime, and and multipart/mixed, simply insert and append the AM> header and footer parts. Agreed. My main objective is above all "to do no harm", so for now, I'm going to adopt these rules: - if it's not MIME or it's text/plain, do the old thing - if it's multipart/mixed, add the header and footers as additional subparts - anything else, pass the message through unchanged We can elaborate on that last one later if necessary. -Barry From Dan Mick Tue Apr 3 03:45:07 2001 From: Dan Mick (Dan Mick) Date: Mon, 2 Apr 2001 19:45:07 -0700 (PDT) Subject: [Mailman-Developers] Mailman 2.1.x Message-ID: <200104030242.TAA10724@utopia.West.Sun.COM> Any opinions on its stability? I'm setting up a new server, and am contemplating starting off with 2.1. Is it ready for prime-ish time (I can investigate and resolve some problems) yet? I'm also considering taking the Postfix plunge at the same time. I probably need mental help. :) From andrewm@connect.com.au Tue Apr 3 04:04:57 2001 From: andrewm@connect.com.au (Andrew McNamara) Date: Tue, 03 Apr 2001 13:04:57 +1000 Subject: [Mailman-Developers] Headers and footers for MIME messages In-Reply-To: Your message of "Mon, 02 Apr 2001 22:30:35 -0400." <15049.13771.337011.738446@anthem.wooz.org> Message-ID: <20010403030457.CF182285B9@wawura.off.connect.com.au> >Ug. It's probably inevitable, but I really don't want Mailman to >become a hypergeneralized MIME slicer-n-dicer. Yes - I think it's sort of inevitable. If you structure your MIME parser correctly, it may be relatively painless. BTW, you should look at the perl MIME module (as used by Majordomo 2) - I understand that it's one of the best MIME interfaces around (although reading other people's perl is futile, it's interface doco might suggest some ideas for your code). > AM> BTW, I think there's a special mime type for headers and > AM> footers - text/plain isn't the right one. Can't remember off > AM> the top of my head. > >I'm not aware of it, so I'd appreciate pointers. Maybe you're >thinking of multipart/digest or message/* types? Neither is exactly >appropriate in this context. I had a quick look when I posted, but couldn't find it. I think I was probably thinking of the multipart/digest and message/* stuff, as you suggest. > AM> - if it's > AM> mime, and it's not already a multipart/mixed, create a > AM> text/multipart with header/original mime/footer. > >I think you mean "create a multipart/mixed with 3 subparts, the >header, the original article, and the footer". Yes - wrap the original mime message in a new multipart/mixed with 3 subparts. Mime is intended to be a hierarchy, so this is safe. It will also be a good test for your Python MIME code - if it's going to cope with the random crap that people mail around, it shouldn't have much trouble producing this. Personally, I find MIME problematic - the basic idea was okay, but when people start nesting objects several levels deep the utility starts to disappear. Also, it assumes that SMTP is a file transport protocol, which it isn't (if it was, it would support restarting failed transfers). I also turn it off in my MUA (exmh) as it slows it down considerably. >My main objective is above all "to do no harm", so for now, I'm going >to adopt these rules: Yes. > - if it's not MIME or it's text/plain, do the old thing > > - if it's multipart/mixed, add the header and footers as > additional subparts > > - anything else, pass the message through unchanged > >We can elaborate on that last one later if necessary. Yes. --- Andrew McNamara (System Architect) connect.com.au Pty Ltd Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia Phone: +61 2 9409 2117, Fax: +61 2 9409 2111 From barry@digicool.com Tue Apr 3 04:02:11 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 23:02:11 -0400 Subject: [Mailman-Developers] Mailman 2.1.x References: <200104030242.TAA10724@utopia.West.Sun.COM> Message-ID: <15049.15667.746981.261424@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Any opinions on its stability? I'm setting up a new server, DM> and am contemplating starting off with 2.1. Is it ready for DM> prime-ish time (I can investigate and resolve some problems) DM> yet? I'm relatively comfortable with its stability in terms of getting mail through the system, although I am not using it for anything except internal testing right now. I haven't even foisted it on my fellow Pythonlabbers yet. And don't worry, you guys will be my first real litter of guinea pigs. :) I'm less comfortable with all the file formats, schemas and APIs I've chosen. E.g. the new pending.db format has already changed and, as befits alpha software, I reserve the right to change formats in incompatible and non-upgradable ways. I will of course, guarantee that you can upgrade from 2.0.3 to 2.1, but not in between any of the alphas. Part of the responsibility of going to beta is to freeze those kinds of things (barring catastrophic showstopping bugs that can't be fixed any other way). If you're comfortable with that, I'd be thrilled with you giving 2.1 a spin for real. DM> I'm also considering taking the Postfix plunge at the same DM> time. I probably need mental help. :) doctor-it-hurts-when-i-do-this-ly y'rs, -Barry From barry@digicool.com Tue Apr 3 04:09:04 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 23:09:04 -0400 Subject: [Mailman-Developers] Headers and footers for MIME messages References: <15049.13771.337011.738446@anthem.wooz.org> <20010403030457.CF182285B9@wawura.off.connect.com.au> Message-ID: <15049.16080.297011.684831@anthem.wooz.org> >>>>> "AM" == Andrew McNamara writes: >> Ug. It's probably inevitable, but I really don't want Mailman >> to become a hypergeneralized MIME slicer-n-dicer. AM> Yes - I think it's sort of inevitable. If you structure your AM> MIME parser correctly, it may be relatively painless. I think mimelib is pretty good, certainly better than anything else I've seen for Python. I've got some nits about its interface, which I'll need to clean up for any 1.0 release (or for inclusion in Python, and I know Guido has some nits). AM> BTW, you should look at the perl MIME module (as used by AM> Majordomo 2) - I understand that it's one of the best MIME AM> interfaces around (although reading other people's perl is AM> futile, it's interface doco might suggest some ideas for your AM> code). Do you have a reference? I gave up Perl almost 7 years ago, so I know I couldn't read it, but if the interface spec is online, I'd love to take a look. AM> It will also be a good test for your Python MIME code - if AM> it's going to cope with the random crap that people mail AM> around, it shouldn't have much trouble producing this. It's actually fairly easy with mimelib. AM> Personally, I find MIME problematic - the basic idea was okay, AM> but when people start nesting objects several levels deep the AM> utility starts to disappear. Also, it assumes that SMTP is a AM> file transport protocol, which it isn't (if it was, it would AM> support restarting failed transfers). I also turn it off in my AM> MUA (exmh) as it slows it down considerably. I agree. Also, I've find that generating MIME correctly really requires holding the entire message hierarchy in memory and making several passes over the generated text before you can really start outputing correctly. That sucks too. Thanks for the feedback. -Barry From andrewm@connect.com.au Tue Apr 3 04:38:58 2001 From: andrewm@connect.com.au (Andrew McNamara) Date: Tue, 03 Apr 2001 13:38:58 +1000 Subject: [Mailman-Developers] Headers and footers for MIME messages In-Reply-To: Your message of "Mon, 02 Apr 2001 23:09:04 -0400." <15049.16080.297011.684831@anthem.wooz.org> Message-ID: <20010403033858.51D30285BC@wawura.off.connect.com.au> >I think mimelib is pretty good, certainly better than anything else >I've seen for Python. I've got some nits about its interface, which >I'll need to clean up for any 1.0 release (or for inclusion in Python, >and I know Guido has some nits). I had a quick look a few weeks back - my impression was that it didn't entirely embrace the OO'edness, although it can be a big mistake to go too far with objects anyway, and I can't provide any sensible comments on what you could do to make it more abstract (armchair critic). If it works, that's the most important goal. 8-) >Do you have a reference? I gave up Perl almost 7 years ago, so I >know I couldn't read it, but if the interface spec is online, I'd love >to take a look. It's the MIME::Tools module on cpan, I think this is the author's site (and it includes online class doco): http://www.zeegee.com/code/perl/MIME-tools/ They also have a MIME::Lite. >I agree. Also, I've find that generating MIME correctly really >requires holding the entire message hierarchy in memory and making >several passes over the generated text before you can really start >outputing correctly. That sucks too. This is definitely the biggest shortcoming with MIME - for things like MTA's, there's a certain amount of presure to include MIME support (encoding 8-bit messages when they encounter a 7 bit path, DSN, etc), but the performance implications just suck too hard. --- Andrew McNamara (System Architect) connect.com.au Pty Ltd Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia Phone: +61 2 9409 2117, Fax: +61 2 9409 2111 From jra@baylink.com Tue Apr 3 06:05:06 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 3 Apr 2001 01:05:06 -0400 Subject: [Mailman-Developers] Headers and footers for MIME messages In-Reply-To: <20010403030457.CF182285B9@wawura.off.connect.com.au>; from Andrew McNamara on Tue, Apr 03, 2001 at 01:04:57PM +1000 References: <15049.13771.337011.738446@anthem.wooz.org> <20010403030457.CF182285B9@wawura.off.connect.com.au> Message-ID: <20010403010506.01340@scfn.thpl.lib.fl.us> On Tue, Apr 03, 2001 at 01:04:57PM +1000, Andrew McNamara wrote: > BTW, you should look at the perl MIME module (as used by Majordomo 2) - > I understand that it's one of the best MIME interfaces around (although > reading other people's perl is futile, it's interface doco might > suggest some ideas for your code). But, Andrew... didn't you read the press release? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From ralph@inputplus.demon.co.uk Tue Apr 3 11:09:44 2001 From: ralph@inputplus.demon.co.uk (Ralph Corderoy) Date: Tue, 03 Apr 2001 11:09:44 +0100 Subject: [Mailman-Developers] patch to remove_member for mass unsubscribes In-Reply-To: Message from Marc MERLIN of "Mon, 02 Apr 2001 16:10:42 PDT." <20010402161042.J29491@magic.merlins.org> Message-ID: <200104031009.LAA05329@inputplus.demon.co.uk> Hi, > Basically it adds a special list name: _alllists_ which does this: > > # time ./remove_members -f /tmp/badmails _alllists_ Perhaps an -option would be better than special-casing a list name. Ralph. From marc_news@valinux.com Tue Apr 3 22:46:08 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 3 Apr 2001 14:46:08 -0700 Subject: [Mailman-Developers] patch to remove_member for mass unsubscribes In-Reply-To: <200104031009.LAA05329@inputplus.demon.co.uk>; from ralph@inputplus.demon.co.uk on Tue, Apr 03, 2001 at 11:09:44AM +0100 References: <200104031009.LAA05329@inputplus.demon.co.uk> Message-ID: <20010403144608.X29491@magic.merlins.org> On Tue, Apr 03, 2001 at 11:09:44AM +0100, Ralph Corderoy wrote: > > Hi, > > > Basically it adds a special list name: _alllists_ which does this: > > > > # time ./remove_members -f /tmp/badmails _alllists_ > > Perhaps an -option would be better than special-casing a list name. I thought about it, but it breaks the option parsing a bit since remove_members kind of expects a list name. Not that it can't be fixed, mind you, but having a list name required depending on whether a flag was there or not seemed a bit ackward. That said, it's trivial to change, and as long as the functionality makes it into the main distribution, how the arguments are parsed doesn't really matter to me, Barry or however considers merging this in is welcome to change the parsing logic and I don't think they need a patch from me to do this :-) 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 bedmonds@antarcti.ca Wed Apr 4 18:09:23 2001 From: bedmonds@antarcti.ca (Brian Edmonds) Date: Wed, 4 Apr 2001 10:09:23 -0700 (PDT) Subject: [Mailman-Developers] Re: patch to remove_member for mass unsubscribes References: <200104031009.LAA05329@inputplus.demon.co.uk> <20010403144608.X29491@magic.merlins.org> Message-ID: Marc MERLIN writes: >> Perhaps an -option would be better than special-casing a list name. > I thought about it, but it breaks the option parsing a bit since > remove_members kind of expects a list name. How about an argument that tells the program to interpret the list name as a regular expression to be matched against all lists. That way you could remove from all lists with a listname of ., and from subsets of lists with other arguments. Brian. From ps@psncc.at Wed Apr 4 22:11:54 2001 From: ps@psncc.at (ps@psncc.at) Date: Wed, 4 Apr 2001 23:11:54 +0200 (CEST) Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers Message-ID: Hi everybody, I just produced the patch included below. It allows to configure not to add the List-* header lines to outgoing non-digest messages. I needed this to hide the HTTP URLs for the webinterface, as Mailman is used "just" as the mailing list backend and the webinterface is to be used by the administrators only. A similar thing should probably be done for the digest case. The patch should apply cleanly to 2.0.2 and 2.0.3. Note that the patch adds a new attribute to the MailList object. This usually breaks existing mailing lists. You can fix the situation by creating a file with just the line mlist.addlistinfo = 1 and using /bin/config_list -i (at least this worked for me) NOTE 1: Use this patch at your own risk. NOTE 2: This is my first Mailman patch (and the first time I ever touched python) so I may have overlooked some details. Does anybody like this feature? peter diff -ur mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py --- mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py Thu Nov 16 05:35:09 2000 +++ mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py Wed Apr 4 22:19:24 2001 @@ -124,14 +124,15 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded. The adding of 2 is for the colon-space # separator. - if len(h) + 2 + len(v) > 78: - v = string.join(string.split(v, ', '), ',\n\t') - msg[h] = v + if mlist.addlistinfo: + if len(h) + 2 + len(v) > 78: + v = string.join(string.split(v, ', '), ',\n\t') + msg[h] = v # # Always delete List-Archive header, but only add it back if the list is # actually archiving del msg['List-Archive'] - if mlist.archive: + if mlist.archive and mlist.addlistinfo: value = '<%s>' % urlparse.urljoin(mlist.web_page_url, mlist.GetBaseArchiveURL()) msg['List-Archive'] = value diff -ur mailman-2.0.2-org/Mailman/MailList.py mailman-2.0.2-patched/Mailman/MailList.py --- mailman-2.0.2-org/Mailman/MailList.py Thu Nov 16 05:33:27 2000 +++ mailman-2.0.2-patched/Mailman/MailList.py Wed Apr 4 21:53:54 2001 @@ -345,6 +345,8 @@ self.msg_header = mm_cfg.DEFAULT_MSG_HEADER self.msg_footer = mm_cfg.DEFAULT_MSG_FOOTER + self.addlistinfo = 1 + def GetConfigInfo(self): config_info = {} config_info['digest'] = Digester.GetConfigInfo(self) @@ -770,6 +772,9 @@ "Text appended to the bottom of every immediately-delivery" " message. " + Utils.maketext('headfoot.html', raw=1)), + + ('addlistinfo', mm_cfg.Toggle, ('No', 'Yes'), 1, + 'Add mailing list information headers to outgoing messages?'), ] config_info['bounce'] = Bouncer.GetConfigInfo(self) From jra@baylink.com Thu Apr 5 00:17:12 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 4 Apr 2001 19:17:12 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: ; from ps@psncc.at on Wed, Apr 04, 2001 at 11:11:54PM +0200 References: Message-ID: <20010404191712.44418@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 11:11:54PM +0200, ps@psncc.at wrote: > Note that the patch adds a new attribute to the MailList object. This > usually breaks existing mailing lists. That comment troubles me. Isn't the point of object oriented design pretty precisely to avoid the need for such comments? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 00:32:58 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 4 Apr 2001 19:32:58 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> Message-ID: <15051.44842.800982.769610@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> That comment troubles me. Isn't the point of object oriented JRA> design pretty precisely to avoid the need for such comments? The issue here is that in essence the patch is changing the schema for the list configuration database. In that case you have two choices: - You can run an external tool off-line that walks over all the databases and updates their schemas. This is essentially what Peter is suggesting you do with config_list. - You can update the schema "on the fly" as you load each new database. This is the approach favored, and used, by Mailman. For the right way to update the schema, e.g. when you add a new attribute to the MailList object, see Mailman/versions.py. It's a horrible hack of code, but it does the job. You'll also need to update DATA_FILE_VERSION in Version.py. conspicuously-not-commenting-on-the-patch-itself-ly y'rs, -Barry From jra@baylink.com Thu Apr 5 01:09:58 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 4 Apr 2001 20:09:58 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15051.44842.800982.769610@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Apr 04, 2001 at 07:32:58PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> Message-ID: <20010404200958.49012@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 07:32:58PM -0400, Barry A. Warsaw wrote: > JRA> That comment troubles me. Isn't the point of object oriented > JRA> design pretty precisely to avoid the need for such comments? > > The issue here is that in essence the patch is changing the schema for > the list configuration database. In that case you have two choices: > > - You can run an external tool off-line that walks over all the > databases and updates their schemas. This is essentially what > Peter is suggesting you do with config_list. > > - You can update the schema "on the fly" as you load each new > database. This is the approach favored, and used, by Mailman. You're saying that a list object *wraps* a database, then. If so, yeah, the object sure as hell *ought* to deal with that issue itself. Careful how you use the word "databases"... I *think* you actually *mean* "records" (or rows), but I'm not sure. Cheer, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 01:19:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 4 Apr 2001 20:19:35 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> Message-ID: <15051.47639.556741.554268@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> You're saying that a list object *wraps* a database, then. JRA> If so, yeah, the object sure as hell *ought* to deal with JRA> that issue itself. JRA> Careful how you use the word "databases"... I *think* you JRA> actually *mean* "records" (or rows), but I'm not sure. Not quite. Okay, I'm being a little bit abstract, but bear with me. Eventually list objects will be backed by a Real Database (and some folks have already prototyped this). Concretely, Mailman currently stores a MailList instance's attributes in a file whose format is a Python marshal of a Python dictionary. This is the config.db file and is essentially what I'm talking about when I say "schema" since it serves the same purpose, although it's not explicitly described, e.g. as it would be in a traditional relational database. Nonetheless, if you change the MailList object's attributes (add or delete) you need to update this implicit schema in the ways I've described. Cheers, -Barry From jra@baylink.com Thu Apr 5 01:26:49 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 4 Apr 2001 20:26:49 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15051.47639.556741.554268@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Apr 04, 2001 at 08:19:35PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> Message-ID: <20010404202649.01789@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 08:19:35PM -0400, Barry A. Warsaw wrote: > JRA> You're saying that a list object *wraps* a database, then. > JRA> If so, yeah, the object sure as hell *ought* to deal with > JRA> that issue itself. > > JRA> Careful how you use the word "databases"... I *think* you > JRA> actually *mean* "records" (or rows), but I'm not sure. > > Not quite. > > Okay, I'm being a little bit abstract, but bear with me. Eventually > list objects will be backed by a Real Database (and some folks > have already prototyped this). Ok... > Concretely, Mailman currently stores a MailList instance's attributes > in a file whose format is a Python marshal of a Python dictionary. > This is the config.db file and is essentially what I'm talking about > when I say "schema" since it serves the same purpose, although it's > not explicitly described, e.g. as it would be in a traditional > relational database. Nonetheless, if you change the MailList object's > attributes (add or delete) you need to update this implicit schema in > the ways I've described. Ah. The problem comes from the fact that the exported marshals won't have the new data. Perhaps python needs to evaluate something else for it's marshalling file format? XML? Hmmmm?? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Thu Apr 5 02:28:29 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 04 Apr 2001 18:28:29 -0700 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 04 Apr 2001 19:17:12 EDT." <20010404191712.44418@scfn.thpl.lib.fl.us> References: <20010404191712.44418@scfn.thpl.lib.fl.us> Message-ID: <5430.986434109@kanga.nu> On Wed, 4 Apr 2001 19:17:12 -0400 Jay R Ashworth wrote: > On Wed, Apr 04, 2001 at 11:11:54PM +0200, ps@psncc.at wrote: >> Note that the patch adds a new attribute to the MailList >> object. This usually breaks existing mailing lists. > That comment troubles me. Isn't the point of object oriented > design pretty precisely to avoid the need for such comments? Yes, except that in this case the relevant objects are streamed to disk and we're talking about changing the object definition (which would therefore change the image streamed to disk). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From barry@digicool.com Thu Apr 5 03:17:07 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 4 Apr 2001 22:17:07 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> Message-ID: <15051.54691.444924.4799@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Ah. The problem comes from the fact that the exported JRA> marshals won't have the new data. Perhaps python needs to JRA> evaluate something else for it's marshalling file format? JRA> XML? Hmmmm?? I'm not sure how that would help -- you still have to update the file to have the new data. Sure, you could do it in a text editor, but no one will! :) Marshals, BTW, exist primarily to support caching of compiled byte code. A .pyc file is a marshal with a little bit of header information. They also happen to be an efficient way to store and load simple Python objects. Pickles are better for more complex objects (e.g. instances, or cyclic data structures). I've no doubt that somewhere, someone's got an XML DTD that supports serialization of Python objects. Probably xmlrpc or something in Zope, I don't know for sure. Of course, Python existed long before XML meant anything other than "eXtremely Mean Lemmings". -Barry From ps@psncc.at Thu Apr 5 06:50:25 2001 From: ps@psncc.at (ps@psncc.at) Date: Thu, 5 Apr 2001 07:50:25 +0200 (CEST) Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 Message-ID: Hi everybody, Having read the replies for my previous patch so far, I have produced version 2 of it. I would also like to note that the functionality applies to both regular and digest messages anyway, so one of the comments from my last posts should be treated as nonsense. Due to this, I have now moved the configurabale option to the "general" options page, and I have properly (?) changed the versions.py file to upgrade mailing lists for the new attribute on-the-fly (I didn't know of the functionality, although I thought it would be hidden somewhere - Barrys mail has pointed me in the right direction). However, this required to increase the DATA_FILE_VERSION in Mailman/Version.py as well (something I was not THAT comfortable with). It also includes a configurable default value for the new attribute as well. I would really like to hear comments on the proposed functionality as well as on the patch's quality (which [indirectly, though] seems to have been the focus of most, if not all, of the replies to my last posting). peter Here is the patch: diff -ur mailman-2.0.2-org/Mailman/Defaults.py.in mailman-2.0.2-patched/Mailman/Defaults.py.in --- mailman-2.0.2-org/Mailman/Defaults.py.in Thu Nov 16 05:23:52 2000 +++ mailman-2.0.2-patched/Mailman/Defaults.py.in Thu Apr 5 07:02:20 2001 @@ -366,6 +366,11 @@ 'subject', 'to', 'cc', 'reply-to', 'organization'] +##### +# Add list header, ie. List-Help, etc. to outgoing non-digest +# messages +##### +DEFAULT_ADDLISTINFO = 1 ##### diff -ur mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py --- mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py Thu Nov 16 05:35:09 2000 +++ mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py Wed Apr 4 23:13:39 2001 @@ -124,14 +124,15 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded. The adding of 2 is for the colon-space # separator. - if len(h) + 2 + len(v) > 78: - v = string.join(string.split(v, ', '), ',\n\t') - msg[h] = v + if mlist.addlistinfo: + if len(h) + 2 + len(v) > 78: + v = string.join(string.split(v, ', '), ',\n\t') + msg[h] = v # # Always delete List-Archive header, but only add it back if the list is # actually archiving del msg['List-Archive'] - if mlist.archive: + if mlist.archive and mlist.addlistinfo: value = '<%s>' % urlparse.urljoin(mlist.web_page_url, mlist.GetBaseArchiveURL()) msg['List-Archive'] = value diff -ur mailman-2.0.2-org/Mailman/MailList.py mailman-2.0.2-patched/Mailman/MailList.py --- mailman-2.0.2-org/Mailman/MailList.py Thu Nov 16 05:33:27 2000 +++ mailman-2.0.2-patched/Mailman/MailList.py Thu Apr 5 07:31:07 2001 @@ -345,6 +345,8 @@ self.msg_header = mm_cfg.DEFAULT_MSG_HEADER self.msg_footer = mm_cfg.DEFAULT_MSG_FOOTER + self.addlistinfo = mm_cfg.DEFAULT_ADDLISTINFO + def GetConfigInfo(self): config_info = {} config_info['digest'] = Digester.GetConfigInfo(self) @@ -544,6 +546,10 @@ ('max_message_size', mm_cfg.Number, 7, 0, 'Maximum length in Kb of a message body. Use 0 for no limit.'), + + ('addlistinfo', mm_cfg.Toggle, ('No', 'Yes'), 1, + 'Add mailing list information headers to outgoing messages ' + '(regular AND digests)?'), ('host_name', mm_cfg.Host, WIDTH, 0, 'Host name this list prefers.', diff -ur mailman-2.0.2-org/Mailman/Version.py mailman-2.0.2-patched/Mailman/Version.py --- mailman-2.0.2-org/Mailman/Version.py Sat Mar 3 07:19:15 2001 +++ mailman-2.0.2-patched/Mailman/Version.py Thu Apr 5 07:39:08 2001 @@ -36,7 +36,7 @@ (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.db schema version number -DATA_FILE_VERSION = 21 +DATA_FILE_VERSION = 22 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 2 diff -ur mailman-2.0.2-org/Mailman/versions.py mailman-2.0.2-patched/Mailman/versions.py --- mailman-2.0.2-org/Mailman/versions.py Wed Jun 14 07:09:58 2000 +++ mailman-2.0.2-patched/Mailman/versions.py Thu Apr 5 06:59:08 2001 @@ -189,6 +189,7 @@ add_only_if_missing('postings_responses', {}, l) add_only_if_missing('admin_responses', {}, l) add_only_if_missing('reply_goes_to_list', '', l) + add_only_if_missing('addlistinfo', mm_cfg.DEFAULT_ADDLISTINFO, l) From jra@baylink.com Thu Apr 5 07:01:10 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 02:01:10 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15051.54691.444924.4799@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Apr 04, 2001 at 10:17:07PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> Message-ID: <20010405020110.57681@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 10:17:07PM -0400, Barry A. Warsaw wrote: > JRA> Ah. The problem comes from the fact that the exported > JRA> marshals won't have the new data. Perhaps python needs to > JRA> evaluate something else for it's marshalling file format? > > JRA> XML? Hmmmm?? > > I'm not sure how that would help -- you still have to update the file > to have the new data. Sure, you could do it in a text editor, but no > one will! :) Because then, at least old unchanged objects which were read in by the 'code inside the object' wouldn't break: they'd just have to pick up the default for that attribute. When you wrote them *back out*, they'd automagically be fixed. > Marshals, BTW, exist primarily to support caching of compiled byte > code. A .pyc file is a marshal with a little bit of header > information. They also happen to be an efficient way to store and > load simple Python objects. Pickles are better for more complex > objects (e.g. instances, or cyclic data structures). Are pickles less prone to break the "objectization" of objects you're going to want persistent storage of? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 14:55:54 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 5 Apr 2001 09:55:54 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> Message-ID: <15052.31082.918502.278802@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Because then, at least old unchanged objects which were read JRA> in by the 'code inside the object' wouldn't break: they'd JRA> just have to pick up the default for that attribute. When JRA> you wrote them *back out*, they'd automagically be fixed. This happens now, since once that attribute's on the MailList object, it'll get written back out to the .db file. >> Marshals, BTW, exist primarily to support caching of compiled >> byte code. A .pyc file is a marshal with a little bit of >> header information. They also happen to be an efficient way to >> store and load simple Python objects. Pickles are better for >> more complex objects (e.g. instances, or cyclic data >> structures). JRA> Are pickles less prone to break the "objectization" of JRA> objects you're going to want persistent storage of? I'm not sure I understand the question. Marshal only handles built-in types (ints, longs, dicts, lists, tuples) and wasn't designed to handle instances. That's what pickle is for (and see the cPickle module for a really fast implementation of the pickle protocol). -Barry From jra@baylink.com Thu Apr 5 17:39:45 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 12:39:45 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15052.31082.918502.278802@anthem.wooz.org>; from "Barry A. Warsaw" on Thu, Apr 05, 2001 at 09:55:54AM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> <15052.31082.918502.278802@anthem.wooz.org> Message-ID: <20010405123945.60935@scfn.thpl.lib.fl.us> On Thu, Apr 05, 2001 at 09:55:54AM -0400, Barry A. Warsaw wrote: > JRA> Because then, at least old unchanged objects which were read > JRA> in by the 'code inside the object' wouldn't break: they'd > JRA> just have to pick up the default for that attribute. When > JRA> you wrote them *back out*, they'd automagically be fixed. > > This happens now, since once that attribute's on the MailList object, > it'll get written back out to the .db file. Oh. It sounded to *me* like the read-in would fail. Misunderstood. Then what's the problem? > JRA> Are pickles less prone to break the "objectization" of > JRA> objects you're going to want persistent storage of? > > I'm not sure I understand the question. Marshal only handles built-in > types (ints, longs, dicts, lists, tuples) and wasn't designed to > handle instances. That's what pickle is for (and see the cPickle > module for a really fast implementation of the pickle protocol). Um, "nevermind". Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 18:23:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 5 Apr 2001 13:23:16 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> <15052.31082.918502.278802@anthem.wooz.org> <20010405123945.60935@scfn.thpl.lib.fl.us> Message-ID: <15052.43524.31062.306270@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Oh. It sounded to *me* like the read-in would fail. JRA> Misunderstood. JRA> Then what's the problem? The read succeeds but the resulting MailList instance won't have the new attribute. When the module tries to access that attribute, you'll get an AttributeError. This /could/ be worked around by using something like: if getattr(mlist, 'my_new_attribute', 0): instead of if mlist.my_new_attribute: The getattr() approach doesn't raise an exception when given a default value. -Barry From jra@baylink.com Thu Apr 5 18:23:24 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 13:23:24 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15052.43524.31062.306270@anthem.wooz.org>; from "Barry A. Warsaw" on Thu, Apr 05, 2001 at 01:23:16PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> <15052.31082.918502.278802@anthem.wooz.org> <20010405123945.60935@scfn.thpl.lib.fl.us> <15052.43524.31062.306270@anthem.wooz.org> Message-ID: <20010405132324.24253@scfn.thpl.lib.fl.us> On Thu, Apr 05, 2001 at 01:23:16PM -0400, Barry A. Warsaw wrote: > JRA> Then what's the problem? > > The read succeeds but the resulting MailList instance won't have the > new attribute. When the module tries to access that attribute, you'll > get an AttributeError. This /could/ be worked around by using > something like: > > if getattr(mlist, 'my_new_attribute', 0): > > instead of > > if mlist.my_new_attribute: > > The getattr() approach doesn't raise an exception when given a default > value. Ah. The problem is that the wrapper isn't first-class. (That is, it fails to behave in a sufficiently transparent fashion to keep you from being able to tell that it's not just "storing the object on disk". (did the explanation make matters worse? :-))) Got it. FYI, I consider that a design deficiency (which is a slightly different category from a 'bug' :-), and I concur that it *should* be fixed; does the approach you mention have other unforseen difficulties that it imposes? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 18:45:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 5 Apr 2001 13:45:31 -0400 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 References: Message-ID: <15052.44859.379837.741282@anthem.wooz.org> >>>>> "ps" == writes: ps> I would really like to hear comments on the proposed ps> functionality I'm currently opposed to making it easy to disable these headers. They are described in RFC 2369 and I think it's important for Mailman to be as standards compliant as possible. That some MUAs haven't caught up yet isn't a good enough argument to change my mind. That being said, I claim that it's trivial to hack the source code to disable these headers. Having your patch available unofficially is a good thing too (thanks!), since it gives sites more options. I'm glad you've made the patch but I'm not inclined to include it in the official release. Cheers, -Barry From chuqui@plaidworks.com Thu Apr 5 19:02:27 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Thu, 5 Apr 2001 11:02:27 -0700 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: <15052.44859.379837.741282@anthem.wooz.org> Message-ID: <200104051804.f35I4Fe17814@lists.apple.com> On Thursday, April 5, 2001, at 10:45 AM, Barry A. Warsaw wrote: > I'm currently opposed to making it easy to disable these headers. > They are described in RFC 2369 and I think it's important for Mailman > to be as standards compliant as possible. These are standards. I think any patch to remove them ought to be rejected, the documentation ought to explicitly discourge people from removing them, and the source code ought to have a note in it recommending against removing them. We want to encourage adoption of the standard, not removal of the header lines. In fact, I'd go further, if it were my project. I'd put it in the FAQ that we do not support removal of the headers, and I'd make it list policy to not support anyone who wants to. If they want to, let them. We're under no obligation to make it easy in any way, and I think in the long-run, doing anything that in any way approves of (even by implication of putting an unsuipported patch somewhere in the disto) is the wrong thing. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. From jra@baylink.com Thu Apr 5 19:12:03 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 14:12:03 -0400 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: <200104051804.f35I4Fe17814@lists.apple.com>; from chuq von rospach on Thu, Apr 05, 2001 at 11:02:27AM -0700 References: <15052.44859.379837.741282@anthem.wooz.org> <200104051804.f35I4Fe17814@lists.apple.com> Message-ID: <20010405141203.35086@scfn.thpl.lib.fl.us> On Thu, Apr 05, 2001 at 11:02:27AM -0700, chuq von rospach wrote: > In fact, I'd go further, if it were my project. I'd put it in the FAQ > that we do not support removal of the headers, and I'd make it list > policy to not support anyone who wants to. If they want to, let them. > We're under no obligation to make it easy in any way, and I think in the > long-run, doing anything that in any way approves of (even by > implication of putting an unsuipported patch somewhere in the disto) is > the wrong thing. And that, given the author, is, as they say, da name'a dat tune. Cheers, -- jr 'ie: "concur"' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From christine@trafficmagnet.net Fri Apr 6 05:22:59 2001 From: christine@trafficmagnet.net (Christine Hall) Date: Fri, 6 Apr 2001 12:22:59 +0800 Subject: [Mailman-Developers] WWW.LIST.ORG Message-ID: <200104060422.MAA06199@ns2.trafficmagnet.net>

Hello,

I visited www.list.org and I noticed that you are not listed on some search engines. I am sure you can increase the number of people who visit www.list.org . Do you know TrafficMagnet? TrafficMagnet is a unique technology that automatically submits your web site to over 300,000+ search engines and directories every month. This is a very low-cost and effective way of advertising your site.

To check our prices and submit www.list.org to 300,000+ search engines, go to TrafficMagnet.net

I would love to hear from you.

Best Regards,
Christine Hall
Sales & Marketing
www.TrafficMagnet.net

   

From webmaster@wunderland.com Fri Apr 6 16:49:16 2001 From: webmaster@wunderland.com (Dale Newfield) Date: Fri, 6 Apr 2001 11:49:16 -0400 (EDT) Subject: [Mailman-Developers] Cross-posting? In-Reply-To: Message-ID: I've installed Mailman at a site that has quite a number of mailing lists. we're trying to figure out a more disjoint re-design of the lists to reduce the problem of cross-posting, but I thought I'd at least ask if anyone's attempted to address this from w/in mailman. If there were a database of message ids, along with information listing which mailing lists those've gone to, wouldn't it be possible to only send messages once to people subscribed to both lists? It's a great piece of software, BTW, and a hack I recently installed to unify passwords across lists (so it looks like a user has only one password instead of one per list) helps out, too. -Dale Newfield webmaster@wunderland.com From darrell@grumblesmurf.net Fri Apr 6 19:21:25 2001 From: darrell@grumblesmurf.net (Darrell Fuhriman) Date: 06 Apr 2001 11:21:25 -0700 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: chuq von rospach's message of "Thu, 5 Apr 2001 11:02:27 -0700" References: <200104051804.f35I4Fe17814@lists.apple.com> Message-ID: chuq von rospach writes: > These are standards. I think any patch to remove them ought to be > rejected, the documentation ought to explicitly discourge people from > removing them, and the source code ought to have a note in it > recommending against removing them. We want to encourage adoption of > the standard, not removal of the header lines. I agree with everything but the first clause (and I was the one that wrote the patch to implement it.) The RFC specifically says that the headers are optional (paragraph 2 section 1 of the RFC.), and I personally believe in giving people options where available. Just because it's probably a bad idea doesn't mean we should be restrictive on things are not mandated. This is already what's done with the optional Reply-To header, for example. If I wanted software that told me that I had to do it the software's (or the software author's) way and no other, I would just use ezmlm. I don't like software that second guesses my decisions, and I see no compelling reason to be second guessing others' decisions here. I say make it optional, but strongly discourage turning it off. Darrell From dan.mick@west.sun.com Fri Apr 6 20:17:49 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Fri, 06 Apr 2001 12:17:49 -0700 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 References: Message-ID: <3ACE165D.16E967D8@west.sun.com> > I would really like to hear comments on the proposed functionality OK. I think it's wrong to have this configurable. I think Mailman should do the right thing wrt list headers, and the right thing is to include them. From apeeters@lashout.net Sat Apr 7 00:15:15 2001 From: apeeters@lashout.net (Adriaan Peeters) Date: Sat, 7 Apr 2001 01:15:15 +0200 Subject: [Mailman-Developers] specific templates Message-ID: <110701c0beef$7078f3d0$0201000a@napoli> Hey all, I sent this to the mailman-users list, but they couldn't give me a complete answer. Does anyone know how to change the automated subcribe confirmation email ? It is possible to add a text via the administrative interface, but is't not possible to change the mail completely. I would like to change the welcome e-mail completely, perhaps even make html mails from it. I tried to copy templates/subscribeack.txt to lists/listname/subscribeack.txt and change something in that file, but it didn't work :( I think it's not a very big deal to change the code to check first if a specific subscribeack.txt exists, then include it, and if not, include the default one. But unfortunately I don't know enough Python to submit a patch :( Is there a way to accomplish this at this moment, or are there any patches out there ? Regards and thanks, Adriaan Peeters From thomas@xs4all.net Sat Apr 7 01:06:47 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 7 Apr 2001 02:06:47 +0200 Subject: [Mailman-Developers] specific templates In-Reply-To: <110701c0beef$7078f3d0$0201000a@napoli>; from apeeters@lashout.net on Sat, Apr 07, 2001 at 01:15:15AM +0200 References: <110701c0beef$7078f3d0$0201000a@napoli> Message-ID: <20010407020647.G2820@xs4all.nl> On Sat, Apr 07, 2001 at 01:15:15AM +0200, Adriaan Peeters wrote: > I sent this to the mailman-users list, but they couldn't give me a comple= te > answer. > Does anyone know how to change the automated subcribe confirmation email ? > It is possible to add a text via the administrative interface, but is't n= ot > possible to change the mail completely. I would like to change the welco= me > e-mail completely, perhaps even make html mails from it. > I tried to copy templates/subscribeack.txt to > lists/listname/subscribeack.txt and change something in that file, but it > didn't work :( What you want is being worked on. Mailman 2.1 will be much more configurable, as well as multilingual (meaning that your site can be in English, and your lists can in Dutch, Spanish or Swahili as well as English. Or the other way 'round) and one of the things that was fixed is that the emails are better configurable. Having said that :) it's not *too* hard to convince Mailman to read template files from the list directory, if you really really want to. You need to adjust the 'maketext' function in Utils.py to accept a mailinglist-argument, and if it's passed in, try to find out if its data dir has the template file. And then you need to go and adjust all maketext calls to include the list object. (maketext should probably be a method ;) I did this for a Dutch list we run, since 2.1 wasn't even on the horizon back then and they *really* wanted to be dutch all the way. And the Mailman we are running is so hacked up anyway, it's just not funny anymore :) My maketext looks like this: def maketext(templatefile, dict, raw=3D0, mlist=3DNone): """Make some text from a template file. Reads the =14emplatefile', relative to mm_cfg.TEMPLATE_DIR, does string substitution by interpolating in the =04ict', and if =12aw' is false, wraps/fills the resulting text by calling wrap(). """ if mlist: file =3D os.path.join(mm_cfg.LIST_DATA_DIR, mlist.internal_name(), templatefile) if not os.path.exists(file): file =3D os.path.join(mm_cfg.TEMPLATE_DIR, templatefile) else: file =3D os.path.join(mm_cfg.TEMPLATE_DIR, templatefile) fp =3D open(file) template =3D fp.read() fp.close() text =3D template % SafeDict(dict) if raw: return text return wrap(text) And then I went and adjusted the 15-something calls to maketext. --=20 Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me sp= read! From jra@baylink.com Sat Apr 7 02:13:36 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 6 Apr 2001 21:13:36 -0400 Subject: [Mailman-Developers] specific templates In-Reply-To: <110701c0beef$7078f3d0$0201000a@napoli>; from Adriaan Peeters on Sat, Apr 07, 2001 at 01:15:15AM +0200 References: <110701c0beef$7078f3d0$0201000a@napoli> Message-ID: <20010406211336.08848@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 01:15:15AM +0200, Adriaan Peeters wrote: > possible to change the mail completely. I would like to change the welcome > e-mail completely, perhaps even make html mails from it. Oh *puhleeze* don't. email is *not* an HTML medium. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Sat Apr 7 02:14:48 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 6 Apr 2001 21:14:48 -0400 Subject: [Mailman-Developers] specific templates In-Reply-To: <20010407020647.G2820@xs4all.nl>; from Thomas Wouters on Sat, Apr 07, 2001 at 02:06:47AM +0200 References: <110701c0beef$7078f3d0$0201000a@napoli> <20010407020647.G2820@xs4all.nl> Message-ID: <20010406211448.18624@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 02:06:47AM +0200, Thomas Wouters wrote: > What you want is being worked on. Mailman 2.1 will be much more > configurable, as well as multilingual (meaning that your site can be in > English, and your lists can in Dutch, Spanish or Swahili as well as English. > Or the other way 'round) and one of the things that was fixed is that the > emails are better configurable. Passwords not required? Will that be one of the new features? :-) Or is it in there already, and I just missed it. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Sat Apr 7 06:55:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sat, 7 Apr 2001 01:55:19 -0400 Subject: [Mailman-Developers] specific templates References: <110701c0beef$7078f3d0$0201000a@napoli> <20010407020647.G2820@xs4all.nl> Message-ID: <15054.43975.861818.904844@anthem.wooz.org> >>>>> "TW" == Thomas Wouters writes: TW> You need to adjust the 'maketext' function in Utils.py to TW> accept a mailinglist-argument I think at one time I was against this for some reason I can't remember. But it does seem like the most reasonable approach, and I'm getting tired of the way Mailman searches for its templates so this will probably go into 2.1. (I'm aware of patch #402426 but I think adding an mlist argument is better.) >>>>> "JRA" == Jay R Ashworth writes: JRA> Passwords not required? Will that be one of the new JRA> features? :-) JRA> Or is it in there already, and I just missed it. You (sort of) missed it. Passwords aren't going away, but users won't need them to unsubscribe. If they don't supply a password they will have to confirm the operation before it goes through. Note that the confirmation mechanism is flexible enough now that I plan to add a lot more things that can be confirmed (like approve, reject, etc. holds via email, etc.). -Barry From jra@baylink.com Sat Apr 7 12:34:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 07:34:15 -0400 Subject: [Mailman-Developers] specific templates In-Reply-To: <15054.43975.861818.904844@anthem.wooz.org>; from "Barry A. Warsaw" on Sat, Apr 07, 2001 at 01:55:19AM -0400 References: <110701c0beef$7078f3d0$0201000a@napoli> <20010407020647.G2820@xs4all.nl> <15054.43975.861818.904844@anthem.wooz.org> Message-ID: <20010407073415.37521@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 01:55:19AM -0400, Barry A. Warsaw wrote: > JRA> Passwords not required? Will that be one of the new > JRA> features? :-) > JRA> Or is it in there already, and I just missed it. > > You (sort of) missed it. Passwords aren't going away, but users won't > need them to unsubscribe. If they don't supply a password they will > have to confirm the operation before it goes through. Well, in this particular customer's case, they don't even want that. Form; fill in email address; click "unsubscribe", buh-bye. They have a low opinion of their customers' patience. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From eric.kidd@pobox.com Sat Apr 7 20:48:58 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 15:48:58 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC Message-ID: <20010407154858.B29075@localhost.Dartmouth.EDU> Hello! I run several Mailman-based mailing lists. And along the way, I've come to really love Mailman. Many thanks to everyone who has worked on it; it's definitely the best list manager I've ever seen. But--for better of for worse--I've decided to tamper with near perfection. :-) Here's what I'm up to: * I want to be able to control Mailman remotely, using scripts. For example, I want to be able to change list preferences, access the approval queue, and generally do anything I could do through the web. * Ideally, I'd like to be able to write these scripts in any popular language. * I don't especially want to fake FORM POSTs and parse the HTML response. This would work, but it's more work than I'd like to get into on the client side. So I've decided to add XML-RPC support to my local copy of Mailman. XML-RPC is a protocol that allows you to make CGI-like "function calls" over HTTP using specially-formatted XML documents. You can read all about XML-RPC here: http://www.xmlrpc.com/ http://www.xmlrpc.com/spec http://www.linuxdoc.org/HOWTO/XML-RPC-HOWTO/index.html The HOWTO contains example clients and servers in many different languages. Fredrik Lundh wrote an excellent implementation of XML-RPC for Python. His code is used in Zope, the RedHat Network and some forthcoming stuff from Eazel: http://www.pythonware.com/products/xmlrpc/index.htm But why use XML-RPC? 1) XML-RPC is really simple. It doesn't get into Schemas, namespaces, alternate encodings, or anything else especially fancy. Fredrik's implemention is less than a 1,000 lines long, which isn't bad for an RPC protocol. I'm not smart enough to cope anything more complicated. :-) 2) XML-RPC is widely supported, with bindings for Python, Perl, Java, C, C++, Tcl, KDE, Zope, AppleScript, Microsoft .NET, Ruby, Rebol, Delphi, and some languages I'd never even heard of. 3) XML-RPC supports complex data-types: arrays, dictionaries, byte arrays, etc. 4) Many XML-RPC implementations support Unicode, including Python, Perl, Java, C and C++. This would allow me to handle international data gracefully. 5) XML-RPC servers can support introspection, allowing a client to discover APIs over the network. This makes it easy to generate documentation, create wrapper classes, and so on, without needing to cope with IDL. For more information on XML-RPC introspection, see: http://xmlrpc-c.sourceforge.net/hacks.php OK, yes, I'm probably crazy. But it seems like a fun hack. So if anybody else is interested in XML-RPC for Mailman, please let me know. And if anybody can tell me why I'm nuts, please let me know that, too. :-) Cheers, Eric -- XML-RPC HOWTO: http://www.linuxdoc.org/HOWTO/XML-RPC-HOWTO/index.html XML-RPC for C and C++: http://xmlrpc-c.sourceforge.net/ xmlrpc-c-devel list: http://xmlrpc-c.sourceforge.net/lists.php From jon@latchkey.com Sat Apr 7 21:38:30 2001 From: jon@latchkey.com (Jon Stevens) Date: Sat, 07 Apr 2001 13:38:30 -0700 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407154858.B29075@localhost.Dartmouth.EDU> Message-ID: on 4/7/01 12:48 PM, "Eric Kidd" wrote: > OK, yes, I'm probably crazy. But it seems like a fun hack. > > So if anybody else is interested in XML-RPC for Mailman, please let me > know. And if anybody can tell me why I'm nuts, please let me know > that, too. :-) > > Cheers, > Eric Hi Eric, I don't think you are nuts at all. This sounds *excellent* and very much needed. I personally, hope this makes it into the mailman distribution as a standard feature (if you donate your code for it). thanks! -jon From ricardo@rixhq.nu Sat Apr 7 22:26:53 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 7 Apr 2001 23:26:53 +0200 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: ; from jon@latchkey.com on Sat, Apr 07, 2001 at 01:38:30PM -0700 References: <20010407154858.B29075@localhost.Dartmouth.EDU> Message-ID: <20010407232653.A14436@rix.rixhq.nu> On Sat, Apr 07, 2001 at 01:38:30PM -0700, Jon Stevens wrote: > on 4/7/01 12:48 PM, "Eric Kidd" wrote: > > OK, yes, I'm probably crazy. But it seems like a fun hack. > > So if anybody else is interested in XML-RPC for Mailman, please let me > > know. And if anybody can tell me why I'm nuts, please let me know > > that, too. :-) > I don't think you are nuts at all. This sounds *excellent* and very much > needed. > I personally, hope this makes it into the mailman distribution as a standard > feature (if you donate your code for it). What about using SOAP? I don't know that much about it but it looks like about the same thing XML-RPC does but I could be wrong though :) -- Regards, Ricardo From eric.kidd@pobox.com Sat Apr 7 22:36:42 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 17:36:42 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407232653.A14436@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 07, 2001 at 11:26:53PM +0200 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> Message-ID: <20010407173642.F29075@localhost.Dartmouth.EDU> On Sat, Apr 07, 2001 at 11:26:53PM +0200, Ricardo Kustner wrote: > What about using SOAP? I don't know that much about it but it looks like > about the same thing XML-RPC does but I could be wrong though :) You can find the two specifications here: http://www.xmlrpc.com/spec http://www.w3.org/TR/SOAP/ Basically, XML-RPC is a very early fork of SOAP, back before a whole bunch of internal Microsoft committees each decided to add their favorite feature to the specification. ;-) Pros of SOAP: * It's going to be built into Microsoft .NET. * Lots of libraries provide support for various subsets of SOAP. A few of these run under Unix. * SOAP is extensible, flexible, malleable, etc. * There's a very reasonable subset of SOAP evolving (BDG), but it's not clear that some of the big developers will be compatible with that subset. Pros of XML-RPC: * All the clients and servers talk to each other already. * It's ridiculously simple. * Clients are available for all of the major scripting languages, and many of the minor ones. * I'm willing to implement it. :-) Basically, XML-RPC is a Real Simple, Right Now kind of thing. SOAP is a little bit like OSI networking or SGML--a sweet idea in theory, but a wee bit complex in practice. But it's not an either-or choice. All my XML-RPC work will be open source, so once there's a good SOAP library for Python, it will be really easy to add SOAP support. Does this seem like a reasonable approach? Cheers, Eric From ricardo@rixhq.nu Sat Apr 7 23:39:22 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sun, 8 Apr 2001 00:39:22 +0200 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407173642.F29075@localhost.Dartmouth.EDU>; from eric.kidd@pobox.com on Sat, Apr 07, 2001 at 05:36:42PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> <20010407173642.F29075@localhost.Dartmouth.EDU> Message-ID: <20010408003922.B14436@rix.rixhq.nu> On Sat, Apr 07, 2001 at 05:36:42PM -0400, Eric Kidd wrote: > On Sat, Apr 07, 2001 at 11:26:53PM +0200, Ricardo Kustner wrote: > > What about using SOAP? I don't know that much about it but it looks like > > about the same thing XML-RPC does but I could be wrong though :) > Basically, XML-RPC is a very early fork of SOAP, back before a whole bunch > of internal Microsoft committees each decided to add their favorite > feature to the specification. ;-) > Pros of XML-RPC: > * All the clients and servers talk to each other already. > * It's ridiculously simple. > * Clients are available for all of the major scripting languages, and > many of the minor ones. > * I'm willing to implement it. :-) > Basically, XML-RPC is a Real Simple, Right Now kind of thing. SOAP is > a little bit like OSI networking or SGML--a sweet idea in theory, but a wee > bit complex in practice. > But it's not an either-or choice. All my XML-RPC work will be open source, > so once there's a good SOAP library for Python, it will be really easy to > add SOAP support. > Does this seem like a reasonable approach? Sounds great to me... This would give some nice opportunities like easy integration into dynamic websites, as long as they are written in a language that supports xmlrpc... I know I would almost certainly be using it in some PHP sites I made to integrate the subscription pages better. Do you think this would require major changes in the mailman code? I can imagine the question will rise if it is something which could be added now or in a future version of mailman. -- Regards, Ricardo From eric.kidd@pobox.com Sat Apr 7 23:38:52 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 18:38:52 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010408003922.B14436@rix.rixhq.nu>; from ricardo@rixhq.nu on Sun, Apr 08, 2001 at 12:39:22AM +0200 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> <20010407173642.F29075@localhost.Dartmouth.EDU> <20010408003922.B14436@rix.rixhq.nu> Message-ID: <20010407183852.H29075@localhost.Dartmouth.EDU> On Sun, Apr 08, 2001 at 12:39:22AM +0200, Ricardo Kustner wrote: > Sounds great to me... This would give some nice opportunities like easy > integration into dynamic websites, as long as they are written in a language > that supports xmlrpc... Hmmm. You should be totally covered on the Unix side of things, and you should be pretty well off under Windows. I'm currently getting e-mails about XML-RPC for Flash, so I'm guessing that most of the obvious languages have been covered. PHP has a good client, so you shouldn't have any trouble. > Do you think this would require major changes in the mailman code? I can > imagine the question will rise if it is something which could be added now > or in a future version of mailman. Probably not, although I'm still getting up to speed on the mailman internals. I think I'm going to write an extra CGI script, and have it make calls into the rest of Mailman as needed. Basically, if an API exists in Mailman, it's a cinch to export the same functionality. But if no API exists for performing a given task, it might get a bit hard. Cheers, Eric From jra@baylink.com Sun Apr 8 01:49:28 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 20:49:28 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407154858.B29075@localhost.Dartmouth.EDU>; from Eric Kidd on Sat, Apr 07, 2001 at 03:48:58PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> Message-ID: <20010407204928.22296@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 03:48:58PM -0400, Eric Kidd wrote: > OK, yes, I'm probably crazy. But it seems like a fun hack. :-) > So if anybody else is interested in XML-RPC for Mailman, please let me > know. And if anybody can tell me why I'm nuts, please let me know > that, too. :-) Um... "security"? What's the current status, there? SSL? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Sun Apr 8 01:50:23 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 20:50:23 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407232653.A14436@rix.rixhq.nu>; from Ricardo Kustner on Sat, Apr 07, 2001 at 11:26:53PM +0200 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> Message-ID: <20010407205023.60489@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 11:26:53PM +0200, Ricardo Kustner wrote: > What about using SOAP? I don't know that much about it but it looks > like about the same thing XML-RPC does but I could be wrong though :) Naaah... Dave Winer likes SOAP. Cheers, -- jr 'ok, ok ":-)", already...' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Sun Apr 8 01:52:28 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 20:52:28 -0400 Subject: [Mailman-Developers] Way OT: XML-RPC in *Flash*? (was: Re: Remote scripting with XML-RPC) In-Reply-To: <20010407183852.H29075@localhost.Dartmouth.EDU>; from Eric Kidd on Sat, Apr 07, 2001 at 06:38:52PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> <20010407173642.F29075@localhost.Dartmouth.EDU> <20010408003922.B14436@rix.rixhq.nu> <20010407183852.H29075@localhost.Dartmouth.EDU> Message-ID: <20010407205228.41732@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 06:38:52PM -0400, Eric Kidd wrote: > Hmmm. You should be totally covered on the Unix side of things, and you > should be pretty well off under Windows. I'm currently getting e-mails > about XML-RPC for Flash, so I'm guessing that most of the obvious > languages have been covered. Oh, just what *I* needed to hear... I can download a Flash file, and it will go off and try to do things as me? ;-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From eric.kidd@pobox.com Sun Apr 8 01:59:43 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 20:59:43 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407204928.22296@scfn.thpl.lib.fl.us>; from jra@baylink.com on Sat, Apr 07, 2001 at 08:49:28PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407204928.22296@scfn.thpl.lib.fl.us> Message-ID: <20010407205943.L29075@localhost.Dartmouth.EDU> On Sat, Apr 07, 2001 at 08:49:28PM -0400, Jay R. Ashworth wrote: > On Sat, Apr 07, 2001 at 03:48:58PM -0400, Eric Kidd wrote: > > So if anybody else is interested in XML-RPC for Mailman, please let me > > know. And if anybody can tell me why I'm nuts, please let me know > > that, too. :-) > > Um... "security"? What's the current status, there? SSL? You get precisely the same security you would using the regular CGI interface. ;-) If you've installed SSL, both approaches provide very nice security. If you haven't installed SSL, you're not going to be a happy camper either way. An XML-RPC server is basically a glorified CGI script with a structured input/output format. Handy, but not really anything new. Cheers, Eric From jra@baylink.com Sun Apr 8 07:00:12 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sun, 8 Apr 2001 02:00:12 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407205943.L29075@localhost.Dartmouth.EDU>; from Eric Kidd on Sat, Apr 07, 2001 at 08:59:43PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407204928.22296@scfn.thpl.lib.fl.us> <20010407205943.L29075@localhost.Dartmouth.EDU> Message-ID: <20010408020012.55672@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 08:59:43PM -0400, Eric Kidd wrote: > > Um... "security"? What's the current status, there? SSL? > > You get precisely the same security you would using the regular CGI > interface. ;-) > > If you've installed SSL, both approaches provide very nice security. If > you haven't installed SSL, you're not going to be a happy camper either > way. Ah. > An XML-RPC server is basically a glorified CGI script with a structured > input/output format. Handy, but not really anything new. Oh, yeah. On the server side, I guess that's true. It's the client side API that makes it cool. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Sun Apr 8 21:15:18 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 08 Apr 2001 13:15:18 -0700 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: Message from "Jay R. Ashworth" of "Sun, 08 Apr 2001 02:00:12 EDT." <20010408020012.55672@scfn.thpl.lib.fl.us> References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407204928.22296@scfn.thpl.lib.fl.us> <20010407205943.L29075@localhost.Dartmouth.EDU> <20010408020012.55672@scfn.thpl.lib.fl.us> Message-ID: <664.986760918@kanga.nu> On Sun, 8 Apr 2001 02:00:12 -0400 Jay R Ashworth wrote: > On Sat, Apr 07, 2001 at 08:59:43PM -0400, Eric Kidd wrote: >> An XML-RPC server is basically a glorified CGI script with a >> structured input/output format. Handy, but not really anything >> new. > Oh, yeah. On the server side, I guess that's true. It's the > client side API that makes it cool. While setting up client key authentication under SSL is not hard, its also something not well documented or familiar to (most) SysAdms. Its fiddly, easy to get wrong, and tends to be frustrating before you reach the "Aha!" point, and that doesn't even count the PKI problem. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From marc_news@valinux.com Sun Apr 8 23:23:22 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Sun, 8 Apr 2001 15:23:22 -0700 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses Message-ID: <20010408152322.A6510@magic.merlins.org> Apparently, this old bug is still here (I remember seeing it in the mailman 1.0rc1 days, and back then we solved it by having the user change his mail name so as not to have a dot) My mailman is configured to look at the header from (not the envelope from), and the header from says: From: David E.Fox It seems that mailman gets confused by the dot in "David E.Fox" and then fails to handle the Email address correctly, and decides that the user isn't in the list of subscribers, so he can't post, or it may just be confused by the fact that there are no quotes around the name. (notice that mailman thinks the Email is davide.fox and not dfox@m206-157.dsl.tsoft.com) Did I miss something, is this actually a buglet that's still here? (Note that this From field is invalid as per RFC 822, because it's missing the double quotes. The user uses Kmail and it's a kmail bug). If you concur that this is a problem, please let me know, and I can open a bug on sourceforge. Thanks, Marc ----- Forwarded message from svlug-admin@lists.svlug.org ----- From: svlug-admin@lists.svlug.org Subject: svlug post from davide.fox requires approval To: svlug-admin@lists.svlug.org X-Ack: no Date: Sat, 07 Apr 2001 14:25:01 -0700 As list administrator, your authorization is requested for the following mailing list posting: List: svlug@lists.svlug.org From: davide.fox Subject: Re: [svlug] DSL vedor shakeout II: PSINet Reason: Post by non-member to a members-only list At your convenience, visit: http://lists.svlug.org/mailman/admindb/svlug to approve or deny the request. ----- End forwarded message ----- -- 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 jra@baylink.com Mon Apr 9 05:37:28 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 9 Apr 2001 00:37:28 -0400 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <20010408152322.A6510@magic.merlins.org>; from Marc MERLIN on Sun, Apr 08, 2001 at 03:23:22PM -0700 References: <20010408152322.A6510@magic.merlins.org> Message-ID: <20010409003728.00098@scfn.thpl.lib.fl.us> On Sun, Apr 08, 2001 at 03:23:22PM -0700, Marc MERLIN wrote: > From: David E.Fox > (Note that this From field is invalid as per RFC 822, because it's missing > the double quotes. The user uses Kmail and it's a kmail bug). Yes, but note that it's *still* parseable, since the error is *outside* the bra-kets; it's arguable whether being pedantic *here* is productive, under the "be conservative what you send, liberal what you accept" principle. And yes, I *know* that someone's program, somewhere, has to be a hard ass... I just don't know whether it's "ours" (:-) or not... Cheers -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From Nigel.Metheringham@InTechnology.co.uk Mon Apr 9 10:15:32 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Mon, 09 Apr 2001 10:15:32 +0100 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: Message from Darrell Fuhriman of "06 Apr 2001 11:21:25 PDT." Message-ID: darrell@grumblesmurf.net said: > I say make it optional, but strongly discourage turning it off. I come in fairly strongly on the not having this as a standard (or distributed) option - I want people to fix their broken MUAs rather than break MLMs to fit. Those using a sane MTA (OK, I mean exim), can simply set the outgoing transport to strip the headers. 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 wheakory@isu.edu Tue Apr 10 16:04:38 2001 From: wheakory@isu.edu (Kory Wheatley) Date: Tue, 10 Apr 2001 09:04:38 -0600 Subject: [Mailman-Developers] mailman qrunner error Message-ID: <3AD32106.2F129C48@isu.edu> --------------8BDDE55C1E873FEDFBB22EBD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm recieving this message below every single minute and nothing has changed on our system, which of course is not allowing mail to be received to the mailing list. Our system is (RED HAT 7.0 Mailman 2.0.3 and the right Python Version). (I manage over a 100 lists for our universtity so this is very critical). The web server will not bring up any of the mailman pages. I receive the following error "We have found a Bug mailman 2.0.3". I have been running this version of Mailman ever since it was released and have not had one problem. In the error logfile file "qrunner" it says Could not acquire qrunner lock I shutdown sendmail and the web server and restarted both, but still have the problem. I just thought that would be worth trying. I also have no lock files so no processes are hanging. I ran check_perms and all permissions were set correctly There are also no messages in the "qfiles" directory. Any solution would be helpful and I would really appreciate it. Thank you ahead of time. ----- The following addresses had permanent fatal errors ----- "|/home/mailman/mail/wrapper post ccaus" (expanded from: ) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/scripts/post", line 33, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 30, in ? import socket ImportError: /usr/lib/libcrypto.so.0: undefined symbol: i2d_X509_EXTENSION 554 "|/home/mailman/mail/wrapper post ccaus"... unknown mailer error 1 Reporting-MTA: dns; mm.isu.edu Received-From-MTA: DNS; ux5-250.isu.edu Arrival-Date: Tue, 10 Apr 2001 08:29:14 -0600 Final-Recipient: RFC822; X-Actual-Recipient: RFC822; |/home/mailman/mail/wrapper post ccaus@mm.isu.edu Action: failed Status: 5.0.0 Last-Attempt-Date: Tue, 10 Apr 2001 08:29:14 -0600 Subject: test 2 Date: Tue, 10 Apr 2001 08:28:55 -0600 From: Kory Wheatley To: ccaus@mm.isu.edu -- ######################################### -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. --------------8BDDE55C1E873FEDFBB22EBD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I'm recieving this  message below every single minute and nothing has changed on our system, which of course is not allowing  mail to be received to the mailing list.
Our system is (RED HAT 7.0 Mailman 2.0.3 and the right Python Version).
(I manage over a 100 lists for our universtity so this is very critical).

The web server will not bring up any of the mailman pages. I receive the following error "We have found a Bug  mailman 2.0.3". I have been running this version of Mailman ever since it was released and have not had one problem.

In the error logfile file "qrunner" it says
Could not acquire qrunner lock

I shutdown sendmail and the web server and restarted both, but still have the problem. I just thought that would be worth trying.
I also have no lock files so no processes are hanging.
I ran check_perms and all permissions were  set correctly
There are also no messages in the "qfiles" directory.

Any solution would be helpful and I would really appreciate it. Thank you ahead of time.

  ----- The following addresses had permanent fatal errors -----
"|/home/mailman/mail/wrapper post ccaus"
    (expanded from: <ccaus@mm.isu.edu>)

   ----- Transcript of session follows -----
Traceback (innermost last):
  File "/home/mailman/scripts/post", line 33, in ?
    from Mailman import MailList
  File "/home/mailman/Mailman/MailList.py", line 30, in ?
    import socket
ImportError: /usr/lib/libcrypto.so.0: undefined symbol: i2d_X509_EXTENSION
554 "|/home/mailman/mail/wrapper post ccaus"... unknown mailer error 1
 
 
 

Reporting-MTA: dns; mm.isu.edu
Received-From-MTA: DNS; ux5-250.isu.edu
Arrival-Date: Tue, 10 Apr 2001 08:29:14 -0600

Final-Recipient: RFC822; <ccaus@mm.isu.edu>
X-Actual-Recipient: RFC822; |/home/mailman/mail/wrapper post ccaus@mm.isu.edu
Action: failed
Status: 5.0.0
Last-Attempt-Date: Tue, 10 Apr 2001 08:29:14 -0600
 

 Subject:
        test 2
   Date:
        Tue, 10 Apr 2001 08:28:55 -0600
   From:
        Kory Wheatley <wheakory@isu.edu>
     To:
        ccaus@mm.isu.edu
 
 
 

--
#########################################

--
#########################################
Kory Wheatley
Academic Computing Analyst Sr.
Phone 282-3874
#########################################
Everything must point to him.
  --------------8BDDE55C1E873FEDFBB22EBD-- From barry@digicool.com Tue Apr 10 17:00:15 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 10 Apr 2001 12:00:15 -0400 Subject: [Mailman-Developers] Re: mailman qrunner error References: <3AD32106.2F129C48@isu.edu> Message-ID: <15059.11791.769045.883659@anthem.wooz.org> KW> I'm recieving this message below every single minute and KW> nothing has changed on our system I'll bet you find that not to be the case. ;) First of all, fire up the version of Python you think Mailman is using. Do this interactively and then try to import socket: % python Python 2.0 (#14, Feb 15 2001, 23:45:39) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import socket >>> socket.__file__ '/usr/local/lib/python2.0/socket.pyc' If this works, then MM is using a different Python than the one on your path. If this fails too, then somebody likely rebuilt Python, perhaps enabling the SSL support. That's the only reason I can think of for _socketmodule.so depending on libcrypto. The crash is probably leaving a stale qrunner lock in the locks directory. -Barry From chuqui@plaidworks.com Tue Apr 10 21:47:24 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 13:47:24 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... Message-ID: <200104102046.f3AKk3e20664@lists.apple.com> Been whapping at my big mailman machine the last week, because it's been slowly falling behind and never quite catching up. Unfortunately, it seems like I've simply hit capacity for now, so I'm looking for ways to extend that or at least minimize the damage until 2.1's multi-threading queueing comes online and I can use it (my big problem is the single-threading....) One thing that would help would be if the Sendmail module got productionalized so it could be used instead of SMTPDirect, because then you could use the -deliverymode=defer option, which you can't on SMTPDirect because it disables some spamchecking. But going elbow-deep into the server for a few days under a constant grinding load has brought forward a few things I thought I'd pass on... First, there's a problem with the way queues are processed. qrunners uses: for file in os.listdir(xxxx) to read the queue. The order is undefined, but in practice, it's basically blatting it out how it's stored in the inode. If you're not overly busy, that's fine. But If you start hitting the point where you're backing up, it means you process "N" slots into the directory, then qrunner exits and starts again, and it then re-covers the same directory slots. Things that go in and don't get processed simply NEVER get processed, unless the system quiets down enough to let qrunner to catch up. Qrunner *really* needs to process the queue FIFO. Unfortunately, teaching qrunner to go FIFO is a bit complicated. you'd have to pull all of the filenames out, stat them all, and then sort that. There's a much easier solution, though -- In Mailman/Message.py where the filename si created, mailman uses time.time() and some other values to create a filename, which is then converted to hex. the idea is to create a unique filename. But in fact, time.time() should be unique (to be paranoid, one could grab it and then check to see if the filename exists and loop), and if you stored the queue files as "time.time()".msg/.db, then qrunner could sort the queue trivially, guaranteeing that the oldest messages are always processed in each queue run. This creates some interesting race conditions, where an item is added to the queue and never comes out -- which causes people to think it's lose and repost it, adding to the queue clogging, which slows stuff, which... until Saturday, when they all go home, the system slows down, and qrunner catches up and posts three day old messages.... And since the system seems to be working just fine, tracking it down is fun... This also led to finding a problem in the bounce processing area. The bouncer works pretty well, but it has one flaw for which I don't have an easy answer. If I'm subscribed as "chuq@plaidworks.com", but for some reason the bounce comes back as "chuq@mail.plaidworks.com" (or vice versa, or if I'm forwarding mail in some other name), the bouncer will catch the bounce and try to process it, not find me, and log it as a "user not subscribed". Unless the admin is somehow post-processing the bounce logs, though, that bounce is never REALLY handled, so it bounces indefinitely, and the admin never knows. This also over time encourages queue clogging and wastes bandwidth and CPU and all of that -- and worse, list admins and site admins probably think everything is fine because the bouncing system is working and these "not a member" bounces are never reported anywhere. On the other, other hand, you probably don't want to just blat all these at admins, since they'll tune them out. But some kind of nightly report of some sort is the tradeoff I'd make, I think, so admins could see continual bounce problems that need to be manually investigated. And I strongly recommend all site admins watch the bounce logs and look for these "missing" bounces, so they can be manually tracked. I found on my busy site this made a HUGE difference in my queue backlogs, too; these things were silently contributing a significant amount of traffic to the queue system and exacerbating my capacity issues. I really think the qrunner issue needs to be dealt with; it only shows up on fairly busy sites, but it's a definite bug for folks like me. The bouncer issue is less nasty, but in a "good citizens clean up their trash" attitude, I think we need to at least make sure list/site admins are aware of these bouncers, unless someone can figure out a way to automate fixing them (this is a place where VERP type things could help, but I'm not going there, honest... giggle) chuq -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. The first rule of holes: If you are in one, stop digging. From chuqui@plaidworks.com Tue Apr 10 22:02:24 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 14:02:24 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <200104102046.f3AKk3e20664@lists.apple.com> Message-ID: <200104102101.f3AL12e23657@lists.apple.com> On Tuesday, April 10, 2001, at 01:47 PM, chuq von rospach wrote: > This creates some interesting race conditions, where an item is added > to the queue and never comes out A way to minimize this, by the way, are to tweak the values: QRUNNER_PROCESS_LIFETIME QRUNNER_MAX_MESSAGES in mm_cfg.py (see Defaults.py for their definitions). By default, they're 15 minutes and 300. That means qrunner quits 4 times an hour, even if the queue isn't done, or after processing 300 messages. So if you have a queue that files to, oh, 450 messages, the first 300 get processed (or less), and as they're processing, the deleted files are replaced with new ones in the directory inode, and then qrunner quits and starts over. Whatever's over that highwater mark is basically stuck in the queue until the system goes idle, and if it never quite goes idle -- you're hosed. I've changed mind to 30 minutes and a MAX of 0 (disabling that check), so that it'll run with as few quits and interruptions as possible, the idea being you want it to process deep into your queue. You can't set LIFETIME too high without risking a hung qrunner taking out the system indefinitely, and if you make it too long, you'll need to tweak other lockfile values (see Defaults.py, if you need any of this, you should be able to figure out which ones need to be tweaked...) -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I tried to get a life once, but they were out of stock. From chuqui@plaidworks.com Tue Apr 10 22:08:12 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 14:08:12 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <200104102101.f3AL12e23657@lists.apple.com> Message-ID: <200104102106.f3AL6oe24147@lists.apple.com> On Tuesday, April 10, 2001, at 02:02 PM, chuq von rospach wrote: > I've changed mind to 30 minutes and a MAX of 0 (disabling that check), Sigh. For "0" read "None" -- It's looking for the text string. IMHO, that's confusing at first glance, but I need to read the documentation more closely. But also, IMHO, it should accept "0" as the same as None.... Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. The Pinball Machine Rule is the observation that it doesn't matter a wit if the instructions are printed clearly for all to see, nobody will read them. They'll just drop their quarter(s) and start pushing buttons like a Tommy. -- Barry Warsaw From csf@moscow.com Wed Apr 11 00:47:21 2001 From: csf@moscow.com (Michael Yount) Date: Tue, 10 Apr 2001 16:47:21 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <200104102046.f3AKk3e20664@lists.apple.com>; from chuqui@plaidworks.com on Tue, Apr 10, 2001 at 01:47:24PM -0700 References: <200104102046.f3AKk3e20664@lists.apple.com> Message-ID: <20010410164721.C488@moscow.com> If relaying on loopback connections is acceptable, there is a simple way to disable lookups during RCPT TO in Sendmail 8.10.0 and later. See http://csf.colorado.edu/archive/2000/mj2-dev/msg02259.html for more information. Chuq, have you tried this approach? Michael On 10 Apr 13:47, chuq von rospach wrote: > > Been whapping at my big mailman machine the last week, because it's been > slowly falling behind and never quite catching up. Unfortunately, it > seems like I've simply hit capacity for now, so I'm looking for ways to > extend that or at least minimize the damage until 2.1's multi-threading > queueing comes online and I can use it (my big problem is the > single-threading....) > > One thing that would help would be if the Sendmail module got > productionalized so it could be used instead of SMTPDirect, because then > you could use the -deliverymode=defer option, which you can't on > SMTPDirect because it disables some spamchecking. > From marc_news@valinux.com Wed Apr 11 06:12:35 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 10 Apr 2001 22:12:35 -0700 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <20010409003728.00098@scfn.thpl.lib.fl.us>; from jra@baylink.com on Mon, Apr 09, 2001 at 12:37:28AM -0400 References: <20010408152322.A6510@magic.merlins.org> <20010409003728.00098@scfn.thpl.lib.fl.us> Message-ID: <20010410221235.A8861@magic.merlins.org> On Mon, Apr 09, 2001 at 12:37:28AM -0400, Jay R. Ashworth wrote: > On Sun, Apr 08, 2001 at 03:23:22PM -0700, Marc MERLIN wrote: > > From: David E.Fox > > (Note that this From field is invalid as per RFC 822, because it's missing > > the double quotes. The user uses Kmail and it's a kmail bug). > > Yes, but note that it's *still* parseable, since the error is *outside* > the bra-kets; Correct. I haven't found the right piece of code in mailman yet, but it smells like a regular expression that grabs the wrong pattern and ends up with davide.fox instead of dfox@m206-157.dsl.tsoft.com > it's arguable whether being pedantic *here* is productive, > under the "be conservative what you send, liberal what you accept" Yeah, I know about all this, I just wanted to point out that it wasn't just mailman that was buggy, it was a mishandling of a non common not really valid case, although it happens in real life. > principle. And yes, I *know* that someone's program, somewhere, has to > be a hard ass... I just don't know whether it's "ours" (:-) or not... Exim is very good at that, but it's an option. In mailman it's not :-) (nor is it really intentional) 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 barry@digicool.com Wed Apr 11 07:36:39 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 02:36:39 -0400 Subject: [Mailman-Developers] Mailman 2.0 usage notes... References: <200104102046.f3AKk3e20664@lists.apple.com> Message-ID: <15059.64375.932030.793628@anthem.wooz.org> >>>>> "cvr" == chuq von rospach writes: cvr> One thing that would help would be if the Sendmail module got cvr> productionalized so it could be used instead of SMTPDirect, cvr> because then you could use the -deliverymode=defer option, cvr> which you can't on SMTPDirect because it disables some cvr> spamchecking. I'd love for this to happen, but someone else is going to have to do the heavy lifting. It's just not that important to me since most MTAs can be configured to defer DNS resolution for localhost relays (as I think Michael Yount suggested for sendmail). cvr> First, there's a problem with the way queues are cvr> processed. qrunners uses: cvr> for file in os.listdir(xxxx) cvr> to read the queue. The order is undefined, but in practice, cvr> it's basically blatting it out how it's stored in the cvr> inode. In MM2.1, we essentialy do the same os.listdir() but we shuffle the files randomly before looping over them. Also, the resource controls in MM2.0 are there because I was worried about things like cyclic garbage bloating the qrunner process. Requiring Python 2.0 is a double win here because it's got cyclic garbage collection and I can use random.shuffle(). So I can get rid of the process limits and just run the loop infinitely. This combined with the parallelizability of the qrunner processes, and the splitting of the queue directories should, I think, solve the problems you're seeing. cvr> This also led to finding a problem in the bounce processing cvr> area. The bouncer works pretty well, but it has one flaw for cvr> which I don't have an easy answer. Several comments. I intend to add a feature to MM (tho' probably not until 3.0) that would let users register mutiple addresses under a single account. Thus I could teach Mailman that anything coming from barry@digicool.com or barry@wooz.org is really from me and should not be held. This would allow the bounce matching code to match disparate email addresses -- at the cost of cooperation from the user or list admin. OTOH, matching "bwarsaw@python.org" with "bwarsaw@mail.python.org" regardless of which is in the bounce and which is in the database, ought to be easy to manage (and I'm a little surprised the code doesn't already do this). See SMART_ADDRESS_MATCH in Defaults.py for a variable that controls this in other contexts. Mind submitting a bug report about this? cvr> If I'm subscribed as "chuq@plaidworks.com", but for some cvr> reason the bounce comes back as "chuq@mail.plaidworks.com" cvr> (or vice versa, or if I'm forwarding mail in some other cvr> name), the bouncer will catch the bounce and try to process cvr> it, not find me, and log it as a "user not cvr> subscribed". Unless the admin is somehow post-processing the cvr> bounce logs, though, that bounce is never REALLY handled, so cvr> it bounces indefinitely, and the admin never knows. MM should be keeping much better stats about its operation, e.g. # of messages per list received, delivered, etc. Include in this a report about bounces that hit non-members. cvr> This also over time encourages queue clogging and wastes cvr> bandwidth and CPU and all of that -- and worse, list admins cvr> and site admins probably think everything is fine because the cvr> bouncing system is working and these "not a member" bounces cvr> are never reported anywhere. In MM2.1, you could tune the bounce qrunner to work less often, giving priority to the incoming and outgoing queues. cvr> On the other, other hand, you probably don't want to just cvr> blat all these at admins, since they'll tune them out. But cvr> some kind of nightly report of some sort is the tradeoff I'd cvr> make, I think, so admins could see continual bounce problems cvr> that need to be manually investigated. Good idea! -Barry From barry@digicool.com Wed Apr 11 07:37:48 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 02:37:48 -0400 Subject: [Mailman-Developers] Mailman 2.0 usage notes... References: <200104102101.f3AL12e23657@lists.apple.com> <200104102106.f3AL6oe24147@lists.apple.com> Message-ID: <15059.64444.591681.810459@anthem.wooz.org> >>>>> "cvr" == chuq von rospach writes: cvr> Sigh. For "0" read "None" -- It's looking for the text cvr> string. cvr> IMHO, that's confusing at first glance, but I need to read cvr> the documentation more closely. But also, IMHO, it should cvr> accept "0" as the same as None.... No longer relevant for 2.1, but if there is a 2.0.4 (and I don't see a need at the moment), it would be good to fix. -Barry From barry@digicool.com Wed Apr 11 07:49:15 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 02:49:15 -0400 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses References: <20010408152322.A6510@magic.merlins.org> <20010409003728.00098@scfn.thpl.lib.fl.us> <20010410221235.A8861@magic.merlins.org> Message-ID: <15059.65131.38792.716734@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Correct. I haven't found the right piece of code in mailman MM> yet, but it smells like a regular expression that grabs the MM> wrong pattern and ends up with davide.fox instead of MM> dfox@m206-157.dsl.tsoft.com I suspect the problem is in Python's rfc822 module: >>> a = rfc822.AddrlistClass('David E.Fox ') >>> a.getaddrlist() [('', 'DavidE.Fox'), ('', 'dfox@m206-157.dsl.tsoft.com')] Mailman, interestingly enough, has Utils.ParseAddrs() which appears to try to work around problems in rfc822: >>> ParseAddrs('David E.Fox ') 'dfox@m206-157.dsl.tsoft.com' which seems to suck out the right address in this case. What should probably in MM2.1 is for MailList.HasExplicitDest() to fallback on the output of ParseAddrs() if the rfc822 method doesn't match. -Barry From chuqui@plaidworks.com Wed Apr 11 07:57:24 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 23:57:24 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <15059.64375.932030.793628@anthem.wooz.org> Message-ID: <200104110650.f3B6odi04544@plaidworks.com> On Tuesday, April 10, 2001, at 11:36 PM, Barry A. Warsaw wrote: > I'd love for this to happen, but someone else is going to have to do > the heavy lifting. yah. If I have time, but I think I'd rather put that time into evaluating and moving to postfix, myself. > In MM2.1, we essentialy do the same os.listdir() but we shuffle the > files randomly before looping over them. I'd really recommend FIFO, Barry. I kinow when my queue starts shuffling, it drives my users crazy (because they write to ask why stuff's coming out of sequence). The end-users really seem to expect FIFO, or at least mostly FIFO. It becomes a lot more important with digest users -- they freak when stuff comes in the digest randomized. > run the loop infinitely. This combined with the parallelizability of > the qrunner processes, and the splitting of the queue directories > should, I think, solve the problems you're seeing. yup. I'm not expecting it to be fixed in 2.0.x as much as making sure it's taken into consideration for 2.1 -- because I know even with the parallelization, we'll still run into servers big enough to have to worry about it (mine sure seems headed there...) > Several comments. I intend to add a feature to MM (tho' probably not > until 3.0) that would let users register mutiple addresses under a > single account. Yes, I'm getting more and more requests for this. > OTOH, matching "bwarsaw@python.org" with "bwarsaw@mail.python.org" > regardless of which is in the bounce and which is in the database, warning, plot complication. warning, plot complication. You can't assume this to be true for third level domains. Overseas, it's NOT true -- because in many cases, the third level of the domain is the equivalent to the second level in .com. So if you assume that fred@anglican.co.uk is the same as fred@catholic.co.uk, you just messed up badly, because anglican and catholic are different companies. You run into a rathole here REAL fast, because the assumptions that are true for .com, .edu, and .net aren't true for the country domains, where in many cases, it all bumps out one sub-level (foo.com.br, boo.edu.pl, etc) > Mind submitting a bug report about this? > yeah, I'll get it in as soon as I can. > In MM2.1, you could tune the bounce qrunner to work less often, giving > priority to the incoming and outgoing queues. > parallelism solves my problem, since the machine in hand is an E250 with two cpu's, one of which is really bored... -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. USENET is a lot better after two or three eggnogs. We shouldn't allow anyone on the net without a bottle of brandy. (chuq von rospach, 1992) From conny@cendio.se Wed Apr 11 13:10:12 2001 From: conny@cendio.se (Conny Andersson) Date: Wed, 11 Apr 2001 14:10:12 +0200 Subject: [Mailman-Developers] Multilanguage support in Mailman. Message-ID: <3AD449A4.DDD4CB77@cendio.se> Hi, I just entered the list and thought I could share a beta release of a Swedish translation of the templates and HTMLFormatter.py files. I'm not sure how to incorporate the changes to Mailman (I have just made symbolic links in my setup) but one suggestion could be to have an option for every user to choose their desired language. You can find the tar file at=20 http://conny.nu/mailman-swe.tar.gz Best, Conny .................................................... Conny Andersson Work Area: Embedded Systems Cendio Systems AB Direct: +46(0)13 290882 Teknikringen 3 Mobile: +46(0)707 452066 583 30 Link=F6ping Fax: +46(0)13 214700 Sweden Internet: www.cendio.com From holmberg@iar.se Wed Apr 11 15:03:39 2001 From: holmberg@iar.se (Johan Holmberg) Date: Wed, 11 Apr 2001 16:03:39 +0200 (MEST) Subject: [Mailman-Developers] Patch for non-ASCII characters in Subject line Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-2110444415-986997469=:13982 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hello mailman-developers ! I have for a long time been annoyed by the fact that Mailman adds more than one copy of the mailing-list-prefix to the Subject line in replies sent to a list. This can occur if the Subject line contains non-ASCII characters (this has been reported in the bug-database as bug #230400: "German Umlaute mess up subject-line and body"). It looks something like (if you can view this in your mailers :-)): Subject: Re: [Test] Re: [Test] r=E4kms=F6rg=E5s The reason seems to be that Mailman has the following "algorithm" to decide what to do: - add list-name-prefix (if it isn't already there) instead of the more correct: - MIME-decode the subject - add list-name-prefix (if it isn't already there) - MIME-reencode the subject If no MIME-decoding is done, Mailman can fail to detect the precense of a mailing-list-prefix, since the prefix can be "buried" in the MIME-encoded stuff. I have made a patch to "CookHeaders.py" that fixes this problem, and implements the second alternative above (see the attached patch). Could something like this be added to future versions of Mailman ?? (I don't know if I have made the change the right way (I'm not a Python programmer)). /Johan Holmberg ---559023410-2110444415-986997469=:13982 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="mailman-subject-patch.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="mailman-subject-patch.txt" KioqIENvb2tIZWFkZXJzLnB5Lm9yaWcJRnJpIEZlYiAxNiAxMzo0MDoxOSAy MDAxDQotLS0gQ29va0hlYWRlcnMucHkJV2VkIEFwciAxMSAxNDowMDoxNyAy MDAxDQoqKioqKioqKioqKioqKioNCioqKiAyMCwyOCAqKioqDQotLS0gMjAs NTIgLS0tLQ0KICBpbXBvcnQgc3RyaW5nDQogIGltcG9ydCByZQ0KICBpbXBv cnQgdXJscGFyc2UNCisgaW1wb3J0IG1pbWlmeQ0KKyANCiAgZnJvbSBNYWls bWFuIGltcG9ydCBtbV9jZmcNCiAgDQogIA0KKyAjLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KKyAjIFRoaXMgZnVuY3Rpb24gTUlNRS1kZWNvZGVzIHRo ZSBzdWJqZWN0IGJlZm9yZSBkZWNpZGluZyBpZiBhDQorICMgcHJlZml4IHNo b3VsZCBiZSBhZGRlZC4gSUYgd2UgY2hhbmdlIHRoZSBzdWJqZWN0IHdlIGhh dmUgdG8NCisgIyAicmVlbmNvZGUiIGl0IGJlZm9yZSBzZW5kaW5nIGl0Lg0K KyAjDQorICMgVGhpcyBpcyBhICJoYWNrIiBtYWRlIGJ5IEpvaGFuIEhvbG1i ZXJnIDxob2xtYmVyZ0BpYXIuc2U+Lg0KKyAjIFNlZW1zIHRvIHdvcmssIGJ1 dCBJJ20gbm8gUHl0aG9uIHByb2dyYW1tZXIgKHByZWZlcnMgUGVybC9SdWJ5 IDotKSkNCisgIyBVc2UgaXQgYXQgeW91ciBvd24gcmlzay4NCisgIw0KKyAN CisgZGVmIGFkZF9wcmVmaXgocHJlZml4LHN1YmplY3QpOg0KKyAgICAgaWYg bm90IHByZWZpeDogcmV0dXJuIHN1YmplY3QNCisgICAgIHRleHQgPSBtaW1p ZnkubWltZV9kZWNvZGVfaGVhZGVyKHN1YmplY3QpDQorICAgICBpZiByZS5z ZWFyY2gocmUuZXNjYXBlKHByZWZpeCksIHRleHQsIHJlLkkpOg0KKyAgICAg ICAgIHJldHVybiBzdWJqZWN0DQorICAgICBlbHNlOg0KKyAgICAgICAgIHRl eHQgPSBwcmVmaXggKyBzdWJqZWN0DQorICAgICAgICAgdGV4dCA9IG1pbWlm eS5taW1lX2VuY29kZV9oZWFkZXIodGV4dCkNCisgICAgICAgICByZXR1cm4g dGV4dA0KKyANCisgIy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCisgDQog IAwNCiAgZGVmIHByb2Nlc3MobWxpc3QsIG1zZywgbXNnZGF0YSk6DQogICAg ICAjIE1hcmsgdGhlIG1lc3NhZ2UgYXMgZGlydHkgc28gdGhhdCBpdHMgdGV4 dCB3aWxsIGJlIGZvcmNlZCB0byBkaXNrIG5leHQNCioqKioqKioqKioqKioq Kg0KKioqIDQ4LDU1ICoqKioNCiAgICAgICAgICAjIHdlIHB1cnBvc2VmdWxs eSBsZWF2ZSBubyBzcGFjZSBiL3cgcHJlZml4IGFuZCBzdWJqZWN0IQ0KICAg ICAgICAgIGlmIG5vdCBzdWJqZWN0Og0KICAgICAgICAgICAgICBtc2dbJ1N1 YmplY3QnXSA9IHByZWZpeCArICcobm8gc3ViamVjdCknDQohICAgICAgICAg ZWxpZiBwcmVmaXggYW5kIG5vdCByZS5zZWFyY2gocmUuZXNjYXBlKHByZWZp eCksIHN1YmplY3QsIHJlLkkpOg0KISAgICAgICAgICAgICBtc2dbJ1N1Ympl Y3QnXSA9IHByZWZpeCArIHN1YmplY3QNCiAgICAgICMNCiAgICAgICMgZ2V0 IHJpZCBvZiBkdXBsaWNhdGUgaGVhZGVycw0KICAgICAgZGVsIG1zZ1snc2Vu ZGVyJ10NCi0tLSA3Miw3OSAtLS0tDQogICAgICAgICAgIyB3ZSBwdXJwb3Nl ZnVsbHkgbGVhdmUgbm8gc3BhY2UgYi93IHByZWZpeCBhbmQgc3ViamVjdCEN CiAgICAgICAgICBpZiBub3Qgc3ViamVjdDoNCiAgICAgICAgICAgICAgbXNn WydTdWJqZWN0J10gPSBwcmVmaXggKyAnKG5vIHN1YmplY3QpJw0KISAgICAg ICAgIGVsaWYgcHJlZml4Og0KISAgICAgICAgICAgICBtc2dbJ1N1YmplY3Qn XSA9IGFkZF9wcmVmaXgocHJlZml4LHN1YmplY3QpDQogICAgICAjDQogICAg ICAjIGdldCByaWQgb2YgZHVwbGljYXRlIGhlYWRlcnMNCiAgICAgIGRlbCBt c2dbJ3NlbmRlciddDQo= ---559023410-2110444415-986997469=:13982-- From barry@digicool.com Wed Apr 11 15:42:43 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 10:42:43 -0400 Subject: [Mailman-Developers] Mailman 2.0 usage notes... References: <15059.64375.932030.793628@anthem.wooz.org> <200104110650.f3B6odi04544@plaidworks.com> Message-ID: <15060.28003.574078.622751@anthem.wooz.org> >>>>> "cvr" == chuq von rospach writes: cvr> I'd really recommend FIFO, Barry. I kinow when my queue cvr> starts shuffling, it drives my users crazy (because they cvr> write to ask why stuff's coming out of sequence). The cvr> end-users really seem to expect FIFO, or at least mostly cvr> FIFO. It becomes a lot more important with digest users -- cvr> they freak when stuff comes in the digest randomized. Bling! Of course. Excellent point. cvr> You can't assume this to be true for third level cvr> domains. Overseas, it's NOT true -- because in many cases, cvr> the third level of the domain is the equivalent to the second cvr> level in .com. So if you assume that fred@anglican.co.uk is cvr> the same as fred@catholic.co.uk, you just messed up badly, cvr> because anglican and catholic are different companies. You cvr> run into a rathole here REAL fast, because the assumptions cvr> that are true for .com, .edu, and .net aren't true for the cvr> country domains, where in many cases, it all bumps out one cvr> sub-level (foo.com.br, boo.edu.pl, etc) Again, good point. Actually SMART_ADDRESS_MATCH would only equivalence fred@catholic.co.uk with fred@co.uk, but that's not right either. I believe all this stuff was added way long ago to help out misconfigured mailers, so maybe that's not as important these days. -Barry From les@2pi.org Wed Apr 11 20:13:32 2001 From: les@2pi.org (Les Niles) Date: Wed, 11 Apr 2001 12:13:32 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <15060.28003.574078.622751@anthem.wooz.org> (barry@digicool.com) References: <15059.64375.932030.793628@anthem.wooz.org> <200104110650.f3B6odi04544@plaidworks.com> <15060.28003.574078.622751@anthem.wooz.org> Message-ID: <200104111913.MAA20033@mutiny.2pi.org> On Wed, 11 Apr 2001 10:42:43 -0400 barry@digicool.com (Barry A. Warsaw) wrote: > cvr> You can't assume this to be true for third level > cvr> domains. Overseas, it's NOT true -- because in many cases, > cvr> the third level of the domain is the equivalent to the second > cvr> level in .com. So if you assume that fred@anglican.co.uk is > cvr> the same as fred@catholic.co.uk, you just messed up badly, > cvr> because anglican and catholic are different companies. You > cvr> run into a rathole here REAL fast, because the assumptions > cvr> that are true for .com, .edu, and .net aren't true for the > cvr> country domains, where in many cases, it all bumps out one > cvr> sub-level (foo.com.br, boo.edu.pl, etc) > >Again, good point. Actually SMART_ADDRESS_MATCH would only >equivalence fred@catholic.co.uk with fred@co.uk, but that's not right >either. I believe all this stuff was added way long ago to help out >misconfigured mailers, so maybe that's not as important these days. How about a goodness-of-match algorithm? fred@catholic.co.uk matches itself with an error of 0, matches fred@co.uk with an error of 1, matches fred@anglican.co.uk with an error of 2, and matches everything else with an infinite error. If the address in the bounce has a unique minimum-error match with a subscriber address (there's only one address that matches with that minimum error) then that is used, otherwise it's considered unmatchable. It seems like this would handle most of the common cases and would very rarely screw up, since bounces ought to have been generated by some subscriber. (OK, it would be nice to also recognize that fredsmith@foo.bar and fsmith@mail.foo.bar are the same person, but that's getting a little carried away....) -les From todd@connactivity.connactivity.com Thu Apr 12 04:35:21 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Wed, 11 Apr 2001 23:35:21 -0400 Subject: [Mailman-Developers] Urgent: Duplicates with 2.0 final Message-ID: <200104120335.f3C3ZLr20523@connactivity.connactivity.com> Sorry for sending this to developers and users. I'm not sure which group is more appropriate. I've been using 2.0 final for a couple of months now without a problem. I've got roughly 60,000 people on my mailing list and I'm using sendmail as the MTA on RH6.2. The list is moderated and there is only 1-2 messages a month. The last message sent to the list was sent to some subscribers twice. I had seen the problem before with 2.0rc1. From the release notes for 2.0rc2, that is documented as fixed (bug #117015) (see below). Anyone know why I would see it happen again in 2.0 Final? Here's what I've done: (1) Scanned the Archives. Found a post to mailman-users with no reply that seems related. http://mail.python.org/pipermail/mailman-users/2001-April/010625.html (2) Looked through Syslog logs for System and Sendmail errors. Nothing unusual reported. (3) Looked through the Mailman logs dir (/home/mailman/logs). Nothing out of the orinary except in the errors file (see below). What's strange about this is the duplicate message had already been sent by this time (the few duplicates checked showed 1st delivery at ~8PM April 6 and subsequent delivery at ~2:30AM April 7 -- all times synced with NTP on systems tested). Excerpt from /home/mailman/logs/errors: Apr 07 04:09:18 2001 qrunner(16818): Traceback (innermost last): Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line 278, in ? Apr 07 04:09:18 2001 qrunner(16818): kids = main(lock) Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line 256, in main Apr 07 04:09:18 2001 qrunner(16818): dequeue(root) Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line 184, in dequeue Apr 07 04:09:18 2001 qrunner(16818): os.unlink(root + '.db') Apr 07 04:09:18 2001 qrunner(16818): OSError : [Errno 2] No such file or directory: '/home/mailman/qfiles/c879896f57e6392365c42f995f13c09de378bbcd.db' (cut-n-paste for 2.0rc2 release notes)... >SourceForge bugs fixed: 116615 (README.BSD update), 117015 (duplicate >messages on moderated posts), 117548 (exception in HyperArch.py), >117682 (typos), 121185 (vsnprintf signature), 121591 and 122017 (bogus >link after web unsubscribe), 121811 (`subscribe' in Subject: doesn't >get archived) Help... From benwa@ocentrix.com Fri Apr 13 02:58:31 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 12 Apr 2001 18:58:31 -0700 Subject: [Mailman-Developers] Documentation for announce only lists Message-ID: <200104130158.f3D1wVe25260@mail.ocentrix.net> Hey all, My company is in the process of implementing Mailman to provide announcement lists for our hosting clients. I have been playing with 2.0.1 to 2.0.3 for the past two months and have come up with what I think is a pretty good (and very verbose) description of how to set up an announce only list. Judging by the amount of traffic on this topic here and on the mailman-users list I though it would be a good idea to submit it. Please excuse the verbosity of my description as I was trying to make the description easy to understand by those who are new to Mailman. I was also trying to take into account the different ways that I thought someone would want to run an announcement list. I have tested each of the methods outlined in the description and it all seems to work well, but I would like to get some more opinions before I post it to the mailman-users list. If anyone finds the descritption usefull please feel free to use it however you like. instructions follow: -------------------- Managing announce only lists. INTRODUCTION Keep in mind that some of the techniques below require making changes that will affect how your Mailman installation will manage all of its lists. Wherever this is an issue it has been pointed out. If you choose to use any of these techniques It might be a good idea to run separate installations of Mailman for discussion lists and announcement lists. If you would like to do this there are some additional tips listed at the end of the instructions. In order to run an announcement list with Mailman you'll need to configure a regular list to allow only certain addresses to post to the list. You should create the list as you would any other list. and make a few changes to the it through the web based administrative interface. An announce only list may require some additional maintenance if you frequently have unauthorized posters attempting to post to the list. BASIC CHANGES In the administrative interface under Privacy options set the following fields as shown. Must posts be approved by an administrator? No Restrict posting privilege to list members? No Then place the e-mail addresses of all of those who are authorized to post announcements in the field "Addresses of members accepted for posting to this list without implicit approval requirement." This will limit all posts to the list to those who are listed. Unfortunately(?) all posts to the list by unauthorized posters will still show up in the "Tend to pending administrative requests" area of the administrative interface. List administrators will also receive an email for each of these posts telling them that they have an administrative request pending. This email can be disabled under General options by setting the field "Should administrator get immediate notice of new requests, as well as daily notices about collected ones?" to "No". This might be a bad idea because this also turns off emails that refer to other types of administrative requests that may need approval such as subscribes and unsubscribes. However, administrators will still receive a notice of any pending administrative requests at 5PM every day. MAINTAINING ANNOUNCE ONLY LISTS Mailman does not come with any easy way to automate tending to the administrative requests that are holding unauthorized posters' emails for approval. I have found that there are different ways to get rid of them manually. Each method has its pros and it's cons. In deciding how to get rid of these unauthorized posts one should consider whether they want the unauthorized poster to know anything about the fact that their post has been held. Under General options the field "Send mail to poster when their posting is held for approval?" will determine... exactly that. If you set this to "Yes" the poster will receive an email based on the contents of the template: (/your_mailman_install_directory/templates/postheld.txt). This template can be modified to explain that they have posted to a list that is for announcements only. And that they have posted from an address that is not authorized for posting. This is a site-wide template, so any changes you make to it will affect all lists. The method used to actually tend to the unauthorized post will also affect how much the poster knows about the posting process. If you choose "reject" in handling the post the poster will receive an email based on the contents of the template: (/your_mailman_install_directory/templates/refuse.txt) combined with the text explanation offered in the text box marked "If you reject this post, please explain (optional)". However, if you choose "discard" the poster will not receive an email at all. Make sure that you tend to these requests frequently because if they are not dealt with they can build up to a very long list on the administrative request management page. These requests will be mixed together with any other types of requests that may be pending. CLOSING These are the basic steps in managing an announcement list with Mailman. There are many other tweaks and changes that you can make to optimize your Mailman install for announcement only lists, such as modifying the templates for each list or for the site. And setting some default values for list creation in mm_cfg.py. And of course since Mailman is an open source project written in Python you could always sit down and learn some Python. Python is a great language that is being used in more and more places for all kinds of projects. With basic to intermediate Python skills you can make some other changes to the Mailman scripts that will make managing announcement only lists a lot easier. As your skills progress you can even help to develop Mailman into exactly the mailing list manager that you are looking for. Wouldn't it be great if you could help to contribute to this wonderful list manager that was given to you freely? RUNNING A SEPERATE ANNOUNCE ONLY INSTALLATION If you are running a separate installation of Mailman for announcement lists only you might make a couple of the changes below. 1. In the file mm_cfg.py, set the variable "DEFAULT_DIGESTABLE = 0" set to make list digests unavailable since announce only lists will not have much traffic. 2. If your announcement lists have very low traffic you might consider redefining the variable "DEFAULT_ARCHIVE_VOLUME_FREQUENCY" in mm_cfg.py. Setting it to "2" will create quarterly archives and setting it to "0" will create yearly archives. 3. If your list admins really don't like the 5PM reminders of requests pending authorization These emails can be disabled by removing or commenting out the second line below in the mailman user's crontab. # At 5PM every day, mail reminders to admins as to pending requests 2 0 17 * * * /usr/bin/python -S /your_mailman_install_directory/cron/checkdbs I *strongly* recommend against doing this however because this will turn off ALL 5PM pending request reminders for ALL lists managed by this Mailman installation. As mentioned above This might be a bad idea because this also turns off emails that refer to other types of administrative requests that need approval such as subscribes and unsubscribes. -------------------- Thank you for your help. - Ben Burnett From Dan Mick Fri Apr 13 03:48:53 2001 From: Dan Mick (Dan Mick) Date: Thu, 12 Apr 2001 19:48:53 -0700 (PDT) Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses Message-ID: <200104130248.TAA07922@utopia.West.Sun.COM> > > >>>>> "MM" == Marc MERLIN writes: > > MM> Correct. I haven't found the right piece of code in mailman > MM> yet, but it smells like a regular expression that grabs the > MM> wrong pattern and ends up with davide.fox instead of > MM> dfox@m206-157.dsl.tsoft.com > > I suspect the problem is in Python's rfc822 module: > > >>> a = rfc822.AddrlistClass('David E.Fox ') > >>> a.getaddrlist() > [('', 'DavidE.Fox'), ('', 'dfox@m206-157.dsl.tsoft.com')] > > Mailman, interestingly enough, has Utils.ParseAddrs() which appears to > try to work around problems in rfc822: > > >>> ParseAddrs('David E.Fox ') > 'dfox@m206-157.dsl.tsoft.com' > > which seems to suck out the right address in this case. What should > probably in MM2.1 is for MailList.HasExplicitDest() to fallback on the > output of ParseAddrs() if the rfc822 method doesn't match. I'm coming to this late, but: we all agree that David E.Fox is not a legal RFC822 address, right? Strings containing spaces must-repeat-must be enclosed in doublequotes: "David E.Fox" I see the subject, but: why is this considered to be a "problem" in rfc822, rather than a problem in the mail format? I would expect other MTAs and MUAs to barf on this too. From schorsch@schorsch.com Fri Apr 13 04:27:55 2001 From: schorsch@schorsch.com (Georg Mischler) Date: Thu, 12 Apr 2001 23:27:55 -0400 (EDT) Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <200104130248.TAA07922@utopia.West.Sun.COM> Message-ID: Dan Mick wrote: > > >>>>> "MM" == Marc MERLIN writes: > > > > MM> Correct. I haven't found the right piece of code in mailman > > MM> yet, but it smells like a regular expression that grabs the > > MM> wrong pattern and ends up with davide.fox instead of > > MM> dfox@m206-157.dsl.tsoft.com > > > > I suspect the problem is in Python's rfc822 module: > > > > >>> a = rfc822.AddrlistClass('David E.Fox ') > > >>> a.getaddrlist() > > [('', 'DavidE.Fox'), ('', 'dfox@m206-157.dsl.tsoft.com')] > > > > Mailman, interestingly enough, has Utils.ParseAddrs() which appears to > > try to work around problems in rfc822: > > > > >>> ParseAddrs('David E.Fox ') > > 'dfox@m206-157.dsl.tsoft.com' > > > > which seems to suck out the right address in this case. What should > > probably in MM2.1 is for MailList.HasExplicitDest() to fallback on the > > output of ParseAddrs() if the rfc822 method doesn't match. > > I'm coming to this late, but: we all agree that > > David E.Fox > > is not a legal RFC822 address, right? I can't read this into the RFC document. > Strings containing spaces must-repeat-must be enclosed in > doublequotes: > > "David E.Fox" As far as I can recognize, the standard only requires quotes when such whitespace characters are present within the address part (inside the <...>). The rest of the string is regarded as comment, and may pretty much take any form. There are actually numerous examples in the RFC document that contain spaces in this comment part, where the comment part is *not* enclosed in any quotes. > I see the subject, but: why is this considered to be a "problem" > in rfc822, rather than a problem in the mail format? I would > expect other MTAs and MUAs to barf on this too. This is indeed a problem with the rfc822 modle, assuming that the following text in the standard document (copied literally) is to be taken seriously: EXAMPLES A.1. ADDRESSES A.1.1. Alfred Neuman A.1.2. Neuman@BBN-TENEXA These two "Alfred Neuman" examples have identical seman- tics, as far as the operation of the local host's mail sending (distribution) program (also sometimes called its "mailer") and the remote host's mail protocol server are concerned. In the first example, the "Alfred Neuman" is ignored by the mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- pient. The second example contains no superfluous informa- tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- pient. Since the part within the angle brackets is unambiguously identifyable as the actual address, the parser should just ignore anything else on the same line. It may be wise to use quotes when sending messages, but not accepting something that is explicitly used as a valid example in the standard document seems to be bad style to the very least... Have fun! -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch.com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ From Dan Mick Fri Apr 13 04:39:38 2001 From: Dan Mick (Dan Mick) Date: Thu, 12 Apr 2001 20:39:38 -0700 (PDT) Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses Message-ID: <200104130339.UAA08958@utopia.West.Sun.COM> > > I'm coming to this late, but: we all agree that > > > > David E.Fox > > > > is not a legal RFC822 address, right? > > I can't read this into the RFC document. OK, I retract my claim. I was misled by address = mailbox ; one addressee / group ; named list mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" phrase = 1*word ; Sequence of words word = atom / quoted-string atom = 1* which seems to lead to "phrase can't include spaces without being quoted". But I missed this disclaimer in 3.4.4: The one exception to this rule is that a single SPACE is assumed to exist between contiguous words in a phrase, Sigh. This, of course, makes me wonder why phrase can't include that in its definition, rather than saying "1*word", but there you have it. From fil@rezo.net Fri Apr 13 11:29:28 2001 From: fil@rezo.net (Fil) Date: Fri, 13 Apr 2001 12:29:28 +0200 Subject: [Mailman-Developers] HandlerAPI ? Message-ID: <20010413122928.A13755@orwell.bok.net> Hi, I read somewhere in tha archives that HandlerAPI is deprecated. However it seems that (from a brand new CVS install with mimelib) it is still called from cron/checkdbs and cron/mailpasswds And here's the output of these two scripts : mailman@miel:~$ python cron/mailpasswds Traceback (most recent call last): File "cron/mailpasswds", line 47, in ? from Mailman.Handlers import HandlerAPI ImportError: cannot import name HandlerAPI mailman@miel:~$ python cron/checkdbs Traceback (most recent call last): File "cron/checkdbs", line 30, in ? from Mailman.Handlers import HandlerAPI ImportError: cannot import name HandlerAPI -- Fil From jra@baylink.com Fri Apr 13 17:15:49 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 13 Apr 2001 12:15:49 -0400 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <200104130339.UAA08958@utopia.West.Sun.COM>; from Dan Mick on Thu, Apr 12, 2001 at 08:39:38PM -0700 References: <200104130339.UAA08958@utopia.West.Sun.COM> Message-ID: <20010413121549.50209@scfn.thpl.lib.fl.us> On Thu, Apr 12, 2001 at 08:39:38PM -0700, Dan Mick wrote: > Sigh. This, of course, makes me wonder why phrase can't include that > in its definition, rather than saying "1*word", but there you have it. Because RFC 822 is due for a cleanup and integration with son-of-1036, that's why. Maybe I'll do it. :-} Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From benwa@ocentrix.com Fri Apr 13 17:10:13 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Fri, 13 Apr 2001 09:10:13 -0700 Subject: [Mailman-Developers] Documentation for announce only lists Message-ID: <200104131610.f3DGADh29745@mail.ocentrix.net> Thanks for the feedback. It went to mailman-DEVLOPERS (no E) so I've posted it in its entirety below. I think the screen shots are a good idea. I'll try to Gimp some together this weekend if I can't get our marketing guys to tackle it. I'm not running any lists with high membership currently, so if anyone else has any tips on running large audience announce lists I'd like to include them in the documentation. -Ben ------- Original Copy ------- Subject: Re: [Mailman-Developers] Documentation for announce only lists Date: 04/12/2001 10:40 PM From: Todd Joseph To: benwa@ocentrix.com Cc: mailman-devlopers@python.org Looks good to me. Some screen shots of the Web pages would help break up the descriptions (draw interest). I've been doing much the same myself. I'm frustrated with duplicate messages having been sent with 2.0 Final (IE I sent an announcement and it went to some email addresses twice). I'm not confident how to resolve the problem. I think announce only lists can be much larger than regular lists (one of mine is 60,000). Something that would be nice to have accompany your document is primer on what to watch for. (IE if you are running a large moderated lists with low volume, you may see duplicates when...) From todd@connactivity.connactivity.com Sat Apr 14 02:28:42 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Fri, 13 Apr 2001 21:28:42 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Wed, 11 Apr 2001 23:35:21 EDT." <200104120335.f3C3ZLr20523@connactivity.connactivity.com> Message-ID: <200104140128.f3E1SgS10869@connactivity.connactivity.com> See below for more info. Since I sent this message the first time, I've had 1 reply. I'm thinking I need to include a snappy come-on in my .sig to get everyone's attention. I've learned one more thing, the mailing list had 1 email address with a space in it. The address something like: blahblah@foobar.org and When I tried to remove it, I got an error saying something like "blahblah@foobar.org is not subscribed." I had to quote the bogus address in order to remove it. Could this address have caused duplicate messages to be sent to some subscribers? I'm really at an impasse right now. If I can't reach a comfort level on what has caused the duplicate messages to be sent, I'll have to look for something else to manage my mailing lists. I know people are using mailman sucessfully, and I must be doing something wrong. Oh, and I'm running Python 1.5.2 Help... Todd Joseph todd@connact.com ----------------- > >Sorry for sending this to developers and users. I'm not sure which >group is more appropriate. > >I've been using 2.0 final for a couple of months now without a >problem. I've got roughly 60,000 people on my mailing list and I'm >using sendmail as the MTA on RH6.2. The list is moderated and there >is only 1-2 messages a month. The last message sent to the list was >sent to some subscribers twice. I had seen the problem before with >2.0rc1. From the release notes for 2.0rc2, that is documented as >fixed (bug #117015) (see below). Anyone know why I would see it >happen again in 2.0 Final? > >Here's what I've done: > >(1) Scanned the Archives. Found a post to mailman-users with no reply >that seems related. http://mail.python.org/pipermail/mailman-users/2001-April >/010625.html > >(2) Looked through Syslog logs for System and Sendmail errors. >Nothing unusual reported. > >(3) Looked through the Mailman logs dir (/home/mailman/logs). Nothing >out of the orinary except in the errors file (see below). What's >strange about this is the duplicate message had already been sent by >this time (the few duplicates checked showed 1st delivery at ~8PM >April 6 and subsequent delivery at ~2:30AM April 7 -- all times synced >with NTP on systems tested). > >Excerpt from /home/mailman/logs/errors: > >Apr 07 04:09:18 2001 qrunner(16818): Traceback (innermost last): >Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line > 278, in ? >Apr 07 04:09:18 2001 qrunner(16818): kids = main(lock) >Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line > 256, in main >Apr 07 04:09:18 2001 qrunner(16818): dequeue(root) >Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line > 184, in dequeue >Apr 07 04:09:18 2001 qrunner(16818): os.unlink(root + '.db') >Apr 07 04:09:18 2001 qrunner(16818): OSError : [Errno 2] No such file or dire >ctory: '/home/mailman/qfiles/c879896f57e6392365c42f995f13c09de378bbcd.db' > >(cut-n-paste for 2.0rc2 release notes)... > >>SourceForge bugs fixed: 116615 (README.BSD update), 117015 (duplicate >>messages on moderated posts), 117548 (exception in HyperArch.py), >>117682 (typos), 121185 (vsnprintf signature), 121591 and 122017 (bogus >>link after web unsubscribe), 121811 (`subscribe' in Subject: doesn't >>get archived) > >Help... > >------------------------------------------------------ >Mailman-Users maillist - Mailman-Users@python.org >http://mail.python.org/mailman/listinfo/mailman-users From barry@digicool.com Sat Apr 14 02:46:20 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 13 Apr 2001 21:46:20 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final References: <200104120335.f3C3ZLr20523@connactivity.connactivity.com> <200104140128.f3E1SgS10869@connactivity.connactivity.com> Message-ID: <15063.44012.655280.504033@anthem.wooz.org> >>>>> "TJ" == Todd Joseph writes: TJ> See below for more info. Since I sent this message the first TJ> time, I've had 1 reply. I'm thinking I need to include a TJ> snappy come-on in my .sig to get everyone's attention. Naw, you just have to offer to finish my taxes for me. Fortunately for you, I'm on hold with the IRS so I get to help you . TJ> I've learned one more thing, the mailing list had 1 email TJ> address with a space in it. The address something like: TJ> blahblah@foobar.org and TJ> When I tried to remove it, I got an error saying something TJ> like "blahblah@foobar.org is not subscribed." I had to quote TJ> the bogus address in order to remove it. Could this address TJ> have caused duplicate messages to be sent to some subscribers? Doubtful, but anything's possible. I'd be surprised if it would cause a dup'ing error that didn't show up in the error logs though. TJ> Oh, and I'm running Python 1.5.2 And Mailman 2.0.3? I'd recommend upgrading even though I doubt any of the fixes between 2.0 and 2.0.3 will address your problems. The error your getting in the log file indicates that one of the queued files is getting deleted out from under qrunner. That could be because you're getting multiple qrunner processes because of some locking failure, or because your qrunner lock is getting stomped on. Have you changed any of the default values in your mm_cfg.py (or Defaults.py) file? You ought to see a bunch of "Could not acquire qrunner lock" messages in the logs/qrunner file. Perversely enough, that indicates that qrunner's lock is working. Are you still seeing duplicates, or was this a one-time occurance? Which DELIVERY_MODULE are you using? If SMTPDirect, are you using any of the experimental thread stuff? Are you running a news gateway? That's the one handler that still does an os.fork() so if for some reason your child processes are returning to the main HandlerAPI loop, then that might explain both symptoms. Check your MTA log files. Can you match the duplicate messages with deliveries by your MTA? If Mailman were sending them out twice, you should see each entry in your MTA logs. I know I'm giving you more questions than answers, but I'll definitely need more information before we can figure out your problem. -Barry From todd@connactivity.connactivity.com Sat Apr 14 03:38:47 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Fri, 13 Apr 2001 22:38:47 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Fri, 13 Apr 2001 21:46:20 EDT." <15063.44012.655280.504033@anthem.wooz.org> Message-ID: <200104140238.f3E2clS23684@connactivity.connactivity.com> BW> BW>Naw, you just have to offer to finish my taxes for me. Fortunately BW>for you, I'm on hold with the IRS so I get to help you . I know the feeling. Ever filed an extension? :) BW> BW> TJ> Oh, and I'm running Python 1.5.2 BW> BW>And Mailman 2.0.3? I'd recommend upgrading even though I doubt any of BW>the fixes between 2.0 and 2.0.3 will address your problems. I'm all for going to 2.0.3 but I want to find whatever went wrong first. I'm wary of upgrading any masking/removing the problem before it's found. BW>The error your getting in the log file indicates that one of the BW>queued files is getting deleted out from under qrunner. That could be BW>because you're getting multiple qrunner processes because of some BW>locking failure, or because your qrunner lock is getting stomped on. I kinda thought so. Any ideas on what could cause that? One more tidbit, I have set the "Action when critical or excessive bounces are detected" to "Do nothing" So, I do have a fair number of bogus addresses in my list. My sendmail queue does get kinda large. I've set it up this way out of paranoia in maintaining the integrity of the list (IE not removing valid email addresses). BW>Have you changed any of the default values in your mm_cfg.py (or BW> Defaults.py) file? OK, I'm bad. I changed them in the Defaults.py file. I tried to use the mm_cfg.py file, but ran into a problem (was a few months ago, don't remember what exactly happened). I've included a copy of my "Defaults.py" and "mm_cfg.py" at the bottom of this message for reference. BW>You ought to see a bunch of "Could not BW>acquire qrunner lock" messages in the logs/qrunner file. Perversely BW>enough, that indicates that qrunner's lock is working. :) yes. BW>Are you still seeing duplicates, or was this a one-time occurance? I'm currently using Mailman to send announcements about once a month which are critical to our business. The duplicates were sent with the last announcement and we need to send another next week (wouldn't you know it, Marketing picks this week to send 2 in a month!). I can't send another announcement until I can be sure we won't have any more duplicates. We'll probably outsource next weeks mailing to someone if I can't get this resolved this weekend. BW>Which DELIVERY_MODULE are you using? SMTPDirect (would I be better off with Sendmail?) BW> If SMTPDirect, are you using any of the experimental thread stuff? Not that I know of. See attached Defaults.py and mm_ctg.py for more info. BW> Are you running a news gateway? No. BW>That's the one handler that still does an os.fork() so if for some BW>reason your child processes are returning to the main HandlerAPI loop, BW>then that might explain both symptoms. BW> BW>Check your MTA log files. Can you match the duplicate messages with BW>deliveries by your MTA? If Mailman were sending them out twice, you BW>should see each entry in your MTA logs. Yes, I have 2 different Message-Id's from sendmail 1 for each message delivered. I actually picked that up from the message headers (thanks to "Roger B.A. Klorese" for that pointer). I think Mailman is sending the twice -- not Sendmail. BW> BW>I know I'm giving you more questions than answers, but I'll definitely BW>need more information before we can figure out your problem. BW> BW>-Barry Thank you! From todd@connactivity.connactivity.com Sat Apr 14 04:16:14 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Fri, 13 Apr 2001 23:16:14 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Fri, 13 Apr 2001 22:38:47 EDT." <200104140238.f3E2clS23684@connactivity.connactivity.com> Message-ID: <200104140316.f3E3GES01022@connactivity.connactivity.com> Forgot the Defaults.py and mm_cfg.py files... ----------------------------- Defaults.py ----------------------------- # -*- python -*- # Copyright (C) 1998,1999,2000 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. """Distributed default settings for significant Mailman config variables. """ # NEVER make site configuration changes to this file. ALWAYS make them in # mm_cfg.py instead, in the designated area. See the comments in that file # for details. import os def seconds(s): return s def minutes(m): return m * 60 def hours(h): return h * 60 * 60 def days(d): return d * 60 * 60 * 24 ##### # General system-wide defaults ##### # Should image logos be used? Set this to false to disable image logos from # "our sponsors" and just use textual links instead. Otherwise, this should # contain the URL base path to the logo images (and must contain the trailing # slash).. If you want to disable Mailman's logo footer altogther, hack # Mailman/htmlformat.py:MailmanLogo(), which also contains the hardcoded links # and image names. IMAGE_LOGOS = '/icons/' # Don't change MAILMAN_URL, unless you want to point it at the list.org # mirror. MAILMAN_URL = 'http://www.gnu.org/software/mailman/mailman.html' #MAILMAN_URL = 'http://www.list.org/' # Site-specific settings DEFAULT_HOST_NAME = 'log2l3c' # DEFAULT_URL must end in a slash! DEFAULT_URL = 'http://log2l3c/mailman/' PUBLIC_ARCHIVE_URL = '/pipermail' PRIVATE_ARCHIVE_URL = '/mailman/private' HOME_PAGE = 'index.html' MAILMAN_OWNER = 'mailman-owner@%s' % DEFAULT_HOST_NAME ##### # Archive defaults ##### # Are archives on or off by default? DEFAULT_ARCHIVE = 1 # 0=Off, 1=On # Are archives public or private by default? DEFAULT_ARCHIVE_PRIVATE = 0 # 0=public, 1=private # ARCHIVE_TO_MBOX #-1 - do not do any archiving # 0 - do not archive to mbox, use builtin mailman html archiving only # 1 - archive to mbox to use an external archiving mechanism only # 2 - archive to both mbox and builtin mailman html archiving - # use this to make both external archiving mechanism work and # mailman's builtin html archiving. the flat mail file can be # useful for searching, external archivers, etc. # ARCHIVE_TO_MBOX = 2 # 0 - yearly # 1 - monthly # 2 - quarterly # 3 - weekly # 4 - daily # DEFAULT_ARCHIVE_VOLUME_FREQUENCY = 1 # These variables control the use of an external archiver. Normally if # archiving is turned on (see ARCHIVE_TO_MBOX above and the list's archive* # attributes) the internal Pipermail archiver is used. This is the default if # both of these variables are set to false. When either is set, the value # should be a shell command string which will get passed to os.popen(). This # string can contain %(listname)s for dictionary interpolation. The name of # the list being archived will be substituted for this. # # Note that if you set one of these variables, you should set both of them # (they can be the same string). This will mean your external archiver will # be used regardless of whether public or private archives are selected. PUBLIC_EXTERNAL_ARCHIVER = 0 PRIVATE_EXTERNAL_ARCHIVER = 0 # Set this to 1 to enable gzipping of the downloadable archive .txt file. # Note that this is /extremely/ inefficient, so an alternative is to just # collect the messages in the associated .txt file and run a cron job every # night to generate the txt.gz file. See cron/nightly_gzip for details. GZIP_ARCHIVE_TXT_FILES = 0 # Pipermail archives contain the raw email addresses of the posting authors. # Some view this as a goldmine for spam harvesters. Set this to false to # moderately obscure email addresses, but note that this breaks mailto: URLs # in the archives too. ARCHIVER_OBSCURES_EMAILADDRS = 0 # Pipermail assumes that messages bodies contain US-ASCII text. # Change this option to define a different character set to be used as # the default character set for the archive. The term "character set" # is used in MIME to refer to a method of converting a sequence of # octets into a sequence of characters. If you change the default # charset, you might need to add it to VERBATIM_ENCODING below. DEFAULT_CHARSET = None # Most character set encodings require special HTML entity characters to be # quoted, otherwise they won't look right in the Pipermail archives. However # some character sets must not quote these characters so that they can be # rendered properly in the browsers. The primary issue is multi-byte # encodings where the octet 0x26 does not always represent the & character. # This variable contains a list of such characters sets which are not # HTML-quoted in the archives. VERBATIM_ENCODING = ['iso-2022-jp'] ##### # Delivery defaults ##### # Delivery module for the message pipeline. See # Mailman/Handlers/HandlerAPI.py for details. Unless overridden specifically # in that module, this handler is used for message delivery to the list, and # to an individual user. This value must be a string naming a module in the # Mailman.Handlers package. # # SECURITY WARNING: The Sendmail module is not secure! Please read the # comments in Mailman/Handlers/Sendmail.py for details. Use at your own # risk. # #DELIVERY_MODULE = 'Sendmail' DELIVERY_MODULE = 'SMTPDirect' # Ceiling on the number of recipients that can be specified in a single SMTP # transaction. Set to 0 to submit the entire recipient list in one # transaction. Only used with the SMTPDirect DELIVERY_MODULE. SMTP_MAX_RCPTS = 500 # Maximum number of simulatenous subthreads that will be used for SMTP # delivery. After the recipients list is chunked according to SMTP_MAX_RCPTS, # each chunk is handed off to the smptd by a separate such thread. If your # Python interpreter was not built for threads, this feature is disabled. You # can explicitly disable it in all cases by setting MAX_DELIVERY_THREADS to # 0. This feature is only supported with the SMTPDirect DELIVERY_MODULE. # # NOTE: This is an experimental feature and limited testing shows that it may # in fact degrade performance, possibly due to Python's global interpreter # lock. Use with caution. MAX_DELIVERY_THREADS = 0 # SMTP host and port, when DELIVERY_MODULE is 'SMTPDirect' SMTPHOST = 'localhost' SMTPPORT = 0 # default from smtplib # Command for direct command pipe delivery to sendmail compatible program, # when DELIVERY_MODULE is 'Sendmail'. SENDMAIL_CMD = '/usr/lib/sendmail' # Allow for handling of MTA-specific features (i.e. aliases). Most MTAs use # "sendmail" (including Sendmail, Postfix, and Exim). Qmail uses the "qmail" # style. MTA_ALIASES_STYLE = 'sendmail' # Set these variables if you need to authenticate to your NNTP server for # Usenet posting or reading. If no authentication is necessary, specify None # for both variables. NNTP_USERNAME = None NNTP_PASSWORD = None # Set this if you have an NNTP server you prefer gatewayed lists to use. DEFAULT_NNTP_HOST = '' ##### # General defaults ##### # Set to true to use the crypt module for passwords instead of md5. Crypt may # not work on all Python installations. Don't change this value once you have # lists running... In fact, you should just let configure set this one and # leave it alone. USE_CRYPT = 1 # When allowing only members to post to a mailing list, how is the sender of # the message determined? If this variable is set to 1, then first the # message's envelope sender is used, with a fallback to the sender if there is # no envelope sender. Set this variable to 0 to always use the sender. # # The envelope sender is set by the SMTP delivery and is thus less easily # spoofed than the sender, which is typically just taken from the From: header # and thus easily spoofed by the end-user. However, sometimes the envelope # sender isn't set correctly and this will manifest itself by postings being # held for approval even if they appear to come from a list member. If you # are having this problem, set this variable to 0, but understand that some # spoofed messages may get through. USE_ENVELOPE_SENDER = 0 # When true, Mailman will consider user@host.domain to be the same address as # user@domain. If set to 0, Mailman will consider user@host.domain to be the # same address as user@Host.DoMain, but different than user@domain. Usernames # will always be case preserved, and host parts of addresses will all be # lowercased. SMART_ADDRESS_MATCH = 1 # When set, the listinfo web page overview of lists on the machine will be # confined to only those lists whose web_page_url configuration option host is # included within the URL by which the page is visited - only those "on the # virtual host". If unset, then all lists are included in the overview. The # admin page overview always includes all the lists. VIRTUAL_HOST_OVERVIEW = 1 DEFAULT_FILTER_PROG = '' # Currently not used! # How many members to display at a time on the admin cgi to unsubscribe them # or change their options? DEFAULT_ADMIN_MEMBER_CHUNKSIZE = 30 # how many bytes of a held message post should be displayed in the admindb web # page? Use a negative number to indicate the entire message, regardless of # size (though this will slow down rendering those pages). ADMINDB_PAGE_TEXT_LIMIT = 4096 ##### # List defaults ##### # Should a list, by default be advertised? What is the default maximum number # of explicit recipients allowed? What is the default maximum message size # allowed? DEFAULT_LIST_ADVERTISED = 1 DEFAULT_MAX_NUM_RECIPIENTS = 10 DEFAULT_MAX_MESSAGE_SIZE = 40 # KB # These format strings will be expanded w.r.t. the dictionary for the # mailing list instance. DEFAULT_SUBJECT_PREFIX = "[%(real_name)s] " DEFAULT_MSG_HEADER = "" DEFAULT_MSG_FOOTER = """_______________________________________________ %(real_name)s mailing list %(real_name)s@%(host_name)s %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s """ # Mail command processor will ignore mail command lines after designated max. DEFAULT_MAIL_COMMANDS_MAX_LINES = 25 # Is the list owner notified of admin requests immediately by mail, as well as # by daily pending-request reminder? DEFAULT_ADMIN_IMMED_NOTIFY = 1 # Is the list owner notified of subscribes/unsubscribes? DEFAULT_ADMIN_NOTIFY_MCHANGES = 0 # Are lists, by default, moderated? DEFAULT_MODERATED = 0 # Bounce if 'To:', 'Cc:', or 'Resent-To:' fields don't explicitly name list? # This is an anti-spam measure DEFAULT_REQUIRE_EXPLICIT_DESTINATION = 1 # Alternate names acceptable as explicit destinations for this list. DEFAULT_ACCEPTABLE_ALIASES =""" """ # For mailing lists that have only other mailing lists for members: DEFAULT_UMBRELLA_LIST = 0 # For umbrella lists, the suffix for the account part of address for # administrative notices (subscription confirmations, password reminders): DEFAULT_UMBRELLA_MEMBER_ADMIN_SUFFIX = "-owner" # This variable controlls whether monthly password reminders are sent. DEFAULT_SEND_REMINDERS = 1 # Send welcome messages to new users? Probably should keep this set to 1. DEFAULT_SEND_WELCOME_MSG = 1 # Wipe sender information, and make it look like the list-admin # address sends all messages DEFAULT_ANONYMOUS_LIST = 0 # {header-name: regexp} spam filtering - we include some for example sake. DEFAULT_BOUNCE_MATCHING_HEADERS = """ # Lines that *start* with a '#' are comments. to: friend@public.com message-id: relay.comanche.denmark.eu from: list@listme.com from: .*@uplinkpro.com """ # Mailman can be configured to "munge" Reply-To: headers for any passing # messages. One the one hand, there are a lot of good reasons not to munge # Reply-To: but on the other, people really seem to want this feature. See # the help for reply_goes_to_list in the web UI for links discussing the # issue. # 0 - Reply-To: not munged # 1 - Reply-To: set back to the list # 2 - Reply-To: set to an explicit value (reply_to_address) DEFAULT_REPLY_GOES_TO_LIST = 0 # SUBSCRIBE POLICY # 0 - open list (only when ALLOW_OPEN_SUBSCRIBE is set to 1) ** # 1 - confirmation required for subscribes # 2 - admin approval required for subscribes # 3 - both confirmation and admin approval required # # ** please do not choose option 0 if you are not allowing open # subscribes (next variable) DEFAULT_SUBSCRIBE_POLICY = 1 # does this site allow completely unchecked subscriptions? ALLOW_OPEN_SUBSCRIBE = 0 # Private_roster == 0: anyone can see, 1: members only, 2: admin only. DEFAULT_PRIVATE_ROSTER = 0 # When exposing members, make them unrecognizable as email addrs, so # web-spiders can't pick up addrs for spam purposes. DEFAULT_OBSCURE_ADDRESSES = 1 # Make it 1 when it works. DEFAULT_MEMBER_POSTING_ONLY = 0 ##### # Digestification defaults ##### # Will list be available in non-digested form? DEFAULT_NONDIGESTABLE = 1 # Will list be available in digested form? DEFAULT_DIGESTABLE = 1 DEFAULT_DIGEST_HEADER = "" DEFAULT_DIGEST_FOOTER = DEFAULT_MSG_FOOTER DEFAULT_DIGEST_IS_DEFAULT = 0 DEFAULT_MIME_IS_DEFAULT_DIGEST = 0 DEFAULT_DIGEST_SIZE_THRESHHOLD = 30 # KB DEFAULT_DIGEST_SEND_PERIODIC = 1 DEFAULT_PLAIN_DIGEST_KEEP_HEADERS = ['message', 'date', 'from', 'subject', 'to', 'cc', 'reply-to', 'organization'] ##### # Bounce processing defaults ##### # Should we do any bounced mail response at all? DEFAULT_BOUNCE_PROCESSING = 1 # Minimum number of days that address has been undeliverable before # we take the automatic bounce action. DEFAULT_MINIMUM_REMOVAL_DATE = 5 # Minimum number of delivery failure notices for an account before we # consider doing the automatic bounce action. DEFAULT_MINIMUM_POST_COUNT_BEFORE_BOUNCE_ACTION = 3 # 0 means do nothing # 1 means disable and notify the list admin # 2 means disable and don't notify the list admin # 3 means remove and notify DEFAULT_AUTOMATIC_BOUNCE_ACTION = 1 # Maximum number of posts that can go by w/o a bounce before we figure # delivery failures to a particular recipient have been resolved. This # needs to account for the big lag between delivery attempt and issuance of # the failure notice. We recommend a value representing the maximum number # of messages you'd reasonably expect an average list to get in 1 hour. DEFAULT_MAX_POSTS_BETWEEN_BOUNCES = 5 # Check for administrivia in messages sent to the main list? DEFAULT_ADMINISTRIVIA = 1 # List of addresses (lhs of the @) that likely come only from MTAs bouncing # messages. This is used in qrunner and MailCommandHandler.py to stop # processing or forwarding such messages. # # TBD: why orphanage? why postoffice? LIKELY_BOUNCE_SENDERS = ('daemon', 'mailer-daemon', 'postmaster', 'orphanage', 'postoffice') ##### # General time limits ##### # Authentication cookie control. When set to 0, Mailman's admin cookie # expires at the end of your session. This is preferred for security reasons, # and to avoid potential problems with incorrect clock and timezone settings. # Set this to a value > 0 to use persistent admin cookies with a lifetime of # that number of seconds. ADMIN_COOKIE_LIFE = 0 # How long should subscriptions requests await confirmation before being # dropped? PENDING_REQUEST_LIFE = days(3) # How long should messages which have delivery failures continue to be # retried? After this period of time, a message that has failed recipients # will be dequeued and those recipients will never receive the message. DELIVERY_RETRY_PERIOD = days(5) ##### # Lock management defaults ##### # These variables control certain aspects of lock acquisition and retention. # They should be tuned as appropriate for your environment. All variables are # specified in units of floating point seconds. YOU MAY NEED TO TUNE THESE # VARIABLES DEPENDING ON THE SIZE OF YOUR LISTS, THE PERFORMANCE OF YOUR # HARDWARE, NETWORK AND GENERAL MAIL HANDLING CAPABILITIES, ETC. # Set this to true to turn on MailList object lock debugging messages, which # will be written to logs/locks. If you think you're having lock problems, or # just want to tune the locks for your system, turn on lock debugging. LIST_LOCK_DEBUGGING = 0 # This variable specifies how long the lock will be retained for a specific # operation on a mailing list. Watch your logs/lock file and if you see a lot # of lock breakages, you might need to bump this up. However if you set this # too high, a faulty script (or incorrect use of bin/withlist) can prevent the # list from being used until the lifetime expires. This is probably one of # the most crucial tuning variables in the system. LIST_LOCK_LIFETIME = hours(5) # This variable specifies how long an attempt will be made to acquire a list # lock by the qrunner process. If the lock acquisition times out, the message # will be re-queued for later delivery. LIST_LOCK_TIMEOUT = seconds(10) # cron/qrunner lock lifetime. This is probably the second most crucial tuning # variable in the system. See the notes for LIST_LOCK_LIFETIME above. Watch # your logs/smtp file and make sure that QRUNNER_LOCK_LIFETIME is set longer # than the longest period you see here. It is a bad thing if multiple # qrunners run at the same time. QRUNNER_LOCK_LIFETIME = hours(10) # Two other qrunner resource management variables. The first controls the # maximum lifetime of any single qrunner process, and the second controls the # maximum number of messages a single qrunner process will, er, process. # Exceeding either limit causes qrunner to exit, reclaiming system resources # and deleting the lock. Other qrunners will then process the remaining # messages. Set either to None to inhibit this resource check. QRUNNER_PROCESS_LIFETIME = minutes(15) QRUNNER_MAX_MESSAGES = 300 ##### # Nothing below here is user configurable. Most of these values are in this # file for convenience. Don't change any of them or override any of them in # your mm_cfg.py file! ##### # These directories are used to find various important files in the Mailman # installation. PREFIX and EXEC_PREFIX are set by configure and should point # to the installation directory of the Mailman package. PYTHON = '/usr/bin/python' PREFIX = '/home/mailman' EXEC_PREFIX = '${prefix}' VAR_PREFIX = '/home/mailman' # Work around a bogus autoconf 2.12 bug if EXEC_PREFIX == '${prefix}': EXEC_PREFIX = PREFIX # CGI extension, change using configure script CGIEXT = '' # Group id that group-owns the Mailman installation MAILMAN_UID = 503 MAILMAN_GID = 503 # Enumeration for types of configurable variables in Mailman. Toggle = 1 Radio = 2 String = 3 Text = 4 Email = 5 EmailList = 6 Host = 7 Number = 8 FileUpload = 9 # Held message disposition actions, for use between admindb.py and # ListAdmin.py. DEFER = 0 APPROVE = 1 REJECT = 2 DISCARD = 3 SUBSCRIBE = 4 # Standard text field width TEXTFIELDWIDTH = 40 # Bitfield for user options Digests = 0 # handled by other mechanism, doesn't need a flag. DisableDelivery = 1 DontReceiveOwnPosts = 2 # Non-digesters only AcknowledgePosts = 4 DisableMime = 8 # Digesters only ConcealSubscription = 16 # Useful directories LIST_DATA_DIR = os.path.join(VAR_PREFIX, 'lists') HTML_DIR = os.path.join(PREFIX, 'public_html') CGI_DIR = os.path.join(EXEC_PREFIX, 'cgi-bin') LOG_DIR = os.path.join(VAR_PREFIX, 'logs') LOCK_DIR = os.path.join(VAR_PREFIX, 'locks') DATA_DIR = os.path.join(VAR_PREFIX, 'data') QUEUE_DIR = os.path.join(VAR_PREFIX, 'qfiles') SPAM_DIR = os.path.join(VAR_PREFIX, 'spam') WRAPPER_DIR = os.path.join(EXEC_PREFIX, 'mail') SCRIPTS_DIR = os.path.join(PREFIX, 'scripts') TEMPLATE_DIR = os.path.join(PREFIX, 'templates') PUBLIC_ARCHIVE_FILE_DIR = os.path.join(VAR_PREFIX, 'archives', 'public') PRIVATE_ARCHIVE_FILE_DIR = os.path.join(VAR_PREFIX, 'archives', 'private') SITE_PW_FILE = os.path.join(DATA_DIR, 'adm.pw') # Import a bunch of version numbers from Version import * ----------------------------- mm_cfg.py ----------------------------- # -*- python -*- # Copyright (C) 1998,1999,2000 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. """This module contains your site-specific settings. >From a brand new distribution it should be copied to mm_cfg.py. If you already have an mm_cfg.py, be careful to add in only the new settings you want. Mailman's installation procedure will never overwrite your mm_cfg.py file. The complete set of distributed defaults, with documentation, are in the file Defaults.py. In mm_cfg.py, override only those you want to change, after the from Defaults import * line (see below). Note that these are just default settings; many can be overridden via the administrator and user interfaces on a per-list or per-user basis. """ ############################################### # Here's where we get the distributed defaults. from Defaults import * ################################################## # Put YOUR site-specific settings below this line. From barry@digicool.com Tue Apr 17 01:01:10 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 16 Apr 2001 20:01:10 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final References: <15063.44012.655280.504033@anthem.wooz.org> <200104140238.f3E2clS23684@connactivity.connactivity.com> Message-ID: <15067.34758.371357.900173@anthem.wooz.org> >>>>> "TJ" == Todd Joseph writes: BW> The error your getting in the log file indicates that one of BW> the queued files is getting deleted out from under qrunner. BW> That could be because you're getting multiple qrunner BW> processes because of some locking failure, or because your BW> qrunner lock is getting stomped on. TJ> I kinda thought so. Any ideas on what could cause that? Are you running Mailman on an NFS mounted file system? Locking /shouldn't/ be susceptible to NFS issues, but it still isn't a terribly good idea. Another scenario is that you've cranked up your qrunner process limits, but not appropriatedly adjusted your qrunner lock lifetime. In that case, qrunner could be running for a long time, exceeding the lock lifetime, and allowing a future cron started qrunner to break the still running qrunner's lock. The best way to see if this is happening is to edit cron/qrunner around about line 274, where the LockFile instance is created. Add an argument "withlogging=1" to turn on lock file logging. Then you'd study the log to see if you get any "lock broken" messages. TJ> One more tidbit, I have set the "Action when critical or TJ> excessive bounces are detected" to "Do nothing" So, I do have TJ> a fair number of bogus addresses in my list. My sendmail TJ> queue does get kinda large. I've set it up this way out of TJ> paranoia in maintaining the integrity of the list (IE not TJ> removing valid email addresses). I don't see how that could matter, even if it leaves bogus addresses in your recipient lists. Then again, I'll bet this isn't a well tested option (the bouncer stuff is an area that I haven't had much time to review). Anything's possible, but it's unlikely if none of the log files is indicating errors. BTW, the default setting doesn't delete any bouncing emails from your list -- it just disables them (currently exactly the same as setting "no mail", but probably for 2.1 those will be distinguishable). TJ> OK, I'm bad. I changed them in the Defaults.py file. I tried TJ> to use the mm_cfg.py file, but ran into a problem (was a few TJ> months ago, don't remember what exactly happened). I'd like to know about those, since changing mm_cfg.py is better. Otherwise future upgrades could overwrite your changes. TJ> I've included a copy of my "Defaults.py" and "mm_cfg.py" at TJ> the bottom of this message for reference. I'll take a look. BW> Which DELIVERY_MODULE are you using? TJ> SMTPDirect (would I be better off with Sendmail?) Nope, you're using the right one. BW> Are you running a news gateway? TJ> No. Okay, so it's not fork leakage (and there are fences for that one, but you never know). I'm leaning heavily toward qrunner contention. -Barry From todd@connactivity.connactivity.com Tue Apr 17 04:08:29 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Mon, 16 Apr 2001 23:08:29 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Mon, 16 Apr 2001 20:01:10 EDT." <15067.34758.371357.900173@anthem.wooz.org> Message-ID: <200104170308.f3H38TO02059@connactivity.connactivity.com> BW>Are you running Mailman on an NFS mounted file system? Locking BW>/shouldn't/ be susceptible to NFS issues, but it still isn't a BW>terribly good idea. No -- all local filesystems. BW>Another scenario is that you've cranked up your qrunner process BW>limits, but not appropriatedly adjusted your qrunner lock lifetime. BW>In that case, qrunner could be running for a long time, exceeding the BW>lock lifetime, and allowing a future cron started qrunner to break the BW>still running qrunner's lock. Interesting. I haven't adjusted any of this intentionally. BW>The best way to see if this is happening is to edit cron/qrunner BW>around about line 274, where the LockFile instance is created. Add an BW>argument "withlogging=1" to turn on lock file logging. Then you'd BW>study the log to see if you get any "lock broken" messages. OK, I'll try that. BW> TJ> OK, I'm bad. I changed them in the Defaults.py file. I tried BW> TJ> to use the mm_cfg.py file, but ran into a problem (was a few BW> TJ> months ago, don't remember what exactly happened). BW> BW>I'd like to know about those, since changing mm_cfg.py is better. BW>Otherwise future upgrades could overwrite your changes. I'll letcha know. Thanks for all the help. Todd From barry@digicool.com Tue Apr 17 04:20:29 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 16 Apr 2001 23:20:29 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final References: <15067.34758.371357.900173@anthem.wooz.org> <200104170308.f3H38TO02059@connactivity.connactivity.com> Message-ID: <15067.46717.691410.181512@anthem.wooz.org> >>>>> "TJ" == Todd Joseph writes: TJ> I'll letcha know. TJ> Thanks for all the help. Cool, no problem. -Barry From chuqui@plaidworks.com Tue Apr 17 07:39:41 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 16 Apr 2001 23:39:41 -0700 Subject: [Mailman-Users] Re: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: <15067.34758.371357.900173@anthem.wooz.org> Message-ID: On 4/16/01 5:01 PM, "Barry A. Warsaw" wrote: > Another scenario is that you've cranked up your qrunner process > limits, but not appropriatedly adjusted your qrunner lock lifetime. Or you haven't changed any of the limits, but the time it takes to send a single message exceeds the lock lifetime. If the lock is set for ten hours, and it takes you 12 hours to deliver a really large e-newsletter, for instance, you're hosed. The lock lifetime has to be longer than the longest possible processing time of any single queue item. If you've got 30-40,000 or more subscribers, you could very easily be exceeding that lifetime. > BTW, the default setting doesn't delete any bouncing emails from your > list -- it just disables them (currently exactly the same as setting > "no mail", but probably for 2.1 those will be distinguishable). I'm finding this is confusing a number of my users, so I changed all my lists to deletion. They knew the mail stopped coming, they knew enough to look and found themselves still subscribed, and didn't know what to do. I guess it depends on what list server background you have. If you're familiar with listserv and it's relatives that have nomail, this makes sense. If you're coming from majordomo or have no real mlist experience, I think it's confusing. And I'm not sure if it really buys you much (and when/how do you decide to clean out your subscriber lists?) From tollef@add.no Mon Apr 16 22:37:07 2001 From: tollef@add.no (Tollef Fog Heen) Date: 16 Apr 2001 23:37:07 +0200 Subject: [Mailman-Developers] broken HTML Message-ID: <87bspwzfuk.fsf@arabella.intern.opera.no> It seems to be a small bug in mailman 2.0.3, in Mailman/htmlformat.py, line 281, this _will_ generate broken html like: soci Admindb Results

Database Updated...

Administrative requests for mailing list: so Note the double (and first unfinished) If this is still in cvs, somebody please fix. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From jcrey@uma.es Tue Apr 17 11:36:08 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Tue, 17 Apr 2001 12:36:08 +0200 Subject: [Mailman-Developers] Multilanguage support in Mailman. References: <3AD449A4.DDD4CB77@cendio.se> Message-ID: <3ADC1C98.BC889D12@uma.es> Conny Andersson wrote: > I'm not sure how to incorporate the changes to > Mailman (I have just made symbolic links in my > setup) but one suggestion could be to have an > option for every user to choose their desired > language. Take a glance to mailman-i18n list and see what to do. Cheers -- = ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From thomas@xs4all.net Tue Apr 17 14:44:40 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 17 Apr 2001 15:44:40 +0200 Subject: [Mailman-Developers] broken HTML In-Reply-To: <87bspwzfuk.fsf@arabella.intern.opera.no>; from tollef@add.no on Mon, Apr 16, 2001 at 11:37:07PM +0200 References: <87bspwzfuk.fsf@arabella.intern.opera.no> Message-ID: <20010417154440.S2820@xs4all.nl> On Mon, Apr 16, 2001 at 11:37:07PM +0200, Tollef Fog Heen wrote: > It seems to be a small bug in mailman 2.0.3, in Mailman/htmlformat.py, > line 281, this _will_ generate broken html like: > > > soci Admindb Results > > >

Database Updated...

Administrative requests for mailing list: so > Note the double (and first unfinished) > If this is still in cvs, somebody please fix. :) Yes, it's still broken. The problem is that the document isn't treated as a 'headless' one, even though the template file treats it as such (it includes its own stuff.) I suggested a fix a few months back (our own webdesign departement ran into the same bug) but Barry rejected it -- I don't recall why. Maybe because he was afraid it'd break too many websites out there. Barry ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From wheakory@isu.edu Tue Apr 17 17:21:33 2001 From: wheakory@isu.edu (Kory Wheatley) Date: Tue, 17 Apr 2001 10:21:33 -0600 Subject: [Mailman-Developers] Mailman Qrunner error Message-ID: <3ADC6D8D.BEB2C27F@isu.edu> I'm receiving this error below which is sent to the Owner of Mailman's email account every minute when the Qrunner cron process runs. Does anyone know what this means. Please respond to wheakory@isu.edu, ( I have over 150 mailman mailing lists that its critical that they function properly). I would greatly appreciate solutions? Traceback (innermost last): File "/home/mailman/cron/qrunner", line 85, in ? from Mailman import MailList ValueError: bad marshal data -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From barry@digicool.com Tue Apr 17 18:01:27 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 17 Apr 2001 13:01:27 -0400 Subject: [Mailman-Developers] Mailman Qrunner error References: <3ADC6D8D.BEB2C27F@isu.edu> Message-ID: <15068.30439.741128.500671@anthem.wooz.org> >>>>> "KW" == Kory Wheatley writes: KW> I'm receiving this error below which is sent to the Owner of KW> Mailman's email account every minute when the Qrunner cron KW> process runs. Does anyone know what this means. Please respond KW> to wheakory@isu.edu, ( I have over 150 mailman mailing lists KW> that its critical that they function properly). I would KW> greatly appreciate solutions? KW> Traceback (innermost last): | File "/home/mailman/cron/qrunner", line 85, in ? | from Mailman import MailList KW> ValueError: bad marshal data Since it's failing on an import, I'd say you have some corrupt .pyc files laying around. Don't know how they got corrupt, but if you remove them and then do "config.status; make install" it should fix them. -Barry From fil@rezo.net Tue Apr 17 20:55:50 2001 From: fil@rezo.net (Fil) Date: Tue, 17 Apr 2001 21:55:50 +0200 Subject: [Mailman-Developers] HandlerAPI ? In-Reply-To: <20010413122928.A13755@orwell.bok.net>; from fil@rezo.net on Fri, Apr 13, 2001 at 12:29:28PM +0200 References: <20010413122928.A13755@orwell.bok.net> Message-ID: <20010417215550.A15255@orwell.bok.net> Hi, what happened to HandlerAPI.py ? It is not there any more in the CVS tree, but it is still called by cron/checkdbs and cron/mailpasswds can someone explain? -- Fil From barry@digicool.com Tue Apr 17 23:21:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 17 Apr 2001 18:21:49 -0400 Subject: [Mailman-Developers] HandlerAPI ? References: <20010413122928.A13755@orwell.bok.net> <20010417215550.A15255@orwell.bok.net> Message-ID: <15068.49661.300774.548080@anthem.wooz.org> >>>>> "F" == Fil writes: F> what happened to HandlerAPI.py ? After the redesign of the qrunner stuff, it was no longer necessary. F> It is not there any more in the CVS tree, but it is still F> called by cron/checkdbs and cron/mailpasswds F> can someone explain? I just haven't gotten around to updating those scripts yet. However, I'll be spending some concentrated time on Mailman over the next few weeks, so I fix those soon. -Barry From Dan Mick Wed Apr 18 02:02:06 2001 From: Dan Mick (Dan Mick) Date: Tue, 17 Apr 2001 18:02:06 -0700 (PDT) Subject: [Mailman-Users] Re: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final Message-ID: <200104180102.SAA28438@utopia.West.Sun.COM> > I guess it depends on what list server background you have. If you're > familiar with listserv and it's relatives that have nomail, this makes > sense. If you're coming from majordomo or have no real mlist experience, I > think it's confusing. And I'm not sure if it really buys you much (and > when/how do you decide to clean out your subscriber lists?) I created a withlist script and a mail template to send reminders to all "nomail" folks, and run it by hand from time to time; I'm not convinced it's better, but it lets me not permanently lose people without giving them a chance to stay less painfully than resubbing. From chuqui@plaidworks.com Wed Apr 18 02:07:11 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 17 Apr 2001 18:07:11 -0700 Subject: [Mailman-Users] Re: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: <200104180102.SAA28438@utopia.West.Sun.COM> Message-ID: <200104180100.f3I10Bi16719@plaidworks.com> On Tuesday, April 17, 2001, at 06:02 PM, Dan Mick wrote: > I created a withlist script and a mail template to send reminders > to all "nomail" folks, and run it by hand from time to time; > I'm not convinced it's better, but it lets me not permanently > lose people without giving them a chance to stay less painfully than > resubbing. > that's an option -- have you considered adding it to the disto? My problem, though, is that I have a group of users that use nomail as an alternative to email aliases (which we've talked about). So I get to choose how to annoy who -- I tend to think it's better to leave nomail to the users, and either remove users or set up a second flag for system use in disabling users, because otherwise we end up with ambiguous situations. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. When an agnostic dies, does he go to the "great perhaps"? From jonny@dir.bg Wed Apr 18 14:30:32 2001 From: jonny@dir.bg (Vassil ) Date: Wed, 18 Apr 2001 16:30:32 +0300 Subject: [Mailman-Developers] (no subject) Message-ID: Hello! I have a big problem with my video card. It is Nvidia ge Force 2 MX and I can't run Linux with it! What should I do? Is there any way ? ----------------------------- Free mail from www.dir.bg! From Dale@Newfield.org Wed Apr 18 14:32:34 2001 From: Dale@Newfield.org (Dale Newfield) Date: Wed, 18 Apr 2001 09:32:34 -0400 (EDT) Subject: [Mailman-Developers] More moderation? In-Reply-To: <200104180102.SAA28438@utopia.West.Sun.COM> Message-ID: One of the settings that allows moderators to conditionally insert themselves is the max size (default to 40K, I believe). How difficult would it be to include another that holds for moderation any message that includes more excerpted material (lines beginning with >) than a certain percentage of the message? How difficult would it be to also allow the process of moderation to actually modify the message (for example, including a [foo bar baz -Moderator] comment block, or trimming excess cruft that really has nothing to do with the message's content)? I might be willing to do this coding if others agreed these are desirable features... Ooh--since I'm suggesting features I'd like, how 'bout the ability to (on a list-by-list basis) flip a switch that would trim out all HTML code from messages sent to the list? -Dale Newfield From jonny@dir.bg Wed Apr 18 14:32:59 2001 From: jonny@dir.bg (Vassil ) Date: Wed, 18 Apr 2001 16:32:59 +0300 Subject: [Mailman-Developers] (no subject) Message-ID: Hello! I have a big problem with my video card. It is Nvidia ge Force 2 MX and I can't run Linux with it! What should I do? Is there any way ? Please write me to jonny@dir.bg I will be very pleased if you answer me! ----------------------------- Free mail from www.dir.bg! From barry@digicool.com Wed Apr 18 20:12:53 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 18 Apr 2001 15:12:53 -0400 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.4 Message-ID: <15069.59189.820989.870483@anthem.wooz.org> --hVjg+bsTAg Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Folks, I've just released Mailman 2.0.4 which is simply a patch release so that Mailman works better with Python 2.1. Mailman 2.0.3 had a few constructs which caused warnings when run with Python 2.1. The unfortunate part is that those warnings could occur in the qrunner process which tended to cause cron to bombard the system administrators with email. If you upgrade your Python to 2.1, you should definitely upgrade to Mailman 2.0.4, otherwise consider it optional. As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.3. You /must/ update your source to 2.0.3 before applying the 2.0.4 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.4 source tree and apply it like so: % patch -p0 < mailman-2.0.3-2.0.4.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net Enjoy, -Barry [From the NEWS file] 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable constructs and uses of deprecated modules that caused annoying warnings when used with Python 2.1. This release quiets those warnings. --hVjg+bsTAg Content-Type: text/plain Content-Disposition: inline; filename="mailman-2.0.3-2.0.4.txt" Content-Transfer-Encoding: 7bit Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.4 retrieving revision 1.25.2.5 diff -u -r1.25.2.4 -r1.25.2.5 --- NEWS 2001/03/12 19:32:10 1.25.2.4 +++ NEWS 2001/04/18 10:45:54 1.25.2.5 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.4 (18-Apr-2001) + + Python 2.1 compatibility release. There were a few questionable + constructs and uses of deprecated modules that caused annoying + warnings when used with Python 2.1. This release quiets those + warnings. + 2.0.3 (12-Mar-2001) Bug fix release. There was a small typo in 2.0.2 in ListAdmin.py Index: Mailman/HTMLFormatter.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/HTMLFormatter.py,v retrieving revision 1.50 retrieving revision 1.50.2.1 diff -u -r1.50 -r1.50.2.1 --- Mailman/HTMLFormatter.py 2000/09/09 19:13:58 1.50 +++ Mailman/HTMLFormatter.py 2001/04/18 04:33:48 1.50.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# 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 @@ -19,14 +19,14 @@ import os -# XXX: should be converted to use re module -import regsub import string -import mm_cfg -import Utils -from htmlformat import * +import re +from Mailman import mm_cfg +from Mailman import Utils +from Mailman.htmlformat import * + class HTMLFormatter: def InitVars(self): @@ -330,7 +330,7 @@ def ParseTags(self, template, replacements): text = self.SnarfHTMLTemplate(template) - parts = regsub.splitx(text, ']*>') + parts = re.split('(]*>)', text) i = 1 while i < len(parts): tag = string.lower(parts[i]) Index: Mailman/Utils.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Utils.py,v retrieving revision 1.104 retrieving revision 1.104.2.2 diff -u -r1.104 -r1.104.2.2 --- Mailman/Utils.py 2000/11/16 21:43:11 1.104 +++ Mailman/Utils.py 2001/04/18 04:23:07 1.104.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# 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 @@ -29,8 +29,6 @@ import re from UserDict import UserDict from types import StringType -# XXX: obsolete, should use re module -import regsub import random import urlparse @@ -415,19 +413,8 @@ def QuoteHyperChars(str): - arr = regsub.splitx(str, '[<>"&]') - i = 1 - while i < len(arr): - if arr[i] == '<': - arr[i] = '<' - elif arr[i] == '>': - arr[i] = '>' - elif arr[i] == '"': - arr[i] = '"' - else: #if arr[i] == '&': - arr[i] = '&' - i = i + 2 - return string.join(arr, '') + from cgi import escape + return escape(str, quote=1) Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.3 retrieving revision 1.20.2.4 diff -u -r1.20.2.3 -r1.20.2.4 --- Mailman/Version.py 2001/03/07 23:25:41 1.20.2.3 +++ Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.3" +VERSION = "2.0.4" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 3 +MICRO_REV = 4 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Bouncers/Catchall.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Attic/Catchall.py,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -u -r1.4 -r1.4.2.1 --- Mailman/Bouncers/Catchall.py 2000/08/07 02:34:33 1.4 +++ Mailman/Bouncers/Catchall.py 2001/04/18 04:41:47 1.4.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# 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 @@ -18,6 +18,16 @@ # implementation of Bouncer.ScanMessage(). We keep it because I don't feel # like splitting it up and porting it. It should at the very least be ported # to use mimetools and re. :( + +# In Python 2.1, the import of regsub causes a DeprecationWarning. This is +# annoying so if we can import the warnings module, we turn off warnings about +# the import of regsub. It's not worth changing the uses of regsub to use the +# re module because Catchall.py is going away in Mailman 2.1. +try: + import warnings + warnings.filterwarnings('ignore', module='regsub') +except ImportError: + pass import re import string Index: admin/www/Makefile =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/Makefile,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- admin/www/Makefile 2000/11/08 18:43:39 1.1 +++ admin/www/Makefile 2001/04/18 10:43:46 1.1.2.1 @@ -1,4 +1,4 @@ -HT2HTML = /home/bwarsaw/projects/ht2html/ht2html.py +HT2HTML = $(HOME)/projects/ht2html/ht2html.py HTSTYLE = MMGenerator HTALLFLAGS = -f -s $(HTSTYLE) Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.4 retrieving revision 1.5.2.5 diff -u -r1.5.2.4 -r1.5.2.5 --- admin/www/download.ht 2001/03/12 19:33:49 1.5.2.4 +++ admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 @@ -65,9 +65,9 @@

Downloading

Version -(2.0.3, +(2.0.4, released on -Mar 12 2001) +Apr 18 2001) is the current GNU release. It is available from the following mirror sites:

    @@ -98,5 +98,3 @@ % gunzip -c mailman.tar.gz | tar xf - -e> -> Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.6 retrieving revision 1.6.2.7 diff -u -r1.6.2.6 -r1.6.2.7 --- admin/www/download.html 2001/03/12 19:33:49 1.6.2.6 +++ admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 @@ -1,6 +1,6 @@ - + 2.0.3, +(2.0.4, released on -Mar 12 2001) +Apr 18 2001) is the current GNU release. It is available from the following mirror sites:
      @@ -270,8 +270,6 @@ % gunzip -c mailman.tar.gz | tar xf - -e> -> Index: cron/qrunner =================================================================== RCS file: /cvsroot/mailman/mailman/cron/qrunner,v retrieving revision 1.18.2.2 retrieving revision 1.18.2.3 diff -u -r1.18.2.2 -r1.18.2.3 --- cron/qrunner 2001/01/03 06:42:11 1.18.2.2 +++ cron/qrunner 2001/04/18 03:58:35 1.18.2.3 @@ -166,8 +166,8 @@ _listcache = {} + def open_list(listname): - global _listcache mlist = _listcache.get(listname) if not mlist: try: @@ -267,7 +267,6 @@ if __name__ == '__main__': - global _listcache ## syslog('qrunner', 'qrunner begining') # first, claim the queue runner lock lock = LockFile.LockFile(QRUNNER_LOCK_FILE, --hVjg+bsTAg-- From dkeller@linkup.com Wed Apr 18 21:04:42 2001 From: dkeller@linkup.com (David Keller) Date: Wed, 18 Apr 2001 15:04:42 -0500 Subject: [Mailman-Developers] remove References: <15069.59189.820989.870483@anthem.wooz.org> Message-ID: <03b001c0c842$cea09100$914447cc@ns1> ----- Original Message ----- From: Barry A. Warsaw To: Cc: ; Sent: Wednesday, April 18, 2001 2:12 PM Subject: [Mailman-Announce] ANNOUNCE Mailman 2.0.4 > > Folks, > > I've just released Mailman 2.0.4 which is simply a patch release so > that Mailman works better with Python 2.1. Mailman 2.0.3 had a few > constructs which caused warnings when run with Python 2.1. The > unfortunate part is that those warnings could occur in the qrunner > process which tended to cause cron to bombard the system > administrators with email. If you upgrade your Python to 2.1, you > should definitely upgrade to Mailman 2.0.4, otherwise consider it > optional. > > As usual, I'm releasing this as both a complete tarball and as a patch > against Mailman 2.0.3. You /must/ update your source to 2.0.3 before > applying the 2.0.4 patch. Since the patch is small, I'm including it > in this message. To apply, cd into your 2.0.4 source tree and apply > it like so: > > % patch -p0 < mailman-2.0.3-2.0.4.txt > > Currently both http://mailman.sourceforge.net and http://www.list.org > are updated, and I expect the gnu.org site to be updated soon as > well. The release information on SF is at > > http://sourceforge.net/project/shownotes.php?release_id=31693 > > See also > > http://www.gnu.org/software/mailman > http://www.list.org > http://mailman.sourceforge.net > > Enjoy, > -Barry > > [From the NEWS file] > > 2.0.4 (18-Apr-2001) > > Python 2.1 compatibility release. There were a few questionable > constructs and uses of deprecated modules that caused annoying > warnings when used with Python 2.1. This release quiets those > warnings. > > ---------------------------------------------------------------------------- ---- > Index: NEWS > =================================================================== > RCS file: /cvsroot/mailman/mailman/NEWS,v > retrieving revision 1.25.2.4 > retrieving revision 1.25.2.5 > diff -u -r1.25.2.4 -r1.25.2.5 > --- NEWS 2001/03/12 19:32:10 1.25.2.4 > +++ NEWS 2001/04/18 10:45:54 1.25.2.5 > @@ -4,6 +4,13 @@ > > Here is a history of user visible changes to Mailman. > > +2.0.4 (18-Apr-2001) > + > + Python 2.1 compatibility release. There were a few questionable > + constructs and uses of deprecated modules that caused annoying > + warnings when used with Python 2.1. This release quiets those > + warnings. > + > 2.0.3 (12-Mar-2001) > > Bug fix release. There was a small typo in 2.0.2 in ListAdmin.py > Index: Mailman/HTMLFormatter.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/HTMLFormatter.py,v > retrieving revision 1.50 > retrieving revision 1.50.2.1 > diff -u -r1.50 -r1.50.2.1 > --- Mailman/HTMLFormatter.py 2000/09/09 19:13:58 1.50 > +++ Mailman/HTMLFormatter.py 2001/04/18 04:33:48 1.50.2.1 > @@ -1,4 +1,4 @@ > -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. > +# 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 > @@ -19,14 +19,14 @@ > > > import os > -# XXX: should be converted to use re module > -import regsub > import string > -import mm_cfg > -import Utils > -from htmlformat import * > +import re > > +from Mailman import mm_cfg > +from Mailman import Utils > +from Mailman.htmlformat import * > > + > > class HTMLFormatter: > def InitVars(self): > @@ -330,7 +330,7 @@ > > def ParseTags(self, template, replacements): > text = self.SnarfHTMLTemplate(template) > - parts = regsub.splitx(text, ']*>') > + parts = re.split('(]*>)', text) > i = 1 > while i < len(parts): > tag = string.lower(parts[i]) > Index: Mailman/Utils.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Utils.py,v > retrieving revision 1.104 > retrieving revision 1.104.2.2 > diff -u -r1.104 -r1.104.2.2 > --- Mailman/Utils.py 2000/11/16 21:43:11 1.104 > +++ Mailman/Utils.py 2001/04/18 04:23:07 1.104.2.2 > @@ -1,4 +1,4 @@ > -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. > +# 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 > @@ -29,8 +29,6 @@ > import re > from UserDict import UserDict > from types import StringType > -# XXX: obsolete, should use re module > -import regsub > import random > import urlparse > > @@ -415,19 +413,8 @@ > > > def QuoteHyperChars(str): > - arr = regsub.splitx(str, '[<>"&]') > - i = 1 > - while i < len(arr): > - if arr[i] == '<': > - arr[i] = '<' > - elif arr[i] == '>': > - arr[i] = '>' > - elif arr[i] == '"': > - arr[i] = '"' > - else: #if arr[i] == '&': > - arr[i] = '&' > - i = i + 2 > - return string.join(arr, '') > + from cgi import escape > + return escape(str, quote=1) > > > > Index: Mailman/Version.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v > retrieving revision 1.20.2.3 > retrieving revision 1.20.2.4 > diff -u -r1.20.2.3 -r1.20.2.4 > --- Mailman/Version.py 2001/03/07 23:25:41 1.20.2.3 > +++ Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 > @@ -15,7 +15,7 @@ > # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > > # Mailman version > -VERSION = "2.0.3" > +VERSION = "2.0.4" > > # And as a hex number in the manner of PY_VERSION_HEX > ALPHA = 0xa > @@ -27,7 +27,7 @@ > > MAJOR_REV = 2 > MINOR_REV = 0 > -MICRO_REV = 3 > +MICRO_REV = 4 > REL_LEVEL = FINAL > # at most 15 beta releases! > REL_SERIAL = 0 > Index: Mailman/Bouncers/Catchall.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Attic/Catchall.py,v > retrieving revision 1.4 > retrieving revision 1.4.2.1 > diff -u -r1.4 -r1.4.2.1 > --- Mailman/Bouncers/Catchall.py 2000/08/07 02:34:33 1.4 > +++ Mailman/Bouncers/Catchall.py 2001/04/18 04:41:47 1.4.2.1 > @@ -1,4 +1,4 @@ > -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. > +# 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 > @@ -18,6 +18,16 @@ > # implementation of Bouncer.ScanMessage(). We keep it because I don't feel > # like splitting it up and porting it. It should at the very least be ported > # to use mimetools and re. :( > + > +# In Python 2.1, the import of regsub causes a DeprecationWarning. This is > +# annoying so if we can import the warnings module, we turn off warnings about > +# the import of regsub. It's not worth changing the uses of regsub to use the > +# re module because Catchall.py is going away in Mailman 2.1. > +try: > + import warnings > + warnings.filterwarnings('ignore', module='regsub') > +except ImportError: > + pass > > import re > import string > Index: admin/www/Makefile > =================================================================== > RCS file: /cvsroot/mailman/mailman/admin/www/Makefile,v > retrieving revision 1.1 > retrieving revision 1.1.2.1 > diff -u -r1.1 -r1.1.2.1 > --- admin/www/Makefile 2000/11/08 18:43:39 1.1 > +++ admin/www/Makefile 2001/04/18 10:43:46 1.1.2.1 > @@ -1,4 +1,4 @@ > -HT2HTML = /home/bwarsaw/projects/ht2html/ht2html.py > +HT2HTML = $(HOME)/projects/ht2html/ht2html.py > > HTSTYLE = MMGenerator > HTALLFLAGS = -f -s $(HTSTYLE) > Index: admin/www/download.ht > =================================================================== > RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v > retrieving revision 1.5.2.4 > retrieving revision 1.5.2.5 > diff -u -r1.5.2.4 -r1.5.2.5 > --- admin/www/download.ht 2001/03/12 19:33:49 1.5.2.4 > +++ admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 > @@ -65,9 +65,9 @@ >

      Downloading

      > >

      Version > -(2.0.3, > +(2.0.4, > released on > -Mar 12 2001) > +Apr 18 2001) > is the current GNU release. It is available from the following mirror sites: > >

        > @@ -98,5 +98,3 @@ > % gunzip -c mailman.tar.gz | tar xf - > > > -e> > -> > Index: admin/www/download.html > =================================================================== > RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v > retrieving revision 1.6.2.6 > retrieving revision 1.6.2.7 > diff -u -r1.6.2.6 -r1.6.2.7 > --- admin/www/download.html 2001/03/12 19:33:49 1.6.2.6 > +++ admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 > @@ -1,6 +1,6 @@ > > > - > + > > > 2.0.3, > +(2.0.4, > released on > -Mar 12 2001) > +Apr 18 2001) > is the current GNU release. It is available from the following mirror sites: > >
          > @@ -270,8 +270,6 @@ > % gunzip -c mailman.tar.gz | tar xf - > > > -e> > -> > > > > Index: cron/qrunner > =================================================================== > RCS file: /cvsroot/mailman/mailman/cron/qrunner,v > retrieving revision 1.18.2.2 > retrieving revision 1.18.2.3 > diff -u -r1.18.2.2 -r1.18.2.3 > --- cron/qrunner 2001/01/03 06:42:11 1.18.2.2 > +++ cron/qrunner 2001/04/18 03:58:35 1.18.2.3 > @@ -166,8 +166,8 @@ > > > _listcache = {} > + > def open_list(listname): > - global _listcache > mlist = _listcache.get(listname) > if not mlist: > try: > @@ -267,7 +267,6 @@ > > > if __name__ == '__main__': > - global _listcache > ## syslog('qrunner', 'qrunner begining') > # first, claim the queue runner lock > lock = LockFile.LockFile(QRUNNER_LOCK_FILE, > From benwa@ocentrix.com Wed Apr 18 21:04:40 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Wed, 18 Apr 2001 13:04:40 -0700 Subject: [Mailman-Developers] (no subject) Message-ID: <200104182004.f3IK4eP23988@mail.ocentrix.net> I keep on getting duplicates of messages sent to this list. I'm replying to one of them now. I don't get duplicates of all messages just certain ones. Is anyone else getting duplicates of messages? I can put together a list of all of the duplicates I've gotten recently if anyone is interested. -Ben ------- Original Copy ------- >Subject: [Mailman-Developers] (no subject) >Date: 04/18/2001 4:30 PM >From: "Vassil " >To: mailman-developers@python.org >Hello! I have a big problem with my video card. It is Nvidia ge Force 2 >MX and I can't run Linux with it! What should I do? Is there any way ? >----------------------------- >Free mail from www.dir.bg! > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman/listinfo/mailman-developers > From barry@digicool.com Wed Apr 18 21:32:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 18 Apr 2001 16:32:31 -0400 Subject: [Mailman-Developers] (no subject) References: <200104182004.f3IK4eP23988@mail.ocentrix.net> Message-ID: <15069.63967.827105.413516@anthem.wooz.org> >>>>> "BB" == Ben Burnett writes: BB> I can put together a list of all of the duplicates I've gotten BB> recently if anyone is interested. That would be great, but please include all the headers! -Barry From thomas@xs4all.net Thu Apr 19 17:35:36 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 19 Apr 2001 18:35:36 +0200 Subject: [Mailman-Developers] (no subject) In-Reply-To: <200104182004.f3IK4eP23988@mail.ocentrix.net>; from benwa@ocentrix.net on Wed, Apr 18, 2001 at 01:04:40PM -0700 References: <200104182004.f3IK4eP23988@mail.ocentrix.net> Message-ID: <20010419183536.C15288@xs4all.nl> On Wed, Apr 18, 2001 at 01:04:40PM -0700, Ben Burnett wrote: > I keep on getting duplicates of messages sent to this list. > I'm replying to one of them now. I don't get duplicates of > all messages just certain ones. Is anyone else getting > duplicates of messages? I can put together a list of all of > the duplicates I've gotten recently if anyone is interested. For the record, I did get two mails from this Vassil you quote below, but they are not duplicates -- one of them has some lines the other does not. Are you sure they are dups ? :) > ------- Original Copy ------- > >Subject: [Mailman-Developers] (no subject) > >Date: 04/18/2001 4:30 PM > >From: "Vassil " > >To: mailman-developers@python.org > > >Hello! I have a big problem with my video card. It is > Nvidia ge Force 2 > >MX and I can't run Linux with it! What should I do? Is > there any way ? > >----------------------------- > >Free mail from www.dir.bg! > > > >_______________________________________________ > >Mailman-Developers mailing list > >Mailman-Developers@python.org > >http://mail.python.org/mailman/listinfo/mailman-developers > > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From benwa@ocentrix.com Thu Apr 19 20:12:38 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 19 Apr 2001 12:12:38 -0700 Subject: [Mailman-Developers] (no subject) In-Reply-To: <20010419183536.C15288@xs4all.nl> References: <200104182004.f3IK4eP23988@mail.ocentrix.net> <200104182004.f3IK4eP23988@mail.ocentrix.net> Message-ID: <5.0.2.1.0.20010419120549.02279a40@mail.ocentrix.com> At 06:35 PM 4/19/01 +0200, Thomas Wouters wrote: >For the record, I did get two mails from this Vassil you quote below, but >they are not duplicates -- one of them has some lines the other does not. >Are you sure they are dups ? :) Yeah I noticed the same thing just before I went to bed last night. They weren't dupes after all, but I still think I've gotten duplicates of other messages. I won't be able to verify this until I get back to the office on monday. - Ben From claw@kanga.nu Thu Apr 26 09:03:01 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 26 Apr 2001 01:03:01 -0700 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) Message-ID: <5063.988272181@kanga.nu> >To: IETF-Announce: ; >Subject: RFC 2919 on List-Id >Cc: rfc-ed@ISI.EDU >Date: Tue, 24 Apr 2001 16:50:44 -0700 >From: RFC Editor > > > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2919 > > Title: List-Id: A Structured Field and Namespace for the > Identification of Mailing Lists > Author(s): R. Chandhok, G. Wenger > Status: Standards Track > Date: March 2001 > Mailbox: chandhok@within.com, wenger@within.com > Pages: 9 > Characters: 18480 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-chandhok-listid-04.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc2919.txt > > >Software that handles electronic mailing list messages (servers >and user agents) needs a way to reliably identify messages that >belong to a particular mailing list. With the advent of list >management headers, it has become even more important >to provide a unique identifier for a mailing list regardless of >the particular host that serves as the list processor at any >given time. > >The List-Id header provides a standard location for such an >identifier. In addition, a namespace for list identifiers >based on fully qualified domain names is described. This >namespace is intended to guarantee uniqueness for list owners >who require it, while allowing for a less rigorous namespace >for experimental and personal use. > >By including the List-Id field, list servers can make it easier >for mail clients to provide automated tools for users to >perform list functions. The list identifier can serve as a key >to make many automated processing tasks easier, and hence more >widely available. > >This is now a Proposed Standard Protocol. > >This document specifies an Internet standards track protocol for >the Internet community, and requests discussion and suggestions >for improvements. Please refer to the current edition of the >"Internet Official Protocol Standards" (STD 1) for the >standardization state and status of this protocol. Distribution >of this memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From jra@baylink.com Thu Apr 26 14:59:36 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 26 Apr 2001 09:59:36 -0400 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) In-Reply-To: <5063.988272181@kanga.nu>; from J C Lawrence on Thu, Apr 26, 2001 at 01:03:01AM -0700 References: <5063.988272181@kanga.nu> Message-ID: <20010426095936.03011@scfn.thpl.lib.fl.us> On Thu, Apr 26, 2001 at 01:03:01AM -0700, J C Lawrence wrote: > >A new Request for Comments is now available in online RFC libraries. > > RFC 2919 > > Title: List-Id: A Structured Field and Namespace for the > > Identification of Mailing Lists What, you're crossing *this* one, and you didn't cross RFC 2821 and RFC 2822? :-) Yes, Barry; those are what the numbers might suggest they are: I hope 2822 includes the stuff from son-of-1036, but I haven't read it yet. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 26 19:42:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 26 Apr 2001 14:42:40 -0400 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) References: <5063.988272181@kanga.nu> <20010426095936.03011@scfn.thpl.lib.fl.us> Message-ID: <15080.27680.803387.778959@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> What, you're crossing *this* one, and you didn't cross RFC JRA> 2821 and RFC 2822? :-) JRA> Yes, Barry; those are what the numbers might suggest they JRA> are: I hope 2822 includes the stuff from son-of-1036, but I JRA> haven't read it yet. Being a regular /. reader, I was aware of 2821 and 2822's release, but I actually hadn't heard about 2919. And yes, I'll be reading all those to see how best to support them in Mailman. ;) -Barry From claw@2wire.com Thu Apr 26 22:41:37 2001 From: claw@2wire.com (J C Lawrence) Date: Thu, 26 Apr 2001 14:41:37 -0700 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) In-Reply-To: Message from "Jay R. Ashworth" of "Thu, 26 Apr 2001 09:59:36 EDT." <20010426095936.03011@scfn.thpl.lib.fl.us> References: <5063.988272181@kanga.nu> <20010426095936.03011@scfn.thpl.lib.fl.us> Message-ID: <13650.988321297@2wire.com> On Thu, 26 Apr 2001 09:59:36 -0400 Jay R Ashworth wrote: > On Thu, Apr 26, 2001 at 01:03:01AM -0700, J C Lawrence wrote: >>> A new Request for Comments is now available in online RFC >>> libraries. > What, you're crossing *this* one, and you didn't cross RFC 2821 > and RFC 2822? :-) Yup, There's not that much actually new in 2821 and 2822. 2919 is actually *new*. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From greg@mad-scientist.com Thu Apr 26 23:27:07 2001 From: greg@mad-scientist.com (Gregory P . Smith) Date: Thu, 26 Apr 2001 15:27:07 -0700 Subject: [Mailman-Developers] syncmail - patch to handle filenames with spaces Message-ID: <20010426152707.A22902@mad-scientist.com> --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This qualifies as a hack in my book, but it works well for our repository. I modified an unknown version of the python syncmail script on our CVS server to properly deal with filenames in the cvs repository that have spaces in them. Attached are the patch against our previous version of syncmail and an actual copy of our whole syncmail script (since it has no obvious version numbers, etc). Why send this here? A friend pointed me to the mailman project as being the maintainers of the python syncmail script. I hope he's right (i didn't see anything obvious mentioning such on the webpage). Previously the version of syncmail we used would send emails saying "***** Broken: Foo no such file" instead of showing the diff of the file named 'Foo goes to the bar' (ie: a filename with evil spaces in it). With this it works with spaces. enjoy or ignore, Greg --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="syncmail-filespaces.patch" Index: syncmail =================================================================== RCS file: /cvsroot/CVSROOT/syncmail,v retrieving revision 1.1 retrieving revision 1.6 diff -u -C5 -r1.1 -r1.6 *** syncmail 2000/09/09 16:36:36 1.1 --- syncmail 2001/04/26 19:05:13 1.6 *************** *** 92,102 **** elif newrev == 'NONE': lines = ['--- %s DELETED ---\n' % file] else: # This /has/ to happen in the background, otherwise we'll run into CVS # lock contention. What a crock. ! diffcmd = '/usr/bin/cvs -f diff -kk -C 2 -r %s -r %s %s' % ( oldrev, newrev, file) fp = os.popen(diffcmd) lines = fp.readlines() sts = fp.close() # ignore the error code, it always seems to be 1 :( --- 92,102 ---- elif newrev == 'NONE': lines = ['--- %s DELETED ---\n' % file] else: # This /has/ to happen in the background, otherwise we'll run into CVS # lock contention. What a crock. ! diffcmd = '/usr/bin/cvs -f diff -kk -C 2 -r %s -r %s "%s"' % ( oldrev, newrev, file) fp = os.popen(diffcmd) lines = fp.readlines() sts = fp.close() # ignore the error code, it always seems to be 1 :( *************** *** 166,176 **** print 'Mailing %s...' % PEOPLE if specs == ['-', 'Imported', 'sources']: return if specs[-3:] == ['-', 'New', 'directory']: del specs[-3:] ! blast_mail(mailcmd, specs[1:]) if __name__ == '__main__': print 'Running syncmail...' --- 166,200 ---- print 'Mailing %s...' % PEOPLE if specs == ['-', 'Imported', 'sources']: return if specs[-3:] == ['-', 'New', 'directory']: del specs[-3:] ! ! # hack to try and deal with filenames containing spaces -greg@electricrain dot com ! files = specs[1:] ! realfiles = [] ! i = 0 ! while i < len(files): ! # the parameters are all 'filename,ver1,ver2' so just put ones in the realfiles list ! # that have ,s in them. (XXX this will break down if your actual names include commas ! # and spaces you bumbling mangled file name morons out there) ! if string.find(files[i], ',') == -1: ! j = i + 1 ! t = files[i] ! while j < len(files): ! t = t + ' ' + files[j] ! if string.find(files[j], ',') != -1: ! realfiles.append(t) ! i = j ! break ! j = j + 1 ! else: ! realfiles.append(files[i]) ! i = i + 1 ! ! #print 'XXX blast mail:', `realfiles`, '(being debugged)' ! blast_mail(mailcmd, realfiles) if __name__ == '__main__': print 'Running syncmail...' --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=syncmail #! /usr/bin/python # -*- Python -*- """Complicated notification for CVS checkins. This script is used to provide email notifications of changes to the CVS repository. These email changes will include context diffs of the changes. Really big diffs will be trimmed. This script is run from a CVS loginfo file (see $CVSROOT/CVSROOT/loginfo). To set this up, create a loginfo entry that looks something like this: mymodule /path/to/syncmail %%s some-email-addr@your.domain In this example, whenever a checkin that matches `mymodule' is made, the syncmail script is invoked, which will generate the diff containing email, and send it to some-email-addr@your.domain. Note: This module used to also do repository synchronizations via rsync-over-ssh, but since the repository has been moved to SourceForge, this is no longer necessary. The syncing functionality has been ripped out in the 3.0, which simplifies it considerably. Access the 2.x versions to refer to this functionality. Because of this, the script's name is misleading. It no longer makes sense to run this script from the command line. Doing so will only print out this usage information. Usage: syncmail [options] <%%S> email-addr [email-addr ...] Where options is: --cvsroot= Use as the environment variable CVSROOT. Otherwise this variable must exist in the environment. --help -h Print this text. <%%S> CVS %%s loginfo expansion. When invoked by CVS, this will be a single string containing the directory the checkin is being made in, relative to $CVSROOT, followed by the list of files that are changing. If the %%s in the loginfo file is %%{sVv}, context diffs for each of the modified files are included in any email messages that are generated. email-addrs At least one email address. """ import os import sys import string import time import getopt # Notification command MAILCMD = '/bin/mail -s "CVS: %(SUBJECT)s" %(PEOPLE)s 2>&1 > /dev/null' # Diff trimming stuff DIFF_HEAD_LINES = 20 DIFF_TAIL_LINES = 20 DIFF_TRUNCATE_IF_LARGER = 1000 def usage(errcode, msg=''): print __doc__ % globals() if msg: print msg sys.exit(errorcode) def calculate_diff(filespec): try: file, oldrev, newrev = string.split(filespec, ',') except ValueError: # No diff to report return '***** Bogus filespec: %s' % filespec if oldrev == 'NONE': try: fp = open(file) lines = fp.readlines() fp.close() lines.insert(0, '--- NEW FILE ---\n') except IOError, e: lines = ['***** Error reading new file: ', str(e)] elif newrev == 'NONE': lines = ['--- %s DELETED ---\n' % file] else: # This /has/ to happen in the background, otherwise we'll run into CVS # lock contention. What a crock. diffcmd = '/usr/bin/cvs -f diff -kk -C 2 -r %s -r %s "%s"' % ( oldrev, newrev, file) fp = os.popen(diffcmd) lines = fp.readlines() sts = fp.close() # ignore the error code, it always seems to be 1 :( ## if sts: ## return 'Error code %d occurred during diff\n' % (sts >> 8) if len(lines) > DIFF_TRUNCATE_IF_LARGER: removedlines = len(lines) - DIFF_HEAD_LINES - DIFF_TAIL_LINES del lines[DIFF_HEAD_LINES:-DIFF_TAIL_LINES] lines.insert(DIFF_HEAD_LINES, '[...%d lines suppressed...]\n' % removedlines) return string.join(lines, '') def blast_mail(mailcmd, filestodiff): # cannot wait for child process or that will cause parent to retain cvs # lock for too long. Urg! if not os.fork(): # in the child # give up the lock you cvs thang! time.sleep(2) fp = os.popen(mailcmd, 'w') fp.write(sys.stdin.read()) fp.write('\n') # append the diffs if available for file in filestodiff: fp.write(calculate_diff(file)) fp.write('\n') fp.close() # doesn't matter what code we return, it isn't waited on os._exit(0) # scan args for options def main(): try: opts, args = getopt.getopt(sys.argv[1:], 'h', ['cvsroot=', 'help']) except getopt.error, msg: usage(1, msg) # parse the options for opt, arg in opts: if opt in ('-h', '--help'): usage(0) elif opt == '--cvsroot': os.environ['CVSROOT'] = arg # What follows is the specification containing the files that were # modified. The argument actually must be split, with the first component # containing the directory the checkin is being made in, relative to # $CVSROOT, followed by the list of files that are changing. if not args: usage(1, 'No CVS module specified') SUBJECT = args[0] specs = string.split(args[0]) del args[0] # The remaining args should be the email addresses if not args: usage(1, 'No recipients specified') # Now do the mail command PEOPLE = string.join(args) mailcmd = MAILCMD % vars() print 'Mailing %s...' % PEOPLE if specs == ['-', 'Imported', 'sources']: return if specs[-3:] == ['-', 'New', 'directory']: del specs[-3:] # hack to try and deal with filenames containing spaces -greg@electricrain dot com files = specs[1:] realfiles = [] i = 0 while i < len(files): # the parameters are all 'filename,ver1,ver2' so just put ones in the realfiles list # that have ,s in them. (XXX this will break down if your actual names include commas # and spaces you bumbling mangled file name morons out there) if string.find(files[i], ',') == -1: j = i + 1 t = files[i] while j < len(files): t = t + ' ' + files[j] if string.find(files[j], ',') != -1: realfiles.append(t) i = j break j = j + 1 else: realfiles.append(files[i]) i = i + 1 #print 'XXX blast mail:', `realfiles`, '(being debugged)' blast_mail(mailcmd, realfiles) if __name__ == '__main__': print 'Running syncmail...' main() print '...syncmail done.' sys.exit(0) --FCuugMFkClbJLl1L-- From barry@digicool.com Fri Apr 27 03:43:27 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 26 Apr 2001 22:43:27 -0400 Subject: [Mailman-Developers] ANNOUNCE mimelib 0.3 Message-ID: <15080.56527.608668.936637@anthem.wooz.org> I've finally moved mimelib development to SourceForge, and uploaded version 0.3. mimelib is yet another MIME and RFC 2822 message handling library for Python. It differs from older modules and packages by providing an abstract MIME object model separate from parsing and generating the plain text representations. There is a parser class to convert from plain text to the model, and a generator class to output plain text from the model. Along the way, the object model can be manipulated in very Pythonic ways (or you can generate an entire model from scratch using the provided message classes). mimelib is compatible with Python 2.x. My goal is to solidify the API and implementation enough for inclusion of mimelib in Python 2.2. mimelib 0.3 is required for the current CVS snapshot of Mailman 2.1 alpha. For online documentation, see http://mimelib.sourceforge.net For project information, see http://sourceforge.net/projects/mimelib For downloading mimelib-0.3.tar.gz, see http://sourceforge.net/project/showfiles.php?group_id=25568 And of course, there's a mailing list for developers Postings: mimelib-devel@lists.sourceforge.net Subscribe: http://lists.sourceforge.net/lists/listinfo/mimelib-devel Enjoy, -Barry From barry@digicool.com Fri Apr 27 03:52:58 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 26 Apr 2001 22:52:58 -0400 Subject: [Mailman-Developers] syncmail - patch to handle filenames with spaces References: <20010426152707.A22902@mad-scientist.com> Message-ID: <15080.57098.235427.364490@anthem.wooz.org> >>>>> "GP" == Gregory P writes: GP> This qualifies as a hack in my book, but it works well for our GP> repository. I modified an unknown version of the python GP> syncmail script on our CVS server to properly deal with GP> filenames in the cvs repository that have spaces in them. GP> Attached are the patch against our previous version of GP> syncmail and an actual copy of our whole syncmail script GP> (since it has no obvious version numbers, etc). GP> Why send this here? A friend pointed me to the mailman GP> project as being the maintainers of the python syncmail GP> script. I hope he's right (i didn't see anything obvious GP> mentioning such on the webpage). GP> Previously the version of syncmail we used would send emails GP> saying "***** Broken: Foo no such file" instead of showing the GP> diff of the file named 'Foo goes to the bar' (ie: a filename GP> with evil spaces in it). With this it works with spaces. Greg, Thanks for the new syncmail script. Actually syncmail is used by the Mailman project, the Python project, (and momentarily, the mimelib project). It's probably also still used by the Jython project. So there are versions in each of those project's CVSROOTs, as well as a version in the Python snippets section of the SF Python Foundary. Between all those, I've found at least 4 different revisions of syncmail! I think the latest one is version 3.16 that Fred Drake hacked last. I'll try to take some time to synchronize all these versions, and upload the merge to the Python snippets (and Mailman and mimelib projects). Again, thanks, -Barry From ralf.laue@virbus.de Fri Apr 27 15:01:37 2001 From: ralf.laue@virbus.de (Ralf Laue) Date: Fri, 27 Apr 2001 16:01:37 +0200 Subject: [Mailman-Developers] Patch: ignoring (no subject) in the subject line of a administrative request Message-ID: <3AE97BC1.DBF9D4CB@virbus.de> Just a simple but useful patch: If someone sends an administrative request to the -request address, he or she may leave the subject line empty, writing the commands(s) in the body of the message. Netscape and other mailers suggest a default subject "(no subject)", and the sender will get an error report because (no subject) is no valid command. Best Wishes, Ralf diff /usr/local/mailman/Mailman/MailCommandHandler.py /usr/src/mailman-2.0.3/Mailman/MailCommandHandler.py 132,134d131 < # ignoring (no subject) in the subject line of a administrative request < if subject == "(no subject)" or subject == "(No Subject)" < subject = "" From Dale@Newfield.org Fri Apr 27 15:03:05 2001 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 27 Apr 2001 10:03:05 -0400 (EDT) Subject: [Mailman-Developers] Small nntp server? In-Reply-To: <15080.56527.608668.936637@anthem.wooz.org> Message-ID: I'm looking to utilize Mailman's Mail-News and News-Mail gateways, but I'm really not interested in serving any other newsgroups, and I don't particularly need to push these news articles upstream to anyplace. (And I don't want to worry about propogation to subscribers sites, or net-wide spam, so I think I'd like to serve it all from our box.) Does anyone have a (free?) unix based nntp server they'd suggest that can be configured to be stand-alone (no pushing upstream or downstream), and would handle 10's of local newsgroups and ~1000 subscribers reasonably well? We're running a FreeBSD box if that matters. -Dale Newfield webmaster@wunderland.com From bart@jukie.net Sat Apr 28 02:04:04 2001 From: bart@jukie.net (Bart Trojanowski) Date: Fri, 27 Apr 2001 21:04:04 -0400 (EDT) Subject: [Mailman-Developers] [PATCH] add message counters to Subject line Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-1374547809-988419618=:20596 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: [ I am not on the list so please leave me in the CC on this thread ] After doing this 'patch' you can specify a single %d anywhere in subject_prefix (ie the 'Prefix for subject line of list postings') and it will be magically replaced to the post_id (ie the message index). BTW, where is the post_id stored? Can I updated it from the command line with some (less)? standard tool? I have tested with formats of type '[LIST (%d)]' for subject_prefix. I would not be surprised if some strange formats may screw up my regular expresions... today is my first day writing Python :) Ex: Say you have a list with subject_prefix set to '[LIST (%d)]' The first post will have a subject of: Subject: [LIST (1)] the real subject line The reply to this will hold: Subject: Re: [LIST (2)] the real subject line The reply to that will hold: Subject: Re: [LIST (3)] the real subject line And so on. Regards, Bart. -- WebSig: http://www.jukie.net/~bart/sig/ --8323328-1374547809-988419618=:20596 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="CookHeaders.py.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="CookHeaders.py.patch" LS0tIENvb2tIZWFkZXJzLnB5LQlGcmkgQXByIDI3IDIwOjU4OjMyIDIwMDEN CisrKyBDb29rSGVhZGVycy5weQlGcmkgQXByIDI3IDIwOjU5OjA3IDIwMDEN CkBAIC00NywxMyArNDcsMjAgQEANCiAgICAgICAgICMgc3VjaCBhcyB0aGUg bGlzdCBhZG1pbikuICBXZSBhc3N1bWUgYWxsIGRpZ2VzdHMgaGF2ZSBhbiBh cHByb3ByaWF0ZQ0KICAgICAgICAgIyBzdWJqZWN0IGhlYWRlciBhZGRlZCBi eSB0aGUgVG9EaWdlc3QgbW9kdWxlLg0KICAgICAgICAgcHJlZml4ID0gbWxp c3Quc3ViamVjdF9wcmVmaXgNCisgICAgICAgIG1wcmVmaXggPSByZS5lc2Nh cGUocHJlZml4KQ0KKyAgICAgICAgaWYgcHJlZml4IGFuZCByZS5zZWFyY2go cmUuZXNjYXBlKCclZCcpLCBwcmVmaXgsIHJlLkkpOg0KKyAgICAgICAgICAg IG1hdGNoID0gcmUubWF0Y2gociJeKC4qKSIrcmUuZXNjYXBlKCIlZCIpKyIo LiopJCIsIHByZWZpeCkNCisgICAgICAgICAgICBpZiBtYXRjaDoNCisgICAg ICAgICAgICAgICAgbXByZWZpeCA9IHJlLmVzY2FwZShtYXRjaC5ncm91cCgx KSkrIlxkKyIrcmUuZXNjYXBlKG1hdGNoLmdyb3VwJCAgICAgICAgICAgIHBy ZWZpeCA9IHByZWZpeCAlIG1saXN0LnBvc3RfaWQNCiAgICAgICAgICMgV2Ug cHVycG9zZWZ1bGx5IGxlYXZlIG5vIHNwYWNlIGIvdyBwcmVmaXggYW5kIHN1 YmplY3QhDQogICAgICAgICBpZiBub3Qgc3ViamVjdDoNCi0gICAgICAgICAg ICBkZWwgbXNnWydzdWJqZWN0J10NCi0gICAgICAgICAgICBtc2dbJ1N1Ympl Y3QnXSA9IHByZWZpeCArIF8oJyhubyBzdWJqZWN0KScpDQotICAgICAgICBl bGlmIHByZWZpeCBhbmQgbm90IHJlLnNlYXJjaChyZS5lc2NhcGUocHJlZml4 KSwgc3ViamVjdCwgcmUuSSk6DQotICAgICAgICAgICAgZGVsIG1zZ1snc3Vi amVjdCddDQotICAgICAgICAgICAgbXNnWydTdWJqZWN0J10gPSBwcmVmaXgg KyBzdWJqZWN0DQorICAgICAgICAgICAgbXNnWydTdWJqZWN0J10gPSBwcmVm aXggKyAnKG5vIHN1YmplY3QpJw0KKyAgICAgICAgZWxpZiBwcmVmaXg6DQor ICAgICAgICAgICAgbWF0Y2ggPSByZS5tYXRjaChyIl4oLiopIittcHJlZml4 KyIoLiopJCIsIHN1YmplY3QpDQorICAgICAgICAgICAgaWYgbWF0Y2g6DQor ICAgICAgICAgICAgICAgIG1zZ1snU3ViamVjdCddID0gbWF0Y2guZ3JvdXAo MSkgKyBwcmVmaXggKyBtYXRjaC5ncm91cCgyKQ0KKyAgICAgICAgICAgIGVs c2U6DQorICAgICAgICAgICAgICAgIG1zZ1snU3ViamVjdCddID0gcHJlZml4 ICsgc3ViamVjdA0KICAgICAjDQogICAgICMgZ2V0IHJpZCBvZiBkdXBsaWNh dGUgaGVhZGVycw0KICAgICBkZWwgbXNnWydzZW5kZXInXQ0K --8323328-1374547809-988419618=:20596-- From ricardo@rixhq.nu Sat Apr 28 11:33:24 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 28 Apr 2001 12:33:24 +0200 Subject: [Mailman-Developers] empty digests Message-ID: <20010428123324.A1102@rix.rixhq.nu> Hi, Last night I had to change all subscribers to one of my lists to a digest version. I used bin/withlist -l in interactive mode and gave the following python commands: all = m.GetMembers() for member in all: m.SetUserDigest(member, 1, force=1) This took a really long time (1635 regular subscribers) and after about 20 minutes I decided to press Ctrl-C cause I was afraid it hung somewhow... this means I wasn't able to do a m.Save() but after checking the number of subscriber was reduced to about 60 so appearantly it did work out... After that I decided to rerun the commands again and this time I waited untill it was finished and did a m.Save() Anyway my point is that now I'm getting some complaints from members about receiving empty digests (it only says the number of posts which should be in there) I'm not sure yet what they are missing but I was wondering if I could have messed things about by interrupting the process w/o a m.Save()? When I look up the subscription options for one of the members who complained I don't see anything weird in there... -- Regards, Ricardo From ricardo@rixhq.nu Sat Apr 28 12:23:41 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 28 Apr 2001 13:23:41 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010428123324.A1102@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 28, 2001 at 12:33:24PM +0200 References: <20010428123324.A1102@rix.rixhq.nu> Message-ID: <20010428132341.C1102@rix.rixhq.nu> On Sat, Apr 28, 2001 at 12:33:24PM +0200, Ricardo Kustner wrote: > Anyway my point is that now I'm getting some complaints from members about > receiving empty digests (it only says the number of posts which should be in > there) I'm not sure yet what they are missing but I was wondering if I > could have messed things about by interrupting the process w/o a m.Save()? uh oh please don't tell me that when mailman sends out digests, they travel through the /etc/aliases addresses cause that would mean a neat little perl script I use filters out the MIME digests... :( [I really need this script to keep the digests clean from garbage)... hmm on the other hand it could also be that the digests are handled directly by qrunner so they won't go through the filter so that wouldn't explain the problems... Regards, Ricardo From wilane@MINT.SN Sun Apr 29 20:12:29 2001 From: wilane@MINT.SN (Ousmane Wilane) Date: Sun, 29 Apr 2001 19:12:29 +0000 (GMT) Subject: [Mailman-Developers] 2006 archives already online! In-Reply-To: Message-ID: Hi, Take a look at the Mailman-dev archives page, we have a 2006-April line there with only one message. Perhaps I'm missing sth! Kind regars. W. O. From tollef@add.no Mon Apr 30 16:59:14 2001 From: tollef@add.no (Tollef Fog Heen) Date: 30 Apr 2001 17:59:14 +0200 Subject: [Mailman-Developers] small fix for admindb.py Message-ID: <87hez6750t.fsf@arabella.intern.opera.no> It seems like admindb.py doesn't escape the body of html emails properly, which can make it impossible to do anything to the post. This patch should fix it. --- mailman/Mailman/Cgi/admindb.py~ Mon Apr 30 17:53:15 2001 +++ mailman/Mailman/Cgi/admindb.py Mon Apr 30 17:56:09 2001 @@ -228,7 +228,7 @@ row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() t.AddCellInfo(row, col-1, align='right') t.AddRow([Bold('Message Excerpt:'), - TextArea('fulltext-%d' % id, text, rows=10, cols=80)]) + TextArea('fulltext-%d' % id, cgi.escape(text), rows=10, cols=80)]) t.AddCellInfo(row+1, col-1, align='right') form.AddItem(t) form.AddItem('

          ') -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From bbum@CODEFAB.COM Mon Apr 30 17:27:56 2001 From: bbum@CODEFAB.COM (Bill Bumgarner) Date: Mon, 30 Apr 2001 12:27:56 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: Message-ID: <200104301627.f3UGRuW78079@pi.codefab.com> This appears to be a fairly common problem; I suspect that MailMan is using a header to set the date and some folks have their client set to preposterous dates. See: http://www.omnigroup.com/mailman/archive/webobjects-dev/ The above is from a mailing list managed with 2.0b3. b.bum On Monday, April 30, 2001, at 12:02 PM, mailman-developers- request@python.org wrote: > Date: Sun, 29 Apr 2001 19:12:29 +0000 (GMT) > From: Ousmane Wilane > To: > Subject: [Mailman-Developers] 2006 archives already online! > > Hi, > Take a look at the Mailman-dev archives page, we have a 2006-April > line there with only one message. Perhaps I'm missing sth! > Kind regars. > > W. O. From darrell@grumblesmurf.net Mon Apr 30 18:23:35 2001 From: darrell@grumblesmurf.net (Darrell Fuhriman) Date: 30 Apr 2001 10:23:35 -0700 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: Bill Bumgarner's message of "Mon, 30 Apr 2001 12:27:56 -0400" References: <200104301627.f3UGRuW78079@pi.codefab.com> Message-ID: Bill Bumgarner writes: > This appears to be a fairly common problem; I suspect that > MailMan is using a header to set the date and some folks have > their client set to preposterous dates. See: That's why under "archival options" you'll find: "Set date in archive to when the mail is claimed to have been sent, or to the time we resend it?" If you leave it on 'when sent', you deserve the mess you'll get in your archives. Darrell From fil@rezo.net Mon Apr 30 20:28:51 2001 From: fil@rezo.net (Fil) Date: Mon, 30 Apr 2001 21:28:51 +0200 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: ; from darrell@grumblesmurf.net on Mon, Apr 30, 2001 at 10:23:35AM -0700 References: <200104301627.f3UGRuW78079@pi.codefab.com> Message-ID: <20010430212851.A5097@orwell.bok.net> @ Darrell Fuhriman (darrell@grumblesmurf.net) : > That's why under "archival options" you'll find: > > "Set date in archive to when the mail is claimed to have been > sent, or to the time we resend it?" > > If you leave it on 'when sent', you deserve the mess you'll get > in your archives. "When sent" is the default. How do you change the default to "When Resent"? Shouldn't it be changed in the mailman's Defaults.py ? -- Fil From marc_news@valinux.com Mon Apr 30 23:41:46 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 30 Apr 2001 15:41:46 -0700 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <20010430212851.A5097@orwell.bok.net>; from fil@rezo.net on Mon, Apr 30, 2001 at 09:28:51PM +0200 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> Message-ID: <20010430154146.C32211@magic.merlins.org> On Mon, Apr 30, 2001 at 09:28:51PM +0200, Fil wrote: > @ Darrell Fuhriman (darrell@grumblesmurf.net) : > > That's why under "archival options" you'll find: > > > > "Set date in archive to when the mail is claimed to have been > > sent, or to the time we resend it?" > > > > If you leave it on 'when sent', you deserve the mess you'll get > > in your archives. > > "When sent" is the default. How do you change the default to "When Resent"? > Shouldn't it be changed in the mailman's Defaults.py ? I very firmly believe this, and so do all the people who have archives showing messages with dates of 2004 or 1990. http://lists.svlug.org/pipermail/svlug/ I've asked the same thing in the past, but it didn't go through. Please? :-) 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 jj-list@mail.dk Mon Apr 30 23:54:39 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Tue, 01 May 2001 00:54:39 +0200 Subject: [Mailman-Developers] Delivering messages to scripts/post Message-ID: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> We have been running Mailman on Windows for about two weeks now and most things seem to work very well. To make it run I had to make some changes - all of them minor - and most of them related to opening files ('b'). Mailmanwin (as I have named it) is probably not useful for anyone but me (and my company) right now; some things do not work at all (web interface, e-mail archive, usenet gateway, all the bin scripts) and some things are changed to make them better fit my needs. I have made an "install" script doing all the work and describing all the changes, so it's fairly easy getting started. I hope to get a webpage up with these things soon. I don't expect the mailman developers to take account of any of these changes. I fully understand and respect that this is a Linux project and would hate if cross platform issues in any way affected the future direction of Mailman. Having said that, it would be nice if no module names conflicted with modules in the standard Python distribution (mailbox) ;) On to the questions. 1. Delivering messages to scripts/post I could not find any MTA for Windows (I didn't look much, though) that was able to get the toaddr and deliver the message to scripts/post. Instead we are using L-soft LSMTP (we used L-soft LISTSERV before changing to Mailman). LSMTP is told to save all messages (complete with all envelope header information) and I have made a Python script that parses each message and calls Enqueu with the correct parameters. This works well, except that we have had a couple of mail loops because of auto-responders replying directly to the list. So my question is, what information does a MTA look for before passing the message to post? I found out that filtering out all messages with daemon and/or postmaster in the fromaddr is a good idea. Are there any other "keywords" that i should know of? 2. Empty envelope fromaddr In some messages the envelope fromaddr is empty. Is it safe to never deliver a message with an empty envelope fromaddr to a list? 3. Using the envelope fromaddr or the message fromaddr I can see that this is a Mailman setting. What are the consequences of using only the envelope fromaddr? Just for the record. L-soft LISTSERV is a great product - the most solid/stable I have ever used. We chaned to Mailman because we needed some things LISTSERV didn't have. All the best, Jesper. From bootc@worldnet.fr Sun Apr 1 12:11:19 2001 From: bootc@worldnet.fr (Chris Boot) Date: Sun, 01 Apr 2001 13:11:19 +0200 Subject: [Mailman-Developers] Contribution: Procmail mail filter format Message-ID: Hi, I installed Mailman on my system yesterday--a very nice piece of code! I have an account on a host which gives me a virtual e-mail address, as in everything that goes to @my.domain.com is forwarded to my account, and I can't just add things to /etc/aliases, or the whole system would go belly up (I don't even have privs to anything in /etc). So what I use to sort through mail is Procmail, which works very nicely. I got Mailman to run in this one-user setup using Procmail quite simply. What I've done is added some code to bin/newlist which will generate the Procmail filtering rules for me. I'm not sure how to submit my changes, but here they are. I did these changes on a pretty vanilla Mailman-2.0.3 distribution. First, the definition of the alias style: PROCMAIL_ALIAS_STYLE = """ :0 * $^To:.*%(listname)s | %(wrapper)s post %(listname)s :0 * $^To:.*%(listname)s+(-owner|-admin) | %(wrapper)s mailowner %(listname)s :0 * $^To:.*%(listname)s-request | %(wrapper)s mailcmd %(listname)s """ And now checking the config for the procmail identifier: elif style == 'procmail': ALIASTEMPLATE = PROCMAIL_ALIAS_STYLE STDOURMSG = 'To create list aliases, add this to your procmailrc:' All you need to do is set the MTA style to 'procmail' and it will generate the Procmail filter rules. I did all of this with no previous knowledge of Python whatsoever, so there probably are some mistakes, despite the small size of this code... Thanks for Mailman. Now I'm paying back. ;-) -- Chris Boot bootc@worldnet.fr "Modem error handling really su~c%dk,s.^D^D&x@R*cCKo#?CB,*o#?C!!b %o#? NO CARRIER From claw@kanga.nu Sun Apr 1 19:18:47 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 01 Apr 2001 11:18:47 -0700 Subject: [Mailman-Developers] Contribution: Procmail mail filter format In-Reply-To: Message from Chris Boot of "Sun, 01 Apr 2001 13:11:19 +0200." References: Message-ID: <15393.986149127@kanga.nu> On Sun, 01 Apr 2001 13:11:19 +0200 Chris Boot wrote: > What I've done is added some code to bin/newlist which will > generate the Procmail filtering rules for me. I'm not sure how to > submit my changes, but here they are. I did these changes on a > pretty vanilla Mailman-2.0.3 distribution. Your procmail rules miss two interesting cases: messages CC'ed or BCC to the list. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From bootc@worldnet.fr Sun Apr 1 20:05:26 2001 From: bootc@worldnet.fr (Chris Boot) Date: Sun, 01 Apr 2001 21:05:26 +0200 Subject: [Mailman-Developers] Contribution: Procmail mail filter format In-Reply-To: <15393.986149127@kanga.nu> Message-ID: > On Sun, 01 Apr 2001 13:11:19 +0200 > Chris Boot wrote: >=20 >> What I've done is added some code to bin/newlist which will >> generate the Procmail filtering rules for me. I'm not sure how to >> submit my changes, but here they are. I did these changes on a >> pretty vanilla Mailman-2.0.3 distribution. >=20 > Your procmail rules miss two interesting cases: messages CC'ed or > BCC to the list. Ah, yes, you're right. I don't know how you can take care of BCC's (they'r= e _meant_ to be hidden, aren't they?), but here's the fix for the CC problem: PROCMAIL_ALIAS_STYLE =3D """ :0 * $^TO_%(listname)s | %(wrapper)s post %(listname)s :0 * $^TO_%(listname)s+(-owner|-admin) | %(wrapper)s mailowner %(listname)s :0=20 * $^TO_%(listname)s-request | %(wrapper)s mailcmd %(listname)s """ The TO_ is a built-in Procmail rule which expands to: (=96((Original-)?(Resent-)?(To|Cc|Bcc)| (X-Envelope|Apparently(-Resent)?)-To):(.*[=96-a-zA-Z0-9_.])?) --=20 Chris Boot bootc@worldnet.fr All your base are belong to us! From ralph@inputplus.demon.co.uk Sun Apr 1 21:18:49 2001 From: ralph@inputplus.demon.co.uk (Ralph Corderoy) Date: Sun, 01 Apr 2001 21:18:49 +0100 Subject: [Mailman-Developers] Problem with mailman-2.1a1, syntax error in bin/update : print >> sys.stderr ... In-Reply-To: Message from barry@digicool.com (Barry A. Warsaw) of "Wed, 28 Mar 2001 21:45:08 CDT." <15042.41396.797377.993500@anthem.wooz.org> Message-ID: <200104012018.VAA23498@inputplus.demon.co.uk> Hi Barry, > I'm not even sure what "make altinstall" does. ;) These error sure > point to Mailman finding an earlier version of Python than 2.0. Couldn't some of the make targets check that the version of Python available is sufficiently recent? This seems to crop up a lot as Mailman is using recent Python features. Ralph. From barry@digicool.com Sun Apr 1 21:30:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 1 Apr 2001 16:30:31 -0400 Subject: [Mailman-Developers] Problem with mailman-2.1a1, syntax error in bin/update : print >> sys.stderr ... References: <15042.41396.797377.993500@anthem.wooz.org> <200104012018.VAA23498@inputplus.demon.co.uk> Message-ID: <15047.36839.404427.802619@anthem.wooz.org> >>>>> "RC" == Ralph Corderoy writes: >> I'm not even sure what "make altinstall" does. ;) These error >> sure point to Mailman finding an earlier version of Python than >> 2.0. RC> Couldn't some of the make targets check that the version of RC> Python available is sufficiently recent? This seems to crop RC> up a lot as Mailman is using recent Python features. The configure script is supposed to enforce this, but it hadn't been updated. I've just checked in the fix for this. -Barry From claw@kanga.nu Sun Apr 1 21:51:31 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 01 Apr 2001 13:51:31 -0700 Subject: [Mailman-Developers] Contribution: Procmail mail filter format In-Reply-To: Message from Chris Boot of "Sun, 01 Apr 2001 21:05:26 +0200." References: Message-ID: <21197.986158291@kanga.nu> On Sun, 01 Apr 2001 21:05:26 +0200 Chris Boot wrote: > Ah, yes, you're right. I don't know how you can take care of > BCC's (they're _meant_ to be hidden, aren't they?), but here's the > fix for the CC problem: The way to track BCC's (given that you have everything running to a common mailbox) is to have an MTA further up the pipe record the destination address (ie original RCPT_TO value) in one of the headers so that you can then filter off that (this may already be happening). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From jj-list@mail.dk Sun Apr 1 22:08:15 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Sun, 01 Apr 2001 23:08:15 +0200 Subject: [Mailman-Developers] Sender field Message-ID: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> Why is the 'sender' header field set to the list admin address? E.g.: Sender: mailman-developers-admin@python.org I'm asking because I haven't seen this elsewhere. Elsewhere being LISTSERV and eGroups. I probably wouldn't have noticed if it wasn't because Outlook 2000 (maybe other versions) shows this information as the 'from' address in the preview pane separator. This is probably a flaw in Outlook - I don't know - maybe it's on purpose. The "correct" 'from' address is shown elsewhere in the program. Anyway, back to my question, is Mailman doing this to conform with some rfc, or would it be safe to either remove the 'sender' header field og simply insert the "correct" 'from' address instead? All the best, Jesper. From claw@kanga.nu Sun Apr 1 22:54:43 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 01 Apr 2001 14:54:43 -0700 Subject: [Mailman-Developers] Sender field In-Reply-To: Message from Jesper Jensen of "Sun, 01 Apr 2001 23:08:15 +0200." <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> Message-ID: <17744.986162083@kanga.nu> On Sun, 01 Apr 2001 23:08:15 +0200 Jesper Jensen wrote: > Why is the 'sender' header field set to the list admin address? > E.g.: Sender: mailman-developers-admin@python.org I'd imagine its to better handle bounces from broken MTAs. > I probably wouldn't have noticed if it wasn't because Outlook 2000 > (maybe other versions) shows this information as the 'from' > address in the preview pane separator. This is probably a flaw in > Outlook... Minimally it is Broken As Designed -- a characteristic we've all beome very familiar with with Outlook. > Anyway, back to my question, is Mailman doing this to conform with > some rfc, or would it be safe to either remove the 'sender' header > field og simply insert the "correct" 'from' address instead? I'm not aware of an RFC mandate which covers this area. That said its worth realising that Sender is an unreliable header and may be re-written by the first MTA (depends on how the message was delivered). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From barry@digicool.com Mon Apr 2 03:30:44 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sun, 1 Apr 2001 22:30:44 -0400 Subject: [Mailman-Developers] Sender field References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> <17744.986162083@kanga.nu> Message-ID: <15047.58452.802942.133727@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> Anyway, back to my question, is Mailman doing this to conform >> with some rfc, or would it be safe to either remove the >> 'sender' header field og simply insert the "correct" 'from' >> address instead? JCL> I'm not aware of an RFC mandate which covers this area. That JCL> said its worth realising that Sender is an unreliable header JCL> and may be re-written by the first MTA (depends on how the JCL> message was delivered). RFC 822, section 4.4.2 says: 4.4.2. SENDER / RESENT-SENDER This field contains the authenticated identity of the AGENT (person, system or process) that sends the message. It is intended for use when the sender is not the author of the mes- sage, or to indicate who among a group of authors actually sent the message. If the contents of the "Sender" field would be completely redundant with the "From" field, then the "Sender" field need not be present and its use is discouraged (though still legal). In particular, the "Sender" field MUST be present if it is NOT the same as the "From" Field. The Sender mailbox specification includes a word sequence which must correspond to a specific agent (i.e., a human user or a computer program) rather than a standard address. This indicates the expectation that the field will identify the single AGENT (person, system, or process) responsible for sending the mail and not simply include the name of a mailbox from which the mail was sent. For example in the case of a shared login name, the name, by itself, would not be adequate. The local-part address unit, which refers to this agent, is expected to be a computer system term, and not (for example) a generalized person reference which can be used outside the network text message context. August 13, 1982 - 21 - RFC #822 Standard for ARPA Internet Text Messages Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer pro- gram generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mail- box specification. My interpretation of this section is that since regular deliveries use the From: field supplied by the original author, but it is Mailman's responsibility for sending the mail through the system, the Sender: field ought to be the human responsible for list maintenance, e.g. list-owner or list-admin. It has proved to be more practical to point Sender: at list-admin so that bounce processing can take first crack at the message, sending it on to the list moderators if that fails. -Barry From jra@baylink.com Mon Apr 2 05:15:55 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 2 Apr 2001 00:15:55 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: <15047.58452.802942.133727@anthem.wooz.org>; from "Barry A. Warsaw" on Sun, Apr 01, 2001 at 10:30:44PM -0400 References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> <17744.986162083@kanga.nu> <15047.58452.802942.133727@anthem.wooz.org> Message-ID: <20010402001555.10352@scfn.thpl.lib.fl.us> On Sun, Apr 01, 2001 at 10:30:44PM -0400, Barry A. Warsaw wrote: > My interpretation of this section is that since regular deliveries use > the From: field supplied by the original author, but it is Mailman's > responsibility for sending the mail through the system, the Sender: > field ought to be the human responsible for list maintenance, > e.g. list-owner or list-admin. It has proved to be more practical to > point Sender: at list-admin so that bounce processing can take first > crack at the message, sending it on to the list moderators if that > fails. I concur entirely, both with your interpretation, and your implementation. For whatever *that's* worth. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Mon Apr 2 06:38:11 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 01:38:11 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? References: <3AC4D141.D3ED6A84@nleaudio.com> Message-ID: <15048.4163.987252.660652@anthem.wooz.org> I've just finished implementing a more general confirmation scheme for Mailman 2.1. There are two aspects to this. When an operation requiring confirmation is performed, a confirmation email message is sent as before. However, the confirmation message will include both a confirming email command and a URL with a unique cookie, and the operation can be performed either by replying to the message or visiting the specified URL. Currently only two confirmable operations are defined: subscribing and removing. The above works regardless of e.g. whether the removal request is coming from cgi or from an email command. This means a user can send the message "unsubscribe" to mylist-request with no address and no password, and they will receive a confirmation message. A reply to that message, or a hit on the URL will remove the user. (Note that if the user actually knows their password, they can include it in the web page or email command for immediate removal.) (Note also that the architecture is general enough that other confirmable operations could be added in the future.) While this isn't exactly password-less accounts, I think it accomplishes basically the same intent. And it strikes a good balance between convenience and security. It means in practice that a user can get removed from a list without having to remember their password (or how to get it!), and the two-step removal in that case isn't too onerous (since most MUAs I suspect would let them click directly on the URL in the mail message). Acks go to Les Niles who implemented a rough cut at this. My implementation was different, but similar in spirit. -Barry From jra@baylink.com Mon Apr 2 06:46:27 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 2 Apr 2001 01:46:27 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? In-Reply-To: <15048.4163.987252.660652@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Apr 02, 2001 at 01:38:11AM -0400 References: <3AC4D141.D3ED6A84@nleaudio.com> <15048.4163.987252.660652@anthem.wooz.org> Message-ID: <20010402014627.21738@scfn.thpl.lib.fl.us> On Mon, Apr 02, 2001 at 01:38:11AM -0400, Barry A. Warsaw wrote: > While this isn't exactly password-less accounts, I think it > accomplishes basically the same intent. And it strikes a good balance > between convenience and security. It means in practice that a user > can get removed from a list without having to remember their password > (or how to get it!), and the two-step removal in that case isn't too > onerous (since most MUAs I suspect would let them click directly on > the URL in the mail message). Two edged sword. I'm trying to remember whose message it is, Slashdot's, I think, that says "don't get your panties in a twist because we included your password in clear". This completely fails to take into account the "I use the same password many places" people. Getting the passwords out of the mail is a good thing... but mail is *still* sniffable. Depends how much security you want people to have... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Mon Apr 2 07:14:30 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 02:14:30 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? References: <3AC4D141.D3ED6A84@nleaudio.com> <15048.4163.987252.660652@anthem.wooz.org> <20010402014627.21738@scfn.thpl.lib.fl.us> Message-ID: <15048.6342.401162.637705@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Two edged sword. JRA> I'm trying to remember whose message it is, Slashdot's, I JRA> think, that says "don't get your panties in a twist because JRA> we included your password in clear". JRA> This completely fails to take into account the "I use the JRA> same password many places" people. JRA> Getting the passwords out of the mail is a good thing... but JRA> mail is *still* sniffable. Depends how much security you JRA> want people to have... The last step (to be added /eventually/) is to allow users to suppress password containing emails unless they specifically hit "Email My Password To Me". This means 1) allowing them to inhibit monthly reminders on a per-user basis; 2) allowing them to suppress the password in the welcome message; 3) adding confirmation emails for things like changing their options. Shouldn't be hard to do, just takes time. Still, we /tell/ users not to use important passwords for their Mailman accounts, but I understand the Pinball Machine Rule[1] applies here. -Barry [1] The PMR is the observation that it doesn't matter a wit if the instructions are printed clearly for all to see, nobody will read them. They'll just drop their quarter(s) and start pushing buttons like a Tommy. From jra@baylink.com Mon Apr 2 15:30:14 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 2 Apr 2001 10:30:14 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Any way users can unsubscribe without a password? In-Reply-To: <15048.6342.401162.637705@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Apr 02, 2001 at 02:14:30AM -0400 References: <3AC4D141.D3ED6A84@nleaudio.com> <15048.4163.987252.660652@anthem.wooz.org> <20010402014627.21738@scfn.thpl.lib.fl.us> <15048.6342.401162.637705@anthem.wooz.org> Message-ID: <20010402103014.04269@scfn.thpl.lib.fl.us> [Filtered back to -devel] On Mon, Apr 02, 2001 at 02:14:30AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > > JRA> Two edged sword. > > JRA> I'm trying to remember whose message it is, Slashdot's, I > JRA> think, that says "don't get your panties in a twist because > JRA> we included your password in clear". > > JRA> This completely fails to take into account the "I use the > JRA> same password many places" people. > > JRA> Getting the passwords out of the mail is a good thing... but > JRA> mail is *still* sniffable. Depends how much security you > JRA> want people to have... > > The last step (to be added /eventually/) is to allow users to suppress > password containing emails unless they specifically hit "Email My > Password To Me". This means 1) allowing them to inhibit monthly > reminders on a per-user basis; 2) allowing them to suppress the > password in the welcome message; 3) adding confirmation emails for > things like changing their options. > > Shouldn't be hard to do, just takes time. My favorite approach was always "ask the user for a challenge question that describes their password *to them*, in addition to the password, and then send them *that* if they can't remember it". > Still, we /tell/ users not to use important passwords for their > Mailman accounts, but I understand the Pinball Machine Rule[1] applies > here. > > [1] The PMR is the observation that it doesn't matter a wit if the > instructions are printed clearly for all to see, nobody will read > them. They'll just drop their quarter(s) and start pushing buttons > like a Tommy. Classic. Whence cometh that one? If there's enough reference for it in the Real World, I'll be Submitting It To Eric. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jj-list@mail.dk Mon Apr 2 21:31:20 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Mon, 02 Apr 2001 22:31:20 +0200 Subject: [Mailman-Developers] Sender field In-Reply-To: <15047.58452.802942.133727@anthem.wooz.org> References: <5.0.2.1.0.20010401225403.038f8dc8@wheresmymailserver.com> <17744.986162083@kanga.nu> Message-ID: <5.0.2.1.0.20010402213457.0378a008@pop3.mail.dk> Barry A. Warsaw wrote: >My interpretation of this section is that since regular deliveries use >the From: field supplied by the original author, but it is Mailman's >responsibility for sending the mail through the system, the Sender: >field ought to be the human responsible for list maintenance, >e.g. list-owner or list-admin. It has proved to be more practical to >point Sender: at list-admin so that bounce processing can take first >crack at the message, sending it on to the list moderators if that >fails. Thanks, very helpful. Jesper. From marc_news@valinux.com Tue Apr 3 00:10:42 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 2 Apr 2001 16:10:42 -0700 Subject: [Mailman-Developers] patch to remove_member for mass unsubscribes Message-ID: <20010402161042.J29491@magic.merlins.org> I submitted: https://sourceforge.net/tracker/index.php?func=detail&aid=413257&group_id=103&atid=300103 Basically it adds a special list name: _alllists_ which does this: usw-sf-list1:/var/local/mailman/bin# time ./remove_members -f /tmp/badmails _alllists_ User `gb@viscomvisual.com' removed from list `berlin-fresco' User `jprice@chiinc.com' removed from list `foxgui-announce' User `bmcgroarty@high-voltage.com' removed from list `freenet-announce' User `Wilhelm.Pastoors@vetmed.uni-giessen.de' removed from list `gump-develop' User `oscu@sina.com' removed from list `linux-usb-devel' User `mehdi-laurent.akkar@fr.delarue.com' removed from list `madchat-annonces' User `ras@colltech.com' removed from list `sendpage-devel' User `mkimball@pdi.com' removed from list `utah-glx-cvs' User `mkimball@pdi.com' removed from list `utah-glx-dev' User `mkimball@pdi.com' removed from list `utah-glx-users' User `brianp@pdi.com' removed from list `vacm-develop' User `guido@comlog.nl' removed from list `wxwindows-users' User `frekytah@jono.com' removed from list `solar-empire-developer' User `dan@dar.net' removed from list `xemacs-winnt' real 7m26.294s user 1m9.120s sys 1m10.640s It ran in 7mn on 10,000+ lists, which ain't that bad considering. Hopefully it will make it in the next mailman. Enjoy, 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 barry@digicool.com Tue Apr 3 03:30:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 22:30:35 -0400 Subject: [Mailman-Developers] Headers and footers for MIME messages References: <15042.46824.976889.309145@anthem.wooz.org> <20010330022005.4687128593@wawura.off.connect.com.au> Message-ID: <15049.13771.337011.738446@anthem.wooz.org> >>>>> "AM" == Andrew McNamara writes: AM> You'll soon end up with a complex language for specifying AM> things like "accept binary attachments only if preceeded by a AM> text/plain", etc.. 8-) Ug. It's probably inevitable, but I really don't want Mailman to become a hypergeneralized MIME slicer-n-dicer. AM> BTW, I think there's a special mime type for headers and AM> footers - text/plain isn't the right one. Can't remember off AM> the top of my head. I'm not aware of it, so I'd appreciate pointers. Maybe you're thinking of multipart/digest or message/* types? Neither is exactly appropriate in this context. AM> The safest rules would be: AM> - if it's not a mime message, do the old thing. Agreed. AM> - if it's AM> mime, and it's not already a multipart/mixed, create a AM> text/multipart with header/original mime/footer. I think you mean "create a multipart/mixed with 3 subparts, the header, the original article, and the footer". AM> - it it's AM> mime, and and multipart/mixed, simply insert and append the AM> header and footer parts. Agreed. My main objective is above all "to do no harm", so for now, I'm going to adopt these rules: - if it's not MIME or it's text/plain, do the old thing - if it's multipart/mixed, add the header and footers as additional subparts - anything else, pass the message through unchanged We can elaborate on that last one later if necessary. -Barry From Dan Mick Tue Apr 3 03:45:07 2001 From: Dan Mick (Dan Mick) Date: Mon, 2 Apr 2001 19:45:07 -0700 (PDT) Subject: [Mailman-Developers] Mailman 2.1.x Message-ID: <200104030242.TAA10724@utopia.West.Sun.COM> Any opinions on its stability? I'm setting up a new server, and am contemplating starting off with 2.1. Is it ready for prime-ish time (I can investigate and resolve some problems) yet? I'm also considering taking the Postfix plunge at the same time. I probably need mental help. :) From andrewm@connect.com.au Tue Apr 3 04:04:57 2001 From: andrewm@connect.com.au (Andrew McNamara) Date: Tue, 03 Apr 2001 13:04:57 +1000 Subject: [Mailman-Developers] Headers and footers for MIME messages In-Reply-To: Your message of "Mon, 02 Apr 2001 22:30:35 -0400." <15049.13771.337011.738446@anthem.wooz.org> Message-ID: <20010403030457.CF182285B9@wawura.off.connect.com.au> >Ug. It's probably inevitable, but I really don't want Mailman to >become a hypergeneralized MIME slicer-n-dicer. Yes - I think it's sort of inevitable. If you structure your MIME parser correctly, it may be relatively painless. BTW, you should look at the perl MIME module (as used by Majordomo 2) - I understand that it's one of the best MIME interfaces around (although reading other people's perl is futile, it's interface doco might suggest some ideas for your code). > AM> BTW, I think there's a special mime type for headers and > AM> footers - text/plain isn't the right one. Can't remember off > AM> the top of my head. > >I'm not aware of it, so I'd appreciate pointers. Maybe you're >thinking of multipart/digest or message/* types? Neither is exactly >appropriate in this context. I had a quick look when I posted, but couldn't find it. I think I was probably thinking of the multipart/digest and message/* stuff, as you suggest. > AM> - if it's > AM> mime, and it's not already a multipart/mixed, create a > AM> text/multipart with header/original mime/footer. > >I think you mean "create a multipart/mixed with 3 subparts, the >header, the original article, and the footer". Yes - wrap the original mime message in a new multipart/mixed with 3 subparts. Mime is intended to be a hierarchy, so this is safe. It will also be a good test for your Python MIME code - if it's going to cope with the random crap that people mail around, it shouldn't have much trouble producing this. Personally, I find MIME problematic - the basic idea was okay, but when people start nesting objects several levels deep the utility starts to disappear. Also, it assumes that SMTP is a file transport protocol, which it isn't (if it was, it would support restarting failed transfers). I also turn it off in my MUA (exmh) as it slows it down considerably. >My main objective is above all "to do no harm", so for now, I'm going >to adopt these rules: Yes. > - if it's not MIME or it's text/plain, do the old thing > > - if it's multipart/mixed, add the header and footers as > additional subparts > > - anything else, pass the message through unchanged > >We can elaborate on that last one later if necessary. Yes. --- Andrew McNamara (System Architect) connect.com.au Pty Ltd Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia Phone: +61 2 9409 2117, Fax: +61 2 9409 2111 From barry@digicool.com Tue Apr 3 04:02:11 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 23:02:11 -0400 Subject: [Mailman-Developers] Mailman 2.1.x References: <200104030242.TAA10724@utopia.West.Sun.COM> Message-ID: <15049.15667.746981.261424@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Any opinions on its stability? I'm setting up a new server, DM> and am contemplating starting off with 2.1. Is it ready for DM> prime-ish time (I can investigate and resolve some problems) DM> yet? I'm relatively comfortable with its stability in terms of getting mail through the system, although I am not using it for anything except internal testing right now. I haven't even foisted it on my fellow Pythonlabbers yet. And don't worry, you guys will be my first real litter of guinea pigs. :) I'm less comfortable with all the file formats, schemas and APIs I've chosen. E.g. the new pending.db format has already changed and, as befits alpha software, I reserve the right to change formats in incompatible and non-upgradable ways. I will of course, guarantee that you can upgrade from 2.0.3 to 2.1, but not in between any of the alphas. Part of the responsibility of going to beta is to freeze those kinds of things (barring catastrophic showstopping bugs that can't be fixed any other way). If you're comfortable with that, I'd be thrilled with you giving 2.1 a spin for real. DM> I'm also considering taking the Postfix plunge at the same DM> time. I probably need mental help. :) doctor-it-hurts-when-i-do-this-ly y'rs, -Barry From barry@digicool.com Tue Apr 3 04:09:04 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 2 Apr 2001 23:09:04 -0400 Subject: [Mailman-Developers] Headers and footers for MIME messages References: <15049.13771.337011.738446@anthem.wooz.org> <20010403030457.CF182285B9@wawura.off.connect.com.au> Message-ID: <15049.16080.297011.684831@anthem.wooz.org> >>>>> "AM" == Andrew McNamara writes: >> Ug. It's probably inevitable, but I really don't want Mailman >> to become a hypergeneralized MIME slicer-n-dicer. AM> Yes - I think it's sort of inevitable. If you structure your AM> MIME parser correctly, it may be relatively painless. I think mimelib is pretty good, certainly better than anything else I've seen for Python. I've got some nits about its interface, which I'll need to clean up for any 1.0 release (or for inclusion in Python, and I know Guido has some nits). AM> BTW, you should look at the perl MIME module (as used by AM> Majordomo 2) - I understand that it's one of the best MIME AM> interfaces around (although reading other people's perl is AM> futile, it's interface doco might suggest some ideas for your AM> code). Do you have a reference? I gave up Perl almost 7 years ago, so I know I couldn't read it, but if the interface spec is online, I'd love to take a look. AM> It will also be a good test for your Python MIME code - if AM> it's going to cope with the random crap that people mail AM> around, it shouldn't have much trouble producing this. It's actually fairly easy with mimelib. AM> Personally, I find MIME problematic - the basic idea was okay, AM> but when people start nesting objects several levels deep the AM> utility starts to disappear. Also, it assumes that SMTP is a AM> file transport protocol, which it isn't (if it was, it would AM> support restarting failed transfers). I also turn it off in my AM> MUA (exmh) as it slows it down considerably. I agree. Also, I've find that generating MIME correctly really requires holding the entire message hierarchy in memory and making several passes over the generated text before you can really start outputing correctly. That sucks too. Thanks for the feedback. -Barry From andrewm@connect.com.au Tue Apr 3 04:38:58 2001 From: andrewm@connect.com.au (Andrew McNamara) Date: Tue, 03 Apr 2001 13:38:58 +1000 Subject: [Mailman-Developers] Headers and footers for MIME messages In-Reply-To: Your message of "Mon, 02 Apr 2001 23:09:04 -0400." <15049.16080.297011.684831@anthem.wooz.org> Message-ID: <20010403033858.51D30285BC@wawura.off.connect.com.au> >I think mimelib is pretty good, certainly better than anything else >I've seen for Python. I've got some nits about its interface, which >I'll need to clean up for any 1.0 release (or for inclusion in Python, >and I know Guido has some nits). I had a quick look a few weeks back - my impression was that it didn't entirely embrace the OO'edness, although it can be a big mistake to go too far with objects anyway, and I can't provide any sensible comments on what you could do to make it more abstract (armchair critic). If it works, that's the most important goal. 8-) >Do you have a reference? I gave up Perl almost 7 years ago, so I >know I couldn't read it, but if the interface spec is online, I'd love >to take a look. It's the MIME::Tools module on cpan, I think this is the author's site (and it includes online class doco): http://www.zeegee.com/code/perl/MIME-tools/ They also have a MIME::Lite. >I agree. Also, I've find that generating MIME correctly really >requires holding the entire message hierarchy in memory and making >several passes over the generated text before you can really start >outputing correctly. That sucks too. This is definitely the biggest shortcoming with MIME - for things like MTA's, there's a certain amount of presure to include MIME support (encoding 8-bit messages when they encounter a 7 bit path, DSN, etc), but the performance implications just suck too hard. --- Andrew McNamara (System Architect) connect.com.au Pty Ltd Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia Phone: +61 2 9409 2117, Fax: +61 2 9409 2111 From jra@baylink.com Tue Apr 3 06:05:06 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 3 Apr 2001 01:05:06 -0400 Subject: [Mailman-Developers] Headers and footers for MIME messages In-Reply-To: <20010403030457.CF182285B9@wawura.off.connect.com.au>; from Andrew McNamara on Tue, Apr 03, 2001 at 01:04:57PM +1000 References: <15049.13771.337011.738446@anthem.wooz.org> <20010403030457.CF182285B9@wawura.off.connect.com.au> Message-ID: <20010403010506.01340@scfn.thpl.lib.fl.us> On Tue, Apr 03, 2001 at 01:04:57PM +1000, Andrew McNamara wrote: > BTW, you should look at the perl MIME module (as used by Majordomo 2) - > I understand that it's one of the best MIME interfaces around (although > reading other people's perl is futile, it's interface doco might > suggest some ideas for your code). But, Andrew... didn't you read the press release? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From ralph@inputplus.demon.co.uk Tue Apr 3 11:09:44 2001 From: ralph@inputplus.demon.co.uk (Ralph Corderoy) Date: Tue, 03 Apr 2001 11:09:44 +0100 Subject: [Mailman-Developers] patch to remove_member for mass unsubscribes In-Reply-To: Message from Marc MERLIN of "Mon, 02 Apr 2001 16:10:42 PDT." <20010402161042.J29491@magic.merlins.org> Message-ID: <200104031009.LAA05329@inputplus.demon.co.uk> Hi, > Basically it adds a special list name: _alllists_ which does this: > > # time ./remove_members -f /tmp/badmails _alllists_ Perhaps an -option would be better than special-casing a list name. Ralph. From marc_news@valinux.com Tue Apr 3 22:46:08 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 3 Apr 2001 14:46:08 -0700 Subject: [Mailman-Developers] patch to remove_member for mass unsubscribes In-Reply-To: <200104031009.LAA05329@inputplus.demon.co.uk>; from ralph@inputplus.demon.co.uk on Tue, Apr 03, 2001 at 11:09:44AM +0100 References: <200104031009.LAA05329@inputplus.demon.co.uk> Message-ID: <20010403144608.X29491@magic.merlins.org> On Tue, Apr 03, 2001 at 11:09:44AM +0100, Ralph Corderoy wrote: > > Hi, > > > Basically it adds a special list name: _alllists_ which does this: > > > > # time ./remove_members -f /tmp/badmails _alllists_ > > Perhaps an -option would be better than special-casing a list name. I thought about it, but it breaks the option parsing a bit since remove_members kind of expects a list name. Not that it can't be fixed, mind you, but having a list name required depending on whether a flag was there or not seemed a bit ackward. That said, it's trivial to change, and as long as the functionality makes it into the main distribution, how the arguments are parsed doesn't really matter to me, Barry or however considers merging this in is welcome to change the parsing logic and I don't think they need a patch from me to do this :-) 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 bedmonds@antarcti.ca Wed Apr 4 18:09:23 2001 From: bedmonds@antarcti.ca (Brian Edmonds) Date: Wed, 4 Apr 2001 10:09:23 -0700 (PDT) Subject: [Mailman-Developers] Re: patch to remove_member for mass unsubscribes References: <200104031009.LAA05329@inputplus.demon.co.uk> <20010403144608.X29491@magic.merlins.org> Message-ID: Marc MERLIN writes: >> Perhaps an -option would be better than special-casing a list name. > I thought about it, but it breaks the option parsing a bit since > remove_members kind of expects a list name. How about an argument that tells the program to interpret the list name as a regular expression to be matched against all lists. That way you could remove from all lists with a listname of ., and from subsets of lists with other arguments. Brian. From ps@psncc.at Wed Apr 4 22:11:54 2001 From: ps@psncc.at (ps@psncc.at) Date: Wed, 4 Apr 2001 23:11:54 +0200 (CEST) Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers Message-ID: Hi everybody, I just produced the patch included below. It allows to configure not to add the List-* header lines to outgoing non-digest messages. I needed this to hide the HTTP URLs for the webinterface, as Mailman is used "just" as the mailing list backend and the webinterface is to be used by the administrators only. A similar thing should probably be done for the digest case. The patch should apply cleanly to 2.0.2 and 2.0.3. Note that the patch adds a new attribute to the MailList object. This usually breaks existing mailing lists. You can fix the situation by creating a file with just the line mlist.addlistinfo = 1 and using /bin/config_list -i (at least this worked for me) NOTE 1: Use this patch at your own risk. NOTE 2: This is my first Mailman patch (and the first time I ever touched python) so I may have overlooked some details. Does anybody like this feature? peter diff -ur mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py --- mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py Thu Nov 16 05:35:09 2000 +++ mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py Wed Apr 4 22:19:24 2001 @@ -124,14 +124,15 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded. The adding of 2 is for the colon-space # separator. - if len(h) + 2 + len(v) > 78: - v = string.join(string.split(v, ', '), ',\n\t') - msg[h] = v + if mlist.addlistinfo: + if len(h) + 2 + len(v) > 78: + v = string.join(string.split(v, ', '), ',\n\t') + msg[h] = v # # Always delete List-Archive header, but only add it back if the list is # actually archiving del msg['List-Archive'] - if mlist.archive: + if mlist.archive and mlist.addlistinfo: value = '<%s>' % urlparse.urljoin(mlist.web_page_url, mlist.GetBaseArchiveURL()) msg['List-Archive'] = value diff -ur mailman-2.0.2-org/Mailman/MailList.py mailman-2.0.2-patched/Mailman/MailList.py --- mailman-2.0.2-org/Mailman/MailList.py Thu Nov 16 05:33:27 2000 +++ mailman-2.0.2-patched/Mailman/MailList.py Wed Apr 4 21:53:54 2001 @@ -345,6 +345,8 @@ self.msg_header = mm_cfg.DEFAULT_MSG_HEADER self.msg_footer = mm_cfg.DEFAULT_MSG_FOOTER + self.addlistinfo = 1 + def GetConfigInfo(self): config_info = {} config_info['digest'] = Digester.GetConfigInfo(self) @@ -770,6 +772,9 @@ "Text appended to the bottom of every immediately-delivery" " message. " + Utils.maketext('headfoot.html', raw=1)), + + ('addlistinfo', mm_cfg.Toggle, ('No', 'Yes'), 1, + 'Add mailing list information headers to outgoing messages?'), ] config_info['bounce'] = Bouncer.GetConfigInfo(self) From jra@baylink.com Thu Apr 5 00:17:12 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 4 Apr 2001 19:17:12 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: ; from ps@psncc.at on Wed, Apr 04, 2001 at 11:11:54PM +0200 References: Message-ID: <20010404191712.44418@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 11:11:54PM +0200, ps@psncc.at wrote: > Note that the patch adds a new attribute to the MailList object. This > usually breaks existing mailing lists. That comment troubles me. Isn't the point of object oriented design pretty precisely to avoid the need for such comments? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 00:32:58 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 4 Apr 2001 19:32:58 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> Message-ID: <15051.44842.800982.769610@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> That comment troubles me. Isn't the point of object oriented JRA> design pretty precisely to avoid the need for such comments? The issue here is that in essence the patch is changing the schema for the list configuration database. In that case you have two choices: - You can run an external tool off-line that walks over all the databases and updates their schemas. This is essentially what Peter is suggesting you do with config_list. - You can update the schema "on the fly" as you load each new database. This is the approach favored, and used, by Mailman. For the right way to update the schema, e.g. when you add a new attribute to the MailList object, see Mailman/versions.py. It's a horrible hack of code, but it does the job. You'll also need to update DATA_FILE_VERSION in Version.py. conspicuously-not-commenting-on-the-patch-itself-ly y'rs, -Barry From jra@baylink.com Thu Apr 5 01:09:58 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 4 Apr 2001 20:09:58 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15051.44842.800982.769610@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Apr 04, 2001 at 07:32:58PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> Message-ID: <20010404200958.49012@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 07:32:58PM -0400, Barry A. Warsaw wrote: > JRA> That comment troubles me. Isn't the point of object oriented > JRA> design pretty precisely to avoid the need for such comments? > > The issue here is that in essence the patch is changing the schema for > the list configuration database. In that case you have two choices: > > - You can run an external tool off-line that walks over all the > databases and updates their schemas. This is essentially what > Peter is suggesting you do with config_list. > > - You can update the schema "on the fly" as you load each new > database. This is the approach favored, and used, by Mailman. You're saying that a list object *wraps* a database, then. If so, yeah, the object sure as hell *ought* to deal with that issue itself. Careful how you use the word "databases"... I *think* you actually *mean* "records" (or rows), but I'm not sure. Cheer, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 01:19:35 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 4 Apr 2001 20:19:35 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> Message-ID: <15051.47639.556741.554268@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> You're saying that a list object *wraps* a database, then. JRA> If so, yeah, the object sure as hell *ought* to deal with JRA> that issue itself. JRA> Careful how you use the word "databases"... I *think* you JRA> actually *mean* "records" (or rows), but I'm not sure. Not quite. Okay, I'm being a little bit abstract, but bear with me. Eventually list objects will be backed by a Real Database (and some folks have already prototyped this). Concretely, Mailman currently stores a MailList instance's attributes in a file whose format is a Python marshal of a Python dictionary. This is the config.db file and is essentially what I'm talking about when I say "schema" since it serves the same purpose, although it's not explicitly described, e.g. as it would be in a traditional relational database. Nonetheless, if you change the MailList object's attributes (add or delete) you need to update this implicit schema in the ways I've described. Cheers, -Barry From jra@baylink.com Thu Apr 5 01:26:49 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 4 Apr 2001 20:26:49 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15051.47639.556741.554268@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Apr 04, 2001 at 08:19:35PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> Message-ID: <20010404202649.01789@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 08:19:35PM -0400, Barry A. Warsaw wrote: > JRA> You're saying that a list object *wraps* a database, then. > JRA> If so, yeah, the object sure as hell *ought* to deal with > JRA> that issue itself. > > JRA> Careful how you use the word "databases"... I *think* you > JRA> actually *mean* "records" (or rows), but I'm not sure. > > Not quite. > > Okay, I'm being a little bit abstract, but bear with me. Eventually > list objects will be backed by a Real Database (and some folks > have already prototyped this). Ok... > Concretely, Mailman currently stores a MailList instance's attributes > in a file whose format is a Python marshal of a Python dictionary. > This is the config.db file and is essentially what I'm talking about > when I say "schema" since it serves the same purpose, although it's > not explicitly described, e.g. as it would be in a traditional > relational database. Nonetheless, if you change the MailList object's > attributes (add or delete) you need to update this implicit schema in > the ways I've described. Ah. The problem comes from the fact that the exported marshals won't have the new data. Perhaps python needs to evaluate something else for it's marshalling file format? XML? Hmmmm?? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Thu Apr 5 02:28:29 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 04 Apr 2001 18:28:29 -0700 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 04 Apr 2001 19:17:12 EDT." <20010404191712.44418@scfn.thpl.lib.fl.us> References: <20010404191712.44418@scfn.thpl.lib.fl.us> Message-ID: <5430.986434109@kanga.nu> On Wed, 4 Apr 2001 19:17:12 -0400 Jay R Ashworth wrote: > On Wed, Apr 04, 2001 at 11:11:54PM +0200, ps@psncc.at wrote: >> Note that the patch adds a new attribute to the MailList >> object. This usually breaks existing mailing lists. > That comment troubles me. Isn't the point of object oriented > design pretty precisely to avoid the need for such comments? Yes, except that in this case the relevant objects are streamed to disk and we're talking about changing the object definition (which would therefore change the image streamed to disk). -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From barry@digicool.com Thu Apr 5 03:17:07 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 4 Apr 2001 22:17:07 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> Message-ID: <15051.54691.444924.4799@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Ah. The problem comes from the fact that the exported JRA> marshals won't have the new data. Perhaps python needs to JRA> evaluate something else for it's marshalling file format? JRA> XML? Hmmmm?? I'm not sure how that would help -- you still have to update the file to have the new data. Sure, you could do it in a text editor, but no one will! :) Marshals, BTW, exist primarily to support caching of compiled byte code. A .pyc file is a marshal with a little bit of header information. They also happen to be an efficient way to store and load simple Python objects. Pickles are better for more complex objects (e.g. instances, or cyclic data structures). I've no doubt that somewhere, someone's got an XML DTD that supports serialization of Python objects. Probably xmlrpc or something in Zope, I don't know for sure. Of course, Python existed long before XML meant anything other than "eXtremely Mean Lemmings". -Barry From ps@psncc.at Thu Apr 5 06:50:25 2001 From: ps@psncc.at (ps@psncc.at) Date: Thu, 5 Apr 2001 07:50:25 +0200 (CEST) Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 Message-ID: Hi everybody, Having read the replies for my previous patch so far, I have produced version 2 of it. I would also like to note that the functionality applies to both regular and digest messages anyway, so one of the comments from my last posts should be treated as nonsense. Due to this, I have now moved the configurabale option to the "general" options page, and I have properly (?) changed the versions.py file to upgrade mailing lists for the new attribute on-the-fly (I didn't know of the functionality, although I thought it would be hidden somewhere - Barrys mail has pointed me in the right direction). However, this required to increase the DATA_FILE_VERSION in Mailman/Version.py as well (something I was not THAT comfortable with). It also includes a configurable default value for the new attribute as well. I would really like to hear comments on the proposed functionality as well as on the patch's quality (which [indirectly, though] seems to have been the focus of most, if not all, of the replies to my last posting). peter Here is the patch: diff -ur mailman-2.0.2-org/Mailman/Defaults.py.in mailman-2.0.2-patched/Mailman/Defaults.py.in --- mailman-2.0.2-org/Mailman/Defaults.py.in Thu Nov 16 05:23:52 2000 +++ mailman-2.0.2-patched/Mailman/Defaults.py.in Thu Apr 5 07:02:20 2001 @@ -366,6 +366,11 @@ 'subject', 'to', 'cc', 'reply-to', 'organization'] +##### +# Add list header, ie. List-Help, etc. to outgoing non-digest +# messages +##### +DEFAULT_ADDLISTINFO = 1 ##### diff -ur mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py --- mailman-2.0.2-org/Mailman/Handlers/CookHeaders.py Thu Nov 16 05:35:09 2000 +++ mailman-2.0.2-patched/Mailman/Handlers/CookHeaders.py Wed Apr 4 23:13:39 2001 @@ -124,14 +124,15 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded. The adding of 2 is for the colon-space # separator. - if len(h) + 2 + len(v) > 78: - v = string.join(string.split(v, ', '), ',\n\t') - msg[h] = v + if mlist.addlistinfo: + if len(h) + 2 + len(v) > 78: + v = string.join(string.split(v, ', '), ',\n\t') + msg[h] = v # # Always delete List-Archive header, but only add it back if the list is # actually archiving del msg['List-Archive'] - if mlist.archive: + if mlist.archive and mlist.addlistinfo: value = '<%s>' % urlparse.urljoin(mlist.web_page_url, mlist.GetBaseArchiveURL()) msg['List-Archive'] = value diff -ur mailman-2.0.2-org/Mailman/MailList.py mailman-2.0.2-patched/Mailman/MailList.py --- mailman-2.0.2-org/Mailman/MailList.py Thu Nov 16 05:33:27 2000 +++ mailman-2.0.2-patched/Mailman/MailList.py Thu Apr 5 07:31:07 2001 @@ -345,6 +345,8 @@ self.msg_header = mm_cfg.DEFAULT_MSG_HEADER self.msg_footer = mm_cfg.DEFAULT_MSG_FOOTER + self.addlistinfo = mm_cfg.DEFAULT_ADDLISTINFO + def GetConfigInfo(self): config_info = {} config_info['digest'] = Digester.GetConfigInfo(self) @@ -544,6 +546,10 @@ ('max_message_size', mm_cfg.Number, 7, 0, 'Maximum length in Kb of a message body. Use 0 for no limit.'), + + ('addlistinfo', mm_cfg.Toggle, ('No', 'Yes'), 1, + 'Add mailing list information headers to outgoing messages ' + '(regular AND digests)?'), ('host_name', mm_cfg.Host, WIDTH, 0, 'Host name this list prefers.', diff -ur mailman-2.0.2-org/Mailman/Version.py mailman-2.0.2-patched/Mailman/Version.py --- mailman-2.0.2-org/Mailman/Version.py Sat Mar 3 07:19:15 2001 +++ mailman-2.0.2-patched/Mailman/Version.py Thu Apr 5 07:39:08 2001 @@ -36,7 +36,7 @@ (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.db schema version number -DATA_FILE_VERSION = 21 +DATA_FILE_VERSION = 22 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 2 diff -ur mailman-2.0.2-org/Mailman/versions.py mailman-2.0.2-patched/Mailman/versions.py --- mailman-2.0.2-org/Mailman/versions.py Wed Jun 14 07:09:58 2000 +++ mailman-2.0.2-patched/Mailman/versions.py Thu Apr 5 06:59:08 2001 @@ -189,6 +189,7 @@ add_only_if_missing('postings_responses', {}, l) add_only_if_missing('admin_responses', {}, l) add_only_if_missing('reply_goes_to_list', '', l) + add_only_if_missing('addlistinfo', mm_cfg.DEFAULT_ADDLISTINFO, l) From jra@baylink.com Thu Apr 5 07:01:10 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 02:01:10 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15051.54691.444924.4799@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Apr 04, 2001 at 10:17:07PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> Message-ID: <20010405020110.57681@scfn.thpl.lib.fl.us> On Wed, Apr 04, 2001 at 10:17:07PM -0400, Barry A. Warsaw wrote: > JRA> Ah. The problem comes from the fact that the exported > JRA> marshals won't have the new data. Perhaps python needs to > JRA> evaluate something else for it's marshalling file format? > > JRA> XML? Hmmmm?? > > I'm not sure how that would help -- you still have to update the file > to have the new data. Sure, you could do it in a text editor, but no > one will! :) Because then, at least old unchanged objects which were read in by the 'code inside the object' wouldn't break: they'd just have to pick up the default for that attribute. When you wrote them *back out*, they'd automagically be fixed. > Marshals, BTW, exist primarily to support caching of compiled byte > code. A .pyc file is a marshal with a little bit of header > information. They also happen to be an efficient way to store and > load simple Python objects. Pickles are better for more complex > objects (e.g. instances, or cyclic data structures). Are pickles less prone to break the "objectization" of objects you're going to want persistent storage of? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 14:55:54 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 5 Apr 2001 09:55:54 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> Message-ID: <15052.31082.918502.278802@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Because then, at least old unchanged objects which were read JRA> in by the 'code inside the object' wouldn't break: they'd JRA> just have to pick up the default for that attribute. When JRA> you wrote them *back out*, they'd automagically be fixed. This happens now, since once that attribute's on the MailList object, it'll get written back out to the .db file. >> Marshals, BTW, exist primarily to support caching of compiled >> byte code. A .pyc file is a marshal with a little bit of >> header information. They also happen to be an efficient way to >> store and load simple Python objects. Pickles are better for >> more complex objects (e.g. instances, or cyclic data >> structures). JRA> Are pickles less prone to break the "objectization" of JRA> objects you're going to want persistent storage of? I'm not sure I understand the question. Marshal only handles built-in types (ints, longs, dicts, lists, tuples) and wasn't designed to handle instances. That's what pickle is for (and see the cPickle module for a really fast implementation of the pickle protocol). -Barry From jra@baylink.com Thu Apr 5 17:39:45 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 12:39:45 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15052.31082.918502.278802@anthem.wooz.org>; from "Barry A. Warsaw" on Thu, Apr 05, 2001 at 09:55:54AM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> <15052.31082.918502.278802@anthem.wooz.org> Message-ID: <20010405123945.60935@scfn.thpl.lib.fl.us> On Thu, Apr 05, 2001 at 09:55:54AM -0400, Barry A. Warsaw wrote: > JRA> Because then, at least old unchanged objects which were read > JRA> in by the 'code inside the object' wouldn't break: they'd > JRA> just have to pick up the default for that attribute. When > JRA> you wrote them *back out*, they'd automagically be fixed. > > This happens now, since once that attribute's on the MailList object, > it'll get written back out to the .db file. Oh. It sounded to *me* like the read-in would fail. Misunderstood. Then what's the problem? > JRA> Are pickles less prone to break the "objectization" of > JRA> objects you're going to want persistent storage of? > > I'm not sure I understand the question. Marshal only handles built-in > types (ints, longs, dicts, lists, tuples) and wasn't designed to > handle instances. That's what pickle is for (and see the cPickle > module for a really fast implementation of the pickle protocol). Um, "nevermind". Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 18:23:16 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 5 Apr 2001 13:23:16 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> <15052.31082.918502.278802@anthem.wooz.org> <20010405123945.60935@scfn.thpl.lib.fl.us> Message-ID: <15052.43524.31062.306270@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Oh. It sounded to *me* like the read-in would fail. JRA> Misunderstood. JRA> Then what's the problem? The read succeeds but the resulting MailList instance won't have the new attribute. When the module tries to access that attribute, you'll get an AttributeError. This /could/ be worked around by using something like: if getattr(mlist, 'my_new_attribute', 0): instead of if mlist.my_new_attribute: The getattr() approach doesn't raise an exception when given a default value. -Barry From jra@baylink.com Thu Apr 5 18:23:24 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 13:23:24 -0400 Subject: [Mailman-Developers] Patch: Optionally Suppressing List Headers In-Reply-To: <15052.43524.31062.306270@anthem.wooz.org>; from "Barry A. Warsaw" on Thu, Apr 05, 2001 at 01:23:16PM -0400 References: <20010404191712.44418@scfn.thpl.lib.fl.us> <15051.44842.800982.769610@anthem.wooz.org> <20010404200958.49012@scfn.thpl.lib.fl.us> <15051.47639.556741.554268@anthem.wooz.org> <20010404202649.01789@scfn.thpl.lib.fl.us> <15051.54691.444924.4799@anthem.wooz.org> <20010405020110.57681@scfn.thpl.lib.fl.us> <15052.31082.918502.278802@anthem.wooz.org> <20010405123945.60935@scfn.thpl.lib.fl.us> <15052.43524.31062.306270@anthem.wooz.org> Message-ID: <20010405132324.24253@scfn.thpl.lib.fl.us> On Thu, Apr 05, 2001 at 01:23:16PM -0400, Barry A. Warsaw wrote: > JRA> Then what's the problem? > > The read succeeds but the resulting MailList instance won't have the > new attribute. When the module tries to access that attribute, you'll > get an AttributeError. This /could/ be worked around by using > something like: > > if getattr(mlist, 'my_new_attribute', 0): > > instead of > > if mlist.my_new_attribute: > > The getattr() approach doesn't raise an exception when given a default > value. Ah. The problem is that the wrapper isn't first-class. (That is, it fails to behave in a sufficiently transparent fashion to keep you from being able to tell that it's not just "storing the object on disk". (did the explanation make matters worse? :-))) Got it. FYI, I consider that a design deficiency (which is a slightly different category from a 'bug' :-), and I concur that it *should* be fixed; does the approach you mention have other unforseen difficulties that it imposes? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 5 18:45:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 5 Apr 2001 13:45:31 -0400 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 References: Message-ID: <15052.44859.379837.741282@anthem.wooz.org> >>>>> "ps" == writes: ps> I would really like to hear comments on the proposed ps> functionality I'm currently opposed to making it easy to disable these headers. They are described in RFC 2369 and I think it's important for Mailman to be as standards compliant as possible. That some MUAs haven't caught up yet isn't a good enough argument to change my mind. That being said, I claim that it's trivial to hack the source code to disable these headers. Having your patch available unofficially is a good thing too (thanks!), since it gives sites more options. I'm glad you've made the patch but I'm not inclined to include it in the official release. Cheers, -Barry From chuqui@plaidworks.com Thu Apr 5 19:02:27 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Thu, 5 Apr 2001 11:02:27 -0700 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: <15052.44859.379837.741282@anthem.wooz.org> Message-ID: <200104051804.f35I4Fe17814@lists.apple.com> On Thursday, April 5, 2001, at 10:45 AM, Barry A. Warsaw wrote: > I'm currently opposed to making it easy to disable these headers. > They are described in RFC 2369 and I think it's important for Mailman > to be as standards compliant as possible. These are standards. I think any patch to remove them ought to be rejected, the documentation ought to explicitly discourge people from removing them, and the source code ought to have a note in it recommending against removing them. We want to encourage adoption of the standard, not removal of the header lines. In fact, I'd go further, if it were my project. I'd put it in the FAQ that we do not support removal of the headers, and I'd make it list policy to not support anyone who wants to. If they want to, let them. We're under no obligation to make it easy in any way, and I think in the long-run, doing anything that in any way approves of (even by implication of putting an unsuipported patch somewhere in the disto) is the wrong thing. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. From jra@baylink.com Thu Apr 5 19:12:03 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 5 Apr 2001 14:12:03 -0400 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: <200104051804.f35I4Fe17814@lists.apple.com>; from chuq von rospach on Thu, Apr 05, 2001 at 11:02:27AM -0700 References: <15052.44859.379837.741282@anthem.wooz.org> <200104051804.f35I4Fe17814@lists.apple.com> Message-ID: <20010405141203.35086@scfn.thpl.lib.fl.us> On Thu, Apr 05, 2001 at 11:02:27AM -0700, chuq von rospach wrote: > In fact, I'd go further, if it were my project. I'd put it in the FAQ > that we do not support removal of the headers, and I'd make it list > policy to not support anyone who wants to. If they want to, let them. > We're under no obligation to make it easy in any way, and I think in the > long-run, doing anything that in any way approves of (even by > implication of putting an unsuipported patch somewhere in the disto) is > the wrong thing. And that, given the author, is, as they say, da name'a dat tune. Cheers, -- jr 'ie: "concur"' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From christine@trafficmagnet.net Fri Apr 6 05:22:59 2001 From: christine@trafficmagnet.net (Christine Hall) Date: Fri, 6 Apr 2001 12:22:59 +0800 Subject: [Mailman-Developers] WWW.LIST.ORG Message-ID: <200104060422.MAA06199@ns2.trafficmagnet.net>

          Hello,

          I visited www.list.org and I noticed that you are not listed on some search engines. I am sure you can increase the number of people who visit www.list.org . Do you know TrafficMagnet? TrafficMagnet is a unique technology that automatically submits your web site to over 300,000+ search engines and directories every month. This is a very low-cost and effective way of advertising your site.

          To check our prices and submit www.list.org to 300,000+ search engines, go to TrafficMagnet.net

          I would love to hear from you.

          Best Regards,
          Christine Hall
          Sales & Marketing
          www.TrafficMagnet.net

             

          From webmaster@wunderland.com Fri Apr 6 16:49:16 2001 From: webmaster@wunderland.com (Dale Newfield) Date: Fri, 6 Apr 2001 11:49:16 -0400 (EDT) Subject: [Mailman-Developers] Cross-posting? In-Reply-To: Message-ID: I've installed Mailman at a site that has quite a number of mailing lists. we're trying to figure out a more disjoint re-design of the lists to reduce the problem of cross-posting, but I thought I'd at least ask if anyone's attempted to address this from w/in mailman. If there were a database of message ids, along with information listing which mailing lists those've gone to, wouldn't it be possible to only send messages once to people subscribed to both lists? It's a great piece of software, BTW, and a hack I recently installed to unify passwords across lists (so it looks like a user has only one password instead of one per list) helps out, too. -Dale Newfield webmaster@wunderland.com From darrell@grumblesmurf.net Fri Apr 6 19:21:25 2001 From: darrell@grumblesmurf.net (Darrell Fuhriman) Date: 06 Apr 2001 11:21:25 -0700 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: chuq von rospach's message of "Thu, 5 Apr 2001 11:02:27 -0700" References: <200104051804.f35I4Fe17814@lists.apple.com> Message-ID: chuq von rospach writes: > These are standards. I think any patch to remove them ought to be > rejected, the documentation ought to explicitly discourge people from > removing them, and the source code ought to have a note in it > recommending against removing them. We want to encourage adoption of > the standard, not removal of the header lines. I agree with everything but the first clause (and I was the one that wrote the patch to implement it.) The RFC specifically says that the headers are optional (paragraph 2 section 1 of the RFC.), and I personally believe in giving people options where available. Just because it's probably a bad idea doesn't mean we should be restrictive on things are not mandated. This is already what's done with the optional Reply-To header, for example. If I wanted software that told me that I had to do it the software's (or the software author's) way and no other, I would just use ezmlm. I don't like software that second guesses my decisions, and I see no compelling reason to be second guessing others' decisions here. I say make it optional, but strongly discourage turning it off. Darrell From dan.mick@west.sun.com Fri Apr 6 20:17:49 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Fri, 06 Apr 2001 12:17:49 -0700 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 References: Message-ID: <3ACE165D.16E967D8@west.sun.com> > I would really like to hear comments on the proposed functionality OK. I think it's wrong to have this configurable. I think Mailman should do the right thing wrt list headers, and the right thing is to include them. From apeeters@lashout.net Sat Apr 7 00:15:15 2001 From: apeeters@lashout.net (Adriaan Peeters) Date: Sat, 7 Apr 2001 01:15:15 +0200 Subject: [Mailman-Developers] specific templates Message-ID: <110701c0beef$7078f3d0$0201000a@napoli> Hey all, I sent this to the mailman-users list, but they couldn't give me a complete answer. Does anyone know how to change the automated subcribe confirmation email ? It is possible to add a text via the administrative interface, but is't not possible to change the mail completely. I would like to change the welcome e-mail completely, perhaps even make html mails from it. I tried to copy templates/subscribeack.txt to lists/listname/subscribeack.txt and change something in that file, but it didn't work :( I think it's not a very big deal to change the code to check first if a specific subscribeack.txt exists, then include it, and if not, include the default one. But unfortunately I don't know enough Python to submit a patch :( Is there a way to accomplish this at this moment, or are there any patches out there ? Regards and thanks, Adriaan Peeters From thomas@xs4all.net Sat Apr 7 01:06:47 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 7 Apr 2001 02:06:47 +0200 Subject: [Mailman-Developers] specific templates In-Reply-To: <110701c0beef$7078f3d0$0201000a@napoli>; from apeeters@lashout.net on Sat, Apr 07, 2001 at 01:15:15AM +0200 References: <110701c0beef$7078f3d0$0201000a@napoli> Message-ID: <20010407020647.G2820@xs4all.nl> On Sat, Apr 07, 2001 at 01:15:15AM +0200, Adriaan Peeters wrote: > I sent this to the mailman-users list, but they couldn't give me a comple= te > answer. > Does anyone know how to change the automated subcribe confirmation email ? > It is possible to add a text via the administrative interface, but is't n= ot > possible to change the mail completely. I would like to change the welco= me > e-mail completely, perhaps even make html mails from it. > I tried to copy templates/subscribeack.txt to > lists/listname/subscribeack.txt and change something in that file, but it > didn't work :( What you want is being worked on. Mailman 2.1 will be much more configurable, as well as multilingual (meaning that your site can be in English, and your lists can in Dutch, Spanish or Swahili as well as English. Or the other way 'round) and one of the things that was fixed is that the emails are better configurable. Having said that :) it's not *too* hard to convince Mailman to read template files from the list directory, if you really really want to. You need to adjust the 'maketext' function in Utils.py to accept a mailinglist-argument, and if it's passed in, try to find out if its data dir has the template file. And then you need to go and adjust all maketext calls to include the list object. (maketext should probably be a method ;) I did this for a Dutch list we run, since 2.1 wasn't even on the horizon back then and they *really* wanted to be dutch all the way. And the Mailman we are running is so hacked up anyway, it's just not funny anymore :) My maketext looks like this: def maketext(templatefile, dict, raw=3D0, mlist=3DNone): """Make some text from a template file. Reads the =14emplatefile', relative to mm_cfg.TEMPLATE_DIR, does string substitution by interpolating in the =04ict', and if =12aw' is false, wraps/fills the resulting text by calling wrap(). """ if mlist: file =3D os.path.join(mm_cfg.LIST_DATA_DIR, mlist.internal_name(), templatefile) if not os.path.exists(file): file =3D os.path.join(mm_cfg.TEMPLATE_DIR, templatefile) else: file =3D os.path.join(mm_cfg.TEMPLATE_DIR, templatefile) fp =3D open(file) template =3D fp.read() fp.close() text =3D template % SafeDict(dict) if raw: return text return wrap(text) And then I went and adjusted the 15-something calls to maketext. --=20 Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me sp= read! From jra@baylink.com Sat Apr 7 02:13:36 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 6 Apr 2001 21:13:36 -0400 Subject: [Mailman-Developers] specific templates In-Reply-To: <110701c0beef$7078f3d0$0201000a@napoli>; from Adriaan Peeters on Sat, Apr 07, 2001 at 01:15:15AM +0200 References: <110701c0beef$7078f3d0$0201000a@napoli> Message-ID: <20010406211336.08848@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 01:15:15AM +0200, Adriaan Peeters wrote: > possible to change the mail completely. I would like to change the welcome > e-mail completely, perhaps even make html mails from it. Oh *puhleeze* don't. email is *not* an HTML medium. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Sat Apr 7 02:14:48 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 6 Apr 2001 21:14:48 -0400 Subject: [Mailman-Developers] specific templates In-Reply-To: <20010407020647.G2820@xs4all.nl>; from Thomas Wouters on Sat, Apr 07, 2001 at 02:06:47AM +0200 References: <110701c0beef$7078f3d0$0201000a@napoli> <20010407020647.G2820@xs4all.nl> Message-ID: <20010406211448.18624@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 02:06:47AM +0200, Thomas Wouters wrote: > What you want is being worked on. Mailman 2.1 will be much more > configurable, as well as multilingual (meaning that your site can be in > English, and your lists can in Dutch, Spanish or Swahili as well as English. > Or the other way 'round) and one of the things that was fixed is that the > emails are better configurable. Passwords not required? Will that be one of the new features? :-) Or is it in there already, and I just missed it. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Sat Apr 7 06:55:19 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Sat, 7 Apr 2001 01:55:19 -0400 Subject: [Mailman-Developers] specific templates References: <110701c0beef$7078f3d0$0201000a@napoli> <20010407020647.G2820@xs4all.nl> Message-ID: <15054.43975.861818.904844@anthem.wooz.org> >>>>> "TW" == Thomas Wouters writes: TW> You need to adjust the 'maketext' function in Utils.py to TW> accept a mailinglist-argument I think at one time I was against this for some reason I can't remember. But it does seem like the most reasonable approach, and I'm getting tired of the way Mailman searches for its templates so this will probably go into 2.1. (I'm aware of patch #402426 but I think adding an mlist argument is better.) >>>>> "JRA" == Jay R Ashworth writes: JRA> Passwords not required? Will that be one of the new JRA> features? :-) JRA> Or is it in there already, and I just missed it. You (sort of) missed it. Passwords aren't going away, but users won't need them to unsubscribe. If they don't supply a password they will have to confirm the operation before it goes through. Note that the confirmation mechanism is flexible enough now that I plan to add a lot more things that can be confirmed (like approve, reject, etc. holds via email, etc.). -Barry From jra@baylink.com Sat Apr 7 12:34:15 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 07:34:15 -0400 Subject: [Mailman-Developers] specific templates In-Reply-To: <15054.43975.861818.904844@anthem.wooz.org>; from "Barry A. Warsaw" on Sat, Apr 07, 2001 at 01:55:19AM -0400 References: <110701c0beef$7078f3d0$0201000a@napoli> <20010407020647.G2820@xs4all.nl> <15054.43975.861818.904844@anthem.wooz.org> Message-ID: <20010407073415.37521@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 01:55:19AM -0400, Barry A. Warsaw wrote: > JRA> Passwords not required? Will that be one of the new > JRA> features? :-) > JRA> Or is it in there already, and I just missed it. > > You (sort of) missed it. Passwords aren't going away, but users won't > need them to unsubscribe. If they don't supply a password they will > have to confirm the operation before it goes through. Well, in this particular customer's case, they don't even want that. Form; fill in email address; click "unsubscribe", buh-bye. They have a low opinion of their customers' patience. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From eric.kidd@pobox.com Sat Apr 7 20:48:58 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 15:48:58 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC Message-ID: <20010407154858.B29075@localhost.Dartmouth.EDU> Hello! I run several Mailman-based mailing lists. And along the way, I've come to really love Mailman. Many thanks to everyone who has worked on it; it's definitely the best list manager I've ever seen. But--for better of for worse--I've decided to tamper with near perfection. :-) Here's what I'm up to: * I want to be able to control Mailman remotely, using scripts. For example, I want to be able to change list preferences, access the approval queue, and generally do anything I could do through the web. * Ideally, I'd like to be able to write these scripts in any popular language. * I don't especially want to fake FORM POSTs and parse the HTML response. This would work, but it's more work than I'd like to get into on the client side. So I've decided to add XML-RPC support to my local copy of Mailman. XML-RPC is a protocol that allows you to make CGI-like "function calls" over HTTP using specially-formatted XML documents. You can read all about XML-RPC here: http://www.xmlrpc.com/ http://www.xmlrpc.com/spec http://www.linuxdoc.org/HOWTO/XML-RPC-HOWTO/index.html The HOWTO contains example clients and servers in many different languages. Fredrik Lundh wrote an excellent implementation of XML-RPC for Python. His code is used in Zope, the RedHat Network and some forthcoming stuff from Eazel: http://www.pythonware.com/products/xmlrpc/index.htm But why use XML-RPC? 1) XML-RPC is really simple. It doesn't get into Schemas, namespaces, alternate encodings, or anything else especially fancy. Fredrik's implemention is less than a 1,000 lines long, which isn't bad for an RPC protocol. I'm not smart enough to cope anything more complicated. :-) 2) XML-RPC is widely supported, with bindings for Python, Perl, Java, C, C++, Tcl, KDE, Zope, AppleScript, Microsoft .NET, Ruby, Rebol, Delphi, and some languages I'd never even heard of. 3) XML-RPC supports complex data-types: arrays, dictionaries, byte arrays, etc. 4) Many XML-RPC implementations support Unicode, including Python, Perl, Java, C and C++. This would allow me to handle international data gracefully. 5) XML-RPC servers can support introspection, allowing a client to discover APIs over the network. This makes it easy to generate documentation, create wrapper classes, and so on, without needing to cope with IDL. For more information on XML-RPC introspection, see: http://xmlrpc-c.sourceforge.net/hacks.php OK, yes, I'm probably crazy. But it seems like a fun hack. So if anybody else is interested in XML-RPC for Mailman, please let me know. And if anybody can tell me why I'm nuts, please let me know that, too. :-) Cheers, Eric -- XML-RPC HOWTO: http://www.linuxdoc.org/HOWTO/XML-RPC-HOWTO/index.html XML-RPC for C and C++: http://xmlrpc-c.sourceforge.net/ xmlrpc-c-devel list: http://xmlrpc-c.sourceforge.net/lists.php From jon@latchkey.com Sat Apr 7 21:38:30 2001 From: jon@latchkey.com (Jon Stevens) Date: Sat, 07 Apr 2001 13:38:30 -0700 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407154858.B29075@localhost.Dartmouth.EDU> Message-ID: on 4/7/01 12:48 PM, "Eric Kidd" wrote: > OK, yes, I'm probably crazy. But it seems like a fun hack. > > So if anybody else is interested in XML-RPC for Mailman, please let me > know. And if anybody can tell me why I'm nuts, please let me know > that, too. :-) > > Cheers, > Eric Hi Eric, I don't think you are nuts at all. This sounds *excellent* and very much needed. I personally, hope this makes it into the mailman distribution as a standard feature (if you donate your code for it). thanks! -jon From ricardo@rixhq.nu Sat Apr 7 22:26:53 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 7 Apr 2001 23:26:53 +0200 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: ; from jon@latchkey.com on Sat, Apr 07, 2001 at 01:38:30PM -0700 References: <20010407154858.B29075@localhost.Dartmouth.EDU> Message-ID: <20010407232653.A14436@rix.rixhq.nu> On Sat, Apr 07, 2001 at 01:38:30PM -0700, Jon Stevens wrote: > on 4/7/01 12:48 PM, "Eric Kidd" wrote: > > OK, yes, I'm probably crazy. But it seems like a fun hack. > > So if anybody else is interested in XML-RPC for Mailman, please let me > > know. And if anybody can tell me why I'm nuts, please let me know > > that, too. :-) > I don't think you are nuts at all. This sounds *excellent* and very much > needed. > I personally, hope this makes it into the mailman distribution as a standard > feature (if you donate your code for it). What about using SOAP? I don't know that much about it but it looks like about the same thing XML-RPC does but I could be wrong though :) -- Regards, Ricardo From eric.kidd@pobox.com Sat Apr 7 22:36:42 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 17:36:42 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407232653.A14436@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 07, 2001 at 11:26:53PM +0200 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> Message-ID: <20010407173642.F29075@localhost.Dartmouth.EDU> On Sat, Apr 07, 2001 at 11:26:53PM +0200, Ricardo Kustner wrote: > What about using SOAP? I don't know that much about it but it looks like > about the same thing XML-RPC does but I could be wrong though :) You can find the two specifications here: http://www.xmlrpc.com/spec http://www.w3.org/TR/SOAP/ Basically, XML-RPC is a very early fork of SOAP, back before a whole bunch of internal Microsoft committees each decided to add their favorite feature to the specification. ;-) Pros of SOAP: * It's going to be built into Microsoft .NET. * Lots of libraries provide support for various subsets of SOAP. A few of these run under Unix. * SOAP is extensible, flexible, malleable, etc. * There's a very reasonable subset of SOAP evolving (BDG), but it's not clear that some of the big developers will be compatible with that subset. Pros of XML-RPC: * All the clients and servers talk to each other already. * It's ridiculously simple. * Clients are available for all of the major scripting languages, and many of the minor ones. * I'm willing to implement it. :-) Basically, XML-RPC is a Real Simple, Right Now kind of thing. SOAP is a little bit like OSI networking or SGML--a sweet idea in theory, but a wee bit complex in practice. But it's not an either-or choice. All my XML-RPC work will be open source, so once there's a good SOAP library for Python, it will be really easy to add SOAP support. Does this seem like a reasonable approach? Cheers, Eric From ricardo@rixhq.nu Sat Apr 7 23:39:22 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sun, 8 Apr 2001 00:39:22 +0200 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407173642.F29075@localhost.Dartmouth.EDU>; from eric.kidd@pobox.com on Sat, Apr 07, 2001 at 05:36:42PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> <20010407173642.F29075@localhost.Dartmouth.EDU> Message-ID: <20010408003922.B14436@rix.rixhq.nu> On Sat, Apr 07, 2001 at 05:36:42PM -0400, Eric Kidd wrote: > On Sat, Apr 07, 2001 at 11:26:53PM +0200, Ricardo Kustner wrote: > > What about using SOAP? I don't know that much about it but it looks like > > about the same thing XML-RPC does but I could be wrong though :) > Basically, XML-RPC is a very early fork of SOAP, back before a whole bunch > of internal Microsoft committees each decided to add their favorite > feature to the specification. ;-) > Pros of XML-RPC: > * All the clients and servers talk to each other already. > * It's ridiculously simple. > * Clients are available for all of the major scripting languages, and > many of the minor ones. > * I'm willing to implement it. :-) > Basically, XML-RPC is a Real Simple, Right Now kind of thing. SOAP is > a little bit like OSI networking or SGML--a sweet idea in theory, but a wee > bit complex in practice. > But it's not an either-or choice. All my XML-RPC work will be open source, > so once there's a good SOAP library for Python, it will be really easy to > add SOAP support. > Does this seem like a reasonable approach? Sounds great to me... This would give some nice opportunities like easy integration into dynamic websites, as long as they are written in a language that supports xmlrpc... I know I would almost certainly be using it in some PHP sites I made to integrate the subscription pages better. Do you think this would require major changes in the mailman code? I can imagine the question will rise if it is something which could be added now or in a future version of mailman. -- Regards, Ricardo From eric.kidd@pobox.com Sat Apr 7 23:38:52 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 18:38:52 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010408003922.B14436@rix.rixhq.nu>; from ricardo@rixhq.nu on Sun, Apr 08, 2001 at 12:39:22AM +0200 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> <20010407173642.F29075@localhost.Dartmouth.EDU> <20010408003922.B14436@rix.rixhq.nu> Message-ID: <20010407183852.H29075@localhost.Dartmouth.EDU> On Sun, Apr 08, 2001 at 12:39:22AM +0200, Ricardo Kustner wrote: > Sounds great to me... This would give some nice opportunities like easy > integration into dynamic websites, as long as they are written in a language > that supports xmlrpc... Hmmm. You should be totally covered on the Unix side of things, and you should be pretty well off under Windows. I'm currently getting e-mails about XML-RPC for Flash, so I'm guessing that most of the obvious languages have been covered. PHP has a good client, so you shouldn't have any trouble. > Do you think this would require major changes in the mailman code? I can > imagine the question will rise if it is something which could be added now > or in a future version of mailman. Probably not, although I'm still getting up to speed on the mailman internals. I think I'm going to write an extra CGI script, and have it make calls into the rest of Mailman as needed. Basically, if an API exists in Mailman, it's a cinch to export the same functionality. But if no API exists for performing a given task, it might get a bit hard. Cheers, Eric From jra@baylink.com Sun Apr 8 01:49:28 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 20:49:28 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407154858.B29075@localhost.Dartmouth.EDU>; from Eric Kidd on Sat, Apr 07, 2001 at 03:48:58PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> Message-ID: <20010407204928.22296@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 03:48:58PM -0400, Eric Kidd wrote: > OK, yes, I'm probably crazy. But it seems like a fun hack. :-) > So if anybody else is interested in XML-RPC for Mailman, please let me > know. And if anybody can tell me why I'm nuts, please let me know > that, too. :-) Um... "security"? What's the current status, there? SSL? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Sun Apr 8 01:50:23 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 20:50:23 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407232653.A14436@rix.rixhq.nu>; from Ricardo Kustner on Sat, Apr 07, 2001 at 11:26:53PM +0200 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> Message-ID: <20010407205023.60489@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 11:26:53PM +0200, Ricardo Kustner wrote: > What about using SOAP? I don't know that much about it but it looks > like about the same thing XML-RPC does but I could be wrong though :) Naaah... Dave Winer likes SOAP. Cheers, -- jr 'ok, ok ":-)", already...' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From jra@baylink.com Sun Apr 8 01:52:28 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 7 Apr 2001 20:52:28 -0400 Subject: [Mailman-Developers] Way OT: XML-RPC in *Flash*? (was: Re: Remote scripting with XML-RPC) In-Reply-To: <20010407183852.H29075@localhost.Dartmouth.EDU>; from Eric Kidd on Sat, Apr 07, 2001 at 06:38:52PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407232653.A14436@rix.rixhq.nu> <20010407173642.F29075@localhost.Dartmouth.EDU> <20010408003922.B14436@rix.rixhq.nu> <20010407183852.H29075@localhost.Dartmouth.EDU> Message-ID: <20010407205228.41732@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 06:38:52PM -0400, Eric Kidd wrote: > Hmmm. You should be totally covered on the Unix side of things, and you > should be pretty well off under Windows. I'm currently getting e-mails > about XML-RPC for Flash, so I'm guessing that most of the obvious > languages have been covered. Oh, just what *I* needed to hear... I can download a Flash file, and it will go off and try to do things as me? ;-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From eric.kidd@pobox.com Sun Apr 8 01:59:43 2001 From: eric.kidd@pobox.com (Eric Kidd) Date: Sat, 7 Apr 2001 20:59:43 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407204928.22296@scfn.thpl.lib.fl.us>; from jra@baylink.com on Sat, Apr 07, 2001 at 08:49:28PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407204928.22296@scfn.thpl.lib.fl.us> Message-ID: <20010407205943.L29075@localhost.Dartmouth.EDU> On Sat, Apr 07, 2001 at 08:49:28PM -0400, Jay R. Ashworth wrote: > On Sat, Apr 07, 2001 at 03:48:58PM -0400, Eric Kidd wrote: > > So if anybody else is interested in XML-RPC for Mailman, please let me > > know. And if anybody can tell me why I'm nuts, please let me know > > that, too. :-) > > Um... "security"? What's the current status, there? SSL? You get precisely the same security you would using the regular CGI interface. ;-) If you've installed SSL, both approaches provide very nice security. If you haven't installed SSL, you're not going to be a happy camper either way. An XML-RPC server is basically a glorified CGI script with a structured input/output format. Handy, but not really anything new. Cheers, Eric From jra@baylink.com Sun Apr 8 07:00:12 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Sun, 8 Apr 2001 02:00:12 -0400 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: <20010407205943.L29075@localhost.Dartmouth.EDU>; from Eric Kidd on Sat, Apr 07, 2001 at 08:59:43PM -0400 References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407204928.22296@scfn.thpl.lib.fl.us> <20010407205943.L29075@localhost.Dartmouth.EDU> Message-ID: <20010408020012.55672@scfn.thpl.lib.fl.us> On Sat, Apr 07, 2001 at 08:59:43PM -0400, Eric Kidd wrote: > > Um... "security"? What's the current status, there? SSL? > > You get precisely the same security you would using the regular CGI > interface. ;-) > > If you've installed SSL, both approaches provide very nice security. If > you haven't installed SSL, you're not going to be a happy camper either > way. Ah. > An XML-RPC server is basically a glorified CGI script with a structured > input/output format. Handy, but not really anything new. Oh, yeah. On the server side, I guess that's true. It's the client side API that makes it cool. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From claw@kanga.nu Sun Apr 8 21:15:18 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 08 Apr 2001 13:15:18 -0700 Subject: [Mailman-Developers] Remote scripting with XML-RPC In-Reply-To: Message from "Jay R. Ashworth" of "Sun, 08 Apr 2001 02:00:12 EDT." <20010408020012.55672@scfn.thpl.lib.fl.us> References: <20010407154858.B29075@localhost.Dartmouth.EDU> <20010407204928.22296@scfn.thpl.lib.fl.us> <20010407205943.L29075@localhost.Dartmouth.EDU> <20010408020012.55672@scfn.thpl.lib.fl.us> Message-ID: <664.986760918@kanga.nu> On Sun, 8 Apr 2001 02:00:12 -0400 Jay R Ashworth wrote: > On Sat, Apr 07, 2001 at 08:59:43PM -0400, Eric Kidd wrote: >> An XML-RPC server is basically a glorified CGI script with a >> structured input/output format. Handy, but not really anything >> new. > Oh, yeah. On the server side, I guess that's true. It's the > client side API that makes it cool. While setting up client key authentication under SSL is not hard, its also something not well documented or familiar to (most) SysAdms. Its fiddly, easy to get wrong, and tends to be frustrating before you reach the "Aha!" point, and that doesn't even count the PKI problem. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From marc_news@valinux.com Sun Apr 8 23:23:22 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Sun, 8 Apr 2001 15:23:22 -0700 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses Message-ID: <20010408152322.A6510@magic.merlins.org> Apparently, this old bug is still here (I remember seeing it in the mailman 1.0rc1 days, and back then we solved it by having the user change his mail name so as not to have a dot) My mailman is configured to look at the header from (not the envelope from), and the header from says: From: David E.Fox It seems that mailman gets confused by the dot in "David E.Fox" and then fails to handle the Email address correctly, and decides that the user isn't in the list of subscribers, so he can't post, or it may just be confused by the fact that there are no quotes around the name. (notice that mailman thinks the Email is davide.fox and not dfox@m206-157.dsl.tsoft.com) Did I miss something, is this actually a buglet that's still here? (Note that this From field is invalid as per RFC 822, because it's missing the double quotes. The user uses Kmail and it's a kmail bug). If you concur that this is a problem, please let me know, and I can open a bug on sourceforge. Thanks, Marc ----- Forwarded message from svlug-admin@lists.svlug.org ----- From: svlug-admin@lists.svlug.org Subject: svlug post from davide.fox requires approval To: svlug-admin@lists.svlug.org X-Ack: no Date: Sat, 07 Apr 2001 14:25:01 -0700 As list administrator, your authorization is requested for the following mailing list posting: List: svlug@lists.svlug.org From: davide.fox Subject: Re: [svlug] DSL vedor shakeout II: PSINet Reason: Post by non-member to a members-only list At your convenience, visit: http://lists.svlug.org/mailman/admindb/svlug to approve or deny the request. ----- End forwarded message ----- -- 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 jra@baylink.com Mon Apr 9 05:37:28 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 9 Apr 2001 00:37:28 -0400 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <20010408152322.A6510@magic.merlins.org>; from Marc MERLIN on Sun, Apr 08, 2001 at 03:23:22PM -0700 References: <20010408152322.A6510@magic.merlins.org> Message-ID: <20010409003728.00098@scfn.thpl.lib.fl.us> On Sun, Apr 08, 2001 at 03:23:22PM -0700, Marc MERLIN wrote: > From: David E.Fox > (Note that this From field is invalid as per RFC 822, because it's missing > the double quotes. The user uses Kmail and it's a kmail bug). Yes, but note that it's *still* parseable, since the error is *outside* the bra-kets; it's arguable whether being pedantic *here* is productive, under the "be conservative what you send, liberal what you accept" principle. And yes, I *know* that someone's program, somewhere, has to be a hard ass... I just don't know whether it's "ours" (:-) or not... Cheers -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From Nigel.Metheringham@InTechnology.co.uk Mon Apr 9 10:15:32 2001 From: Nigel.Metheringham@InTechnology.co.uk (Nigel Metheringham) Date: Mon, 09 Apr 2001 10:15:32 +0100 Subject: [Mailman-Developers] Re: Patch: Optionally Suppressing List Headers - v2 In-Reply-To: Message from Darrell Fuhriman of "06 Apr 2001 11:21:25 PDT." Message-ID: darrell@grumblesmurf.net said: > I say make it optional, but strongly discourage turning it off. I come in fairly strongly on the not having this as a standard (or distributed) option - I want people to fix their broken MUAs rather than break MLMs to fit. Those using a sane MTA (OK, I mean exim), can simply set the outgoing transport to strip the headers. 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 wheakory@isu.edu Tue Apr 10 16:04:38 2001 From: wheakory@isu.edu (Kory Wheatley) Date: Tue, 10 Apr 2001 09:04:38 -0600 Subject: [Mailman-Developers] mailman qrunner error Message-ID: <3AD32106.2F129C48@isu.edu> --------------8BDDE55C1E873FEDFBB22EBD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm recieving this message below every single minute and nothing has changed on our system, which of course is not allowing mail to be received to the mailing list. Our system is (RED HAT 7.0 Mailman 2.0.3 and the right Python Version). (I manage over a 100 lists for our universtity so this is very critical). The web server will not bring up any of the mailman pages. I receive the following error "We have found a Bug mailman 2.0.3". I have been running this version of Mailman ever since it was released and have not had one problem. In the error logfile file "qrunner" it says Could not acquire qrunner lock I shutdown sendmail and the web server and restarted both, but still have the problem. I just thought that would be worth trying. I also have no lock files so no processes are hanging. I ran check_perms and all permissions were set correctly There are also no messages in the "qfiles" directory. Any solution would be helpful and I would really appreciate it. Thank you ahead of time. ----- The following addresses had permanent fatal errors ----- "|/home/mailman/mail/wrapper post ccaus" (expanded from: ) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/scripts/post", line 33, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 30, in ? import socket ImportError: /usr/lib/libcrypto.so.0: undefined symbol: i2d_X509_EXTENSION 554 "|/home/mailman/mail/wrapper post ccaus"... unknown mailer error 1 Reporting-MTA: dns; mm.isu.edu Received-From-MTA: DNS; ux5-250.isu.edu Arrival-Date: Tue, 10 Apr 2001 08:29:14 -0600 Final-Recipient: RFC822; X-Actual-Recipient: RFC822; |/home/mailman/mail/wrapper post ccaus@mm.isu.edu Action: failed Status: 5.0.0 Last-Attempt-Date: Tue, 10 Apr 2001 08:29:14 -0600 Subject: test 2 Date: Tue, 10 Apr 2001 08:28:55 -0600 From: Kory Wheatley To: ccaus@mm.isu.edu -- ######################################### -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. --------------8BDDE55C1E873FEDFBB22EBD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I'm recieving this  message below every single minute and nothing has changed on our system, which of course is not allowing  mail to be received to the mailing list.
          Our system is (RED HAT 7.0 Mailman 2.0.3 and the right Python Version).
          (I manage over a 100 lists for our universtity so this is very critical).

          The web server will not bring up any of the mailman pages. I receive the following error "We have found a Bug  mailman 2.0.3". I have been running this version of Mailman ever since it was released and have not had one problem.

          In the error logfile file "qrunner" it says
          Could not acquire qrunner lock

          I shutdown sendmail and the web server and restarted both, but still have the problem. I just thought that would be worth trying.
          I also have no lock files so no processes are hanging.
          I ran check_perms and all permissions were  set correctly
          There are also no messages in the "qfiles" directory.

          Any solution would be helpful and I would really appreciate it. Thank you ahead of time.

            ----- The following addresses had permanent fatal errors -----
          "|/home/mailman/mail/wrapper post ccaus"
              (expanded from: <ccaus@mm.isu.edu>)

             ----- Transcript of session follows -----
          Traceback (innermost last):
            File "/home/mailman/scripts/post", line 33, in ?
              from Mailman import MailList
            File "/home/mailman/Mailman/MailList.py", line 30, in ?
              import socket
          ImportError: /usr/lib/libcrypto.so.0: undefined symbol: i2d_X509_EXTENSION
          554 "|/home/mailman/mail/wrapper post ccaus"... unknown mailer error 1
           
           
           

          Reporting-MTA: dns; mm.isu.edu
          Received-From-MTA: DNS; ux5-250.isu.edu
          Arrival-Date: Tue, 10 Apr 2001 08:29:14 -0600

          Final-Recipient: RFC822; <ccaus@mm.isu.edu>
          X-Actual-Recipient: RFC822; |/home/mailman/mail/wrapper post ccaus@mm.isu.edu
          Action: failed
          Status: 5.0.0
          Last-Attempt-Date: Tue, 10 Apr 2001 08:29:14 -0600
           

           Subject:
                  test 2
             Date:
                  Tue, 10 Apr 2001 08:28:55 -0600
             From:
                  Kory Wheatley <wheakory@isu.edu>
               To:
                  ccaus@mm.isu.edu
           
           
           

          --
          #########################################

          --
          #########################################
          Kory Wheatley
          Academic Computing Analyst Sr.
          Phone 282-3874
          #########################################
          Everything must point to him.
            --------------8BDDE55C1E873FEDFBB22EBD-- From barry@digicool.com Tue Apr 10 17:00:15 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 10 Apr 2001 12:00:15 -0400 Subject: [Mailman-Developers] Re: mailman qrunner error References: <3AD32106.2F129C48@isu.edu> Message-ID: <15059.11791.769045.883659@anthem.wooz.org> KW> I'm recieving this message below every single minute and KW> nothing has changed on our system I'll bet you find that not to be the case. ;) First of all, fire up the version of Python you think Mailman is using. Do this interactively and then try to import socket: % python Python 2.0 (#14, Feb 15 2001, 23:45:39) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import socket >>> socket.__file__ '/usr/local/lib/python2.0/socket.pyc' If this works, then MM is using a different Python than the one on your path. If this fails too, then somebody likely rebuilt Python, perhaps enabling the SSL support. That's the only reason I can think of for _socketmodule.so depending on libcrypto. The crash is probably leaving a stale qrunner lock in the locks directory. -Barry From chuqui@plaidworks.com Tue Apr 10 21:47:24 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 13:47:24 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... Message-ID: <200104102046.f3AKk3e20664@lists.apple.com> Been whapping at my big mailman machine the last week, because it's been slowly falling behind and never quite catching up. Unfortunately, it seems like I've simply hit capacity for now, so I'm looking for ways to extend that or at least minimize the damage until 2.1's multi-threading queueing comes online and I can use it (my big problem is the single-threading....) One thing that would help would be if the Sendmail module got productionalized so it could be used instead of SMTPDirect, because then you could use the -deliverymode=defer option, which you can't on SMTPDirect because it disables some spamchecking. But going elbow-deep into the server for a few days under a constant grinding load has brought forward a few things I thought I'd pass on... First, there's a problem with the way queues are processed. qrunners uses: for file in os.listdir(xxxx) to read the queue. The order is undefined, but in practice, it's basically blatting it out how it's stored in the inode. If you're not overly busy, that's fine. But If you start hitting the point where you're backing up, it means you process "N" slots into the directory, then qrunner exits and starts again, and it then re-covers the same directory slots. Things that go in and don't get processed simply NEVER get processed, unless the system quiets down enough to let qrunner to catch up. Qrunner *really* needs to process the queue FIFO. Unfortunately, teaching qrunner to go FIFO is a bit complicated. you'd have to pull all of the filenames out, stat them all, and then sort that. There's a much easier solution, though -- In Mailman/Message.py where the filename si created, mailman uses time.time() and some other values to create a filename, which is then converted to hex. the idea is to create a unique filename. But in fact, time.time() should be unique (to be paranoid, one could grab it and then check to see if the filename exists and loop), and if you stored the queue files as "time.time()".msg/.db, then qrunner could sort the queue trivially, guaranteeing that the oldest messages are always processed in each queue run. This creates some interesting race conditions, where an item is added to the queue and never comes out -- which causes people to think it's lose and repost it, adding to the queue clogging, which slows stuff, which... until Saturday, when they all go home, the system slows down, and qrunner catches up and posts three day old messages.... And since the system seems to be working just fine, tracking it down is fun... This also led to finding a problem in the bounce processing area. The bouncer works pretty well, but it has one flaw for which I don't have an easy answer. If I'm subscribed as "chuq@plaidworks.com", but for some reason the bounce comes back as "chuq@mail.plaidworks.com" (or vice versa, or if I'm forwarding mail in some other name), the bouncer will catch the bounce and try to process it, not find me, and log it as a "user not subscribed". Unless the admin is somehow post-processing the bounce logs, though, that bounce is never REALLY handled, so it bounces indefinitely, and the admin never knows. This also over time encourages queue clogging and wastes bandwidth and CPU and all of that -- and worse, list admins and site admins probably think everything is fine because the bouncing system is working and these "not a member" bounces are never reported anywhere. On the other, other hand, you probably don't want to just blat all these at admins, since they'll tune them out. But some kind of nightly report of some sort is the tradeoff I'd make, I think, so admins could see continual bounce problems that need to be manually investigated. And I strongly recommend all site admins watch the bounce logs and look for these "missing" bounces, so they can be manually tracked. I found on my busy site this made a HUGE difference in my queue backlogs, too; these things were silently contributing a significant amount of traffic to the queue system and exacerbating my capacity issues. I really think the qrunner issue needs to be dealt with; it only shows up on fairly busy sites, but it's a definite bug for folks like me. The bouncer issue is less nasty, but in a "good citizens clean up their trash" attitude, I think we need to at least make sure list/site admins are aware of these bouncers, unless someone can figure out a way to automate fixing them (this is a place where VERP type things could help, but I'm not going there, honest... giggle) chuq -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. The first rule of holes: If you are in one, stop digging. From chuqui@plaidworks.com Tue Apr 10 22:02:24 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 14:02:24 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <200104102046.f3AKk3e20664@lists.apple.com> Message-ID: <200104102101.f3AL12e23657@lists.apple.com> On Tuesday, April 10, 2001, at 01:47 PM, chuq von rospach wrote: > This creates some interesting race conditions, where an item is added > to the queue and never comes out A way to minimize this, by the way, are to tweak the values: QRUNNER_PROCESS_LIFETIME QRUNNER_MAX_MESSAGES in mm_cfg.py (see Defaults.py for their definitions). By default, they're 15 minutes and 300. That means qrunner quits 4 times an hour, even if the queue isn't done, or after processing 300 messages. So if you have a queue that files to, oh, 450 messages, the first 300 get processed (or less), and as they're processing, the deleted files are replaced with new ones in the directory inode, and then qrunner quits and starts over. Whatever's over that highwater mark is basically stuck in the queue until the system goes idle, and if it never quite goes idle -- you're hosed. I've changed mind to 30 minutes and a MAX of 0 (disabling that check), so that it'll run with as few quits and interruptions as possible, the idea being you want it to process deep into your queue. You can't set LIFETIME too high without risking a hung qrunner taking out the system indefinitely, and if you make it too long, you'll need to tweak other lockfile values (see Defaults.py, if you need any of this, you should be able to figure out which ones need to be tweaked...) -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I tried to get a life once, but they were out of stock. From chuqui@plaidworks.com Tue Apr 10 22:08:12 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 14:08:12 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <200104102101.f3AL12e23657@lists.apple.com> Message-ID: <200104102106.f3AL6oe24147@lists.apple.com> On Tuesday, April 10, 2001, at 02:02 PM, chuq von rospach wrote: > I've changed mind to 30 minutes and a MAX of 0 (disabling that check), Sigh. For "0" read "None" -- It's looking for the text string. IMHO, that's confusing at first glance, but I need to read the documentation more closely. But also, IMHO, it should accept "0" as the same as None.... Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. The Pinball Machine Rule is the observation that it doesn't matter a wit if the instructions are printed clearly for all to see, nobody will read them. They'll just drop their quarter(s) and start pushing buttons like a Tommy. -- Barry Warsaw From csf@moscow.com Wed Apr 11 00:47:21 2001 From: csf@moscow.com (Michael Yount) Date: Tue, 10 Apr 2001 16:47:21 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <200104102046.f3AKk3e20664@lists.apple.com>; from chuqui@plaidworks.com on Tue, Apr 10, 2001 at 01:47:24PM -0700 References: <200104102046.f3AKk3e20664@lists.apple.com> Message-ID: <20010410164721.C488@moscow.com> If relaying on loopback connections is acceptable, there is a simple way to disable lookups during RCPT TO in Sendmail 8.10.0 and later. See http://csf.colorado.edu/archive/2000/mj2-dev/msg02259.html for more information. Chuq, have you tried this approach? Michael On 10 Apr 13:47, chuq von rospach wrote: > > Been whapping at my big mailman machine the last week, because it's been > slowly falling behind and never quite catching up. Unfortunately, it > seems like I've simply hit capacity for now, so I'm looking for ways to > extend that or at least minimize the damage until 2.1's multi-threading > queueing comes online and I can use it (my big problem is the > single-threading....) > > One thing that would help would be if the Sendmail module got > productionalized so it could be used instead of SMTPDirect, because then > you could use the -deliverymode=defer option, which you can't on > SMTPDirect because it disables some spamchecking. > From marc_news@valinux.com Wed Apr 11 06:12:35 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 10 Apr 2001 22:12:35 -0700 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <20010409003728.00098@scfn.thpl.lib.fl.us>; from jra@baylink.com on Mon, Apr 09, 2001 at 12:37:28AM -0400 References: <20010408152322.A6510@magic.merlins.org> <20010409003728.00098@scfn.thpl.lib.fl.us> Message-ID: <20010410221235.A8861@magic.merlins.org> On Mon, Apr 09, 2001 at 12:37:28AM -0400, Jay R. Ashworth wrote: > On Sun, Apr 08, 2001 at 03:23:22PM -0700, Marc MERLIN wrote: > > From: David E.Fox > > (Note that this From field is invalid as per RFC 822, because it's missing > > the double quotes. The user uses Kmail and it's a kmail bug). > > Yes, but note that it's *still* parseable, since the error is *outside* > the bra-kets; Correct. I haven't found the right piece of code in mailman yet, but it smells like a regular expression that grabs the wrong pattern and ends up with davide.fox instead of dfox@m206-157.dsl.tsoft.com > it's arguable whether being pedantic *here* is productive, > under the "be conservative what you send, liberal what you accept" Yeah, I know about all this, I just wanted to point out that it wasn't just mailman that was buggy, it was a mishandling of a non common not really valid case, although it happens in real life. > principle. And yes, I *know* that someone's program, somewhere, has to > be a hard ass... I just don't know whether it's "ours" (:-) or not... Exim is very good at that, but it's an option. In mailman it's not :-) (nor is it really intentional) 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 barry@digicool.com Wed Apr 11 07:36:39 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 02:36:39 -0400 Subject: [Mailman-Developers] Mailman 2.0 usage notes... References: <200104102046.f3AKk3e20664@lists.apple.com> Message-ID: <15059.64375.932030.793628@anthem.wooz.org> >>>>> "cvr" == chuq von rospach writes: cvr> One thing that would help would be if the Sendmail module got cvr> productionalized so it could be used instead of SMTPDirect, cvr> because then you could use the -deliverymode=defer option, cvr> which you can't on SMTPDirect because it disables some cvr> spamchecking. I'd love for this to happen, but someone else is going to have to do the heavy lifting. It's just not that important to me since most MTAs can be configured to defer DNS resolution for localhost relays (as I think Michael Yount suggested for sendmail). cvr> First, there's a problem with the way queues are cvr> processed. qrunners uses: cvr> for file in os.listdir(xxxx) cvr> to read the queue. The order is undefined, but in practice, cvr> it's basically blatting it out how it's stored in the cvr> inode. In MM2.1, we essentialy do the same os.listdir() but we shuffle the files randomly before looping over them. Also, the resource controls in MM2.0 are there because I was worried about things like cyclic garbage bloating the qrunner process. Requiring Python 2.0 is a double win here because it's got cyclic garbage collection and I can use random.shuffle(). So I can get rid of the process limits and just run the loop infinitely. This combined with the parallelizability of the qrunner processes, and the splitting of the queue directories should, I think, solve the problems you're seeing. cvr> This also led to finding a problem in the bounce processing cvr> area. The bouncer works pretty well, but it has one flaw for cvr> which I don't have an easy answer. Several comments. I intend to add a feature to MM (tho' probably not until 3.0) that would let users register mutiple addresses under a single account. Thus I could teach Mailman that anything coming from barry@digicool.com or barry@wooz.org is really from me and should not be held. This would allow the bounce matching code to match disparate email addresses -- at the cost of cooperation from the user or list admin. OTOH, matching "bwarsaw@python.org" with "bwarsaw@mail.python.org" regardless of which is in the bounce and which is in the database, ought to be easy to manage (and I'm a little surprised the code doesn't already do this). See SMART_ADDRESS_MATCH in Defaults.py for a variable that controls this in other contexts. Mind submitting a bug report about this? cvr> If I'm subscribed as "chuq@plaidworks.com", but for some cvr> reason the bounce comes back as "chuq@mail.plaidworks.com" cvr> (or vice versa, or if I'm forwarding mail in some other cvr> name), the bouncer will catch the bounce and try to process cvr> it, not find me, and log it as a "user not cvr> subscribed". Unless the admin is somehow post-processing the cvr> bounce logs, though, that bounce is never REALLY handled, so cvr> it bounces indefinitely, and the admin never knows. MM should be keeping much better stats about its operation, e.g. # of messages per list received, delivered, etc. Include in this a report about bounces that hit non-members. cvr> This also over time encourages queue clogging and wastes cvr> bandwidth and CPU and all of that -- and worse, list admins cvr> and site admins probably think everything is fine because the cvr> bouncing system is working and these "not a member" bounces cvr> are never reported anywhere. In MM2.1, you could tune the bounce qrunner to work less often, giving priority to the incoming and outgoing queues. cvr> On the other, other hand, you probably don't want to just cvr> blat all these at admins, since they'll tune them out. But cvr> some kind of nightly report of some sort is the tradeoff I'd cvr> make, I think, so admins could see continual bounce problems cvr> that need to be manually investigated. Good idea! -Barry From barry@digicool.com Wed Apr 11 07:37:48 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 02:37:48 -0400 Subject: [Mailman-Developers] Mailman 2.0 usage notes... References: <200104102101.f3AL12e23657@lists.apple.com> <200104102106.f3AL6oe24147@lists.apple.com> Message-ID: <15059.64444.591681.810459@anthem.wooz.org> >>>>> "cvr" == chuq von rospach writes: cvr> Sigh. For "0" read "None" -- It's looking for the text cvr> string. cvr> IMHO, that's confusing at first glance, but I need to read cvr> the documentation more closely. But also, IMHO, it should cvr> accept "0" as the same as None.... No longer relevant for 2.1, but if there is a 2.0.4 (and I don't see a need at the moment), it would be good to fix. -Barry From barry@digicool.com Wed Apr 11 07:49:15 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 02:49:15 -0400 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses References: <20010408152322.A6510@magic.merlins.org> <20010409003728.00098@scfn.thpl.lib.fl.us> <20010410221235.A8861@magic.merlins.org> Message-ID: <15059.65131.38792.716734@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Correct. I haven't found the right piece of code in mailman MM> yet, but it smells like a regular expression that grabs the MM> wrong pattern and ends up with davide.fox instead of MM> dfox@m206-157.dsl.tsoft.com I suspect the problem is in Python's rfc822 module: >>> a = rfc822.AddrlistClass('David E.Fox ') >>> a.getaddrlist() [('', 'DavidE.Fox'), ('', 'dfox@m206-157.dsl.tsoft.com')] Mailman, interestingly enough, has Utils.ParseAddrs() which appears to try to work around problems in rfc822: >>> ParseAddrs('David E.Fox ') 'dfox@m206-157.dsl.tsoft.com' which seems to suck out the right address in this case. What should probably in MM2.1 is for MailList.HasExplicitDest() to fallback on the output of ParseAddrs() if the rfc822 method doesn't match. -Barry From chuqui@plaidworks.com Wed Apr 11 07:57:24 2001 From: chuqui@plaidworks.com (chuq von rospach) Date: Tue, 10 Apr 2001 23:57:24 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <15059.64375.932030.793628@anthem.wooz.org> Message-ID: <200104110650.f3B6odi04544@plaidworks.com> On Tuesday, April 10, 2001, at 11:36 PM, Barry A. Warsaw wrote: > I'd love for this to happen, but someone else is going to have to do > the heavy lifting. yah. If I have time, but I think I'd rather put that time into evaluating and moving to postfix, myself. > In MM2.1, we essentialy do the same os.listdir() but we shuffle the > files randomly before looping over them. I'd really recommend FIFO, Barry. I kinow when my queue starts shuffling, it drives my users crazy (because they write to ask why stuff's coming out of sequence). The end-users really seem to expect FIFO, or at least mostly FIFO. It becomes a lot more important with digest users -- they freak when stuff comes in the digest randomized. > run the loop infinitely. This combined with the parallelizability of > the qrunner processes, and the splitting of the queue directories > should, I think, solve the problems you're seeing. yup. I'm not expecting it to be fixed in 2.0.x as much as making sure it's taken into consideration for 2.1 -- because I know even with the parallelization, we'll still run into servers big enough to have to worry about it (mine sure seems headed there...) > Several comments. I intend to add a feature to MM (tho' probably not > until 3.0) that would let users register mutiple addresses under a > single account. Yes, I'm getting more and more requests for this. > OTOH, matching "bwarsaw@python.org" with "bwarsaw@mail.python.org" > regardless of which is in the bounce and which is in the database, warning, plot complication. warning, plot complication. You can't assume this to be true for third level domains. Overseas, it's NOT true -- because in many cases, the third level of the domain is the equivalent to the second level in .com. So if you assume that fred@anglican.co.uk is the same as fred@catholic.co.uk, you just messed up badly, because anglican and catholic are different companies. You run into a rathole here REAL fast, because the assumptions that are true for .com, .edu, and .net aren't true for the country domains, where in many cases, it all bumps out one sub-level (foo.com.br, boo.edu.pl, etc) > Mind submitting a bug report about this? > yeah, I'll get it in as soon as I can. > In MM2.1, you could tune the bounce qrunner to work less often, giving > priority to the incoming and outgoing queues. > parallelism solves my problem, since the machine in hand is an E250 with two cpu's, one of which is really bored... -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. USENET is a lot better after two or three eggnogs. We shouldn't allow anyone on the net without a bottle of brandy. (chuq von rospach, 1992) From conny@cendio.se Wed Apr 11 13:10:12 2001 From: conny@cendio.se (Conny Andersson) Date: Wed, 11 Apr 2001 14:10:12 +0200 Subject: [Mailman-Developers] Multilanguage support in Mailman. Message-ID: <3AD449A4.DDD4CB77@cendio.se> Hi, I just entered the list and thought I could share a beta release of a Swedish translation of the templates and HTMLFormatter.py files. I'm not sure how to incorporate the changes to Mailman (I have just made symbolic links in my setup) but one suggestion could be to have an option for every user to choose their desired language. You can find the tar file at=20 http://conny.nu/mailman-swe.tar.gz Best, Conny .................................................... Conny Andersson Work Area: Embedded Systems Cendio Systems AB Direct: +46(0)13 290882 Teknikringen 3 Mobile: +46(0)707 452066 583 30 Link=F6ping Fax: +46(0)13 214700 Sweden Internet: www.cendio.com From holmberg@iar.se Wed Apr 11 15:03:39 2001 From: holmberg@iar.se (Johan Holmberg) Date: Wed, 11 Apr 2001 16:03:39 +0200 (MEST) Subject: [Mailman-Developers] Patch for non-ASCII characters in Subject line Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-2110444415-986997469=:13982 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hello mailman-developers ! I have for a long time been annoyed by the fact that Mailman adds more than one copy of the mailing-list-prefix to the Subject line in replies sent to a list. This can occur if the Subject line contains non-ASCII characters (this has been reported in the bug-database as bug #230400: "German Umlaute mess up subject-line and body"). It looks something like (if you can view this in your mailers :-)): Subject: Re: [Test] Re: [Test] r=E4kms=F6rg=E5s The reason seems to be that Mailman has the following "algorithm" to decide what to do: - add list-name-prefix (if it isn't already there) instead of the more correct: - MIME-decode the subject - add list-name-prefix (if it isn't already there) - MIME-reencode the subject If no MIME-decoding is done, Mailman can fail to detect the precense of a mailing-list-prefix, since the prefix can be "buried" in the MIME-encoded stuff. I have made a patch to "CookHeaders.py" that fixes this problem, and implements the second alternative above (see the attached patch). Could something like this be added to future versions of Mailman ?? (I don't know if I have made the change the right way (I'm not a Python programmer)). /Johan Holmberg ---559023410-2110444415-986997469=:13982 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="mailman-subject-patch.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="mailman-subject-patch.txt" KioqIENvb2tIZWFkZXJzLnB5Lm9yaWcJRnJpIEZlYiAxNiAxMzo0MDoxOSAy MDAxDQotLS0gQ29va0hlYWRlcnMucHkJV2VkIEFwciAxMSAxNDowMDoxNyAy MDAxDQoqKioqKioqKioqKioqKioNCioqKiAyMCwyOCAqKioqDQotLS0gMjAs NTIgLS0tLQ0KICBpbXBvcnQgc3RyaW5nDQogIGltcG9ydCByZQ0KICBpbXBv cnQgdXJscGFyc2UNCisgaW1wb3J0IG1pbWlmeQ0KKyANCiAgZnJvbSBNYWls bWFuIGltcG9ydCBtbV9jZmcNCiAgDQogIA0KKyAjLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KKyAjIFRoaXMgZnVuY3Rpb24gTUlNRS1kZWNvZGVzIHRo ZSBzdWJqZWN0IGJlZm9yZSBkZWNpZGluZyBpZiBhDQorICMgcHJlZml4IHNo b3VsZCBiZSBhZGRlZC4gSUYgd2UgY2hhbmdlIHRoZSBzdWJqZWN0IHdlIGhh dmUgdG8NCisgIyAicmVlbmNvZGUiIGl0IGJlZm9yZSBzZW5kaW5nIGl0Lg0K KyAjDQorICMgVGhpcyBpcyBhICJoYWNrIiBtYWRlIGJ5IEpvaGFuIEhvbG1i ZXJnIDxob2xtYmVyZ0BpYXIuc2U+Lg0KKyAjIFNlZW1zIHRvIHdvcmssIGJ1 dCBJJ20gbm8gUHl0aG9uIHByb2dyYW1tZXIgKHByZWZlcnMgUGVybC9SdWJ5 IDotKSkNCisgIyBVc2UgaXQgYXQgeW91ciBvd24gcmlzay4NCisgIw0KKyAN CisgZGVmIGFkZF9wcmVmaXgocHJlZml4LHN1YmplY3QpOg0KKyAgICAgaWYg bm90IHByZWZpeDogcmV0dXJuIHN1YmplY3QNCisgICAgIHRleHQgPSBtaW1p ZnkubWltZV9kZWNvZGVfaGVhZGVyKHN1YmplY3QpDQorICAgICBpZiByZS5z ZWFyY2gocmUuZXNjYXBlKHByZWZpeCksIHRleHQsIHJlLkkpOg0KKyAgICAg ICAgIHJldHVybiBzdWJqZWN0DQorICAgICBlbHNlOg0KKyAgICAgICAgIHRl eHQgPSBwcmVmaXggKyBzdWJqZWN0DQorICAgICAgICAgdGV4dCA9IG1pbWlm eS5taW1lX2VuY29kZV9oZWFkZXIodGV4dCkNCisgICAgICAgICByZXR1cm4g dGV4dA0KKyANCisgIy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCisgDQog IAwNCiAgZGVmIHByb2Nlc3MobWxpc3QsIG1zZywgbXNnZGF0YSk6DQogICAg ICAjIE1hcmsgdGhlIG1lc3NhZ2UgYXMgZGlydHkgc28gdGhhdCBpdHMgdGV4 dCB3aWxsIGJlIGZvcmNlZCB0byBkaXNrIG5leHQNCioqKioqKioqKioqKioq Kg0KKioqIDQ4LDU1ICoqKioNCiAgICAgICAgICAjIHdlIHB1cnBvc2VmdWxs eSBsZWF2ZSBubyBzcGFjZSBiL3cgcHJlZml4IGFuZCBzdWJqZWN0IQ0KICAg ICAgICAgIGlmIG5vdCBzdWJqZWN0Og0KICAgICAgICAgICAgICBtc2dbJ1N1 YmplY3QnXSA9IHByZWZpeCArICcobm8gc3ViamVjdCknDQohICAgICAgICAg ZWxpZiBwcmVmaXggYW5kIG5vdCByZS5zZWFyY2gocmUuZXNjYXBlKHByZWZp eCksIHN1YmplY3QsIHJlLkkpOg0KISAgICAgICAgICAgICBtc2dbJ1N1Ympl Y3QnXSA9IHByZWZpeCArIHN1YmplY3QNCiAgICAgICMNCiAgICAgICMgZ2V0 IHJpZCBvZiBkdXBsaWNhdGUgaGVhZGVycw0KICAgICAgZGVsIG1zZ1snc2Vu ZGVyJ10NCi0tLSA3Miw3OSAtLS0tDQogICAgICAgICAgIyB3ZSBwdXJwb3Nl ZnVsbHkgbGVhdmUgbm8gc3BhY2UgYi93IHByZWZpeCBhbmQgc3ViamVjdCEN CiAgICAgICAgICBpZiBub3Qgc3ViamVjdDoNCiAgICAgICAgICAgICAgbXNn WydTdWJqZWN0J10gPSBwcmVmaXggKyAnKG5vIHN1YmplY3QpJw0KISAgICAg ICAgIGVsaWYgcHJlZml4Og0KISAgICAgICAgICAgICBtc2dbJ1N1YmplY3Qn XSA9IGFkZF9wcmVmaXgocHJlZml4LHN1YmplY3QpDQogICAgICAjDQogICAg ICAjIGdldCByaWQgb2YgZHVwbGljYXRlIGhlYWRlcnMNCiAgICAgIGRlbCBt c2dbJ3NlbmRlciddDQo= ---559023410-2110444415-986997469=:13982-- From barry@digicool.com Wed Apr 11 15:42:43 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 11 Apr 2001 10:42:43 -0400 Subject: [Mailman-Developers] Mailman 2.0 usage notes... References: <15059.64375.932030.793628@anthem.wooz.org> <200104110650.f3B6odi04544@plaidworks.com> Message-ID: <15060.28003.574078.622751@anthem.wooz.org> >>>>> "cvr" == chuq von rospach writes: cvr> I'd really recommend FIFO, Barry. I kinow when my queue cvr> starts shuffling, it drives my users crazy (because they cvr> write to ask why stuff's coming out of sequence). The cvr> end-users really seem to expect FIFO, or at least mostly cvr> FIFO. It becomes a lot more important with digest users -- cvr> they freak when stuff comes in the digest randomized. Bling! Of course. Excellent point. cvr> You can't assume this to be true for third level cvr> domains. Overseas, it's NOT true -- because in many cases, cvr> the third level of the domain is the equivalent to the second cvr> level in .com. So if you assume that fred@anglican.co.uk is cvr> the same as fred@catholic.co.uk, you just messed up badly, cvr> because anglican and catholic are different companies. You cvr> run into a rathole here REAL fast, because the assumptions cvr> that are true for .com, .edu, and .net aren't true for the cvr> country domains, where in many cases, it all bumps out one cvr> sub-level (foo.com.br, boo.edu.pl, etc) Again, good point. Actually SMART_ADDRESS_MATCH would only equivalence fred@catholic.co.uk with fred@co.uk, but that's not right either. I believe all this stuff was added way long ago to help out misconfigured mailers, so maybe that's not as important these days. -Barry From les@2pi.org Wed Apr 11 20:13:32 2001 From: les@2pi.org (Les Niles) Date: Wed, 11 Apr 2001 12:13:32 -0700 Subject: [Mailman-Developers] Mailman 2.0 usage notes... In-Reply-To: <15060.28003.574078.622751@anthem.wooz.org> (barry@digicool.com) References: <15059.64375.932030.793628@anthem.wooz.org> <200104110650.f3B6odi04544@plaidworks.com> <15060.28003.574078.622751@anthem.wooz.org> Message-ID: <200104111913.MAA20033@mutiny.2pi.org> On Wed, 11 Apr 2001 10:42:43 -0400 barry@digicool.com (Barry A. Warsaw) wrote: > cvr> You can't assume this to be true for third level > cvr> domains. Overseas, it's NOT true -- because in many cases, > cvr> the third level of the domain is the equivalent to the second > cvr> level in .com. So if you assume that fred@anglican.co.uk is > cvr> the same as fred@catholic.co.uk, you just messed up badly, > cvr> because anglican and catholic are different companies. You > cvr> run into a rathole here REAL fast, because the assumptions > cvr> that are true for .com, .edu, and .net aren't true for the > cvr> country domains, where in many cases, it all bumps out one > cvr> sub-level (foo.com.br, boo.edu.pl, etc) > >Again, good point. Actually SMART_ADDRESS_MATCH would only >equivalence fred@catholic.co.uk with fred@co.uk, but that's not right >either. I believe all this stuff was added way long ago to help out >misconfigured mailers, so maybe that's not as important these days. How about a goodness-of-match algorithm? fred@catholic.co.uk matches itself with an error of 0, matches fred@co.uk with an error of 1, matches fred@anglican.co.uk with an error of 2, and matches everything else with an infinite error. If the address in the bounce has a unique minimum-error match with a subscriber address (there's only one address that matches with that minimum error) then that is used, otherwise it's considered unmatchable. It seems like this would handle most of the common cases and would very rarely screw up, since bounces ought to have been generated by some subscriber. (OK, it would be nice to also recognize that fredsmith@foo.bar and fsmith@mail.foo.bar are the same person, but that's getting a little carried away....) -les From todd@connactivity.connactivity.com Thu Apr 12 04:35:21 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Wed, 11 Apr 2001 23:35:21 -0400 Subject: [Mailman-Developers] Urgent: Duplicates with 2.0 final Message-ID: <200104120335.f3C3ZLr20523@connactivity.connactivity.com> Sorry for sending this to developers and users. I'm not sure which group is more appropriate. I've been using 2.0 final for a couple of months now without a problem. I've got roughly 60,000 people on my mailing list and I'm using sendmail as the MTA on RH6.2. The list is moderated and there is only 1-2 messages a month. The last message sent to the list was sent to some subscribers twice. I had seen the problem before with 2.0rc1. From the release notes for 2.0rc2, that is documented as fixed (bug #117015) (see below). Anyone know why I would see it happen again in 2.0 Final? Here's what I've done: (1) Scanned the Archives. Found a post to mailman-users with no reply that seems related. http://mail.python.org/pipermail/mailman-users/2001-April/010625.html (2) Looked through Syslog logs for System and Sendmail errors. Nothing unusual reported. (3) Looked through the Mailman logs dir (/home/mailman/logs). Nothing out of the orinary except in the errors file (see below). What's strange about this is the duplicate message had already been sent by this time (the few duplicates checked showed 1st delivery at ~8PM April 6 and subsequent delivery at ~2:30AM April 7 -- all times synced with NTP on systems tested). Excerpt from /home/mailman/logs/errors: Apr 07 04:09:18 2001 qrunner(16818): Traceback (innermost last): Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line 278, in ? Apr 07 04:09:18 2001 qrunner(16818): kids = main(lock) Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line 256, in main Apr 07 04:09:18 2001 qrunner(16818): dequeue(root) Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line 184, in dequeue Apr 07 04:09:18 2001 qrunner(16818): os.unlink(root + '.db') Apr 07 04:09:18 2001 qrunner(16818): OSError : [Errno 2] No such file or directory: '/home/mailman/qfiles/c879896f57e6392365c42f995f13c09de378bbcd.db' (cut-n-paste for 2.0rc2 release notes)... >SourceForge bugs fixed: 116615 (README.BSD update), 117015 (duplicate >messages on moderated posts), 117548 (exception in HyperArch.py), >117682 (typos), 121185 (vsnprintf signature), 121591 and 122017 (bogus >link after web unsubscribe), 121811 (`subscribe' in Subject: doesn't >get archived) Help... From benwa@ocentrix.com Fri Apr 13 02:58:31 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 12 Apr 2001 18:58:31 -0700 Subject: [Mailman-Developers] Documentation for announce only lists Message-ID: <200104130158.f3D1wVe25260@mail.ocentrix.net> Hey all, My company is in the process of implementing Mailman to provide announcement lists for our hosting clients. I have been playing with 2.0.1 to 2.0.3 for the past two months and have come up with what I think is a pretty good (and very verbose) description of how to set up an announce only list. Judging by the amount of traffic on this topic here and on the mailman-users list I though it would be a good idea to submit it. Please excuse the verbosity of my description as I was trying to make the description easy to understand by those who are new to Mailman. I was also trying to take into account the different ways that I thought someone would want to run an announcement list. I have tested each of the methods outlined in the description and it all seems to work well, but I would like to get some more opinions before I post it to the mailman-users list. If anyone finds the descritption usefull please feel free to use it however you like. instructions follow: -------------------- Managing announce only lists. INTRODUCTION Keep in mind that some of the techniques below require making changes that will affect how your Mailman installation will manage all of its lists. Wherever this is an issue it has been pointed out. If you choose to use any of these techniques It might be a good idea to run separate installations of Mailman for discussion lists and announcement lists. If you would like to do this there are some additional tips listed at the end of the instructions. In order to run an announcement list with Mailman you'll need to configure a regular list to allow only certain addresses to post to the list. You should create the list as you would any other list. and make a few changes to the it through the web based administrative interface. An announce only list may require some additional maintenance if you frequently have unauthorized posters attempting to post to the list. BASIC CHANGES In the administrative interface under Privacy options set the following fields as shown. Must posts be approved by an administrator? No Restrict posting privilege to list members? No Then place the e-mail addresses of all of those who are authorized to post announcements in the field "Addresses of members accepted for posting to this list without implicit approval requirement." This will limit all posts to the list to those who are listed. Unfortunately(?) all posts to the list by unauthorized posters will still show up in the "Tend to pending administrative requests" area of the administrative interface. List administrators will also receive an email for each of these posts telling them that they have an administrative request pending. This email can be disabled under General options by setting the field "Should administrator get immediate notice of new requests, as well as daily notices about collected ones?" to "No". This might be a bad idea because this also turns off emails that refer to other types of administrative requests that may need approval such as subscribes and unsubscribes. However, administrators will still receive a notice of any pending administrative requests at 5PM every day. MAINTAINING ANNOUNCE ONLY LISTS Mailman does not come with any easy way to automate tending to the administrative requests that are holding unauthorized posters' emails for approval. I have found that there are different ways to get rid of them manually. Each method has its pros and it's cons. In deciding how to get rid of these unauthorized posts one should consider whether they want the unauthorized poster to know anything about the fact that their post has been held. Under General options the field "Send mail to poster when their posting is held for approval?" will determine... exactly that. If you set this to "Yes" the poster will receive an email based on the contents of the template: (/your_mailman_install_directory/templates/postheld.txt). This template can be modified to explain that they have posted to a list that is for announcements only. And that they have posted from an address that is not authorized for posting. This is a site-wide template, so any changes you make to it will affect all lists. The method used to actually tend to the unauthorized post will also affect how much the poster knows about the posting process. If you choose "reject" in handling the post the poster will receive an email based on the contents of the template: (/your_mailman_install_directory/templates/refuse.txt) combined with the text explanation offered in the text box marked "If you reject this post, please explain (optional)". However, if you choose "discard" the poster will not receive an email at all. Make sure that you tend to these requests frequently because if they are not dealt with they can build up to a very long list on the administrative request management page. These requests will be mixed together with any other types of requests that may be pending. CLOSING These are the basic steps in managing an announcement list with Mailman. There are many other tweaks and changes that you can make to optimize your Mailman install for announcement only lists, such as modifying the templates for each list or for the site. And setting some default values for list creation in mm_cfg.py. And of course since Mailman is an open source project written in Python you could always sit down and learn some Python. Python is a great language that is being used in more and more places for all kinds of projects. With basic to intermediate Python skills you can make some other changes to the Mailman scripts that will make managing announcement only lists a lot easier. As your skills progress you can even help to develop Mailman into exactly the mailing list manager that you are looking for. Wouldn't it be great if you could help to contribute to this wonderful list manager that was given to you freely? RUNNING A SEPERATE ANNOUNCE ONLY INSTALLATION If you are running a separate installation of Mailman for announcement lists only you might make a couple of the changes below. 1. In the file mm_cfg.py, set the variable "DEFAULT_DIGESTABLE = 0" set to make list digests unavailable since announce only lists will not have much traffic. 2. If your announcement lists have very low traffic you might consider redefining the variable "DEFAULT_ARCHIVE_VOLUME_FREQUENCY" in mm_cfg.py. Setting it to "2" will create quarterly archives and setting it to "0" will create yearly archives. 3. If your list admins really don't like the 5PM reminders of requests pending authorization These emails can be disabled by removing or commenting out the second line below in the mailman user's crontab. # At 5PM every day, mail reminders to admins as to pending requests 2 0 17 * * * /usr/bin/python -S /your_mailman_install_directory/cron/checkdbs I *strongly* recommend against doing this however because this will turn off ALL 5PM pending request reminders for ALL lists managed by this Mailman installation. As mentioned above This might be a bad idea because this also turns off emails that refer to other types of administrative requests that need approval such as subscribes and unsubscribes. -------------------- Thank you for your help. - Ben Burnett From Dan Mick Fri Apr 13 03:48:53 2001 From: Dan Mick (Dan Mick) Date: Thu, 12 Apr 2001 19:48:53 -0700 (PDT) Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses Message-ID: <200104130248.TAA07922@utopia.West.Sun.COM> > > >>>>> "MM" == Marc MERLIN writes: > > MM> Correct. I haven't found the right piece of code in mailman > MM> yet, but it smells like a regular expression that grabs the > MM> wrong pattern and ends up with davide.fox instead of > MM> dfox@m206-157.dsl.tsoft.com > > I suspect the problem is in Python's rfc822 module: > > >>> a = rfc822.AddrlistClass('David E.Fox ') > >>> a.getaddrlist() > [('', 'DavidE.Fox'), ('', 'dfox@m206-157.dsl.tsoft.com')] > > Mailman, interestingly enough, has Utils.ParseAddrs() which appears to > try to work around problems in rfc822: > > >>> ParseAddrs('David E.Fox ') > 'dfox@m206-157.dsl.tsoft.com' > > which seems to suck out the right address in this case. What should > probably in MM2.1 is for MailList.HasExplicitDest() to fallback on the > output of ParseAddrs() if the rfc822 method doesn't match. I'm coming to this late, but: we all agree that David E.Fox is not a legal RFC822 address, right? Strings containing spaces must-repeat-must be enclosed in doublequotes: "David E.Fox" I see the subject, but: why is this considered to be a "problem" in rfc822, rather than a problem in the mail format? I would expect other MTAs and MUAs to barf on this too. From schorsch@schorsch.com Fri Apr 13 04:27:55 2001 From: schorsch@schorsch.com (Georg Mischler) Date: Thu, 12 Apr 2001 23:27:55 -0400 (EDT) Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <200104130248.TAA07922@utopia.West.Sun.COM> Message-ID: Dan Mick wrote: > > >>>>> "MM" == Marc MERLIN writes: > > > > MM> Correct. I haven't found the right piece of code in mailman > > MM> yet, but it smells like a regular expression that grabs the > > MM> wrong pattern and ends up with davide.fox instead of > > MM> dfox@m206-157.dsl.tsoft.com > > > > I suspect the problem is in Python's rfc822 module: > > > > >>> a = rfc822.AddrlistClass('David E.Fox ') > > >>> a.getaddrlist() > > [('', 'DavidE.Fox'), ('', 'dfox@m206-157.dsl.tsoft.com')] > > > > Mailman, interestingly enough, has Utils.ParseAddrs() which appears to > > try to work around problems in rfc822: > > > > >>> ParseAddrs('David E.Fox ') > > 'dfox@m206-157.dsl.tsoft.com' > > > > which seems to suck out the right address in this case. What should > > probably in MM2.1 is for MailList.HasExplicitDest() to fallback on the > > output of ParseAddrs() if the rfc822 method doesn't match. > > I'm coming to this late, but: we all agree that > > David E.Fox > > is not a legal RFC822 address, right? I can't read this into the RFC document. > Strings containing spaces must-repeat-must be enclosed in > doublequotes: > > "David E.Fox" As far as I can recognize, the standard only requires quotes when such whitespace characters are present within the address part (inside the <...>). The rest of the string is regarded as comment, and may pretty much take any form. There are actually numerous examples in the RFC document that contain spaces in this comment part, where the comment part is *not* enclosed in any quotes. > I see the subject, but: why is this considered to be a "problem" > in rfc822, rather than a problem in the mail format? I would > expect other MTAs and MUAs to barf on this too. This is indeed a problem with the rfc822 modle, assuming that the following text in the standard document (copied literally) is to be taken seriously: EXAMPLES A.1. ADDRESSES A.1.1. Alfred Neuman A.1.2. Neuman@BBN-TENEXA These two "Alfred Neuman" examples have identical seman- tics, as far as the operation of the local host's mail sending (distribution) program (also sometimes called its "mailer") and the remote host's mail protocol server are concerned. In the first example, the "Alfred Neuman" is ignored by the mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- pient. The second example contains no superfluous informa- tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- pient. Since the part within the angle brackets is unambiguously identifyable as the actual address, the parser should just ignore anything else on the same line. It may be wise to use quotes when sending messages, but not accepting something that is explicitly used as a valid example in the standard document seems to be bad style to the very least... Have fun! -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch.com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ From Dan Mick Fri Apr 13 04:39:38 2001 From: Dan Mick (Dan Mick) Date: Thu, 12 Apr 2001 20:39:38 -0700 (PDT) Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses Message-ID: <200104130339.UAA08958@utopia.West.Sun.COM> > > I'm coming to this late, but: we all agree that > > > > David E.Fox > > > > is not a legal RFC822 address, right? > > I can't read this into the RFC document. OK, I retract my claim. I was misled by address = mailbox ; one addressee / group ; named list mailbox = addr-spec ; simple address / phrase route-addr ; name & addr-spec route-addr = "<" [route] addr-spec ">" phrase = 1*word ; Sequence of words word = atom / quoted-string atom = 1* which seems to lead to "phrase can't include spaces without being quoted". But I missed this disclaimer in 3.4.4: The one exception to this rule is that a single SPACE is assumed to exist between contiguous words in a phrase, Sigh. This, of course, makes me wonder why phrase can't include that in its definition, rather than saying "1*word", but there you have it. From fil@rezo.net Fri Apr 13 11:29:28 2001 From: fil@rezo.net (Fil) Date: Fri, 13 Apr 2001 12:29:28 +0200 Subject: [Mailman-Developers] HandlerAPI ? Message-ID: <20010413122928.A13755@orwell.bok.net> Hi, I read somewhere in tha archives that HandlerAPI is deprecated. However it seems that (from a brand new CVS install with mimelib) it is still called from cron/checkdbs and cron/mailpasswds And here's the output of these two scripts : mailman@miel:~$ python cron/mailpasswds Traceback (most recent call last): File "cron/mailpasswds", line 47, in ? from Mailman.Handlers import HandlerAPI ImportError: cannot import name HandlerAPI mailman@miel:~$ python cron/checkdbs Traceback (most recent call last): File "cron/checkdbs", line 30, in ? from Mailman.Handlers import HandlerAPI ImportError: cannot import name HandlerAPI -- Fil From jra@baylink.com Fri Apr 13 17:15:49 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 13 Apr 2001 12:15:49 -0400 Subject: [Mailman-Developers] mailman misparses non RFC 822 compliant Email addresses In-Reply-To: <200104130339.UAA08958@utopia.West.Sun.COM>; from Dan Mick on Thu, Apr 12, 2001 at 08:39:38PM -0700 References: <200104130339.UAA08958@utopia.West.Sun.COM> Message-ID: <20010413121549.50209@scfn.thpl.lib.fl.us> On Thu, Apr 12, 2001 at 08:39:38PM -0700, Dan Mick wrote: > Sigh. This, of course, makes me wonder why phrase can't include that > in its definition, rather than saying "1*word", but there you have it. Because RFC 822 is due for a cleanup and integration with son-of-1036, that's why. Maybe I'll do it. :-} Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From benwa@ocentrix.com Fri Apr 13 17:10:13 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Fri, 13 Apr 2001 09:10:13 -0700 Subject: [Mailman-Developers] Documentation for announce only lists Message-ID: <200104131610.f3DGADh29745@mail.ocentrix.net> Thanks for the feedback. It went to mailman-DEVLOPERS (no E) so I've posted it in its entirety below. I think the screen shots are a good idea. I'll try to Gimp some together this weekend if I can't get our marketing guys to tackle it. I'm not running any lists with high membership currently, so if anyone else has any tips on running large audience announce lists I'd like to include them in the documentation. -Ben ------- Original Copy ------- Subject: Re: [Mailman-Developers] Documentation for announce only lists Date: 04/12/2001 10:40 PM From: Todd Joseph To: benwa@ocentrix.com Cc: mailman-devlopers@python.org Looks good to me. Some screen shots of the Web pages would help break up the descriptions (draw interest). I've been doing much the same myself. I'm frustrated with duplicate messages having been sent with 2.0 Final (IE I sent an announcement and it went to some email addresses twice). I'm not confident how to resolve the problem. I think announce only lists can be much larger than regular lists (one of mine is 60,000). Something that would be nice to have accompany your document is primer on what to watch for. (IE if you are running a large moderated lists with low volume, you may see duplicates when...) From todd@connactivity.connactivity.com Sat Apr 14 02:28:42 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Fri, 13 Apr 2001 21:28:42 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Wed, 11 Apr 2001 23:35:21 EDT." <200104120335.f3C3ZLr20523@connactivity.connactivity.com> Message-ID: <200104140128.f3E1SgS10869@connactivity.connactivity.com> See below for more info. Since I sent this message the first time, I've had 1 reply. I'm thinking I need to include a snappy come-on in my .sig to get everyone's attention. I've learned one more thing, the mailing list had 1 email address with a space in it. The address something like: blahblah@foobar.org and When I tried to remove it, I got an error saying something like "blahblah@foobar.org is not subscribed." I had to quote the bogus address in order to remove it. Could this address have caused duplicate messages to be sent to some subscribers? I'm really at an impasse right now. If I can't reach a comfort level on what has caused the duplicate messages to be sent, I'll have to look for something else to manage my mailing lists. I know people are using mailman sucessfully, and I must be doing something wrong. Oh, and I'm running Python 1.5.2 Help... Todd Joseph todd@connact.com ----------------- > >Sorry for sending this to developers and users. I'm not sure which >group is more appropriate. > >I've been using 2.0 final for a couple of months now without a >problem. I've got roughly 60,000 people on my mailing list and I'm >using sendmail as the MTA on RH6.2. The list is moderated and there >is only 1-2 messages a month. The last message sent to the list was >sent to some subscribers twice. I had seen the problem before with >2.0rc1. From the release notes for 2.0rc2, that is documented as >fixed (bug #117015) (see below). Anyone know why I would see it >happen again in 2.0 Final? > >Here's what I've done: > >(1) Scanned the Archives. Found a post to mailman-users with no reply >that seems related. http://mail.python.org/pipermail/mailman-users/2001-April >/010625.html > >(2) Looked through Syslog logs for System and Sendmail errors. >Nothing unusual reported. > >(3) Looked through the Mailman logs dir (/home/mailman/logs). Nothing >out of the orinary except in the errors file (see below). What's >strange about this is the duplicate message had already been sent by >this time (the few duplicates checked showed 1st delivery at ~8PM >April 6 and subsequent delivery at ~2:30AM April 7 -- all times synced >with NTP on systems tested). > >Excerpt from /home/mailman/logs/errors: > >Apr 07 04:09:18 2001 qrunner(16818): Traceback (innermost last): >Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line > 278, in ? >Apr 07 04:09:18 2001 qrunner(16818): kids = main(lock) >Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line > 256, in main >Apr 07 04:09:18 2001 qrunner(16818): dequeue(root) >Apr 07 04:09:18 2001 qrunner(16818): File "/home/mailman/cron/qrunner", line > 184, in dequeue >Apr 07 04:09:18 2001 qrunner(16818): os.unlink(root + '.db') >Apr 07 04:09:18 2001 qrunner(16818): OSError : [Errno 2] No such file or dire >ctory: '/home/mailman/qfiles/c879896f57e6392365c42f995f13c09de378bbcd.db' > >(cut-n-paste for 2.0rc2 release notes)... > >>SourceForge bugs fixed: 116615 (README.BSD update), 117015 (duplicate >>messages on moderated posts), 117548 (exception in HyperArch.py), >>117682 (typos), 121185 (vsnprintf signature), 121591 and 122017 (bogus >>link after web unsubscribe), 121811 (`subscribe' in Subject: doesn't >>get archived) > >Help... > >------------------------------------------------------ >Mailman-Users maillist - Mailman-Users@python.org >http://mail.python.org/mailman/listinfo/mailman-users From barry@digicool.com Sat Apr 14 02:46:20 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Fri, 13 Apr 2001 21:46:20 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final References: <200104120335.f3C3ZLr20523@connactivity.connactivity.com> <200104140128.f3E1SgS10869@connactivity.connactivity.com> Message-ID: <15063.44012.655280.504033@anthem.wooz.org> >>>>> "TJ" == Todd Joseph writes: TJ> See below for more info. Since I sent this message the first TJ> time, I've had 1 reply. I'm thinking I need to include a TJ> snappy come-on in my .sig to get everyone's attention. Naw, you just have to offer to finish my taxes for me. Fortunately for you, I'm on hold with the IRS so I get to help you . TJ> I've learned one more thing, the mailing list had 1 email TJ> address with a space in it. The address something like: TJ> blahblah@foobar.org and TJ> When I tried to remove it, I got an error saying something TJ> like "blahblah@foobar.org is not subscribed." I had to quote TJ> the bogus address in order to remove it. Could this address TJ> have caused duplicate messages to be sent to some subscribers? Doubtful, but anything's possible. I'd be surprised if it would cause a dup'ing error that didn't show up in the error logs though. TJ> Oh, and I'm running Python 1.5.2 And Mailman 2.0.3? I'd recommend upgrading even though I doubt any of the fixes between 2.0 and 2.0.3 will address your problems. The error your getting in the log file indicates that one of the queued files is getting deleted out from under qrunner. That could be because you're getting multiple qrunner processes because of some locking failure, or because your qrunner lock is getting stomped on. Have you changed any of the default values in your mm_cfg.py (or Defaults.py) file? You ought to see a bunch of "Could not acquire qrunner lock" messages in the logs/qrunner file. Perversely enough, that indicates that qrunner's lock is working. Are you still seeing duplicates, or was this a one-time occurance? Which DELIVERY_MODULE are you using? If SMTPDirect, are you using any of the experimental thread stuff? Are you running a news gateway? That's the one handler that still does an os.fork() so if for some reason your child processes are returning to the main HandlerAPI loop, then that might explain both symptoms. Check your MTA log files. Can you match the duplicate messages with deliveries by your MTA? If Mailman were sending them out twice, you should see each entry in your MTA logs. I know I'm giving you more questions than answers, but I'll definitely need more information before we can figure out your problem. -Barry From todd@connactivity.connactivity.com Sat Apr 14 03:38:47 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Fri, 13 Apr 2001 22:38:47 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Fri, 13 Apr 2001 21:46:20 EDT." <15063.44012.655280.504033@anthem.wooz.org> Message-ID: <200104140238.f3E2clS23684@connactivity.connactivity.com> BW> BW>Naw, you just have to offer to finish my taxes for me. Fortunately BW>for you, I'm on hold with the IRS so I get to help you . I know the feeling. Ever filed an extension? :) BW> BW> TJ> Oh, and I'm running Python 1.5.2 BW> BW>And Mailman 2.0.3? I'd recommend upgrading even though I doubt any of BW>the fixes between 2.0 and 2.0.3 will address your problems. I'm all for going to 2.0.3 but I want to find whatever went wrong first. I'm wary of upgrading any masking/removing the problem before it's found. BW>The error your getting in the log file indicates that one of the BW>queued files is getting deleted out from under qrunner. That could be BW>because you're getting multiple qrunner processes because of some BW>locking failure, or because your qrunner lock is getting stomped on. I kinda thought so. Any ideas on what could cause that? One more tidbit, I have set the "Action when critical or excessive bounces are detected" to "Do nothing" So, I do have a fair number of bogus addresses in my list. My sendmail queue does get kinda large. I've set it up this way out of paranoia in maintaining the integrity of the list (IE not removing valid email addresses). BW>Have you changed any of the default values in your mm_cfg.py (or BW> Defaults.py) file? OK, I'm bad. I changed them in the Defaults.py file. I tried to use the mm_cfg.py file, but ran into a problem (was a few months ago, don't remember what exactly happened). I've included a copy of my "Defaults.py" and "mm_cfg.py" at the bottom of this message for reference. BW>You ought to see a bunch of "Could not BW>acquire qrunner lock" messages in the logs/qrunner file. Perversely BW>enough, that indicates that qrunner's lock is working. :) yes. BW>Are you still seeing duplicates, or was this a one-time occurance? I'm currently using Mailman to send announcements about once a month which are critical to our business. The duplicates were sent with the last announcement and we need to send another next week (wouldn't you know it, Marketing picks this week to send 2 in a month!). I can't send another announcement until I can be sure we won't have any more duplicates. We'll probably outsource next weeks mailing to someone if I can't get this resolved this weekend. BW>Which DELIVERY_MODULE are you using? SMTPDirect (would I be better off with Sendmail?) BW> If SMTPDirect, are you using any of the experimental thread stuff? Not that I know of. See attached Defaults.py and mm_ctg.py for more info. BW> Are you running a news gateway? No. BW>That's the one handler that still does an os.fork() so if for some BW>reason your child processes are returning to the main HandlerAPI loop, BW>then that might explain both symptoms. BW> BW>Check your MTA log files. Can you match the duplicate messages with BW>deliveries by your MTA? If Mailman were sending them out twice, you BW>should see each entry in your MTA logs. Yes, I have 2 different Message-Id's from sendmail 1 for each message delivered. I actually picked that up from the message headers (thanks to "Roger B.A. Klorese" for that pointer). I think Mailman is sending the twice -- not Sendmail. BW> BW>I know I'm giving you more questions than answers, but I'll definitely BW>need more information before we can figure out your problem. BW> BW>-Barry Thank you! From todd@connactivity.connactivity.com Sat Apr 14 04:16:14 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Fri, 13 Apr 2001 23:16:14 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Fri, 13 Apr 2001 22:38:47 EDT." <200104140238.f3E2clS23684@connactivity.connactivity.com> Message-ID: <200104140316.f3E3GES01022@connactivity.connactivity.com> Forgot the Defaults.py and mm_cfg.py files... ----------------------------- Defaults.py ----------------------------- # -*- python -*- # Copyright (C) 1998,1999,2000 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. """Distributed default settings for significant Mailman config variables. """ # NEVER make site configuration changes to this file. ALWAYS make them in # mm_cfg.py instead, in the designated area. See the comments in that file # for details. import os def seconds(s): return s def minutes(m): return m * 60 def hours(h): return h * 60 * 60 def days(d): return d * 60 * 60 * 24 ##### # General system-wide defaults ##### # Should image logos be used? Set this to false to disable image logos from # "our sponsors" and just use textual links instead. Otherwise, this should # contain the URL base path to the logo images (and must contain the trailing # slash).. If you want to disable Mailman's logo footer altogther, hack # Mailman/htmlformat.py:MailmanLogo(), which also contains the hardcoded links # and image names. IMAGE_LOGOS = '/icons/' # Don't change MAILMAN_URL, unless you want to point it at the list.org # mirror. MAILMAN_URL = 'http://www.gnu.org/software/mailman/mailman.html' #MAILMAN_URL = 'http://www.list.org/' # Site-specific settings DEFAULT_HOST_NAME = 'log2l3c' # DEFAULT_URL must end in a slash! DEFAULT_URL = 'http://log2l3c/mailman/' PUBLIC_ARCHIVE_URL = '/pipermail' PRIVATE_ARCHIVE_URL = '/mailman/private' HOME_PAGE = 'index.html' MAILMAN_OWNER = 'mailman-owner@%s' % DEFAULT_HOST_NAME ##### # Archive defaults ##### # Are archives on or off by default? DEFAULT_ARCHIVE = 1 # 0=Off, 1=On # Are archives public or private by default? DEFAULT_ARCHIVE_PRIVATE = 0 # 0=public, 1=private # ARCHIVE_TO_MBOX #-1 - do not do any archiving # 0 - do not archive to mbox, use builtin mailman html archiving only # 1 - archive to mbox to use an external archiving mechanism only # 2 - archive to both mbox and builtin mailman html archiving - # use this to make both external archiving mechanism work and # mailman's builtin html archiving. the flat mail file can be # useful for searching, external archivers, etc. # ARCHIVE_TO_MBOX = 2 # 0 - yearly # 1 - monthly # 2 - quarterly # 3 - weekly # 4 - daily # DEFAULT_ARCHIVE_VOLUME_FREQUENCY = 1 # These variables control the use of an external archiver. Normally if # archiving is turned on (see ARCHIVE_TO_MBOX above and the list's archive* # attributes) the internal Pipermail archiver is used. This is the default if # both of these variables are set to false. When either is set, the value # should be a shell command string which will get passed to os.popen(). This # string can contain %(listname)s for dictionary interpolation. The name of # the list being archived will be substituted for this. # # Note that if you set one of these variables, you should set both of them # (they can be the same string). This will mean your external archiver will # be used regardless of whether public or private archives are selected. PUBLIC_EXTERNAL_ARCHIVER = 0 PRIVATE_EXTERNAL_ARCHIVER = 0 # Set this to 1 to enable gzipping of the downloadable archive .txt file. # Note that this is /extremely/ inefficient, so an alternative is to just # collect the messages in the associated .txt file and run a cron job every # night to generate the txt.gz file. See cron/nightly_gzip for details. GZIP_ARCHIVE_TXT_FILES = 0 # Pipermail archives contain the raw email addresses of the posting authors. # Some view this as a goldmine for spam harvesters. Set this to false to # moderately obscure email addresses, but note that this breaks mailto: URLs # in the archives too. ARCHIVER_OBSCURES_EMAILADDRS = 0 # Pipermail assumes that messages bodies contain US-ASCII text. # Change this option to define a different character set to be used as # the default character set for the archive. The term "character set" # is used in MIME to refer to a method of converting a sequence of # octets into a sequence of characters. If you change the default # charset, you might need to add it to VERBATIM_ENCODING below. DEFAULT_CHARSET = None # Most character set encodings require special HTML entity characters to be # quoted, otherwise they won't look right in the Pipermail archives. However # some character sets must not quote these characters so that they can be # rendered properly in the browsers. The primary issue is multi-byte # encodings where the octet 0x26 does not always represent the & character. # This variable contains a list of such characters sets which are not # HTML-quoted in the archives. VERBATIM_ENCODING = ['iso-2022-jp'] ##### # Delivery defaults ##### # Delivery module for the message pipeline. See # Mailman/Handlers/HandlerAPI.py for details. Unless overridden specifically # in that module, this handler is used for message delivery to the list, and # to an individual user. This value must be a string naming a module in the # Mailman.Handlers package. # # SECURITY WARNING: The Sendmail module is not secure! Please read the # comments in Mailman/Handlers/Sendmail.py for details. Use at your own # risk. # #DELIVERY_MODULE = 'Sendmail' DELIVERY_MODULE = 'SMTPDirect' # Ceiling on the number of recipients that can be specified in a single SMTP # transaction. Set to 0 to submit the entire recipient list in one # transaction. Only used with the SMTPDirect DELIVERY_MODULE. SMTP_MAX_RCPTS = 500 # Maximum number of simulatenous subthreads that will be used for SMTP # delivery. After the recipients list is chunked according to SMTP_MAX_RCPTS, # each chunk is handed off to the smptd by a separate such thread. If your # Python interpreter was not built for threads, this feature is disabled. You # can explicitly disable it in all cases by setting MAX_DELIVERY_THREADS to # 0. This feature is only supported with the SMTPDirect DELIVERY_MODULE. # # NOTE: This is an experimental feature and limited testing shows that it may # in fact degrade performance, possibly due to Python's global interpreter # lock. Use with caution. MAX_DELIVERY_THREADS = 0 # SMTP host and port, when DELIVERY_MODULE is 'SMTPDirect' SMTPHOST = 'localhost' SMTPPORT = 0 # default from smtplib # Command for direct command pipe delivery to sendmail compatible program, # when DELIVERY_MODULE is 'Sendmail'. SENDMAIL_CMD = '/usr/lib/sendmail' # Allow for handling of MTA-specific features (i.e. aliases). Most MTAs use # "sendmail" (including Sendmail, Postfix, and Exim). Qmail uses the "qmail" # style. MTA_ALIASES_STYLE = 'sendmail' # Set these variables if you need to authenticate to your NNTP server for # Usenet posting or reading. If no authentication is necessary, specify None # for both variables. NNTP_USERNAME = None NNTP_PASSWORD = None # Set this if you have an NNTP server you prefer gatewayed lists to use. DEFAULT_NNTP_HOST = '' ##### # General defaults ##### # Set to true to use the crypt module for passwords instead of md5. Crypt may # not work on all Python installations. Don't change this value once you have # lists running... In fact, you should just let configure set this one and # leave it alone. USE_CRYPT = 1 # When allowing only members to post to a mailing list, how is the sender of # the message determined? If this variable is set to 1, then first the # message's envelope sender is used, with a fallback to the sender if there is # no envelope sender. Set this variable to 0 to always use the sender. # # The envelope sender is set by the SMTP delivery and is thus less easily # spoofed than the sender, which is typically just taken from the From: header # and thus easily spoofed by the end-user. However, sometimes the envelope # sender isn't set correctly and this will manifest itself by postings being # held for approval even if they appear to come from a list member. If you # are having this problem, set this variable to 0, but understand that some # spoofed messages may get through. USE_ENVELOPE_SENDER = 0 # When true, Mailman will consider user@host.domain to be the same address as # user@domain. If set to 0, Mailman will consider user@host.domain to be the # same address as user@Host.DoMain, but different than user@domain. Usernames # will always be case preserved, and host parts of addresses will all be # lowercased. SMART_ADDRESS_MATCH = 1 # When set, the listinfo web page overview of lists on the machine will be # confined to only those lists whose web_page_url configuration option host is # included within the URL by which the page is visited - only those "on the # virtual host". If unset, then all lists are included in the overview. The # admin page overview always includes all the lists. VIRTUAL_HOST_OVERVIEW = 1 DEFAULT_FILTER_PROG = '' # Currently not used! # How many members to display at a time on the admin cgi to unsubscribe them # or change their options? DEFAULT_ADMIN_MEMBER_CHUNKSIZE = 30 # how many bytes of a held message post should be displayed in the admindb web # page? Use a negative number to indicate the entire message, regardless of # size (though this will slow down rendering those pages). ADMINDB_PAGE_TEXT_LIMIT = 4096 ##### # List defaults ##### # Should a list, by default be advertised? What is the default maximum number # of explicit recipients allowed? What is the default maximum message size # allowed? DEFAULT_LIST_ADVERTISED = 1 DEFAULT_MAX_NUM_RECIPIENTS = 10 DEFAULT_MAX_MESSAGE_SIZE = 40 # KB # These format strings will be expanded w.r.t. the dictionary for the # mailing list instance. DEFAULT_SUBJECT_PREFIX = "[%(real_name)s] " DEFAULT_MSG_HEADER = "" DEFAULT_MSG_FOOTER = """_______________________________________________ %(real_name)s mailing list %(real_name)s@%(host_name)s %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s """ # Mail command processor will ignore mail command lines after designated max. DEFAULT_MAIL_COMMANDS_MAX_LINES = 25 # Is the list owner notified of admin requests immediately by mail, as well as # by daily pending-request reminder? DEFAULT_ADMIN_IMMED_NOTIFY = 1 # Is the list owner notified of subscribes/unsubscribes? DEFAULT_ADMIN_NOTIFY_MCHANGES = 0 # Are lists, by default, moderated? DEFAULT_MODERATED = 0 # Bounce if 'To:', 'Cc:', or 'Resent-To:' fields don't explicitly name list? # This is an anti-spam measure DEFAULT_REQUIRE_EXPLICIT_DESTINATION = 1 # Alternate names acceptable as explicit destinations for this list. DEFAULT_ACCEPTABLE_ALIASES =""" """ # For mailing lists that have only other mailing lists for members: DEFAULT_UMBRELLA_LIST = 0 # For umbrella lists, the suffix for the account part of address for # administrative notices (subscription confirmations, password reminders): DEFAULT_UMBRELLA_MEMBER_ADMIN_SUFFIX = "-owner" # This variable controlls whether monthly password reminders are sent. DEFAULT_SEND_REMINDERS = 1 # Send welcome messages to new users? Probably should keep this set to 1. DEFAULT_SEND_WELCOME_MSG = 1 # Wipe sender information, and make it look like the list-admin # address sends all messages DEFAULT_ANONYMOUS_LIST = 0 # {header-name: regexp} spam filtering - we include some for example sake. DEFAULT_BOUNCE_MATCHING_HEADERS = """ # Lines that *start* with a '#' are comments. to: friend@public.com message-id: relay.comanche.denmark.eu from: list@listme.com from: .*@uplinkpro.com """ # Mailman can be configured to "munge" Reply-To: headers for any passing # messages. One the one hand, there are a lot of good reasons not to munge # Reply-To: but on the other, people really seem to want this feature. See # the help for reply_goes_to_list in the web UI for links discussing the # issue. # 0 - Reply-To: not munged # 1 - Reply-To: set back to the list # 2 - Reply-To: set to an explicit value (reply_to_address) DEFAULT_REPLY_GOES_TO_LIST = 0 # SUBSCRIBE POLICY # 0 - open list (only when ALLOW_OPEN_SUBSCRIBE is set to 1) ** # 1 - confirmation required for subscribes # 2 - admin approval required for subscribes # 3 - both confirmation and admin approval required # # ** please do not choose option 0 if you are not allowing open # subscribes (next variable) DEFAULT_SUBSCRIBE_POLICY = 1 # does this site allow completely unchecked subscriptions? ALLOW_OPEN_SUBSCRIBE = 0 # Private_roster == 0: anyone can see, 1: members only, 2: admin only. DEFAULT_PRIVATE_ROSTER = 0 # When exposing members, make them unrecognizable as email addrs, so # web-spiders can't pick up addrs for spam purposes. DEFAULT_OBSCURE_ADDRESSES = 1 # Make it 1 when it works. DEFAULT_MEMBER_POSTING_ONLY = 0 ##### # Digestification defaults ##### # Will list be available in non-digested form? DEFAULT_NONDIGESTABLE = 1 # Will list be available in digested form? DEFAULT_DIGESTABLE = 1 DEFAULT_DIGEST_HEADER = "" DEFAULT_DIGEST_FOOTER = DEFAULT_MSG_FOOTER DEFAULT_DIGEST_IS_DEFAULT = 0 DEFAULT_MIME_IS_DEFAULT_DIGEST = 0 DEFAULT_DIGEST_SIZE_THRESHHOLD = 30 # KB DEFAULT_DIGEST_SEND_PERIODIC = 1 DEFAULT_PLAIN_DIGEST_KEEP_HEADERS = ['message', 'date', 'from', 'subject', 'to', 'cc', 'reply-to', 'organization'] ##### # Bounce processing defaults ##### # Should we do any bounced mail response at all? DEFAULT_BOUNCE_PROCESSING = 1 # Minimum number of days that address has been undeliverable before # we take the automatic bounce action. DEFAULT_MINIMUM_REMOVAL_DATE = 5 # Minimum number of delivery failure notices for an account before we # consider doing the automatic bounce action. DEFAULT_MINIMUM_POST_COUNT_BEFORE_BOUNCE_ACTION = 3 # 0 means do nothing # 1 means disable and notify the list admin # 2 means disable and don't notify the list admin # 3 means remove and notify DEFAULT_AUTOMATIC_BOUNCE_ACTION = 1 # Maximum number of posts that can go by w/o a bounce before we figure # delivery failures to a particular recipient have been resolved. This # needs to account for the big lag between delivery attempt and issuance of # the failure notice. We recommend a value representing the maximum number # of messages you'd reasonably expect an average list to get in 1 hour. DEFAULT_MAX_POSTS_BETWEEN_BOUNCES = 5 # Check for administrivia in messages sent to the main list? DEFAULT_ADMINISTRIVIA = 1 # List of addresses (lhs of the @) that likely come only from MTAs bouncing # messages. This is used in qrunner and MailCommandHandler.py to stop # processing or forwarding such messages. # # TBD: why orphanage? why postoffice? LIKELY_BOUNCE_SENDERS = ('daemon', 'mailer-daemon', 'postmaster', 'orphanage', 'postoffice') ##### # General time limits ##### # Authentication cookie control. When set to 0, Mailman's admin cookie # expires at the end of your session. This is preferred for security reasons, # and to avoid potential problems with incorrect clock and timezone settings. # Set this to a value > 0 to use persistent admin cookies with a lifetime of # that number of seconds. ADMIN_COOKIE_LIFE = 0 # How long should subscriptions requests await confirmation before being # dropped? PENDING_REQUEST_LIFE = days(3) # How long should messages which have delivery failures continue to be # retried? After this period of time, a message that has failed recipients # will be dequeued and those recipients will never receive the message. DELIVERY_RETRY_PERIOD = days(5) ##### # Lock management defaults ##### # These variables control certain aspects of lock acquisition and retention. # They should be tuned as appropriate for your environment. All variables are # specified in units of floating point seconds. YOU MAY NEED TO TUNE THESE # VARIABLES DEPENDING ON THE SIZE OF YOUR LISTS, THE PERFORMANCE OF YOUR # HARDWARE, NETWORK AND GENERAL MAIL HANDLING CAPABILITIES, ETC. # Set this to true to turn on MailList object lock debugging messages, which # will be written to logs/locks. If you think you're having lock problems, or # just want to tune the locks for your system, turn on lock debugging. LIST_LOCK_DEBUGGING = 0 # This variable specifies how long the lock will be retained for a specific # operation on a mailing list. Watch your logs/lock file and if you see a lot # of lock breakages, you might need to bump this up. However if you set this # too high, a faulty script (or incorrect use of bin/withlist) can prevent the # list from being used until the lifetime expires. This is probably one of # the most crucial tuning variables in the system. LIST_LOCK_LIFETIME = hours(5) # This variable specifies how long an attempt will be made to acquire a list # lock by the qrunner process. If the lock acquisition times out, the message # will be re-queued for later delivery. LIST_LOCK_TIMEOUT = seconds(10) # cron/qrunner lock lifetime. This is probably the second most crucial tuning # variable in the system. See the notes for LIST_LOCK_LIFETIME above. Watch # your logs/smtp file and make sure that QRUNNER_LOCK_LIFETIME is set longer # than the longest period you see here. It is a bad thing if multiple # qrunners run at the same time. QRUNNER_LOCK_LIFETIME = hours(10) # Two other qrunner resource management variables. The first controls the # maximum lifetime of any single qrunner process, and the second controls the # maximum number of messages a single qrunner process will, er, process. # Exceeding either limit causes qrunner to exit, reclaiming system resources # and deleting the lock. Other qrunners will then process the remaining # messages. Set either to None to inhibit this resource check. QRUNNER_PROCESS_LIFETIME = minutes(15) QRUNNER_MAX_MESSAGES = 300 ##### # Nothing below here is user configurable. Most of these values are in this # file for convenience. Don't change any of them or override any of them in # your mm_cfg.py file! ##### # These directories are used to find various important files in the Mailman # installation. PREFIX and EXEC_PREFIX are set by configure and should point # to the installation directory of the Mailman package. PYTHON = '/usr/bin/python' PREFIX = '/home/mailman' EXEC_PREFIX = '${prefix}' VAR_PREFIX = '/home/mailman' # Work around a bogus autoconf 2.12 bug if EXEC_PREFIX == '${prefix}': EXEC_PREFIX = PREFIX # CGI extension, change using configure script CGIEXT = '' # Group id that group-owns the Mailman installation MAILMAN_UID = 503 MAILMAN_GID = 503 # Enumeration for types of configurable variables in Mailman. Toggle = 1 Radio = 2 String = 3 Text = 4 Email = 5 EmailList = 6 Host = 7 Number = 8 FileUpload = 9 # Held message disposition actions, for use between admindb.py and # ListAdmin.py. DEFER = 0 APPROVE = 1 REJECT = 2 DISCARD = 3 SUBSCRIBE = 4 # Standard text field width TEXTFIELDWIDTH = 40 # Bitfield for user options Digests = 0 # handled by other mechanism, doesn't need a flag. DisableDelivery = 1 DontReceiveOwnPosts = 2 # Non-digesters only AcknowledgePosts = 4 DisableMime = 8 # Digesters only ConcealSubscription = 16 # Useful directories LIST_DATA_DIR = os.path.join(VAR_PREFIX, 'lists') HTML_DIR = os.path.join(PREFIX, 'public_html') CGI_DIR = os.path.join(EXEC_PREFIX, 'cgi-bin') LOG_DIR = os.path.join(VAR_PREFIX, 'logs') LOCK_DIR = os.path.join(VAR_PREFIX, 'locks') DATA_DIR = os.path.join(VAR_PREFIX, 'data') QUEUE_DIR = os.path.join(VAR_PREFIX, 'qfiles') SPAM_DIR = os.path.join(VAR_PREFIX, 'spam') WRAPPER_DIR = os.path.join(EXEC_PREFIX, 'mail') SCRIPTS_DIR = os.path.join(PREFIX, 'scripts') TEMPLATE_DIR = os.path.join(PREFIX, 'templates') PUBLIC_ARCHIVE_FILE_DIR = os.path.join(VAR_PREFIX, 'archives', 'public') PRIVATE_ARCHIVE_FILE_DIR = os.path.join(VAR_PREFIX, 'archives', 'private') SITE_PW_FILE = os.path.join(DATA_DIR, 'adm.pw') # Import a bunch of version numbers from Version import * ----------------------------- mm_cfg.py ----------------------------- # -*- python -*- # Copyright (C) 1998,1999,2000 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. """This module contains your site-specific settings. From a brand new distribution it should be copied to mm_cfg.py. If you already have an mm_cfg.py, be careful to add in only the new settings you want. Mailman's installation procedure will never overwrite your mm_cfg.py file. The complete set of distributed defaults, with documentation, are in the file Defaults.py. In mm_cfg.py, override only those you want to change, after the from Defaults import * line (see below). Note that these are just default settings; many can be overridden via the administrator and user interfaces on a per-list or per-user basis. """ ############################################### # Here's where we get the distributed defaults. from Defaults import * ################################################## # Put YOUR site-specific settings below this line. From barry@digicool.com Tue Apr 17 01:01:10 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 16 Apr 2001 20:01:10 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final References: <15063.44012.655280.504033@anthem.wooz.org> <200104140238.f3E2clS23684@connactivity.connactivity.com> Message-ID: <15067.34758.371357.900173@anthem.wooz.org> >>>>> "TJ" == Todd Joseph writes: BW> The error your getting in the log file indicates that one of BW> the queued files is getting deleted out from under qrunner. BW> That could be because you're getting multiple qrunner BW> processes because of some locking failure, or because your BW> qrunner lock is getting stomped on. TJ> I kinda thought so. Any ideas on what could cause that? Are you running Mailman on an NFS mounted file system? Locking /shouldn't/ be susceptible to NFS issues, but it still isn't a terribly good idea. Another scenario is that you've cranked up your qrunner process limits, but not appropriatedly adjusted your qrunner lock lifetime. In that case, qrunner could be running for a long time, exceeding the lock lifetime, and allowing a future cron started qrunner to break the still running qrunner's lock. The best way to see if this is happening is to edit cron/qrunner around about line 274, where the LockFile instance is created. Add an argument "withlogging=1" to turn on lock file logging. Then you'd study the log to see if you get any "lock broken" messages. TJ> One more tidbit, I have set the "Action when critical or TJ> excessive bounces are detected" to "Do nothing" So, I do have TJ> a fair number of bogus addresses in my list. My sendmail TJ> queue does get kinda large. I've set it up this way out of TJ> paranoia in maintaining the integrity of the list (IE not TJ> removing valid email addresses). I don't see how that could matter, even if it leaves bogus addresses in your recipient lists. Then again, I'll bet this isn't a well tested option (the bouncer stuff is an area that I haven't had much time to review). Anything's possible, but it's unlikely if none of the log files is indicating errors. BTW, the default setting doesn't delete any bouncing emails from your list -- it just disables them (currently exactly the same as setting "no mail", but probably for 2.1 those will be distinguishable). TJ> OK, I'm bad. I changed them in the Defaults.py file. I tried TJ> to use the mm_cfg.py file, but ran into a problem (was a few TJ> months ago, don't remember what exactly happened). I'd like to know about those, since changing mm_cfg.py is better. Otherwise future upgrades could overwrite your changes. TJ> I've included a copy of my "Defaults.py" and "mm_cfg.py" at TJ> the bottom of this message for reference. I'll take a look. BW> Which DELIVERY_MODULE are you using? TJ> SMTPDirect (would I be better off with Sendmail?) Nope, you're using the right one. BW> Are you running a news gateway? TJ> No. Okay, so it's not fork leakage (and there are fences for that one, but you never know). I'm leaning heavily toward qrunner contention. -Barry From todd@connactivity.connactivity.com Tue Apr 17 04:08:29 2001 From: todd@connactivity.connactivity.com (Todd Joseph) Date: Mon, 16 Apr 2001 23:08:29 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: Your message of "Mon, 16 Apr 2001 20:01:10 EDT." <15067.34758.371357.900173@anthem.wooz.org> Message-ID: <200104170308.f3H38TO02059@connactivity.connactivity.com> BW>Are you running Mailman on an NFS mounted file system? Locking BW>/shouldn't/ be susceptible to NFS issues, but it still isn't a BW>terribly good idea. No -- all local filesystems. BW>Another scenario is that you've cranked up your qrunner process BW>limits, but not appropriatedly adjusted your qrunner lock lifetime. BW>In that case, qrunner could be running for a long time, exceeding the BW>lock lifetime, and allowing a future cron started qrunner to break the BW>still running qrunner's lock. Interesting. I haven't adjusted any of this intentionally. BW>The best way to see if this is happening is to edit cron/qrunner BW>around about line 274, where the LockFile instance is created. Add an BW>argument "withlogging=1" to turn on lock file logging. Then you'd BW>study the log to see if you get any "lock broken" messages. OK, I'll try that. BW> TJ> OK, I'm bad. I changed them in the Defaults.py file. I tried BW> TJ> to use the mm_cfg.py file, but ran into a problem (was a few BW> TJ> months ago, don't remember what exactly happened). BW> BW>I'd like to know about those, since changing mm_cfg.py is better. BW>Otherwise future upgrades could overwrite your changes. I'll letcha know. Thanks for all the help. Todd From barry@digicool.com Tue Apr 17 04:20:29 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Mon, 16 Apr 2001 23:20:29 -0400 Subject: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final References: <15067.34758.371357.900173@anthem.wooz.org> <200104170308.f3H38TO02059@connactivity.connactivity.com> Message-ID: <15067.46717.691410.181512@anthem.wooz.org> >>>>> "TJ" == Todd Joseph writes: TJ> I'll letcha know. TJ> Thanks for all the help. Cool, no problem. -Barry From chuqui@plaidworks.com Tue Apr 17 07:39:41 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 16 Apr 2001 23:39:41 -0700 Subject: [Mailman-Users] Re: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: <15067.34758.371357.900173@anthem.wooz.org> Message-ID: On 4/16/01 5:01 PM, "Barry A. Warsaw" wrote: > Another scenario is that you've cranked up your qrunner process > limits, but not appropriatedly adjusted your qrunner lock lifetime. Or you haven't changed any of the limits, but the time it takes to send a single message exceeds the lock lifetime. If the lock is set for ten hours, and it takes you 12 hours to deliver a really large e-newsletter, for instance, you're hosed. The lock lifetime has to be longer than the longest possible processing time of any single queue item. If you've got 30-40,000 or more subscribers, you could very easily be exceeding that lifetime. > BTW, the default setting doesn't delete any bouncing emails from your > list -- it just disables them (currently exactly the same as setting > "no mail", but probably for 2.1 those will be distinguishable). I'm finding this is confusing a number of my users, so I changed all my lists to deletion. They knew the mail stopped coming, they knew enough to look and found themselves still subscribed, and didn't know what to do. I guess it depends on what list server background you have. If you're familiar with listserv and it's relatives that have nomail, this makes sense. If you're coming from majordomo or have no real mlist experience, I think it's confusing. And I'm not sure if it really buys you much (and when/how do you decide to clean out your subscriber lists?) From tollef@add.no Mon Apr 16 22:37:07 2001 From: tollef@add.no (Tollef Fog Heen) Date: 16 Apr 2001 23:37:07 +0200 Subject: [Mailman-Developers] broken HTML Message-ID: <87bspwzfuk.fsf@arabella.intern.opera.no> It seems to be a small bug in mailman 2.0.3, in Mailman/htmlformat.py, line 281, this _will_ generate broken html like: soci Admindb Results

          Database Updated...

          Administrative requests for mailing list: so Note the double (and first unfinished) If this is still in cvs, somebody please fix. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From jcrey@uma.es Tue Apr 17 11:36:08 2001 From: jcrey@uma.es (Juan Carlos Rey Anaya) Date: Tue, 17 Apr 2001 12:36:08 +0200 Subject: [Mailman-Developers] Multilanguage support in Mailman. References: <3AD449A4.DDD4CB77@cendio.se> Message-ID: <3ADC1C98.BC889D12@uma.es> Conny Andersson wrote: > I'm not sure how to incorporate the changes to > Mailman (I have just made symbolic links in my > setup) but one suggestion could be to have an > option for every user to choose their desired > language. Take a glance to mailman-i18n list and see what to do. Cheers -- = ___ / F \ [[[]]]] ( O O ) #----------------0000--(_)--0000---------------# | Juan Carlos Rey Anaya (jcrey@uma.es) | | Servicio Central de inform=E1tica | | Universidad de M=E1laga - Espa=F1a | #----------------------------------------------# From thomas@xs4all.net Tue Apr 17 14:44:40 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 17 Apr 2001 15:44:40 +0200 Subject: [Mailman-Developers] broken HTML In-Reply-To: <87bspwzfuk.fsf@arabella.intern.opera.no>; from tollef@add.no on Mon, Apr 16, 2001 at 11:37:07PM +0200 References: <87bspwzfuk.fsf@arabella.intern.opera.no> Message-ID: <20010417154440.S2820@xs4all.nl> On Mon, Apr 16, 2001 at 11:37:07PM +0200, Tollef Fog Heen wrote: > It seems to be a small bug in mailman 2.0.3, in Mailman/htmlformat.py, > line 281, this _will_ generate broken html like: > > > soci Admindb Results > > >

          Database Updated...

          Administrative requests for mailing list: so > Note the double (and first unfinished) > If this is still in cvs, somebody please fix. :) Yes, it's still broken. The problem is that the document isn't treated as a 'headless' one, even though the template file treats it as such (it includes its own stuff.) I suggested a fix a few months back (our own webdesign departement ran into the same bug) but Barry rejected it -- I don't recall why. Maybe because he was afraid it'd break too many websites out there. Barry ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From wheakory@isu.edu Tue Apr 17 17:21:33 2001 From: wheakory@isu.edu (Kory Wheatley) Date: Tue, 17 Apr 2001 10:21:33 -0600 Subject: [Mailman-Developers] Mailman Qrunner error Message-ID: <3ADC6D8D.BEB2C27F@isu.edu> I'm receiving this error below which is sent to the Owner of Mailman's email account every minute when the Qrunner cron process runs. Does anyone know what this means. Please respond to wheakory@isu.edu, ( I have over 150 mailman mailing lists that its critical that they function properly). I would greatly appreciate solutions? Traceback (innermost last): File "/home/mailman/cron/qrunner", line 85, in ? from Mailman import MailList ValueError: bad marshal data -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From barry@digicool.com Tue Apr 17 18:01:27 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 17 Apr 2001 13:01:27 -0400 Subject: [Mailman-Developers] Mailman Qrunner error References: <3ADC6D8D.BEB2C27F@isu.edu> Message-ID: <15068.30439.741128.500671@anthem.wooz.org> >>>>> "KW" == Kory Wheatley writes: KW> I'm receiving this error below which is sent to the Owner of KW> Mailman's email account every minute when the Qrunner cron KW> process runs. Does anyone know what this means. Please respond KW> to wheakory@isu.edu, ( I have over 150 mailman mailing lists KW> that its critical that they function properly). I would KW> greatly appreciate solutions? KW> Traceback (innermost last): | File "/home/mailman/cron/qrunner", line 85, in ? | from Mailman import MailList KW> ValueError: bad marshal data Since it's failing on an import, I'd say you have some corrupt .pyc files laying around. Don't know how they got corrupt, but if you remove them and then do "config.status; make install" it should fix them. -Barry From fil@rezo.net Tue Apr 17 20:55:50 2001 From: fil@rezo.net (Fil) Date: Tue, 17 Apr 2001 21:55:50 +0200 Subject: [Mailman-Developers] HandlerAPI ? In-Reply-To: <20010413122928.A13755@orwell.bok.net>; from fil@rezo.net on Fri, Apr 13, 2001 at 12:29:28PM +0200 References: <20010413122928.A13755@orwell.bok.net> Message-ID: <20010417215550.A15255@orwell.bok.net> Hi, what happened to HandlerAPI.py ? It is not there any more in the CVS tree, but it is still called by cron/checkdbs and cron/mailpasswds can someone explain? -- Fil From barry@digicool.com Tue Apr 17 23:21:49 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Tue, 17 Apr 2001 18:21:49 -0400 Subject: [Mailman-Developers] HandlerAPI ? References: <20010413122928.A13755@orwell.bok.net> <20010417215550.A15255@orwell.bok.net> Message-ID: <15068.49661.300774.548080@anthem.wooz.org> >>>>> "F" == Fil writes: F> what happened to HandlerAPI.py ? After the redesign of the qrunner stuff, it was no longer necessary. F> It is not there any more in the CVS tree, but it is still F> called by cron/checkdbs and cron/mailpasswds F> can someone explain? I just haven't gotten around to updating those scripts yet. However, I'll be spending some concentrated time on Mailman over the next few weeks, so I fix those soon. -Barry From Dan Mick Wed Apr 18 02:02:06 2001 From: Dan Mick (Dan Mick) Date: Tue, 17 Apr 2001 18:02:06 -0700 (PDT) Subject: [Mailman-Users] Re: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final Message-ID: <200104180102.SAA28438@utopia.West.Sun.COM> > I guess it depends on what list server background you have. If you're > familiar with listserv and it's relatives that have nomail, this makes > sense. If you're coming from majordomo or have no real mlist experience, I > think it's confusing. And I'm not sure if it really buys you much (and > when/how do you decide to clean out your subscriber lists?) I created a withlist script and a mail template to send reminders to all "nomail" folks, and run it by hand from time to time; I'm not convinced it's better, but it lets me not permanently lose people without giving them a chance to stay less painfully than resubbing. From chuqui@plaidworks.com Wed Apr 18 02:07:11 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 17 Apr 2001 18:07:11 -0700 Subject: [Mailman-Users] Re: [Mailman-Developers] URGENT Please Help: Duplicates with 2.0 final In-Reply-To: <200104180102.SAA28438@utopia.West.Sun.COM> Message-ID: <200104180100.f3I10Bi16719@plaidworks.com> On Tuesday, April 17, 2001, at 06:02 PM, Dan Mick wrote: > I created a withlist script and a mail template to send reminders > to all "nomail" folks, and run it by hand from time to time; > I'm not convinced it's better, but it lets me not permanently > lose people without giving them a chance to stay less painfully than > resubbing. > that's an option -- have you considered adding it to the disto? My problem, though, is that I have a group of users that use nomail as an alternative to email aliases (which we've talked about). So I get to choose how to annoy who -- I tend to think it's better to leave nomail to the users, and either remove users or set up a second flag for system use in disabling users, because otherwise we end up with ambiguous situations. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. When an agnostic dies, does he go to the "great perhaps"? From jonny@dir.bg Wed Apr 18 14:30:32 2001 From: jonny@dir.bg (Vassil ) Date: Wed, 18 Apr 2001 16:30:32 +0300 Subject: [Mailman-Developers] (no subject) Message-ID: Hello! I have a big problem with my video card. It is Nvidia ge Force 2 MX and I can't run Linux with it! What should I do? Is there any way ? ----------------------------- Free mail from www.dir.bg! From Dale@Newfield.org Wed Apr 18 14:32:34 2001 From: Dale@Newfield.org (Dale Newfield) Date: Wed, 18 Apr 2001 09:32:34 -0400 (EDT) Subject: [Mailman-Developers] More moderation? In-Reply-To: <200104180102.SAA28438@utopia.West.Sun.COM> Message-ID: One of the settings that allows moderators to conditionally insert themselves is the max size (default to 40K, I believe). How difficult would it be to include another that holds for moderation any message that includes more excerpted material (lines beginning with >) than a certain percentage of the message? How difficult would it be to also allow the process of moderation to actually modify the message (for example, including a [foo bar baz -Moderator] comment block, or trimming excess cruft that really has nothing to do with the message's content)? I might be willing to do this coding if others agreed these are desirable features... Ooh--since I'm suggesting features I'd like, how 'bout the ability to (on a list-by-list basis) flip a switch that would trim out all HTML code from messages sent to the list? -Dale Newfield From jonny@dir.bg Wed Apr 18 14:32:59 2001 From: jonny@dir.bg (Vassil ) Date: Wed, 18 Apr 2001 16:32:59 +0300 Subject: [Mailman-Developers] (no subject) Message-ID: Hello! I have a big problem with my video card. It is Nvidia ge Force 2 MX and I can't run Linux with it! What should I do? Is there any way ? Please write me to jonny@dir.bg I will be very pleased if you answer me! ----------------------------- Free mail from www.dir.bg! From barry@digicool.com Wed Apr 18 20:12:53 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 18 Apr 2001 15:12:53 -0400 Subject: [Mailman-Developers] ANNOUNCE Mailman 2.0.4 Message-ID: <15069.59189.820989.870483@anthem.wooz.org> --hVjg+bsTAg Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Folks, I've just released Mailman 2.0.4 which is simply a patch release so that Mailman works better with Python 2.1. Mailman 2.0.3 had a few constructs which caused warnings when run with Python 2.1. The unfortunate part is that those warnings could occur in the qrunner process which tended to cause cron to bombard the system administrators with email. If you upgrade your Python to 2.1, you should definitely upgrade to Mailman 2.0.4, otherwise consider it optional. As usual, I'm releasing this as both a complete tarball and as a patch against Mailman 2.0.3. You /must/ update your source to 2.0.3 before applying the 2.0.4 patch. Since the patch is small, I'm including it in this message. To apply, cd into your 2.0.4 source tree and apply it like so: % patch -p0 < mailman-2.0.3-2.0.4.txt Currently both http://mailman.sourceforge.net and http://www.list.org are updated, and I expect the gnu.org site to be updated soon as well. The release information on SF is at http://sourceforge.net/project/shownotes.php?release_id=31693 See also http://www.gnu.org/software/mailman http://www.list.org http://mailman.sourceforge.net Enjoy, -Barry [From the NEWS file] 2.0.4 (18-Apr-2001) Python 2.1 compatibility release. There were a few questionable constructs and uses of deprecated modules that caused annoying warnings when used with Python 2.1. This release quiets those warnings. --hVjg+bsTAg Content-Type: text/plain Content-Disposition: inline; filename="mailman-2.0.3-2.0.4.txt" Content-Transfer-Encoding: 7bit Index: NEWS =================================================================== RCS file: /cvsroot/mailman/mailman/NEWS,v retrieving revision 1.25.2.4 retrieving revision 1.25.2.5 diff -u -r1.25.2.4 -r1.25.2.5 --- NEWS 2001/03/12 19:32:10 1.25.2.4 +++ NEWS 2001/04/18 10:45:54 1.25.2.5 @@ -4,6 +4,13 @@ Here is a history of user visible changes to Mailman. +2.0.4 (18-Apr-2001) + + Python 2.1 compatibility release. There were a few questionable + constructs and uses of deprecated modules that caused annoying + warnings when used with Python 2.1. This release quiets those + warnings. + 2.0.3 (12-Mar-2001) Bug fix release. There was a small typo in 2.0.2 in ListAdmin.py Index: Mailman/HTMLFormatter.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/HTMLFormatter.py,v retrieving revision 1.50 retrieving revision 1.50.2.1 diff -u -r1.50 -r1.50.2.1 --- Mailman/HTMLFormatter.py 2000/09/09 19:13:58 1.50 +++ Mailman/HTMLFormatter.py 2001/04/18 04:33:48 1.50.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# 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 @@ -19,14 +19,14 @@ import os -# XXX: should be converted to use re module -import regsub import string -import mm_cfg -import Utils -from htmlformat import * +import re +from Mailman import mm_cfg +from Mailman import Utils +from Mailman.htmlformat import * + class HTMLFormatter: def InitVars(self): @@ -330,7 +330,7 @@ def ParseTags(self, template, replacements): text = self.SnarfHTMLTemplate(template) - parts = regsub.splitx(text, ']*>') + parts = re.split('(]*>)', text) i = 1 while i < len(parts): tag = string.lower(parts[i]) Index: Mailman/Utils.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Utils.py,v retrieving revision 1.104 retrieving revision 1.104.2.2 diff -u -r1.104 -r1.104.2.2 --- Mailman/Utils.py 2000/11/16 21:43:11 1.104 +++ Mailman/Utils.py 2001/04/18 04:23:07 1.104.2.2 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# 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 @@ -29,8 +29,6 @@ import re from UserDict import UserDict from types import StringType -# XXX: obsolete, should use re module -import regsub import random import urlparse @@ -415,19 +413,8 @@ def QuoteHyperChars(str): - arr = regsub.splitx(str, '[<>"&]') - i = 1 - while i < len(arr): - if arr[i] == '<': - arr[i] = '<' - elif arr[i] == '>': - arr[i] = '>' - elif arr[i] == '"': - arr[i] = '"' - else: #if arr[i] == '&': - arr[i] = '&' - i = i + 2 - return string.join(arr, '') + from cgi import escape + return escape(str, quote=1) Index: Mailman/Version.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v retrieving revision 1.20.2.3 retrieving revision 1.20.2.4 diff -u -r1.20.2.3 -r1.20.2.4 --- Mailman/Version.py 2001/03/07 23:25:41 1.20.2.3 +++ Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 @@ -15,7 +15,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Mailman version -VERSION = "2.0.3" +VERSION = "2.0.4" # And as a hex number in the manner of PY_VERSION_HEX ALPHA = 0xa @@ -27,7 +27,7 @@ MAJOR_REV = 2 MINOR_REV = 0 -MICRO_REV = 3 +MICRO_REV = 4 REL_LEVEL = FINAL # at most 15 beta releases! REL_SERIAL = 0 Index: Mailman/Bouncers/Catchall.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Attic/Catchall.py,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -u -r1.4 -r1.4.2.1 --- Mailman/Bouncers/Catchall.py 2000/08/07 02:34:33 1.4 +++ Mailman/Bouncers/Catchall.py 2001/04/18 04:41:47 1.4.2.1 @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. +# 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 @@ -18,6 +18,16 @@ # implementation of Bouncer.ScanMessage(). We keep it because I don't feel # like splitting it up and porting it. It should at the very least be ported # to use mimetools and re. :( + +# In Python 2.1, the import of regsub causes a DeprecationWarning. This is +# annoying so if we can import the warnings module, we turn off warnings about +# the import of regsub. It's not worth changing the uses of regsub to use the +# re module because Catchall.py is going away in Mailman 2.1. +try: + import warnings + warnings.filterwarnings('ignore', module='regsub') +except ImportError: + pass import re import string Index: admin/www/Makefile =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/Makefile,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- admin/www/Makefile 2000/11/08 18:43:39 1.1 +++ admin/www/Makefile 2001/04/18 10:43:46 1.1.2.1 @@ -1,4 +1,4 @@ -HT2HTML = /home/bwarsaw/projects/ht2html/ht2html.py +HT2HTML = $(HOME)/projects/ht2html/ht2html.py HTSTYLE = MMGenerator HTALLFLAGS = -f -s $(HTSTYLE) Index: admin/www/download.ht =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v retrieving revision 1.5.2.4 retrieving revision 1.5.2.5 diff -u -r1.5.2.4 -r1.5.2.5 --- admin/www/download.ht 2001/03/12 19:33:49 1.5.2.4 +++ admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 @@ -65,9 +65,9 @@

          Downloading

          Version -(2.0.3, +(2.0.4, released on -Mar 12 2001) +Apr 18 2001) is the current GNU release. It is available from the following mirror sites:

            @@ -98,5 +98,3 @@ % gunzip -c mailman.tar.gz | tar xf - -e> -> Index: admin/www/download.html =================================================================== RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v retrieving revision 1.6.2.6 retrieving revision 1.6.2.7 diff -u -r1.6.2.6 -r1.6.2.7 --- admin/www/download.html 2001/03/12 19:33:49 1.6.2.6 +++ admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 @@ -1,6 +1,6 @@ - + 2.0.3, +(2.0.4, released on -Mar 12 2001) +Apr 18 2001) is the current GNU release. It is available from the following mirror sites:
              @@ -270,8 +270,6 @@ % gunzip -c mailman.tar.gz | tar xf - -e> -> Index: cron/qrunner =================================================================== RCS file: /cvsroot/mailman/mailman/cron/qrunner,v retrieving revision 1.18.2.2 retrieving revision 1.18.2.3 diff -u -r1.18.2.2 -r1.18.2.3 --- cron/qrunner 2001/01/03 06:42:11 1.18.2.2 +++ cron/qrunner 2001/04/18 03:58:35 1.18.2.3 @@ -166,8 +166,8 @@ _listcache = {} + def open_list(listname): - global _listcache mlist = _listcache.get(listname) if not mlist: try: @@ -267,7 +267,6 @@ if __name__ == '__main__': - global _listcache ## syslog('qrunner', 'qrunner begining') # first, claim the queue runner lock lock = LockFile.LockFile(QRUNNER_LOCK_FILE, --hVjg+bsTAg-- From dkeller@linkup.com Wed Apr 18 21:04:42 2001 From: dkeller@linkup.com (David Keller) Date: Wed, 18 Apr 2001 15:04:42 -0500 Subject: [Mailman-Developers] remove References: <15069.59189.820989.870483@anthem.wooz.org> Message-ID: <03b001c0c842$cea09100$914447cc@ns1> ----- Original Message ----- From: Barry A. Warsaw To: Cc: ; Sent: Wednesday, April 18, 2001 2:12 PM Subject: [Mailman-Announce] ANNOUNCE Mailman 2.0.4 > > Folks, > > I've just released Mailman 2.0.4 which is simply a patch release so > that Mailman works better with Python 2.1. Mailman 2.0.3 had a few > constructs which caused warnings when run with Python 2.1. The > unfortunate part is that those warnings could occur in the qrunner > process which tended to cause cron to bombard the system > administrators with email. If you upgrade your Python to 2.1, you > should definitely upgrade to Mailman 2.0.4, otherwise consider it > optional. > > As usual, I'm releasing this as both a complete tarball and as a patch > against Mailman 2.0.3. You /must/ update your source to 2.0.3 before > applying the 2.0.4 patch. Since the patch is small, I'm including it > in this message. To apply, cd into your 2.0.4 source tree and apply > it like so: > > % patch -p0 < mailman-2.0.3-2.0.4.txt > > Currently both http://mailman.sourceforge.net and http://www.list.org > are updated, and I expect the gnu.org site to be updated soon as > well. The release information on SF is at > > http://sourceforge.net/project/shownotes.php?release_id=31693 > > See also > > http://www.gnu.org/software/mailman > http://www.list.org > http://mailman.sourceforge.net > > Enjoy, > -Barry > > [From the NEWS file] > > 2.0.4 (18-Apr-2001) > > Python 2.1 compatibility release. There were a few questionable > constructs and uses of deprecated modules that caused annoying > warnings when used with Python 2.1. This release quiets those > warnings. > > ---------------------------------------------------------------------------- ---- > Index: NEWS > =================================================================== > RCS file: /cvsroot/mailman/mailman/NEWS,v > retrieving revision 1.25.2.4 > retrieving revision 1.25.2.5 > diff -u -r1.25.2.4 -r1.25.2.5 > --- NEWS 2001/03/12 19:32:10 1.25.2.4 > +++ NEWS 2001/04/18 10:45:54 1.25.2.5 > @@ -4,6 +4,13 @@ > > Here is a history of user visible changes to Mailman. > > +2.0.4 (18-Apr-2001) > + > + Python 2.1 compatibility release. There were a few questionable > + constructs and uses of deprecated modules that caused annoying > + warnings when used with Python 2.1. This release quiets those > + warnings. > + > 2.0.3 (12-Mar-2001) > > Bug fix release. There was a small typo in 2.0.2 in ListAdmin.py > Index: Mailman/HTMLFormatter.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/HTMLFormatter.py,v > retrieving revision 1.50 > retrieving revision 1.50.2.1 > diff -u -r1.50 -r1.50.2.1 > --- Mailman/HTMLFormatter.py 2000/09/09 19:13:58 1.50 > +++ Mailman/HTMLFormatter.py 2001/04/18 04:33:48 1.50.2.1 > @@ -1,4 +1,4 @@ > -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. > +# 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 > @@ -19,14 +19,14 @@ > > > import os > -# XXX: should be converted to use re module > -import regsub > import string > -import mm_cfg > -import Utils > -from htmlformat import * > +import re > > +from Mailman import mm_cfg > +from Mailman import Utils > +from Mailman.htmlformat import * > > + > > class HTMLFormatter: > def InitVars(self): > @@ -330,7 +330,7 @@ > > def ParseTags(self, template, replacements): > text = self.SnarfHTMLTemplate(template) > - parts = regsub.splitx(text, ']*>') > + parts = re.split('(]*>)', text) > i = 1 > while i < len(parts): > tag = string.lower(parts[i]) > Index: Mailman/Utils.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Utils.py,v > retrieving revision 1.104 > retrieving revision 1.104.2.2 > diff -u -r1.104 -r1.104.2.2 > --- Mailman/Utils.py 2000/11/16 21:43:11 1.104 > +++ Mailman/Utils.py 2001/04/18 04:23:07 1.104.2.2 > @@ -1,4 +1,4 @@ > -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. > +# 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 > @@ -29,8 +29,6 @@ > import re > from UserDict import UserDict > from types import StringType > -# XXX: obsolete, should use re module > -import regsub > import random > import urlparse > > @@ -415,19 +413,8 @@ > > > def QuoteHyperChars(str): > - arr = regsub.splitx(str, '[<>"&]') > - i = 1 > - while i < len(arr): > - if arr[i] == '<': > - arr[i] = '<' > - elif arr[i] == '>': > - arr[i] = '>' > - elif arr[i] == '"': > - arr[i] = '"' > - else: #if arr[i] == '&': > - arr[i] = '&' > - i = i + 2 > - return string.join(arr, '') > + from cgi import escape > + return escape(str, quote=1) > > > > Index: Mailman/Version.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Version.py,v > retrieving revision 1.20.2.3 > retrieving revision 1.20.2.4 > diff -u -r1.20.2.3 -r1.20.2.4 > --- Mailman/Version.py 2001/03/07 23:25:41 1.20.2.3 > +++ Mailman/Version.py 2001/04/18 04:43:29 1.20.2.4 > @@ -15,7 +15,7 @@ > # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > > # Mailman version > -VERSION = "2.0.3" > +VERSION = "2.0.4" > > # And as a hex number in the manner of PY_VERSION_HEX > ALPHA = 0xa > @@ -27,7 +27,7 @@ > > MAJOR_REV = 2 > MINOR_REV = 0 > -MICRO_REV = 3 > +MICRO_REV = 4 > REL_LEVEL = FINAL > # at most 15 beta releases! > REL_SERIAL = 0 > Index: Mailman/Bouncers/Catchall.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Attic/Catchall.py,v > retrieving revision 1.4 > retrieving revision 1.4.2.1 > diff -u -r1.4 -r1.4.2.1 > --- Mailman/Bouncers/Catchall.py 2000/08/07 02:34:33 1.4 > +++ Mailman/Bouncers/Catchall.py 2001/04/18 04:41:47 1.4.2.1 > @@ -1,4 +1,4 @@ > -# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. > +# 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 > @@ -18,6 +18,16 @@ > # implementation of Bouncer.ScanMessage(). We keep it because I don't feel > # like splitting it up and porting it. It should at the very least be ported > # to use mimetools and re. :( > + > +# In Python 2.1, the import of regsub causes a DeprecationWarning. This is > +# annoying so if we can import the warnings module, we turn off warnings about > +# the import of regsub. It's not worth changing the uses of regsub to use the > +# re module because Catchall.py is going away in Mailman 2.1. > +try: > + import warnings > + warnings.filterwarnings('ignore', module='regsub') > +except ImportError: > + pass > > import re > import string > Index: admin/www/Makefile > =================================================================== > RCS file: /cvsroot/mailman/mailman/admin/www/Makefile,v > retrieving revision 1.1 > retrieving revision 1.1.2.1 > diff -u -r1.1 -r1.1.2.1 > --- admin/www/Makefile 2000/11/08 18:43:39 1.1 > +++ admin/www/Makefile 2001/04/18 10:43:46 1.1.2.1 > @@ -1,4 +1,4 @@ > -HT2HTML = /home/bwarsaw/projects/ht2html/ht2html.py > +HT2HTML = $(HOME)/projects/ht2html/ht2html.py > > HTSTYLE = MMGenerator > HTALLFLAGS = -f -s $(HTSTYLE) > Index: admin/www/download.ht > =================================================================== > RCS file: /cvsroot/mailman/mailman/admin/www/download.ht,v > retrieving revision 1.5.2.4 > retrieving revision 1.5.2.5 > diff -u -r1.5.2.4 -r1.5.2.5 > --- admin/www/download.ht 2001/03/12 19:33:49 1.5.2.4 > +++ admin/www/download.ht 2001/04/18 10:44:14 1.5.2.5 > @@ -65,9 +65,9 @@ >

              Downloading

              > >

              Version > -(2.0.3, > +(2.0.4, > released on > -Mar 12 2001) > +Apr 18 2001) > is the current GNU release. It is available from the following mirror sites: > >

                > @@ -98,5 +98,3 @@ > % gunzip -c mailman.tar.gz | tar xf - > > > -e> > -> > Index: admin/www/download.html > =================================================================== > RCS file: /cvsroot/mailman/mailman/admin/www/download.html,v > retrieving revision 1.6.2.6 > retrieving revision 1.6.2.7 > diff -u -r1.6.2.6 -r1.6.2.7 > --- admin/www/download.html 2001/03/12 19:33:49 1.6.2.6 > +++ admin/www/download.html 2001/04/18 10:44:14 1.6.2.7 > @@ -1,6 +1,6 @@ > > > - > + > > > 2.0.3, > +(2.0.4, > released on > -Mar 12 2001) > +Apr 18 2001) > is the current GNU release. It is available from the following mirror sites: > >
                  > @@ -270,8 +270,6 @@ > % gunzip -c mailman.tar.gz | tar xf - > > > -e> > -> > > > > Index: cron/qrunner > =================================================================== > RCS file: /cvsroot/mailman/mailman/cron/qrunner,v > retrieving revision 1.18.2.2 > retrieving revision 1.18.2.3 > diff -u -r1.18.2.2 -r1.18.2.3 > --- cron/qrunner 2001/01/03 06:42:11 1.18.2.2 > +++ cron/qrunner 2001/04/18 03:58:35 1.18.2.3 > @@ -166,8 +166,8 @@ > > > _listcache = {} > + > def open_list(listname): > - global _listcache > mlist = _listcache.get(listname) > if not mlist: > try: > @@ -267,7 +267,6 @@ > > > if __name__ == '__main__': > - global _listcache > ## syslog('qrunner', 'qrunner begining') > # first, claim the queue runner lock > lock = LockFile.LockFile(QRUNNER_LOCK_FILE, > From benwa@ocentrix.com Wed Apr 18 21:04:40 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Wed, 18 Apr 2001 13:04:40 -0700 Subject: [Mailman-Developers] (no subject) Message-ID: <200104182004.f3IK4eP23988@mail.ocentrix.net> I keep on getting duplicates of messages sent to this list. I'm replying to one of them now. I don't get duplicates of all messages just certain ones. Is anyone else getting duplicates of messages? I can put together a list of all of the duplicates I've gotten recently if anyone is interested. -Ben ------- Original Copy ------- >Subject: [Mailman-Developers] (no subject) >Date: 04/18/2001 4:30 PM >From: "Vassil " >To: mailman-developers@python.org >Hello! I have a big problem with my video card. It is Nvidia ge Force 2 >MX and I can't run Linux with it! What should I do? Is there any way ? >----------------------------- >Free mail from www.dir.bg! > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman/listinfo/mailman-developers > From barry@digicool.com Wed Apr 18 21:32:31 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Wed, 18 Apr 2001 16:32:31 -0400 Subject: [Mailman-Developers] (no subject) References: <200104182004.f3IK4eP23988@mail.ocentrix.net> Message-ID: <15069.63967.827105.413516@anthem.wooz.org> >>>>> "BB" == Ben Burnett writes: BB> I can put together a list of all of the duplicates I've gotten BB> recently if anyone is interested. That would be great, but please include all the headers! -Barry From thomas@xs4all.net Thu Apr 19 17:35:36 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Thu, 19 Apr 2001 18:35:36 +0200 Subject: [Mailman-Developers] (no subject) In-Reply-To: <200104182004.f3IK4eP23988@mail.ocentrix.net>; from benwa@ocentrix.net on Wed, Apr 18, 2001 at 01:04:40PM -0700 References: <200104182004.f3IK4eP23988@mail.ocentrix.net> Message-ID: <20010419183536.C15288@xs4all.nl> On Wed, Apr 18, 2001 at 01:04:40PM -0700, Ben Burnett wrote: > I keep on getting duplicates of messages sent to this list. > I'm replying to one of them now. I don't get duplicates of > all messages just certain ones. Is anyone else getting > duplicates of messages? I can put together a list of all of > the duplicates I've gotten recently if anyone is interested. For the record, I did get two mails from this Vassil you quote below, but they are not duplicates -- one of them has some lines the other does not. Are you sure they are dups ? :) > ------- Original Copy ------- > >Subject: [Mailman-Developers] (no subject) > >Date: 04/18/2001 4:30 PM > >From: "Vassil " > >To: mailman-developers@python.org > > >Hello! I have a big problem with my video card. It is > Nvidia ge Force 2 > >MX and I can't run Linux with it! What should I do? Is > there any way ? > >----------------------------- > >Free mail from www.dir.bg! > > > >_______________________________________________ > >Mailman-Developers mailing list > >Mailman-Developers@python.org > >http://mail.python.org/mailman/listinfo/mailman-developers > > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From benwa@ocentrix.com Thu Apr 19 20:12:38 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 19 Apr 2001 12:12:38 -0700 Subject: [Mailman-Developers] (no subject) In-Reply-To: <20010419183536.C15288@xs4all.nl> References: <200104182004.f3IK4eP23988@mail.ocentrix.net> <200104182004.f3IK4eP23988@mail.ocentrix.net> Message-ID: <5.0.2.1.0.20010419120549.02279a40@mail.ocentrix.com> At 06:35 PM 4/19/01 +0200, Thomas Wouters wrote: >For the record, I did get two mails from this Vassil you quote below, but >they are not duplicates -- one of them has some lines the other does not. >Are you sure they are dups ? :) Yeah I noticed the same thing just before I went to bed last night. They weren't dupes after all, but I still think I've gotten duplicates of other messages. I won't be able to verify this until I get back to the office on monday. - Ben From claw@kanga.nu Thu Apr 26 09:03:01 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 26 Apr 2001 01:03:01 -0700 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) Message-ID: <5063.988272181@kanga.nu> >To: IETF-Announce: ; >Subject: RFC 2919 on List-Id >Cc: rfc-ed@ISI.EDU >Date: Tue, 24 Apr 2001 16:50:44 -0700 >From: RFC Editor > > > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2919 > > Title: List-Id: A Structured Field and Namespace for the > Identification of Mailing Lists > Author(s): R. Chandhok, G. Wenger > Status: Standards Track > Date: March 2001 > Mailbox: chandhok@within.com, wenger@within.com > Pages: 9 > Characters: 18480 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-chandhok-listid-04.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc2919.txt > > >Software that handles electronic mailing list messages (servers >and user agents) needs a way to reliably identify messages that >belong to a particular mailing list. With the advent of list >management headers, it has become even more important >to provide a unique identifier for a mailing list regardless of >the particular host that serves as the list processor at any >given time. > >The List-Id header provides a standard location for such an >identifier. In addition, a namespace for list identifiers >based on fully qualified domain names is described. This >namespace is intended to guarantee uniqueness for list owners >who require it, while allowing for a less rigorous namespace >for experimental and personal use. > >By including the List-Id field, list servers can make it easier >for mail clients to provide automated tools for users to >perform list functions. The list identifier can serve as a key >to make many automated processing tasks easier, and hence more >widely available. > >This is now a Proposed Standard Protocol. > >This document specifies an Internet standards track protocol for >the Internet community, and requests discussion and suggestions >for improvements. Please refer to the current edition of the >"Internet Official Protocol Standards" (STD 1) for the >standardization state and status of this protocol. Distribution >of this memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From jra@baylink.com Thu Apr 26 14:59:36 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 26 Apr 2001 09:59:36 -0400 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) In-Reply-To: <5063.988272181@kanga.nu>; from J C Lawrence on Thu, Apr 26, 2001 at 01:03:01AM -0700 References: <5063.988272181@kanga.nu> Message-ID: <20010426095936.03011@scfn.thpl.lib.fl.us> On Thu, Apr 26, 2001 at 01:03:01AM -0700, J C Lawrence wrote: > >A new Request for Comments is now available in online RFC libraries. > > RFC 2919 > > Title: List-Id: A Structured Field and Namespace for the > > Identification of Mailing Lists What, you're crossing *this* one, and you didn't cross RFC 2821 and RFC 2822? :-) Yes, Barry; those are what the numbers might suggest they are: I hope 2822 includes the stuff from son-of-1036, but I haven't read it yet. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 From barry@digicool.com Thu Apr 26 19:42:40 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 26 Apr 2001 14:42:40 -0400 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) References: <5063.988272181@kanga.nu> <20010426095936.03011@scfn.thpl.lib.fl.us> Message-ID: <15080.27680.803387.778959@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> What, you're crossing *this* one, and you didn't cross RFC JRA> 2821 and RFC 2822? :-) JRA> Yes, Barry; those are what the numbers might suggest they JRA> are: I hope 2822 includes the stuff from son-of-1036, but I JRA> haven't read it yet. Being a regular /. reader, I was aware of 2821 and 2822's release, but I actually hadn't heard about 2919. And yes, I'll be reading all those to see how best to support them in Mailman. ;) -Barry From claw@2wire.com Thu Apr 26 22:41:37 2001 From: claw@2wire.com (J C Lawrence) Date: Thu, 26 Apr 2001 14:41:37 -0700 Subject: [Mailman-Developers] RFC 2919 on List-Id (fwd) In-Reply-To: Message from "Jay R. Ashworth" of "Thu, 26 Apr 2001 09:59:36 EDT." <20010426095936.03011@scfn.thpl.lib.fl.us> References: <5063.988272181@kanga.nu> <20010426095936.03011@scfn.thpl.lib.fl.us> Message-ID: <13650.988321297@2wire.com> On Thu, 26 Apr 2001 09:59:36 -0400 Jay R Ashworth wrote: > On Thu, Apr 26, 2001 at 01:03:01AM -0700, J C Lawrence wrote: >>> A new Request for Comments is now available in online RFC >>> libraries. > What, you're crossing *this* one, and you didn't cross RFC 2821 > and RFC 2822? :-) Yup, There's not that much actually new in 2821 and 2822. 2919 is actually *new*. -- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- From greg@mad-scientist.com Thu Apr 26 23:27:07 2001 From: greg@mad-scientist.com (Gregory P . Smith) Date: Thu, 26 Apr 2001 15:27:07 -0700 Subject: [Mailman-Developers] syncmail - patch to handle filenames with spaces Message-ID: <20010426152707.A22902@mad-scientist.com> --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This qualifies as a hack in my book, but it works well for our repository. I modified an unknown version of the python syncmail script on our CVS server to properly deal with filenames in the cvs repository that have spaces in them. Attached are the patch against our previous version of syncmail and an actual copy of our whole syncmail script (since it has no obvious version numbers, etc). Why send this here? A friend pointed me to the mailman project as being the maintainers of the python syncmail script. I hope he's right (i didn't see anything obvious mentioning such on the webpage). Previously the version of syncmail we used would send emails saying "***** Broken: Foo no such file" instead of showing the diff of the file named 'Foo goes to the bar' (ie: a filename with evil spaces in it). With this it works with spaces. enjoy or ignore, Greg --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="syncmail-filespaces.patch" Index: syncmail =================================================================== RCS file: /cvsroot/CVSROOT/syncmail,v retrieving revision 1.1 retrieving revision 1.6 diff -u -C5 -r1.1 -r1.6 *** syncmail 2000/09/09 16:36:36 1.1 --- syncmail 2001/04/26 19:05:13 1.6 *************** *** 92,102 **** elif newrev == 'NONE': lines = ['--- %s DELETED ---\n' % file] else: # This /has/ to happen in the background, otherwise we'll run into CVS # lock contention. What a crock. ! diffcmd = '/usr/bin/cvs -f diff -kk -C 2 -r %s -r %s %s' % ( oldrev, newrev, file) fp = os.popen(diffcmd) lines = fp.readlines() sts = fp.close() # ignore the error code, it always seems to be 1 :( --- 92,102 ---- elif newrev == 'NONE': lines = ['--- %s DELETED ---\n' % file] else: # This /has/ to happen in the background, otherwise we'll run into CVS # lock contention. What a crock. ! diffcmd = '/usr/bin/cvs -f diff -kk -C 2 -r %s -r %s "%s"' % ( oldrev, newrev, file) fp = os.popen(diffcmd) lines = fp.readlines() sts = fp.close() # ignore the error code, it always seems to be 1 :( *************** *** 166,176 **** print 'Mailing %s...' % PEOPLE if specs == ['-', 'Imported', 'sources']: return if specs[-3:] == ['-', 'New', 'directory']: del specs[-3:] ! blast_mail(mailcmd, specs[1:]) if __name__ == '__main__': print 'Running syncmail...' --- 166,200 ---- print 'Mailing %s...' % PEOPLE if specs == ['-', 'Imported', 'sources']: return if specs[-3:] == ['-', 'New', 'directory']: del specs[-3:] ! ! # hack to try and deal with filenames containing spaces -greg@electricrain dot com ! files = specs[1:] ! realfiles = [] ! i = 0 ! while i < len(files): ! # the parameters are all 'filename,ver1,ver2' so just put ones in the realfiles list ! # that have ,s in them. (XXX this will break down if your actual names include commas ! # and spaces you bumbling mangled file name morons out there) ! if string.find(files[i], ',') == -1: ! j = i + 1 ! t = files[i] ! while j < len(files): ! t = t + ' ' + files[j] ! if string.find(files[j], ',') != -1: ! realfiles.append(t) ! i = j ! break ! j = j + 1 ! else: ! realfiles.append(files[i]) ! i = i + 1 ! ! #print 'XXX blast mail:', `realfiles`, '(being debugged)' ! blast_mail(mailcmd, realfiles) if __name__ == '__main__': print 'Running syncmail...' --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=syncmail #! /usr/bin/python # -*- Python -*- """Complicated notification for CVS checkins. This script is used to provide email notifications of changes to the CVS repository. These email changes will include context diffs of the changes. Really big diffs will be trimmed. This script is run from a CVS loginfo file (see $CVSROOT/CVSROOT/loginfo). To set this up, create a loginfo entry that looks something like this: mymodule /path/to/syncmail %%s some-email-addr@your.domain In this example, whenever a checkin that matches `mymodule' is made, the syncmail script is invoked, which will generate the diff containing email, and send it to some-email-addr@your.domain. Note: This module used to also do repository synchronizations via rsync-over-ssh, but since the repository has been moved to SourceForge, this is no longer necessary. The syncing functionality has been ripped out in the 3.0, which simplifies it considerably. Access the 2.x versions to refer to this functionality. Because of this, the script's name is misleading. It no longer makes sense to run this script from the command line. Doing so will only print out this usage information. Usage: syncmail [options] <%%S> email-addr [email-addr ...] Where options is: --cvsroot= Use as the environment variable CVSROOT. Otherwise this variable must exist in the environment. --help -h Print this text. <%%S> CVS %%s loginfo expansion. When invoked by CVS, this will be a single string containing the directory the checkin is being made in, relative to $CVSROOT, followed by the list of files that are changing. If the %%s in the loginfo file is %%{sVv}, context diffs for each of the modified files are included in any email messages that are generated. email-addrs At least one email address. """ import os import sys import string import time import getopt # Notification command MAILCMD = '/bin/mail -s "CVS: %(SUBJECT)s" %(PEOPLE)s 2>&1 > /dev/null' # Diff trimming stuff DIFF_HEAD_LINES = 20 DIFF_TAIL_LINES = 20 DIFF_TRUNCATE_IF_LARGER = 1000 def usage(errcode, msg=''): print __doc__ % globals() if msg: print msg sys.exit(errorcode) def calculate_diff(filespec): try: file, oldrev, newrev = string.split(filespec, ',') except ValueError: # No diff to report return '***** Bogus filespec: %s' % filespec if oldrev == 'NONE': try: fp = open(file) lines = fp.readlines() fp.close() lines.insert(0, '--- NEW FILE ---\n') except IOError, e: lines = ['***** Error reading new file: ', str(e)] elif newrev == 'NONE': lines = ['--- %s DELETED ---\n' % file] else: # This /has/ to happen in the background, otherwise we'll run into CVS # lock contention. What a crock. diffcmd = '/usr/bin/cvs -f diff -kk -C 2 -r %s -r %s "%s"' % ( oldrev, newrev, file) fp = os.popen(diffcmd) lines = fp.readlines() sts = fp.close() # ignore the error code, it always seems to be 1 :( ## if sts: ## return 'Error code %d occurred during diff\n' % (sts >> 8) if len(lines) > DIFF_TRUNCATE_IF_LARGER: removedlines = len(lines) - DIFF_HEAD_LINES - DIFF_TAIL_LINES del lines[DIFF_HEAD_LINES:-DIFF_TAIL_LINES] lines.insert(DIFF_HEAD_LINES, '[...%d lines suppressed...]\n' % removedlines) return string.join(lines, '') def blast_mail(mailcmd, filestodiff): # cannot wait for child process or that will cause parent to retain cvs # lock for too long. Urg! if not os.fork(): # in the child # give up the lock you cvs thang! time.sleep(2) fp = os.popen(mailcmd, 'w') fp.write(sys.stdin.read()) fp.write('\n') # append the diffs if available for file in filestodiff: fp.write(calculate_diff(file)) fp.write('\n') fp.close() # doesn't matter what code we return, it isn't waited on os._exit(0) # scan args for options def main(): try: opts, args = getopt.getopt(sys.argv[1:], 'h', ['cvsroot=', 'help']) except getopt.error, msg: usage(1, msg) # parse the options for opt, arg in opts: if opt in ('-h', '--help'): usage(0) elif opt == '--cvsroot': os.environ['CVSROOT'] = arg # What follows is the specification containing the files that were # modified. The argument actually must be split, with the first component # containing the directory the checkin is being made in, relative to # $CVSROOT, followed by the list of files that are changing. if not args: usage(1, 'No CVS module specified') SUBJECT = args[0] specs = string.split(args[0]) del args[0] # The remaining args should be the email addresses if not args: usage(1, 'No recipients specified') # Now do the mail command PEOPLE = string.join(args) mailcmd = MAILCMD % vars() print 'Mailing %s...' % PEOPLE if specs == ['-', 'Imported', 'sources']: return if specs[-3:] == ['-', 'New', 'directory']: del specs[-3:] # hack to try and deal with filenames containing spaces -greg@electricrain dot com files = specs[1:] realfiles = [] i = 0 while i < len(files): # the parameters are all 'filename,ver1,ver2' so just put ones in the realfiles list # that have ,s in them. (XXX this will break down if your actual names include commas # and spaces you bumbling mangled file name morons out there) if string.find(files[i], ',') == -1: j = i + 1 t = files[i] while j < len(files): t = t + ' ' + files[j] if string.find(files[j], ',') != -1: realfiles.append(t) i = j break j = j + 1 else: realfiles.append(files[i]) i = i + 1 #print 'XXX blast mail:', `realfiles`, '(being debugged)' blast_mail(mailcmd, realfiles) if __name__ == '__main__': print 'Running syncmail...' main() print '...syncmail done.' sys.exit(0) --FCuugMFkClbJLl1L-- From barry@digicool.com Fri Apr 27 03:43:27 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 26 Apr 2001 22:43:27 -0400 Subject: [Mailman-Developers] ANNOUNCE mimelib 0.3 Message-ID: <15080.56527.608668.936637@anthem.wooz.org> I've finally moved mimelib development to SourceForge, and uploaded version 0.3. mimelib is yet another MIME and RFC 2822 message handling library for Python. It differs from older modules and packages by providing an abstract MIME object model separate from parsing and generating the plain text representations. There is a parser class to convert from plain text to the model, and a generator class to output plain text from the model. Along the way, the object model can be manipulated in very Pythonic ways (or you can generate an entire model from scratch using the provided message classes). mimelib is compatible with Python 2.x. My goal is to solidify the API and implementation enough for inclusion of mimelib in Python 2.2. mimelib 0.3 is required for the current CVS snapshot of Mailman 2.1 alpha. For online documentation, see http://mimelib.sourceforge.net For project information, see http://sourceforge.net/projects/mimelib For downloading mimelib-0.3.tar.gz, see http://sourceforge.net/project/showfiles.php?group_id=25568 And of course, there's a mailing list for developers Postings: mimelib-devel@lists.sourceforge.net Subscribe: http://lists.sourceforge.net/lists/listinfo/mimelib-devel Enjoy, -Barry From barry@digicool.com Fri Apr 27 03:52:58 2001 From: barry@digicool.com (Barry A. Warsaw) Date: Thu, 26 Apr 2001 22:52:58 -0400 Subject: [Mailman-Developers] syncmail - patch to handle filenames with spaces References: <20010426152707.A22902@mad-scientist.com> Message-ID: <15080.57098.235427.364490@anthem.wooz.org> >>>>> "GP" == Gregory P writes: GP> This qualifies as a hack in my book, but it works well for our GP> repository. I modified an unknown version of the python GP> syncmail script on our CVS server to properly deal with GP> filenames in the cvs repository that have spaces in them. GP> Attached are the patch against our previous version of GP> syncmail and an actual copy of our whole syncmail script GP> (since it has no obvious version numbers, etc). GP> Why send this here? A friend pointed me to the mailman GP> project as being the maintainers of the python syncmail GP> script. I hope he's right (i didn't see anything obvious GP> mentioning such on the webpage). GP> Previously the version of syncmail we used would send emails GP> saying "***** Broken: Foo no such file" instead of showing the GP> diff of the file named 'Foo goes to the bar' (ie: a filename GP> with evil spaces in it). With this it works with spaces. Greg, Thanks for the new syncmail script. Actually syncmail is used by the Mailman project, the Python project, (and momentarily, the mimelib project). It's probably also still used by the Jython project. So there are versions in each of those project's CVSROOTs, as well as a version in the Python snippets section of the SF Python Foundary. Between all those, I've found at least 4 different revisions of syncmail! I think the latest one is version 3.16 that Fred Drake hacked last. I'll try to take some time to synchronize all these versions, and upload the merge to the Python snippets (and Mailman and mimelib projects). Again, thanks, -Barry From ralf.laue@virbus.de Fri Apr 27 15:01:37 2001 From: ralf.laue@virbus.de (Ralf Laue) Date: Fri, 27 Apr 2001 16:01:37 +0200 Subject: [Mailman-Developers] Patch: ignoring (no subject) in the subject line of a administrative request Message-ID: <3AE97BC1.DBF9D4CB@virbus.de> Just a simple but useful patch: If someone sends an administrative request to the -request address, he or she may leave the subject line empty, writing the commands(s) in the body of the message. Netscape and other mailers suggest a default subject "(no subject)", and the sender will get an error report because (no subject) is no valid command. Best Wishes, Ralf diff /usr/local/mailman/Mailman/MailCommandHandler.py /usr/src/mailman-2.0.3/Mailman/MailCommandHandler.py 132,134d131 < # ignoring (no subject) in the subject line of a administrative request < if subject == "(no subject)" or subject == "(No Subject)" < subject = "" From Dale@Newfield.org Fri Apr 27 15:03:05 2001 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 27 Apr 2001 10:03:05 -0400 (EDT) Subject: [Mailman-Developers] Small nntp server? In-Reply-To: <15080.56527.608668.936637@anthem.wooz.org> Message-ID: I'm looking to utilize Mailman's Mail-News and News-Mail gateways, but I'm really not interested in serving any other newsgroups, and I don't particularly need to push these news articles upstream to anyplace. (And I don't want to worry about propogation to subscribers sites, or net-wide spam, so I think I'd like to serve it all from our box.) Does anyone have a (free?) unix based nntp server they'd suggest that can be configured to be stand-alone (no pushing upstream or downstream), and would handle 10's of local newsgroups and ~1000 subscribers reasonably well? We're running a FreeBSD box if that matters. -Dale Newfield webmaster@wunderland.com From bart@jukie.net Sat Apr 28 02:04:04 2001 From: bart@jukie.net (Bart Trojanowski) Date: Fri, 27 Apr 2001 21:04:04 -0400 (EDT) Subject: [Mailman-Developers] [PATCH] add message counters to Subject line Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-1374547809-988419618=:20596 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: [ I am not on the list so please leave me in the CC on this thread ] After doing this 'patch' you can specify a single %d anywhere in subject_prefix (ie the 'Prefix for subject line of list postings') and it will be magically replaced to the post_id (ie the message index). BTW, where is the post_id stored? Can I updated it from the command line with some (less)? standard tool? I have tested with formats of type '[LIST (%d)]' for subject_prefix. I would not be surprised if some strange formats may screw up my regular expresions... today is my first day writing Python :) Ex: Say you have a list with subject_prefix set to '[LIST (%d)]' The first post will have a subject of: Subject: [LIST (1)] the real subject line The reply to this will hold: Subject: Re: [LIST (2)] the real subject line The reply to that will hold: Subject: Re: [LIST (3)] the real subject line And so on. Regards, Bart. -- WebSig: http://www.jukie.net/~bart/sig/ --8323328-1374547809-988419618=:20596 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="CookHeaders.py.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="CookHeaders.py.patch" LS0tIENvb2tIZWFkZXJzLnB5LQlGcmkgQXByIDI3IDIwOjU4OjMyIDIwMDEN CisrKyBDb29rSGVhZGVycy5weQlGcmkgQXByIDI3IDIwOjU5OjA3IDIwMDEN CkBAIC00NywxMyArNDcsMjAgQEANCiAgICAgICAgICMgc3VjaCBhcyB0aGUg bGlzdCBhZG1pbikuICBXZSBhc3N1bWUgYWxsIGRpZ2VzdHMgaGF2ZSBhbiBh cHByb3ByaWF0ZQ0KICAgICAgICAgIyBzdWJqZWN0IGhlYWRlciBhZGRlZCBi eSB0aGUgVG9EaWdlc3QgbW9kdWxlLg0KICAgICAgICAgcHJlZml4ID0gbWxp c3Quc3ViamVjdF9wcmVmaXgNCisgICAgICAgIG1wcmVmaXggPSByZS5lc2Nh cGUocHJlZml4KQ0KKyAgICAgICAgaWYgcHJlZml4IGFuZCByZS5zZWFyY2go cmUuZXNjYXBlKCclZCcpLCBwcmVmaXgsIHJlLkkpOg0KKyAgICAgICAgICAg IG1hdGNoID0gcmUubWF0Y2gociJeKC4qKSIrcmUuZXNjYXBlKCIlZCIpKyIo LiopJCIsIHByZWZpeCkNCisgICAgICAgICAgICBpZiBtYXRjaDoNCisgICAg ICAgICAgICAgICAgbXByZWZpeCA9IHJlLmVzY2FwZShtYXRjaC5ncm91cCgx KSkrIlxkKyIrcmUuZXNjYXBlKG1hdGNoLmdyb3VwJCAgICAgICAgICAgIHBy ZWZpeCA9IHByZWZpeCAlIG1saXN0LnBvc3RfaWQNCiAgICAgICAgICMgV2Ug cHVycG9zZWZ1bGx5IGxlYXZlIG5vIHNwYWNlIGIvdyBwcmVmaXggYW5kIHN1 YmplY3QhDQogICAgICAgICBpZiBub3Qgc3ViamVjdDoNCi0gICAgICAgICAg ICBkZWwgbXNnWydzdWJqZWN0J10NCi0gICAgICAgICAgICBtc2dbJ1N1Ympl Y3QnXSA9IHByZWZpeCArIF8oJyhubyBzdWJqZWN0KScpDQotICAgICAgICBl bGlmIHByZWZpeCBhbmQgbm90IHJlLnNlYXJjaChyZS5lc2NhcGUocHJlZml4 KSwgc3ViamVjdCwgcmUuSSk6DQotICAgICAgICAgICAgZGVsIG1zZ1snc3Vi amVjdCddDQotICAgICAgICAgICAgbXNnWydTdWJqZWN0J10gPSBwcmVmaXgg KyBzdWJqZWN0DQorICAgICAgICAgICAgbXNnWydTdWJqZWN0J10gPSBwcmVm aXggKyAnKG5vIHN1YmplY3QpJw0KKyAgICAgICAgZWxpZiBwcmVmaXg6DQor ICAgICAgICAgICAgbWF0Y2ggPSByZS5tYXRjaChyIl4oLiopIittcHJlZml4 KyIoLiopJCIsIHN1YmplY3QpDQorICAgICAgICAgICAgaWYgbWF0Y2g6DQor ICAgICAgICAgICAgICAgIG1zZ1snU3ViamVjdCddID0gbWF0Y2guZ3JvdXAo MSkgKyBwcmVmaXggKyBtYXRjaC5ncm91cCgyKQ0KKyAgICAgICAgICAgIGVs c2U6DQorICAgICAgICAgICAgICAgIG1zZ1snU3ViamVjdCddID0gcHJlZml4 ICsgc3ViamVjdA0KICAgICAjDQogICAgICMgZ2V0IHJpZCBvZiBkdXBsaWNh dGUgaGVhZGVycw0KICAgICBkZWwgbXNnWydzZW5kZXInXQ0K --8323328-1374547809-988419618=:20596-- From ricardo@rixhq.nu Sat Apr 28 11:33:24 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 28 Apr 2001 12:33:24 +0200 Subject: [Mailman-Developers] empty digests Message-ID: <20010428123324.A1102@rix.rixhq.nu> Hi, Last night I had to change all subscribers to one of my lists to a digest version. I used bin/withlist -l in interactive mode and gave the following python commands: all = m.GetMembers() for member in all: m.SetUserDigest(member, 1, force=1) This took a really long time (1635 regular subscribers) and after about 20 minutes I decided to press Ctrl-C cause I was afraid it hung somewhow... this means I wasn't able to do a m.Save() but after checking the number of subscriber was reduced to about 60 so appearantly it did work out... After that I decided to rerun the commands again and this time I waited untill it was finished and did a m.Save() Anyway my point is that now I'm getting some complaints from members about receiving empty digests (it only says the number of posts which should be in there) I'm not sure yet what they are missing but I was wondering if I could have messed things about by interrupting the process w/o a m.Save()? When I look up the subscription options for one of the members who complained I don't see anything weird in there... -- Regards, Ricardo From ricardo@rixhq.nu Sat Apr 28 12:23:41 2001 From: ricardo@rixhq.nu (Ricardo Kustner) Date: Sat, 28 Apr 2001 13:23:41 +0200 Subject: [Mailman-Developers] empty digests In-Reply-To: <20010428123324.A1102@rix.rixhq.nu>; from ricardo@rixhq.nu on Sat, Apr 28, 2001 at 12:33:24PM +0200 References: <20010428123324.A1102@rix.rixhq.nu> Message-ID: <20010428132341.C1102@rix.rixhq.nu> On Sat, Apr 28, 2001 at 12:33:24PM +0200, Ricardo Kustner wrote: > Anyway my point is that now I'm getting some complaints from members about > receiving empty digests (it only says the number of posts which should be in > there) I'm not sure yet what they are missing but I was wondering if I > could have messed things about by interrupting the process w/o a m.Save()? uh oh please don't tell me that when mailman sends out digests, they travel through the /etc/aliases addresses cause that would mean a neat little perl script I use filters out the MIME digests... :( [I really need this script to keep the digests clean from garbage)... hmm on the other hand it could also be that the digests are handled directly by qrunner so they won't go through the filter so that wouldn't explain the problems... Regards, Ricardo From wilane@MINT.SN Sun Apr 29 20:12:29 2001 From: wilane@MINT.SN (Ousmane Wilane) Date: Sun, 29 Apr 2001 19:12:29 +0000 (GMT) Subject: [Mailman-Developers] 2006 archives already online! In-Reply-To: Message-ID: Hi, Take a look at the Mailman-dev archives page, we have a 2006-April line there with only one message. Perhaps I'm missing sth! Kind regars. W. O. From tollef@add.no Mon Apr 30 16:59:14 2001 From: tollef@add.no (Tollef Fog Heen) Date: 30 Apr 2001 17:59:14 +0200 Subject: [Mailman-Developers] small fix for admindb.py Message-ID: <87hez6750t.fsf@arabella.intern.opera.no> It seems like admindb.py doesn't escape the body of html emails properly, which can make it impossible to do anything to the post. This patch should fix it. --- mailman/Mailman/Cgi/admindb.py~ Mon Apr 30 17:53:15 2001 +++ mailman/Mailman/Cgi/admindb.py Mon Apr 30 17:56:09 2001 @@ -228,7 +228,7 @@ row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() t.AddCellInfo(row, col-1, align='right') t.AddRow([Bold('Message Excerpt:'), - TextArea('fulltext-%d' % id, text, rows=10, cols=80)]) + TextArea('fulltext-%d' % id, cgi.escape(text), rows=10, cols=80)]) t.AddCellInfo(row+1, col-1, align='right') form.AddItem(t) form.AddItem('

                  ') -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. From bbum@CODEFAB.COM Mon Apr 30 17:27:56 2001 From: bbum@CODEFAB.COM (Bill Bumgarner) Date: Mon, 30 Apr 2001 12:27:56 -0400 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: Message-ID: <200104301627.f3UGRuW78079@pi.codefab.com> This appears to be a fairly common problem; I suspect that MailMan is using a header to set the date and some folks have their client set to preposterous dates. See: http://www.omnigroup.com/mailman/archive/webobjects-dev/ The above is from a mailing list managed with 2.0b3. b.bum On Monday, April 30, 2001, at 12:02 PM, mailman-developers- request@python.org wrote: > Date: Sun, 29 Apr 2001 19:12:29 +0000 (GMT) > From: Ousmane Wilane > To: > Subject: [Mailman-Developers] 2006 archives already online! > > Hi, > Take a look at the Mailman-dev archives page, we have a 2006-April > line there with only one message. Perhaps I'm missing sth! > Kind regars. > > W. O. From darrell@grumblesmurf.net Mon Apr 30 18:23:35 2001 From: darrell@grumblesmurf.net (Darrell Fuhriman) Date: 30 Apr 2001 10:23:35 -0700 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: Bill Bumgarner's message of "Mon, 30 Apr 2001 12:27:56 -0400" References: <200104301627.f3UGRuW78079@pi.codefab.com> Message-ID: Bill Bumgarner writes: > This appears to be a fairly common problem; I suspect that > MailMan is using a header to set the date and some folks have > their client set to preposterous dates. See: That's why under "archival options" you'll find: "Set date in archive to when the mail is claimed to have been sent, or to the time we resend it?" If you leave it on 'when sent', you deserve the mess you'll get in your archives. Darrell From fil@rezo.net Mon Apr 30 20:28:51 2001 From: fil@rezo.net (Fil) Date: Mon, 30 Apr 2001 21:28:51 +0200 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: ; from darrell@grumblesmurf.net on Mon, Apr 30, 2001 at 10:23:35AM -0700 References: <200104301627.f3UGRuW78079@pi.codefab.com> Message-ID: <20010430212851.A5097@orwell.bok.net> @ Darrell Fuhriman (darrell@grumblesmurf.net) : > That's why under "archival options" you'll find: > > "Set date in archive to when the mail is claimed to have been > sent, or to the time we resend it?" > > If you leave it on 'when sent', you deserve the mess you'll get > in your archives. "When sent" is the default. How do you change the default to "When Resent"? Shouldn't it be changed in the mailman's Defaults.py ? -- Fil From marc_news@valinux.com Mon Apr 30 23:41:46 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 30 Apr 2001 15:41:46 -0700 Subject: [Mailman-Developers] Re: 2006 archives already online! In-Reply-To: <20010430212851.A5097@orwell.bok.net>; from fil@rezo.net on Mon, Apr 30, 2001 at 09:28:51PM +0200 References: <200104301627.f3UGRuW78079@pi.codefab.com> <20010430212851.A5097@orwell.bok.net> Message-ID: <20010430154146.C32211@magic.merlins.org> On Mon, Apr 30, 2001 at 09:28:51PM +0200, Fil wrote: > @ Darrell Fuhriman (darrell@grumblesmurf.net) : > > That's why under "archival options" you'll find: > > > > "Set date in archive to when the mail is claimed to have been > > sent, or to the time we resend it?" > > > > If you leave it on 'when sent', you deserve the mess you'll get > > in your archives. > > "When sent" is the default. How do you change the default to "When Resent"? > Shouldn't it be changed in the mailman's Defaults.py ? I very firmly believe this, and so do all the people who have archives showing messages with dates of 2004 or 1990. http://lists.svlug.org/pipermail/svlug/ I've asked the same thing in the past, but it didn't go through. Please? :-) 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 jj-list@mail.dk Mon Apr 30 23:54:39 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Tue, 01 May 2001 00:54:39 +0200 Subject: [Mailman-Developers] Delivering messages to scripts/post Message-ID: <5.1.0.14.0.20010430234057.04a6a008@wheresmymailserver.com> We have been running Mailman on Windows for about two weeks now and most things seem to work very well. To make it run I had to make some changes - all of them minor - and most of them related to opening files ('b'). Mailmanwin (as I have named it) is probably not useful for anyone but me (and my company) right now; some things do not work at all (web interface, e-mail archive, usenet gateway, all the bin scripts) and some things are changed to make them better fit my needs. I have made an "install" script doing all the work and describing all the changes, so it's fairly easy getting started. I hope to get a webpage up with these things soon. I don't expect the mailman developers to take account of any of these changes. I fully understand and respect that this is a Linux project and would hate if cross platform issues in any way affected the future direction of Mailman. Having said that, it would be nice if no module names conflicted with modules in the standard Python distribution (mailbox) ;) On to the questions. 1. Delivering messages to scripts/post I could not find any MTA for Windows (I didn't look much, though) that was able to get the toaddr and deliver the message to scripts/post. Instead we are using L-soft LSMTP (we used L-soft LISTSERV before changing to Mailman). LSMTP is told to save all messages (complete with all envelope header information) and I have made a Python script that parses each message and calls Enqueu with the correct parameters. This works well, except that we have had a couple of mail loops because of auto-responders replying directly to the list. So my question is, what information does a MTA look for before passing the message to post? I found out that filtering out all messages with daemon and/or postmaster in the fromaddr is a good idea. Are there any other "keywords" that i should know of? 2. Empty envelope fromaddr In some messages the envelope fromaddr is empty. Is it safe to never deliver a message with an empty envelope fromaddr to a list? 3. Using the envelope fromaddr or the message fromaddr I can see that this is a Mailman setting. What are the consequences of using only the envelope fromaddr? Just for the record. L-soft LISTSERV is a great product - the most solid/stable I have ever used. We chaned to Mailman because we needed some things LISTSERV didn't have. All the best, Jesper.