Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
On Thu, Dec 07, 2006 at 06:23:40PM -0600, Brad Knowles wrote: At 4:57 PM -0500 12/7/06, Alan McConnell wrote: Meanwhile, I am adminning(sp?), through my ISP, a new but quite active E-list. But their mailman install is incomplete; they haven't put in Pipermail(about which I know _nothing_). Uh, what version of Mailman is that? I thought that Mailman had fully integrated Pipermail along with the base code, for many years now? Are they running Mailman 1.x or something? mm 2.1.5 . But under Debian, so it has experienced/endured the Debian security upgrade procedures. and massage these messages and then ship them off to the new very skilful tech staff that my ISP is allegedly hiring, and they will be able to slip this collection adroitly into place. And it will be as if archiving was always in place . . . So long as you save the messages in mbox format, and you have access to the command-line, you can always use the arch tool to import the old messages into the new archives. The instructions for doing this kind of stuff are in the FAQ. But if you don't have direct command-line access to the server, then you'll be dependant on the staff that do. And from what you've described, that's really the crux of the problem you're already faced with. You are exactly right. It is, like so many other thingsg, a political problem. PatriotNet is a small ISP; its founder died, the widow sold to another, totally incompetent, company . . . but now it has passed to yet another company, which is known to have Linux/Unix competent people, and which makes good noises in re tech support. Since you say mbox format and since my MUA is mutt, set up to use mbox, I think/hope/believe I am OK . . . but time will tell. Many thanks to you and to the others who have chimed in. This E-list is wonderful; run the way a help list should be IMHO. Best wishes, Alan -- Alan McConnell : http://patriot.net/users/alan There are many good Impeachment sites; one of the best is: www.waifllc.org -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] virtual domains + postfix
Hello, trying to setup mailman with virtual domains and postfix, no matter what I tried I get No such mailbox, I postfix I set up the alias_maps to hold the generated aliases that pipe to mailman and virtual_alias_maps points to the file that holds the fully qualified list addresses which in turn point to the aliases defined in the alias_maps. I really have no Idea what to do to make it work, I tried several howtos from the web but none the approaches seem to work out I'll provide any informations you need to help me analyze this but since I have no idea what's really going on here anymore I figured I wait what you say you need... \martin -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
At 7:52 AM -0500 12/8/06, Alan McConnell quoted me: Uh, what version of Mailman is that? I thought that Mailman had fully integrated Pipermail along with the base code, for many years now? Are they running Mailman 1.x or something? mm 2.1.5 . But under Debian, so it has experienced/endured the Debian security upgrade procedures. Okay, now that is one of the most bizarre things I've heard of in a very long time. I cannot comprehend how they could possibly ship a version of Mailman 2.1.x that does not automatically include the bundled Pipermail component. Congratulations -- I've been in this business long enough that I don't get too many surprises like this anymore. Yet, Mailman has recently provided me these kinds of surprises twice in the last couple of weeks or so. There should definitely be some sort of prize that you win as a result of your experience. You are exactly right. It is, like so many other thingsg, a political problem. PatriotNet is a small ISP; its founder died, the widow sold to another, totally incompetent, company . . . but now it has passed to yet another company, which is known to have Linux/Unix competent people, and which makes good noises in re tech support. Ahh. PatriotNet. I had heard good things about them years ago, but it's been a while since I've seen that name. Interesting to see what has since happened to that company. Since you say mbox format and since my MUA is mutt, set up to use mbox, I think/hope/believe I am OK . . . but time will tell. In terms of the mbox format itself, you should be fine. I'm seriously thinking of switching back to mutt myself (after being away for so many years), because Qualcomm/Eudora have decided to kill the product as a separate program and the next major version is going to be based on the Thunderbird platform. Of course, if I wanted Thunderbird, I'd be using Thunderbird. I have over 6GB of archives in Eudora's slightly modified version of mbox archives, and I'm not looking forward to what I'm going to have to do in order to move to a different program. I may take a look at what happens with Eudora after the change, I might go ahead and switch to real Thunderbird, or I might switch to a different program altogether -- which would almost certainly be mutt. I haven't decided yet. But regardless of what happens to me, you should definitely be fine with mutt. I think your issue is going to be the level of support that you get from the people who have yet to be brought in to help manage the systems, and whether or not they have the level of clue and talent required to be able to properly import your mailboxes for the archives. As far as that goes, about all I can do is to wish you luck, and then we all wait to see what happens. Many thanks to you and to the others who have chimed in. This E-list is wonderful; run the way a help list should be IMHO. I'm pretty much always glad to help, if I can -- as permitted by time and available resources. -- Brad Knowles, [EMAIL PROTECTED] Trend Micro has announced that they will cancel the stop.mail-abuse.org mail forwarding service as of 15 November 2006. If you have an old e-mail account for me at this domain, please make sure you correct that with the current address. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] removing members with non-standard characters
Patrick Bogen wrote: On 12/6/06, Anne Ramey [EMAIL PROTECTED] wrote: I'm not sure how one of my list admins managed to do this, but they have four members on their list that look like this in the membership list: b http://lists.ncmail.net/mailman/options/nciin-network-ops/%00b%00r%00i%00a%00n%00v%00--at--%00n%00c%00c%00c%00s%00.%00c%00c%00.%00n%00c%00.%00u%00s%00%00%00%00%00%1F%00%00%00%01%00%00%00%00%00%00%00%03%00%00%00 See FAQ 3.13. How do I remove a user name or email address with an illegal character in it? http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq03.013.htp I should have mentioned that will not work for this case. You'll notice that these are not all nice ascii characters. some are spaces, some deletes, some other hex values...I don't know what they all are because they will not copy and past nicely. They don't appear at all when I do list_members. Any other ideas -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
On Thu, 7 Dec 2006, Barry Warsaw wrote: Have I mentioned recently how long I've been looking for a volunteer to help make all this not suck? ;} Pipermail is just one of those things that people either live with or ditch. I've used Hypermail for probably a decade to archive Majordomo lists. It makes web archives from mbox files natively. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/ -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Email arrives after a long delay
Hello Brad, First, many thanks for your long, useful and complete response (whaou...) I'm not a email specialist but when I seen the message: [ID 801593 mail.warning] kB6BcXf1016562: collect: premature EOM: unexpected close ) I Think you are true, there is a problem on our Exchange server... The second problem is now to convince our Exchange administrator... But I think your response will give them a good idea about the problem... :-) Thanks again for your help and have a nice week-end Jean -Message d'origine- De : Brad Knowles [mailto:[EMAIL PROTECTED] Envoyé : jeudi, 7. décembre 2006 17:52 À : BERTHOLD Jean; mailman-users@python.org Cc : BERTHOLD Jean Objet : Re: [Mailman-Users] Email arrives after a long delay At 9:34 AM +0100 12/7/06, BERTHOLD Jean wrote: I have a configuration problem. All my lists works correctly excepted that the emails arrives with a delay of 10 minutes on the mailman server. In the world of Internet e-mail, ten minutes is nothing. In fact, that's pretty damn fast. Dec 06 12:49:49 2006 (4144) post to fpbg-dtr from [EMAIL PROTECTED], size=1880, message-id=[EMAIL PROTECTED], success Dec 06 13:08:18 2006 (4144) post to fpbg-dtr from [EMAIL PROTECTED], size=1875, message-id=[EMAIL PROTECTED], success Okay, so here we have two different messages coming into Mailman from you. So that we can make it easy to identify them, let's call them 630 and 634, which comes from the last three digits of the Message-ID field before the at-symbol. Dec 06 12:49:49 2006 (4144) [EMAIL PROTECTED] smtp to fpbg-dtr for 1 recips, completed in 0.318 seconds Okay, so we see that 630 came into Mailman from the MTA at 12:49:49 and went back out to the MTA in less than a second. That's good. Dec 6 12:48:46 bahamas sendmail[16562]: [ID 801593 mail.warning] kB6BcXf1016562: collect: premature EOM: unexpected close Dec 6 12:48:46 bahamas sendmail[16562]: [ID 801593 mail.notice] kB6BcXf1016562: collect: unexpected close on connection from swexch01lpro.sila.local, sender=[EMAIL PROTECTED] Dec 6 12:48:46 bahamas sendmail[16562]: [ID 801593 mail.info] kB6BcXf1016562: from=[EMAIL PROTECTED], size=1217, class=0, nrcpts=1, proto=ESMTP, daemon=MTA-v4, relay=swexch01lpro.sila.local [172.25.2.76] These are signs that your Exchange server is screwing up the SMTP protocol. Dec 6 12:49:46 bahamas sendmail[16721]: [ID 801593 mail.info] kB6BnkRQ016721: from=[EMAIL PROTECTED], size=1315, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA-v4, relay=swexch01lpro.sila.local [172.25.2.76] Okay, so here is 630 coming into the system from Exchange. Note that the sendmail queue-id in this case is kB6BnkRQ016721. This is how we tie other log entries together back to this same message -- by the sendmail queue-id. Dec 6 12:49:47 bahamas sendmail[16722]: [ID 801593 mail.info] kB6BnkRQ016721: to=|/usr/local/mailman/mail/mailman post fpbg-dtr, ctladdr=[EMAIL PROTECTED] (1/0), delay=00:00:01, xdelay=00:00:01, mailer=prog, pri=31536, dsn=2.0.0, stat=Sent Okay, so here is sendmail saying that it has now sent 630 to Mailman. We know that it's what we're calling message 630 because we see the same sendmail queue-id, namely kB6BnkRQ016721. Note that Mailman says that it finished getting this message about two seconds later (at 12:49:49), and that Mailman then sends that message back to the MTA in less than a second (still 12:49:49). Dec 6 12:49:49 bahamas sendmail[16725]: [ID 801593 mail.info] kB6Bnnn6016725: from=[EMAIL PROTECTED], size=1880, class=-30, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1] Okay, so here is 630 having come back out of Mailman, and going into the MTA to be delivered to the recipient. Note that the sendmail queue-id is now kB6Bnnn6016725, because as far as sendmail is concerned this is a totally different message. Sendmail doesn't know that the content is exactly the same, and that what has happened is that the message has come through sendmail, into Mailman, and then back out again. Sendmail sees the inbound and outbound legs as being two totally separate messages. Any further delay is totally and completely out of the hands of Mailman. There is absolutely nothing that we can do to help. Dec 6 13:08:20 bahamas sendmail[17179]: [ID 801593 mail.info] kB6C8Kge017177: to=[EMAIL PROTECTED], delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=176820, relay=mta0.eosholding.ch. [193.8.222.23], dsn=2.0.0, stat=Sent (Ok: queued as 360A520C03B) Dunno what message this is, but it doesn't look like it's 630. Note that the sendmail queue-id is different -- Message 630 came in with queue-id kB6Bnnn6016725, and this has queue-id kB6C8Kge017177. So, it looks like there are some log entries missing. Dec 6 13:08:21 bahamas sendmail[17180]: [ID 801593 mail.info] kB6C8LhF017180: from=[EMAIL PROTECTED], size=2777,
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Mark Sapiro wrote: Paul Tomblin wrote: Quoting Barry Warsaw ([EMAIL PROTECTED]): It already does escape From lines in the body of the message. It does this by way of the email package's Generator class, which is instantiated with mangle_from_=True. Must be a newer version than the one in Debian stable. I grepped for mangle in /var/lib/mailman/Mailman/*, and didn't find it. The parameter does appear in /usr/lib/python2.3/email/Generator.py, but since I don't know python I don't know how to pass it to it. I'm guessing it has something to do with changing the g = Generator(fp) and g = Generator(outfp) lines in Mailman/ListAdmin.py or more likely the g = Generator(self.fp) line in Mailman/Mailbox.py? Is it as simple as changing that last one to g = Generator(self.fp,mangle_from_=True)? Yes it is. And I think Barry may have misspoken as I don't think that change is in the SVN trunk or Release_2_1-maint branch. According to the docs for email.Generator, mangle_from defaults to True and has since at least python 2.3. So setting it shouldn't be needed AFAICS. In that case, shouldn't any message that reaches mailman with an unescaped From_ line in the body already be handled properly? It seems like something else must be borked. That or all of the messages in a list mbox that contain unescaped From_ lines got there from really old versions of Mailman/python. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp == You know an odd feeling? Sitting on the toilet eating a chocolate candy bar. -- George Carlin, Napalm Silly Putty pgp0YagKhc7uk.pgp Description: PGP signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Quoting Todd Zullinger ([EMAIL PROTECTED]): Mark Sapiro wrote: Paul Tomblin wrote: Quoting Barry Warsaw ([EMAIL PROTECTED]): It already does escape From lines in the body of the message. It does this by way of the email package's Generator class, which is instantiated with mangle_from_=True. According to the docs for email.Generator, mangle_from defaults to True and has since at least python 2.3. So setting it shouldn't be needed AFAICS. Oh right, now I get it. I told you I didn't know Python, but I should have been able to figure that def __init__(self, outfp, mangle_from_=True, maxheaderlen=78): meant that it defaulted to True in Generator.py so didn't need to be changed in Mailman. In that case, shouldn't any message that reaches mailman with an unescaped From_ line in the body already be handled properly? It seems like something else must be borked. That or all of the messages in a list mbox that contain unescaped From_ lines got there from really old versions of Mailman/python. That is distinctly possible. The archives in question go back to 1998. I didn't keep track of when the *last* unescaped From_ line was put in the archives. -- Paul Tomblin [EMAIL PROTECTED] http://blog.xcski.com/ It could have been raining flaming bulldozers, and those idiots would have been standing out there smoking, going 'hey, look at that John Deere burn!' -- Texan AMD security guard -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Brad == Brad Knowles Re: [Mailman-Users] Mailman archive messages(not rm, but install!) Fri, 8 Dec 2006 08:52:26 -0600 Brad At 7:52 AM -0500 12/8/06, Alan McConnell quoted me: Uh, what version of Mailman is that? I thought that Mailman had fully integrated Pipermail along with the base code, for many years now? Are they running Mailman 1.x or something? mm 2.1.5 . But under Debian, so it has experienced/endured the Debian security upgrade procedures. Brad Okay, now that is one of the most bizarre things I've heard Brad of in a very long time. I cannot comprehend how they could Brad possibly ship a version of Mailman 2.1.x that does not Brad automatically include the bundled Pipermail component. Brad Congratulations -- I've been in this business long enough Brad that I don't get too many surprises like this anymore. Yet, Brad Mailman has recently provided me these kinds of surprises Brad twice in the last couple of weeks or so. Brad There should definitely be some sort of prize that you win Brad as a result of your experience. See http://packages.debian.org/unstable/mail/mailman for a description of the Debian Mailman package that integrates ... archiving Further down that page under the heading Download mailman click on one of the list of files buttons and see among other things: usr/lib/mailman/Mailman/Archiver/pipermail.py jam pgpMEZkVN4gX6.pgp Description: PGP signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Paul Tomblin wrote: Oh right, now I get it. I told you I didn't know Python, but I should have been able to figure that def __init__(self, outfp, mangle_from_=True, maxheaderlen=78): meant that it defaulted to True in Generator.py so didn't need to be changed in Mailman. :-) I actually trusted the docs (which I probably shouldn't do). But you're right, the __init__ line confirms the default setting for mangle_from. In that case, shouldn't any message that reaches mailman with an unescaped From_ line in the body already be handled properly? It seems like something else must be borked. That or all of the messages in a list mbox that contain unescaped From_ lines got there from really old versions of Mailman/python. That is distinctly possible. The archives in question go back to 1998. I didn't keep track of when the *last* unescaped From_ line was put in the archives. It still sucks that you have to muck around with the mboxes to get pipermail to archive them properly. I feel your pain. I am currently trying to get another lists archives into better shape and have run into the same issue. I'm seriously lacking in the skill to fix pipermail or I'd take Barry up on trying to fix it. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp == An idea is not responsible for the people who believe in it. -- Anonymous pgpKLGsxj1cPw.pgp Description: PGP signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] A scrubber issue
In honor of recent discussions on pipermail, I think I've found another issue with archiving, though this seems to be in Mailman.Scrubber. In a few recent posts to the GnuPG lists, Werner Koch sent along some signed patches fixing issues in the gpg code. Unfortunately, the archives ate his posts[1] so we can't point others to the patches in the archives as nicely as one would like. It seems that the problem is that both message parts lack a Content-type: text/plain; charset=us-ascii header and the first part also lacks a Content-disposition: inline header. If I edit the raw message to include a Content-type: text/plain; charset=us-ascii header for each mime part, it passes the scrubber as is archived properly. From my limited reading of RFC 2045[2], it seems that a mime part without a content-type header should be assumed to be text/plain; charset=us-ascii. Is the scrubber wrong to not assume this or are there too many issues with making this (apparently quite standards conformant) assumption? [1] http://lists.gnupg.org/pipermail/gnupg-users/2006-December/029976.html [2] http://www.ietf.org/rfc/rfc2045.txt -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp == To know what is right and not to do it is the worst cowardice. -- Confucius pgpbumhTkm81V.pgp Description: PGP signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] removing members with non-standard characters
Anne Ramey wrote: I should have mentioned that will not work for this case. You'll notice that these are not all nice ascii characters. some are spaces, some deletes, some other hex values...I don't know what they all are because they will not copy and past nicely. They don't appear at all when I do list_members. Any other ideas There are several options and I have lots of ideas. Have you tried just checking the 'unsub' box next to the entry? The 'address' you see looks a lot like the URL of the options page that the address is a link to. Perhaps you are not seeing the address at all, but rather, you are seeing the result of funny characters in the address confusing the browser's rendering of the anchor tag. It looks like http://lists.ncmail.net/mailman/options/nciin-network-ops/%00b%00r%00i%00a%00n%00v%00--at--%00n%00c%00c%00c%00s%00.%00c%00c%00.%00n%00c%00.%00u%00s%00%00%00%00%00%1F%00%00%00%01%00%00%00%00%00%00%00%03%00%00%00 is a link to the options page of the user whose address is %00b%00r%00i%00a%00n%00v%00--at--%00n%00c%00c%00c%00s%00.%00c%00c%00.%00n%00c%00.%00u%00s%00%00%00%00%00%1F%00%00%00%01%00%00%00%00%00%00%00%03%00%00%00 (if you replace --at-- with @, %00 with ^@, %1F with ^_, %01 with ^A and %03 with ^C) Do you see [EMAIL PROTECTED] on the list_members output? Does this entry appear in the membership list on its own page at the beginning? It also looks like someone mass subscribed a list pasted from or output by a word processor If the bad addresses don't appear in list_members (I don't know why they wouldn't, but maybe they just appear with the control characters that you don't see and thus look OK) you can do bin/list_members listname | bin/synch_members -f - -n listname and if you like what that says, you can do bin/list_members listname | bin/synch_members -f - listname You might also try bin/list_members -i listname to see what that shows. You could create a simple withlist script to validate member addresses and delete invalid ones.. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 8, 2006, at 11:10 AM, Paul Tomblin wrote: In that case, shouldn't any message that reaches mailman with an unescaped From_ line in the body already be handled properly? It seems like something else must be borked. That or all of the messages in a list mbox that contain unescaped From_ lines got there from really old versions of Mailman/python. That is distinctly possible. The archives in question go back to 1998. I didn't keep track of when the *last* unescaped From_ line was put in the archives. Sorry, I should have been clearer that the /default/ behavior of the generator is to mangle From_ lines. So it's true that nothing in Mailman should need to be changed. However, it's also true that in the distant past, there were some bugs in the mbox implementation which would cause broken mbox files to be written. A quick scan through the svn logs jogs my memory: r6341 on 2003-04-17 was added to fix a message separation bug. I don't know how long that bug was lurking, but the fix puts it just before the 2.1.2 release according to the NEWS file. I'll bet that it existed from 2.1 final (Dec 2002) until 2.1.2 (Apr 2003), the latter which was probably released specifically to fix this problem! Note that this bug had no effect on the archiving of new messages on the fly. Those always got archived correctly. But the message was appended to the mbox file incorrectly which meant that if you regenerated your archives, you'd be screwed. This was what bin/ cleanarch was intended to fix. BTW, one less ambitious way to participate here to help fix things would be to improve bin/cleanarch. At the very least, you should be able to run that script and get an mbox file that bin/arch can use to DTRT. It would also be nice if bin/arch was able to compensate for running out of memory, possibly by changing it to fork a sub-process to do the actual archiving with the parent process pre-chunking the workload for the child. Anyway, I'm cc'ing mailman-developers. Further discussion of how to improve matters should be conducted on that list (and mailman-users should be removed). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRXmlMHEjvBPtnXfVAQIFYAP/W2LEOrKhqrB6sDniHKADAV5iMuLm19zu nUkvrJpOumD78+tRDa1DCQG8RaCSAZ7bNkTA2VwIUgcX1I4+9d7ylklonQSiRJzB xbg+OBD5+x5q+Cdo9qX1dhlGWTdmrSReN0CLRx6408JX8qtXhIh+3S0f3tG44bYE lB76OX4HPXo= =nhI8 -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman stop delivering ... problem withApproval.py?
[EMAIL PROTECTED] wrote: The mailman lists on my server have suddenly stopped delivering mail. And what update to Mailman or Python was installed just before this happened? The error of one of the messages is cut and paste below ... All the messages are being shunted off and not delivered when it reaches the Approval.py and has trouble inporting ...? File /usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Approve.py, line 28, in ? from email.Iterators import typed_subpart_iterator ImportError: cannot import name typed_subpart_iterator The above import has been in Approve.py since 2.1.0. Something else in your system changed. See http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq06.011.htp for the reason why I can't be more helpful. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Brad Knowles wrote: At 7:52 AM -0500 12/8/06, Alan McConnell quoted me: Uh, what version of Mailman is that? I thought that Mailman had fully integrated Pipermail along with the base code, for many years now? Are they running Mailman 1.x or something? mm 2.1.5 . But under Debian, so it has experienced/endured the Debian security upgrade procedures. Okay, now that is one of the most bizarre things I've heard of in a very long time. I cannot comprehend how they could possibly ship a version of Mailman 2.1.x that does not automatically include the bundled Pipermail component. But the hosting service could set ARCHIVE_TO_MBOX = 1 in mm_cfg.py to disable pipermail archiving and archive only to the .mbox file. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman stop delivering ... problem withApproval.py?
The mailman lists on my server have suddenly stopped delivering mail. And what update to Mailman or Python was installed just before this happened? There was no update to either Mailman or Python ... but one of the lists was hit with a *massive* amount of spam that caused too many files open error, this same spam attack eventually caused the server to run out of memory :( The above import has been in Approve.py since 2.1.0. Something else in your system changed. When creating a temp list for a testing sandbox the Import errors were replaced by AttributeError: 'str' object has no attribute 'get_sender' errors, and then all errors stopped and the lists on the server started working again. My assumption is that Mailman was using up server resources to deal with spam and a (few) files got corrupted, which files were then recompiled on the creation of a new list. I'm now sending all mail to the list owner to dev/null and am content filtering and discarding mail with images ... I'm hoping that that will reduce the amount of resources that Mailman needs should another load hit. One interesting thing, the qfiles/shunt/*.pck files were owned:group by mailman:mailman, but the most recent AttributeError .pck files are owned:group root:mailman. How is it that Mailman started writing files with root as the owner? See http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq06.011.htp for the reason why I can't be more helpful. Yeah. I appreciate the time you've been able to give. Thanks. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] A scrubber issue
Todd Zullinger wrote: In honor of recent discussions on pipermail, I think I've found another issue with archiving, though this seems to be in Mailman.Scrubber. In a few recent posts to the GnuPG lists, Werner Koch sent along some signed patches fixing issues in the gpg code. Unfortunately, the archives ate his posts[1] so we can't point others to the patches in the archives as nicely as one would like. There seems to be another issue in that there is no 'link' to the scrubbed part, just a relative URL which doesn't work. It seems that the problem is that both message parts lack a Content-type: text/plain; charset=us-ascii header and the first part also lacks a Content-disposition: inline header. If I edit the raw message to include a Content-type: text/plain; charset=us-ascii header for each mime part, it passes the scrubber as is archived properly. From my limited reading of RFC 2045[2], it seems that a mime part without a content-type header should be assumed to be text/plain; charset=us-ascii. Is the scrubber wrong to not assume this or are there too many issues with making this (apparently quite standards conformant) assumption? [1] http://lists.gnupg.org/pipermail/gnupg-users/2006-December/029976.html [2] http://www.ietf.org/rfc/rfc2045.txt You are correct in your assessment of why the part is scrubbed in the first place. Also, it seems that according to sec 5.2 of RFC 2045 we could assume 'us-ascii', but I expect this may cause other problems with non-compliant MUAs. Tokio is responsible for a lot of scrubber code, and he has a lot of experience with Japanese so I suspect there is a reason we do it this way. It seems that a good part of the problem in the above referenced archive is that the scrubbed attachment is not given a clickable link, and in fact the relative path given doesn't even work. I think at least part of this must be specific to this site - perhaps a (intentionally?) bad value for PUBLIC_ARCHIVE_URL in mm_cfg.py. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman stop delivering ... problemwithApproval.py?
SML wrote: There was no update to either Mailman or Python ... but one of the lists was hit with a *massive* amount of spam that caused too many files open error, this same spam attack eventually caused the server to run out of memory :( And the reboot of the server could have caused things which were previously downloaded and waiting for a reboot to install to finally be installed. The above import has been in Approve.py since 2.1.0. Something else in your system changed. When creating a temp list for a testing sandbox the Import errors were replaced by AttributeError: 'str' object has no attribute 'get_sender' errors, and then all errors stopped and the lists on the server started working again. I've seen reports of this error before and it appears to me to be a symptom of an underlying Python problem that causes incoming queue entries to be missing critical metadata. My assumption is that Mailman was using up server resources to deal with spam and a (few) files got corrupted, which files were then recompiled on the creation of a new list. Creating a new list shouldn't cause anything to be recompiled or reloaded. One interesting thing, the qfiles/shunt/*.pck files were owned:group by mailman:mailman, but the most recent AttributeError .pck files are owned:group root:mailman. How is it that Mailman started writing files with root as the owner? Because it was root that ran the 'bin/mailmanctl start' so root owns the qrunner processes. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] A scrubber issue
Hi Mark, Mark Sapiro wrote: There seems to be another issue in that there is no 'link' to the scrubbed part, just a relative URL which doesn't work. Yes, there are other issues with the configuration there. Click on the list info link and then follow that to the archives. You get into the top level of the public archive dir, seeing a listing of all of the lists and list mboxes. However, I created a fresh list on my system to see whether this was a list configuration issue or not and it's reproduceable using a default list setup. I initially thought it must be some over-agressive content filtering, but after having it work on a virgin list I don't think that's the case. There may still be a way to configure the content filtering to work around this, but I'm not familiar enough with the various possibilities to know that. You are correct in your assessment of why the part is scrubbed in the first place. Also, it seems that according to sec 5.2 of RFC 2045 we could assume 'us-ascii', but I expect this may cause other problems with non-compliant MUAs. Tokio is responsible for a lot of scrubber code, and he has a lot of experience with Japanese so I suspect there is a reason we do it this way. I was guessing this might be the case as well. Hopefully Tokio or someone else who's intimate with the code can comment on whether that's the case or not. It always sucks when the choice is either not conform to a standard or not work properly in the real world. I don't envy the choices you guys have to make when writing email parsing code. :) If it came to it, perhaps there could be an option to be strict about the parsing for those that would rather conform than be able to handle all of the junk that people send? I tend to go this direction when I configure my MTA's, but I realize this isn't always a viable choice for others. It seems that a good part of the problem in the above referenced archive is that the scrubbed attachment is not given a clickable link, and in fact the relative path given doesn't even work. I think at least part of this must be specific to this site - perhaps a (intentionally?) bad value for PUBLIC_ARCHIVE_URL in mm_cfg.py. I don't think it's related. My test list created a proper link to the second message part, but it still scrubbed both mime parts. If I added a content-disposition: inline header to the first part, then it was similarly scrubbed and a link inserted. Without that header, the part just disappeared completely. I can send you config_list output for the test list if you like, but there weren't any changes made to the config so it should be nothing but Mailman default. I don't know what OS the real gnupg-users list runs on, but my test list was created on Fedora Core 6, using the packaged mailman rpm there (version 2.1.9). I don't think there are significant deviations from Mailman's source other than the FHS patch that they apply. If you think it's relevant, I can install from source and test as well. Thanks, -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp == It is not enough to be busy, so are the ants. The question is: what are we busy about? -- Henry David Thoreau pgpn6IJzCLqa8.pgp Description: PGP signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] problem with mailing lists general contact address
All, I am using mailman as installed and administered by a web host in vancouver, webserve.ca. When I set up a mailing list, the general contact address on the mail.mail.domainname.ca/mailman/listinfo page is listed as [EMAIL PROTECTED], rather than [EMAIL PROTECTED] When I send a test email to [EMAIL PROTECTED] I get a bounce back with this message: This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. [EMAIL PROTECTED] When I send a test email to [EMAIL PROTECTED] I get a bounce back with this message: You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at [EMAIL PROTECTED] I presume this is a configuration issue. Unfortunately I do not have access on the configuration server, and the webserve.ca support people seem to be at a loss as to what to do. Judging from the fact that python's own mail list page uses [EMAIL PROTECTED], I presume that the issue is faulty configuration of the general list contact address in the configuration file. Could someone explain to me how this can be fixed, so that I can pass it on? Thanks much, - Henrik -- Henrik Bechmann www.osscommons.ca www.bechmannsoftware.com Webmaster, www.dufferinpark.ca -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] A scrubber issue
Todd Zullinger wrote: However, I created a fresh list on my system to see whether this was a list configuration issue or not and it's reproduceable using a default list setup. I initially thought it must be some over-agressive content filtering, but after having it work on a virgin list I don't think that's the case. There may still be a way to configure the content filtering to work around this, but I'm not familiar enough with the various possibilities to know that. It shouldn't be a content filtering issue. If a part is missing a Content-Type: header, the message methods get_content_type() and get_content_maintype() which are used by MimeDel.py (content filtering) return the default types which are text/plain and text except for subparts of multipart/digest when they are message/rfc822 and message. It seems that a good part of the problem in the above referenced archive is that the scrubbed attachment is not given a clickable link, and in fact the relative path given doesn't even work. I think at least part of this must be specific to this site - perhaps a (intentionally?) bad value for PUBLIC_ARCHIVE_URL in mm_cfg.py. I don't think it's related. My test list created a proper link to the second message part, but it still scrubbed both mime parts. If I added a content-disposition: inline header to the first part, then it was similarly scrubbed and a link inserted. Without that header, the part just disappeared completely. I can't duplicate this. I am trying a multipart/mixed message with two 'no content-type' parts and a third 'Content-Type: text/plain; charset=us-ascii' part. The first two parts are (individually) either scrubbed and replaced with An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://example.com/pipermail/list1/attachments/... or left in the message body depending on whether or not they contain a Content-Disposition: inline header. I can send you config_list output for the test list if you like, but there weren't any changes made to the config so it should be nothing but Mailman default. I don't know what OS the real gnupg-users list runs on, but my test list was created on Fedora Core 6, using the packaged mailman rpm there (version 2.1.9). I don't think there are significant deviations from Mailman's source other than the FHS patch that they apply. If you think it's relevant, I can install from source and test as well. Can you just send me the original message that has parts lost? -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] A scrubber issue
Mark Sapiro wrote:
It shouldn't be a content filtering issue. If a part is missing a
Content-Type: header, the message methods get_content_type() and
get_content_maintype() which are used by MimeDel.py (content
filtering) return the default types which are text/plain and text
except for subparts of multipart/digest when they are message/rfc822
and message.
Okay, good to know.
I can't duplicate this.
It's quite possible this is something that's tickled by the way Gnus
creates the message. I know mutt doesn't create the sort of messages
that trigger this either.
Can you just send me the original message that has parts lost?
Attached is the original message from the list mbox and one that I
munged up to included a content-type: text/plain; charset=us-ascii.
--
ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
==
Women should be obscene and not heard.
-- Groucho Marx
From [EMAIL PROTECTED] Thu Dec 07 19:26:34 2006
Received: from kerckhoffs.g10code.com ([217.69.77.222])
by trithemius.gnupg.org with esmtp (Exim 4.50 #1 (Debian))
id 1GsNx4-0008G7-A7 for [EMAIL PROTECTED];
Thu, 07 Dec 2006 19:26:34 +0100
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1
(Debian)) id 1GsO7a-0001Qr-HL
for gnupg-users@gnupg.org; Thu, 07 Dec 2006 19:37:26 +0100
Received: from wk by localhost with local (Exim 4.62 #1 (Debian))
id 1GsNsD-0001gg-RX
for gnupg-users@gnupg.org; Thu, 07 Dec 2006 19:21:33 +0100
From: Werner Koch [EMAIL PROTECTED]
To: gnupg-users@gnupg.org
Subject: Signed patch against 2.0.1
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[EMAIL PROTECTED]
Mail-Followup-To: gnupg-users@gnupg.org
Date: Thu, 07 Dec 2006 19:21:33 +0100
Message-ID: [EMAIL PROTECTED]
User-Agent: Gnus/5.110006 (No Gnus v0.6)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary==KGB-Sundevil-gamma-Skipjack-government-Vince-Foster-Treasury-bce-S-B
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on
trithemius.gnupg.org
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=ham
version=3.0.3
X-BeenThere: gnupg-users@gnupg.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Help and discussion among users of GnuPG gnupg-users.gnupg.org
List-Unsubscribe: http://lists.gnupg.org/mailman/listinfo/gnupg-users,
mailto:[EMAIL PROTECTED]
List-Archive: /pipermail
List-Post: mailto:gnupg-users@gnupg.org
List-Help: mailto:[EMAIL PROTECTED]
List-Subscribe: http://lists.gnupg.org/mailman/listinfo/gnupg-users,
mailto:[EMAIL PROTECTED]
X-List-Received-Date: Thu, 07 Dec 2006 18:27:13 -
Content-Length: 8376
Lines: 294
--=KGB-Sundevil-gamma-Skipjack-government-Vince-Foster-Treasury-bce-S-B
Hi!
Here comes a signed patch against 2.0.1 for those who care to verify
signatures ;-).
Shalom-Salam,
Werner
--=KGB-Sundevil-gamma-Skipjack-government-Vince-Foster-Treasury-bce-S-B
Content-Disposition: inline; filename=filter-context-20-small.diff
Content-Description: Patch against 2.0.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
This is a patch against GnuPG 2.0.1. Change the directory to g10/ and
apply this patch.
2006-12-02 Werner Koch [EMAIL PROTECTED]
* encr-data.c: Allocate DFX context on the heap and not on the
stack. Changes at several places. Fixes CVE-2006-6235.
Index: encr-data.c
===
--- encr-data.c (revision 4352)
+++ encr-data.c (working copy)
@@ -39,16 +39,37 @@
static int decode_filter ( void *opaque, int control, IOBUF a,
byte *buf, size_t *ret_len);
-typedef struct
+typedef struct decode_filter_context_s
{
gcry_cipher_hd_t cipher_hd;
gcry_md_hd_t mdc_hash;
char defer[22];
int defer_filled;
int eof_seen;
-} decode_filter_ctx_t;
+ int refcount;
+} *decode_filter_ctx_t;
+/* Helper to release the decode context. */
+static void
+release_dfx_context (decode_filter_ctx_t dfx)
+{
+ if (!dfx)
+return;
+
+ assert (dfx-refcount);
+ if ( !--dfx-refcount )
+{
+ gcry_cipher_close (dfx-cipher_hd);
+ dfx-cipher_hd = NULL;
+ gcry_md_close (dfx-mdc_hash);
+ dfx-mdc_hash = NULL;
+ xfree (dfx);
+}
+}
+
+
+
/
* Decrypt the data, specified by ED with the key DEK.
*/
@@ -62,7 +83,11 @@
unsigned blocksize;
unsigned nprefix;
- memset( dfx, 0, sizeof dfx );
+ dfx = xtrycalloc (1, sizeof *dfx);
+ if (!dfx)
+return gpg_error_from_syserror ();
+ dfx-refcount = 1;
+
if ( opt.verbose !dek-algo_info_printed )
{
const char *s = gcry_cipher_algo_name (dek-algo);
@@ -77,20 +102,20 @@
goto leave;
blocksize = gcry_cipher_get_algo_blklen (dek-algo);
if ( !blocksize || blocksize 16 )
-
Re: [Mailman-Users] problem with mailing lists general contact address
Henrik wrote:
When I set up a mailing list, the general contact address on the
mail.mail.domainname.ca/mailman/listinfo page is listed as
[EMAIL PROTECTED], rather than [EMAIL PROTECTED]
The domain in this address depends on whether or not
VIRTUAL_HOST_OVERVIEW is set to Yes or No. The default is Yes. If you
visit the http://www.example.com/mailman/listinfo overview page and
you see only lists in the www.example.com domain, then it is set to
Yes. If you see all the advertised lists on the server, then it is set
to No (in mm_cfg.py).
So, if VIRTUAL_HOST_OVERVIEW is set to No, the domain in the site list
address is the result of looking up DEFAULT_URL_HOST in the
VIRTUAL_HOSTS dictionary - i.e. it is the second argument from
add_virtualhost(DEFAULT_URL_HOST, xxx)
from mm_cfg.py (normally this is DEFAULT_EMAIL_HOST).
If VIRTUAL_HOST_OVERVIEW is set to Yes, the domain is the result of
looking up the host domain from the URL used to access the page.
In your case, assuming no typo above even though it looks strange,
there is an entry in mm_cfg.py like
add_virtualhost('mail.mail.domainname.ca', 'mail.domainname.ca')
that should be
add_virtualhost('mail.mail.domainname.ca', 'domainname.ca')
instead.
There is another possibility. This add_virtualhost entry also affects
your own lists. Is the domain 'mail.domainname.ca' the correct domain
for mailing to your lists? If so, you don't want to change the
add_virtualhost entry; you need to add an alias or whatever to the MTA
for your domain for the mailman list.
On the third hand, I visited the listinfo page on the server at
ns38.servepower.com, and it appears to be a cPanel mailman so I relly
don't have a clue. See
http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq06.011.htp.
When I send a test email to [EMAIL PROTECTED] I get a bounce
back with this message:
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
[EMAIL PROTECTED]
When I send a test email to [EMAIL PROTECTED] I get a bounce back
with this message:
You are not allowed to post to this mailing list, and your message has
been automatically rejected. If you think that your messages are
being rejected in error, contact the mailing list owner at [EMAIL PROTECTED]
I presume this is a configuration issue. Unfortunately I do not have
access on the configuration server, and the webserve.ca support people
seem to be at a loss as to what to do.
You get the above message because the installation has only one site
list (mailman) for all supported domains and it is configured to
reject posts from non-members
Yet, since this is presumably a cPanel Mailman, if it is the case that
the domain for mail to your lists IS mail.domainname.ca, you may be
able to solve the whole problem by just creating a 'mailman' list in
your own domain.
Judging from the fact that python's own mail list page uses
[EMAIL PROTECTED], I presume that the issue is faulty configuration of
the general list contact address in the configuration file.
Could someone explain to me how this can be fixed, so that I can pass it on?
If the above doesn't do it, let us know what else you need.
--
Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] A scrubber issue
Todd Zullinger wrote: Attached is the original message from the list mbox and one that I munged up to included a content-type: text/plain; charset=3Dus-ascii. I see the symptom with the original message. I'll look further, but it seems to have something to do with the fact that the first sub-part has no headers at all. I have looked at RFC 2045 and I don't see that any headers are required, but I don't yet know what the underlying issue in Scrubber is. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
At 11:43 AM -0500 12/8/06, John A. Martin wrote: See http://packages.debian.org/unstable/mail/mailman for a description of the Debian Mailman package that integrates archiving Further down that page under the heading Download mailman click on one of the list of files buttons and see among other things: usr/lib/mailman/Mailman/Archiver/pipermail.py I've never claimed to be a Debian expert, and if they're mucking about with packages that include certain features by default in order to remove those features, then there's not much I can do to help the poor souls that are stuck with that kind of stuff. However, no amount of your expecting me to do fact-checking with the way that Debian is building their highly modified packaged versions of our software is going to change that. It's physically impossible to keep up with how every single vendor is choosing to ship our software. As far as I'm concerned, Debian is now further in the doghouse with me with regards to Mailman than most any other vendor, with the possible exception of cPanel. Even Apple ships a relatively plain-jane version of Mailman 2.1.5 with their MacOS X Server platform, even if they do have their own proprietary management system that they tack on. Now, if you want to side with the Debian folks on this, you're welcome to do that. But no one in that camp is going to be getting any sympathy from me. -- Brad Knowles, [EMAIL PROTECTED] Trend Micro has announced that they will cancel the stop.mail-abuse.org mail forwarding service as of 15 November 2006. If you have an old e-mail account for me at this domain, please make sure you correct that with the current address. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Quoting Brad Knowles ([EMAIL PROTECTED]):
At 11:43 AM -0500 12/8/06, John A. Martin wrote:
See http://packages.debian.org/unstable/mail/mailman for a
description of the Debian Mailman package that integrates
archiving Further down that page under the heading
Download mailman click on one of the list of files buttons and see
among other things: usr/lib/mailman/Mailman/Archiver/pipermail.py
I've never claimed to be a Debian expert, and if they're mucking
about with packages that include certain features by default in order
to remove those features, then there's not much I can do to help the
poor souls that are stuck with that kind of stuff.
I don't know what John is experiencing, but I'm using Mailman installed
from Debian Stable, and have been for a couple of years, and it's always
had pipermail.
--
Paul Tomblin [EMAIL PROTECTED] http://blog.xcski.com/
What we obtain too cheap we esteem too lightly; it is dearness only that
gives everything its value. - Thomas Paine.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] problem with mailing lists general contact address
Thanks Mark,
If VIRTUAL_HOST_OVERVIEW is set to Yes, the domain is the result of
looking up the host domain from the URL used to access the page.
This appears to be the case:
In fact if I access the page with mail.domainname.ca/mailman/, the
contact address is [EMAIL PROTECTED], whereas if I access the
page with domainname.ca/mailman/listinfo (ie without the mail.
subdomain), the contact address shows as [EMAIL PROTECTED]
Reading the domain from the URL is desirable as I have a number of
domain names associated with the account, and wish to have mailing lists
set up for all or most of them. But is seems like what should be used is
something like (in totally pseudo regex, I have no idea what the syntax
is in python)
add_virtualhost('/(mail\.)?(*.)/', '$2')
Is this true? What would the entry look like? (I don't unfortunately
have access to mm_cfg.py - is it in principle possible to have a
mm_cfg.py for a user of a linux system -- ie for a web account). I would
have to pass this on to the web host.
Then the other problem would appear to be that the default mail address
([EMAIL PROTECTED]) is not set up properly on creation of the mail
list.
Does all this seem like a reasonable theory?
BTW, mail list creation is done through cpanel, so I presume the
installation was done through cpanel as well. But I don't know for sure.
Also, yes I did make a typo with mail.mail.domainname.ca. I should have
typed mail.domainname.ca. Sorry about the confusion.
Is the domain 'mail.domainname.ca' the correct domain
for mailing to your lists? If so, you don't want to change the
add_virtualhost entry; you need to add an alias or whatever to the MTA
for your domain for the mailman list.
I have no control over this, and am not sure of the question. The pop3
(and SMTP) mail server is mail.domainname.ca. Would this interfere?
Lists are sent to [EMAIL PROTECTED], ie no mail subdomain is used
for mailing to the lists. Does this answer that question?
You get the above message because the installation has only one site
list (mailman) for all supported domains and it is configured to
reject posts from non-members
The ideal would be to have [EMAIL PROTECTED] go to the list owner
associated with the domain name (ie multiple domain names on my web
account), as opposed to my web account (in effect my web acount, read
Linux user, is host to multiple domain names, but so, presumably, are
other users on the same installation).
Yet, since this is presumably a cPanel Mailman, if it is the case that
the domain for mail to your lists IS mail.domainname.ca, you may be
able to solve the whole problem by just creating a 'mailman' list in
your own domain.
Sorry, don't quite get that. You mean create a list called
[EMAIL PROTECTED], and this would pre-empt the central installation
routing? And just make the list private, with only the owner as a
recipient? This is an interesting possibility, though if I understand it
right, the proper solution would be to have the mail list installation
process check sendmail for the existence of a default address for the
domain list administrator ([EMAIL PROTECTED]) and create one if it
doesn't exist. But I may not be understanding this properly. What about
creating a sendmail account called [EMAIL PROTECTED] Would this
pre-empt the mail from going to the installation-wide address? If this
were the case, then the remaining problem would be the aforementioned
assignment by add_virtualhost. True?
Thanks again,
All the best,
- Henrik
Mark Sapiro wrote:
Henrik wrote:
When I set up a mailing list, the general contact address on the
mail.mail.domainname.ca/mailman/listinfo page is listed as
[EMAIL PROTECTED], rather than [EMAIL PROTECTED]
The domain in this address depends on whether or not
VIRTUAL_HOST_OVERVIEW is set to Yes or No. The default is Yes. If you
visit the http://www.example.com/mailman/listinfo overview page and
you see only lists in the www.example.com domain, then it is set to
Yes. If you see all the advertised lists on the server, then it is set
to No (in mm_cfg.py).
So, if VIRTUAL_HOST_OVERVIEW is set to No, the domain in the site list
address is the result of looking up DEFAULT_URL_HOST in the
VIRTUAL_HOSTS dictionary - i.e. it is the second argument from
add_virtualhost(DEFAULT_URL_HOST, xxx)
from mm_cfg.py (normally this is DEFAULT_EMAIL_HOST).
If VIRTUAL_HOST_OVERVIEW is set to Yes, the domain is the result of
looking up the host domain from the URL used to access the page.
In your case, assuming no typo above even though it looks strange,
there is an entry in mm_cfg.py like
add_virtualhost('mail.mail.domainname.ca', 'mail.domainname.ca')
that should be
add_virtualhost('mail.mail.domainname.ca', 'domainname.ca')
instead.
There is another possibility. This add_virtualhost entry also affects
your own lists. Is the domain 'mail.domainname.ca' the correct domain
for mailing to your lists? If so, you don't
Re: [Mailman-Users] problem with mailing lists general contact address
Henrik wrote:
If VIRTUAL_HOST_OVERVIEW is set to Yes, the domain is the result of
looking up the host domain from the URL used to access the page.
This appears to be the case:
In fact if I access the page with mail.domainname.ca/mailman/, the
contact address is [EMAIL PROTECTED], whereas if I access the
page with domainname.ca/mailman/listinfo (ie without the mail.
subdomain), the contact address shows as [EMAIL PROTECTED]
Actually, my description in that reply was incomplete. I should have
added to the above
and if the host domain is not a key in VIRTUAL_HOSTS, the host domain
itself is used
Reading the domain from the URL is desirable as I have a number of
domain names associated with the account, and wish to have mailing lists
set up for all or most of them. But is seems like what should be used is
something like (in totally pseudo regex, I have no idea what the syntax
is in python)
add_virtualhost('/(mail\.)?(*.)/', '$2')
You need to do one of two things:
Either have one canonical host name per domain for web access, enforced
if necessary with rewrite rules in the web server, and then have one
add_virtualhost('web host name', 'corresponding email domain')
for each domain.
Or have two (assuming the email domain should be 'example.com')
add_virtualhost('example.com', 'example.com')
add_virtualhost('mail.example.com', 'example.com')
Note that it is OK to have two entries with the same email host if the
web hosts are different, but you can't have two entries with the same
web host as the second just replaces the first.
Is this true? What would the entry look like? (I don't unfortunately
have access to mm_cfg.py - is it in principle possible to have a
mm_cfg.py for a user of a linux system -- ie for a web account). I would
have to pass this on to the web host.
There is one mm_cfg.py for the whole mailman installation. The only way
around this is to run separate instances of Mailman for separate
domains.
Then the other problem would appear to be that the default mail address
([EMAIL PROTECTED]) is not set up properly on creation of the mail
list.
It is not an attribute of the list at all. The local part is the name
of the site list and the domain is determined as above. This is all
determined on the fly when the listinfo page is sent.
Yet, since this is presumably a cPanel Mailman, if it is the case that
the domain for mail to your lists IS mail.domainname.ca, you may be
able to solve the whole problem by just creating a 'mailman' list in
your own domain.
Sorry, don't quite get that. You mean create a list called
[EMAIL PROTECTED], and this would pre-empt the central installation
routing? And just make the list private, with only the owner as a
recipient?
Well, I didn't have enough information (and I still don't because I'm
shooting in the dark and don't know how cPanel does this), but I
thought your lists might be in the mail.domainname.ca domain and not
the domainname.ca domain. In that case, I was pretty sure you could
have created a [EMAIL PROTECTED] list. You may still be able
to create a [EMAIL PROTECTED] list which would override the site
list for your domain.
I don't know if it would work or not, but the worst that can happen is
it won't create the list, or it will but mail will still go to the
site list.
This is an interesting possibility, though if I understand it
right, the proper solution would be to have the mail list installation
process check sendmail for the existence of a default address for the
domain list administrator ([EMAIL PROTECTED]) and create one if it
doesn't exist. But I may not be understanding this properly. What about
creating a sendmail account called [EMAIL PROTECTED] Would this
pre-empt the mail from going to the installation-wide address?
It might. You could try that.
If this
were the case, then the remaining problem would be the aforementioned
assignment by add_virtualhost. True?
I think so.
--
Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Paul == Paul Tomblin
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Fri, 8 Dec 2006 20:04:51 -0500
Alan == Alan McConnell
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Fri, 8 Dec 2006 07:52:33 -0500
Paul Quoting Brad Knowles ([EMAIL PROTECTED]):
At 11:43 AM -0500 12/8/06, John A. Martin wrote:
See http://packages.debian.org/unstable/mail/mailman for a
description of the Debian Mailman package that integrates
archiving Further down that page under the
heading Download mailman click on one of the list of
files buttons and see among other things:
usr/lib/mailman/Mailman/Archiver/pipermail.py
I've never claimed to be a Debian expert, and if they're
mucking about with packages that include certain features by
default in order to remove those features,
What makes you, Brad, think that Debian removes pipermail when shown
where it can be seen by anybody that it is included! What mucking
about or other removal of features are you, or someone else, referring
to?
then there's not much I can do to help the poor souls that are
stuck with that kind of stuff.
The first recourse when having trouble with a Debian package should
not be to the upstream but to the Debian maintainers, usually via a
Debian Bug report.
Paul I don't know what John is experiencing,
I am experiencing dismay at the innuendo followed by disinformation
with respect to the Debian Mailman package.
Paul but I'm using Mailman installed from Debian Stable, and have
Paul been for a couple of years, and it's always had pipermail.
Yes. AFICT the absence of pipermail from the Debian Mailman is a
fantasy held only by Brad Knowles as the explanation for difficulties
experienced by a user who remarked as follows:
Alan mm 2.1.5 . But under Debian, so it has
Alan experienced/endured the Debian security upgrade
Alan procedures.
jam
pgpETWwqkMUPs.pgp
Description: PGP signature
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
At 10:17 PM -0500 12/8/06, John A. Martin wrote: I've never claimed to be a Debian expert, and if they're mucking about with packages that include certain features by default in order to remove those features, What makes you, Brad, think that Debian removes pipermail when shown where it can be seen by anybody that it is included! What mucking about or other removal of features are you, or someone else, referring to? I didn't say that Debian did. Alan McConnell said that Mailman had been installed without pipermail: Meanwhile, I am adminning(sp?), through my ISP, a new but quite active E-list. But their mailman install is incomplete; they haven't put in Pipermail (about which I know _nothing_). When asked what kind of whacked-out version of Mailman they were running that didn't include the built-in version of pipermail, he said: mm 2.1.5 . But under Debian, so it has experienced/endured the Debian security upgrade procedures. To which my reply was: Okay, now that is one of the most bizarre things I've heard of in a very long time. I cannot comprehend how they could possibly ship a version of Mailman 2.1.x that does not automatically include the bundled Pipermail component. This lead to your mildly offensive reply, where you publicly said: See http://packages.debian.org/unstable/mail/mailman for a description of the Debian Mailman package that integrates archiving Further down that page under the heading Download mailman click on one of the list of files buttons and see among other things: usr/lib/mailman/Mailman/Archiver/pipermail.py Yet nowhere on that page do I find any reference to pipermail. If you had wanted to provide proof that Debian provides pipermail as part of the package, you should have been much less obtuse and offensive with your language, and much more explicit in the URL you provided. Based on what I saw on that page, and the rude behaviour I was seeing from you, I concluded that Debian had actually done precisely what I had previously commented on to Alan, and led to my response: I've never claimed to be a Debian expert, and if they're mucking about with packages that include certain features by default in order to remove those features, then there's not much I can do to help the poor souls that are stuck with that kind of stuff. However, no amount of your expecting me to do fact-checking with the way that Debian is building their highly modified packaged versions of our software is going to change that. It's physically impossible to keep up with how every single vendor is choosing to ship our software. Note that I do not, at any time, make an outright claim that Debian was stripping pipermail from the Mailman package that they were providing -- I said ... if they're mucking about with packages that include certain features by default to remove those features Obviously the subtle difference in this statement was completely lost on you. The first recourse when having trouble with a Debian package should not be to the upstream but to the Debian maintainers, usually via a Debian Bug report. I don't think it's appropriate for us to be filing bug reports on these sorts of things with package maintainers of a given platform. If the users of those packages wish to file bug reports, I would fully support that. If the package maintainers wish to come back to us and file bug reports against our code in our bug tracking system, I welcome that. But no one here has the time to go tracking down every single bloody bizarre behaviour that may or may not be a result of something strange that a package maintainer decided to do, and then to track them down and sit on them until they fix their bug. That is, unless you're volunteering to do that, of course. If so, then please just go ahead and do so, and quit making worse a situation that is already pretty bad to begin with. Paul I don't know what John is experiencing, I am experiencing dismay at the innuendo followed by disinformation with respect to the Debian Mailman package. If you want clarity in a discussion, it would really help if you would actually provide some measure of clarity in your own postings. If I've made a mistake, and that fact is pointed out to me in a reasonably neutral and constructive way, I generally accept and even welcome the correction and genuinely work towards a good resolution to the problem. However, if your first reaction is obtuse and offensive bluster with baseball bats, then you damn well better be prepared for the kind of reaction you're going to receive. Paul but I'm using Mailman installed from Debian Stable, and have Paul been for a couple of years, and it's always had pipermail. Yes.
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Brad Knowles writes: I've never claimed to be a Debian expert, and if they're mucking about with packages that include certain features by default in order to remove those features, then there's not much I can do to help the poor souls that are stuck with that kind of stuff. That's not what they do. Debian splits packages into components for ease of maintenance of the package infrastructure. Users are expected to select virtual packages that cause a collection of components to be installed. By design, the package named mailman is either a complete virtual package, or a single package that contains all of Mailman. A package named after the upstream package is intended to install all of it. It works. The mailman package did install a complete Mailman on several Debian systems where I use Mailman. This is not the same as cPanel, which *does* deliberately inhibit capabilities that Mailman admins need. This is a situation where the user misjudges what the bug is, and reports to the wrong channel. It's not terribly nice of Debian to risk your time on their ability to create robust, non-buggy virtual packages, but it is the result of providing a service that the Mailman project does not, and should not. This policy will occasionally result in the kind of problem we see here. It's a tradeoff. You don't like it as it manifests on Mailman-Users, and you shouldn't---all we're ever going to see here is the bugs. But all you need to say is the Mailman project distributes Mailman with the pipermail archiver included. If you don't have it, it is a packaging issue. Your vendor Debian needs to know about it, and you need to get support from them. In sum, I think you are doing the Mailman project a disservice by denigrating Debian. If they're really doing their users such a disservice, you (or somebody from Mailman who understands the issues) should report it as a bug. In my experience the various distros, including Debian, are responsive to upstream maintainers. Regards, -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] A scrubber issue
Hi all, Mark Sapiro wrote: Todd Zullinger wrote: Attached is the original message from the list mbox and one that I munged up to included a content-type: text/plain; charset=3Dus-ascii. I see the symptom with the original message. I'll look further, but it seems to have something to do with the fact that the first sub-part has no headers at all. I have looked at RFC 2045 and I don't see that any headers are required, but I don't yet know what the underlying issue in Scrubber is. It looks like the problem is something to do with email package behavior. Here is a test code to reproduce the problem: from email import message_from_string s = '''MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ABCDEFG Preamble --ABCDEFG A message without header --ABCDEFG Content-Disposition: inline Another text with a header --ABCDEFG-- ''' m = message_from_string(s) for p in m.walk(): print p.get_content_type() if p: print p.get_payload(decode=True) This program prints out like this: multipart/mixed None text/plain text/plain Another text with a header Note that 'A message without header' is not printed out. If I remove 'If p:' and print the payload unconditionally, I get: multipart/mixed None text/plain A message without header text/plain Another text with a header Here, the no-header part is printed out. The patch of revision 7281 may have been over-protective against the bug-id: 1099138 in message reconstruction part (line 327 in http://mailman.svn.sourceforge.net/viewvc/mailman/branches/Release_2_1-maint/mailman/Mailman/Handlers/Scrubber.py?r1=7207r2=7281 ) but we may have to be paranoid against wired message like no-header text. I believe well behaved MUAs won't generate no-header text parts. (or, I believed ;-) -- Tokio Kikuchi, [EMAIL PROTECTED] http://weather.is.kochi-u.ac.jp/ -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman archive messages(not rm, but install!)
Brad == Brad Knowles Re: [Mailman-Users] Mailman archive messages(not rm, but install!) Fri, 8 Dec 2006 22:28:19 -0600 Brad At 10:17 PM -0500 12/8/06, John A. Martin wrote: I've never claimed to be a Debian expert, and if they're mucking about with packages that include certain features by default in order to remove those features, What makes you, Brad, think that Debian removes pipermail when shown where it can be seen by anybody that it is included! What mucking about or other removal of features are you, or someone else, referring to? Oops. The first sentence of mine above was intended to end with a question mark rather than an exclamation mark. Maybe that would have sounded better. Brad I didn't say that Debian did. Alan McConnell said that Brad Mailman had been installed without pipermail: Does that mean that the Debian Package does not carry pipermail? Brad Meanwhile, I am adminning(sp?), through my ISP, a new Brad but quite active E-list. But their mailman install is Brad incomplete; they haven't put in Pipermail (about which Brad I know _nothing_). Brad When asked what kind of whacked-out version of Mailman they Brad were running that didn't include the built-in version of Brad pipermail, he said: Brad mm 2.1.5 . But under Debian, so it has Brad experienced/endured the Debian security upgrade Brad procedures. Does that mean that the Debian Package does not carry pipermail? Brad To which my reply was: Brad Okay, now that is one of the most bizarre things I've Brad heard of in a very long time. I cannot comprehend how Brad they could possibly ship a version of Mailman 2.1.x Brad that does not automatically include the bundled Brad Pipermail component. Between you and Alan you suggest something that is not true. You are an authority on this list (and elsewhere). Beginners will conclude From your statement that they should avoid using the Debian package. Whether that is good advice or not it is not justified by the line of evidence above. Excuse me if I have a tendency based upon the above to suspect a readiness to assume that Debian does bizarre things when there is no evidence supporting that assumption. Brad This lead to your mildly offensive reply, where you publicly Brad said: Brad See http://packages.debian.org/unstable/mail/mailman Brad for a description of the Debian Mailman package that Brad integrates archiving Further down that Brad page under the heading Download mailman click on one Brad of the list of files buttons and see among other Brad things: Brad usr/lib/mailman/Mailman/Archiver/pipermail.py I do not know what there is offensive and no offense was intended. I generally try to be precise and succinct. If one clicks one of the buttons mentioned, one sees a URL something like http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelistword=mailmanversion=unstablearch=i386 (for the i386 architecture) which I thought was uglier than mentioning the button to click at the URL I gave. Brad Yet nowhere on that page do I find any reference to Brad pipermail. If you had wanted to provide proof that Debian Brad provides pipermail as part of the package, you should have Brad been much less obtuse and offensive with your language, and Brad much more explicit in the URL you provided. If you had bothered to click on one of the list of files buttons you would have (for the i386 archetecture) seen the pipermail.py file as the 19th of 3438 files. The first recourse when having trouble with a Debian package should not be to the upstream but to the Debian maintainers, usually via a Debian Bug report. Brad I don't think it's appropriate for us to be filing bug Brad reports on these sorts of things with package maintainers of Brad a given platform. If the users of those packages wish to Brad file bug reports, I would fully support that. If the Brad package maintainers wish to come back to us and file bug Brad reports against our code in our bug tracking system, I Brad welcome that. I agree with what you say in the paragraph above and would have thought that went without saying. However when packaging issues arise I think it would be good to suggest that users of various distributions should consult whatever support the distribution offers. For the Debian Mailman package, which does not have a related Debian mailing list, the Debian user should usually file a Debian Bug report. Presumably the one having trouble with a Debian package is a Debian user not the us which I take to mean you and the Mailman community as a whole. I've said enough. My enthusiasm is well restrained when it is necessary to craft each sentence
