Mailman 3 July 2002 - Mailman-Developers

[ mailman-Bugs-584989 ] bounced large messages are deleted!
by noreply＠sourceforge.net 22 Jul '02

22 Jul '02

Bugs item #584989, was opened at 2002-07-22 18:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_i… Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_i…

1 0

[ mailman-Bugs-584775 ] long listnames in RFC2369 break header!
by noreply＠sourceforge.net 22 Jul '02

22 Jul '02

Bugs item #584775, was opened at 2002-07-22 09:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_i… Category: mail delivery Group: 2.1 beta >Status: Closed Resolution: None >Priority: 6 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: long listnames in RFC2369 break header! Initial Comment: We have some lists with very long listnames. If I include RDC2369-headers they're breaking up the header and suddenly they`re part of the mailbody. It seems, that CookHeaders.py adds a line break or an empty line or something like that and the MTA (Postfix) takes this empty line as the split between header and beginning body. Peer ---------------------------------------------------------------------- >Comment By: Peer Heinlein (pheinlein) Date: 2002-07-22 18:09 Message: Logged In: YES user_id=581680 Sorry, it seems that this bug is already fixed in snapshot 20020722. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_i…

1 0

[ mailman-Bugs-584917 ] Extra slash in private archive URL
by noreply＠sourceforge.net 22 Jul '02

22 Jul '02

Bugs item #584917, was opened at 2002-07-22 07:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Arnett (narnett) Assigned to: Nobody/Anonymous (nobody) Summary: Extra slash in private archive URL Initial Comment: Mailman 2.0 on RH 7.1 -- After converting a public archive to private and rebuilding with bin/arch, the web pages pointing to the private archive have an extra slash in them (after /private/). E.g.: http://www.mccmedia.com/mailman/private//myli st/ I haven't tried to reproduce this yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_i…

1 0

[ mailman-Bugs-584775 ] long listnames in RFC2369 break header!
by noreply＠sourceforge.net 22 Jul '02

22 Jul '02

Bugs item #584775, was opened at 2002-07-22 09:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_i… Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) >Summary: long listnames in RFC2369 break header! Initial Comment: We have some lists with very long listnames. If I include RDC2369-headers they're breaking up the header and suddenly they`re part of the mailbody. It seems, that CookHeaders.py adds a line break or an empty line or something like that and the MTA (Postfix) takes this empty line as the split between header and beginning body. Peer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_i…

1 0

[ mailman-Bugs-584775 ] long listnames in RFC2369 breake header!
by noreply＠sourceforge.net 22 Jul '02

22 Jul '02

Bugs item #584775, was opened at 2002-07-22 09:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_i… Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: long listnames in RFC2369 breake header! Initial Comment: We have some lists with very long listnames. If I include RDC2369-headers they're breaking up the header and suddenly they`re part of the mailbody. It seems, that CookHeaders.py adds a line break or an empty line or something like that and the MTA (Postfix) takes this empty line as the split between header and beginning body. Peer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_i…

1 0

patch: reply-to list and sender
by Christian Seitz 21 Jul '02

21 Jul '02

Hi all, we moved our mailing lists from Majordomo to Mailman several months ago and one disadvantage of Mailman is, that you can set the reply-to only to "Poster", "This list" and "Explicit address", but not to something like "This list and sender". This patch is testet with Mailman 2.0.6 to 2.0.11 and it works fine for us. Could you please include this patch in the next version of Mailman? --- mailman-2.0.11/Mailman/MailList.py Sun Jul 21 15:51:06 2002 +++ mailman-2.0.11-patched/Mailman/MailList.py Sun Jul 21 15:51:10 2002 @@ -420,7 +420,7 @@ ' text will be added to the unsubscribe message.'), ('reply_goes_to_list', mm_cfg.Radio, - ('Poster', 'This list', 'Explicit address'), 0, + ('Poster', 'This list', 'Explicit address', 'This list and sender'), 0, '''Where are replies to list messages directed? <tt>Poster</tt> is <em>strongly</em> recommended for most mailing lists.''', --- mailman-2.0.11/Mailman/Handlers/CookHeaders.py Sun Jul 21 15:51:44 2002 +++ mailman-2.0.11-patched/Mailman/Handlers/CookHeaders.py Sun Jul 21 15:51:41 2002 @@ -89,7 +89,11 @@ elif mlist.reply_goes_to_list == 2: xreplyto = msg.get('reply-to') msg['Reply-To'] = mlist.reply_to_address - # Give the recipient some ability to un-munge things. + # Set Reply-To: to list and sender + elif mlist.reply_goes_to_list == 3: + xreplyto = msg.get('reply-to') + msg['Reply-To'] = mlist.GetListEmail() + ', ' + msg.GetSender() + # Give the recipient some ability to un-munge things. if xreplyto: msg['X-Reply-To'] = xreplyto # Chris -- Christian Seitz <chris(a)in-berlin.de> http://berli.net/ IN-Berlin - http://www.in-berlin.de/ PGP Fingerprint: A9 17 03 0D 36 AB 07 4E D0 1E C3 8E 3F B0 66 9A

1 0

[ mailman-Feature Requests-584468 ] listinfo: cache
by noreply＠sourceforge.net 21 Jul '02

21 Jul '02

Feature Requests item #584468, was opened at 2002-07-21 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=584468&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: listinfo: cache Initial Comment: We`re running more than 700 lists on our mailinglist-server. Mailman needs between 20 and 40 seconds to generate the public listinfo page. Wouldn`t it be possible to generate a listinfo.cache including all these necessary informations to speed up the process? These listinfo.cache could be valid for some specific time, before it is removed and regenerated. Or this cache-file can be deleted if somenbody is changing his list configuration. Thanks... p.heinlein(a)jpberlin.de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=584468&group_i…

1 0

RE: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail]
by Dan Kohn 20 Jul '02

20 Jul '02

RFC 822 has been obsoleted by RFC 2822. See my next message for more details. http://www.normos.org/en/summaries/ietf/rfc/rfc822.html - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600> -----Original Message----- From: Alan Batie [mailto:alan@batie.org] Sent: Saturday, July 20, 2002 10:05 To: Terri Oda Cc: mailman-developers(a)python.org Subject: Re: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] On Sat, Jul 20, 2002 at 12:13:08PM -0400, Terri Oda wrote: > I've been getting these periodically from one of my list members' servers > and I'm curious... is > To: user(a)domain.com <user(a)domain.com> > really an invalid address? MailMAX is the only server I've ever seen thrown > an error on this. I thought it was legal, but on reviewing RFC 822, I find that it is, in fact, invalid: if the phrase outside <>'s contains any of spaces, ctrls or: specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. ...it must be quoted: To: "user(a)domain.com" <user(a)domain.com> -- Alan Batie ______ www.rdrop.com/users/alan Me alan(a)batie.org \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ razor.sourceforge.net NO SPAM! A free society is a place where it's safe to be unpopular. -Adlai Stevenson, statesman (1900-1965) _______________________________________________ Mailman-Developers mailing list Mailman-Developers(a)python.org http://mail.python.org/mailman-21/listinfo/mailman-developers

1 0

Opening up a few can o' worms here...
by Chuq Von Rospach 19 Jul '02

19 Jul '02

Howdy, ya'll. Back from vacation, and opening up a few can o' worms (gotta big can opener here!) for everyone to chew on.... Apologize if this goes all over the map, a bunch of things have been simmering and I want to pass them along to get your perspective, see if they are issues that ought to be considered in Mailman somehow, and perhaps warn you of stuff I'm seeing before it hits you... First, a minor announcement. I'm no longer in charge of the mailing lists at apple, sort of. We've hired a person full-time, and he's been taking over the lists server as his full-time responsibility, allowing me to go off and work on other projects. I'm still in the loop, just not "it". I'm still going to be heavily involved as we move that box to Mailman 2.1, and after that, probably fade a bit more into the woodwork (I still run my Mailman box at home, however, so I'm not going away. JC, quite jeering) Anyway, on to issues more substantive. With the explosion of spam, privacy issues and protection issues have been of great interest around here, including fascinating (but not family friendly) discussions with our legal beagles. The end result of all of that is a decision that subscriber e-mail addresses are considered a significant asset that needs to be protected to the greatest extent possible. We're currently evaluating exactly what that means (and it means the list rules/T&Cs are going to need to be revamped as well, in ways we're still figuring out) to do what we can to make sure people who post to the mailing lists don't get harvested. One thing we're definitely doing is moving to a cloaked archive. Since we already distribute all archives out of HTTP, not FTP, we're working on a CGI that'll strip all e-mail information out of messages on the fly (among other things, like header cleanup and some trivial formatting fixes). The idea is simple -- we've finally hit the point where you can't put an e-mail address up on a public site under any cirucmstance safely, so we're having to move to a system where we simply don't do that. I think the Mailman stuff needs to think about this, also. It impacts the archiving setup and other issues, but the harvesters have hit the point where we simply can't risk disclosing that info. It creates other problems -- you can't see a posting in the archive and send email to that person with more questions (or answers), but that seems trivial compared to the problems the spammers are causing. A secondary issue here is the problem of disclosing admins and admin addresses. I know we've hashed that through once, but we've come to the (somewhat reluctant) decision to whitelist all public, non-personal email addresses. We're going to be implementing TMDA to do this, and will be switching all admin to generic addresses that filter through TMDA, as well as things like postmaster@ and the like. While I hate making users jump through hoops to get through to a real person (for those that don't know, TMDA is an overt whitelist. If you're not on the whitelist, you get mail back telling you to take some action, and until you do, the mail isn't delivered), but the abuse by the spammers on admin addresses is now so bad I'm declaring defeat and going to the whitelist. I'm going to look and see if I can interface TMDA to the subscriber databases so that subscribers are by definition whitelisted, but we've hit the poiint where we have to do this. I'm not happy about it, but the war is lost, I think. And speaking of privacy, harvesting and spamming, a new and disturbing thing happened this weekend that I want to bring up -- one for which I have lots of questions, but no real answers. A bunch of users on some of our mail lists were spammed, and it became very clear very quickly that addresses were harvested off of at least one of our mail lists. As you might guess, a lynch mob formed, and I lit the first virtual torch and we all sharpened the pitchforks. Fortunately, the person who did it came forward to me and admitted guilt, and explained what happened. And what happened is pretty damn disturbing. See, he had one of those "I must tell the masses!" moments, where he finally felt it was time to send out a call to arms on a subject he felt strongly about. So what he did was open up his address book and send his message to everyone in it. And he's running one of these new e-mail clients that happily caches addresses it sees in case you want them again. So all of the addresses of people posting to the mailing lists he subscribed to were in his address book cache, so when he grabbed his address book, he grabbed all of those addresses, too. So we have a clear violation of our anti-harvesting rules -- yet he didn't overtly harvest. He just grabbed what was in his address book at the time. This creates a major privacy quagmire. How do you set up rules for something like that? Where does ownership and protection end? (I'm talking ethically, not technically. I think we all realize that once someone posts email to a list, you've given up control to anyone who doesn't feel obligated to follow the rules). This wasn't a case of overtly violating the rules, but of a piece of technology creating a situation where it wasn't understood there were rules being violated. I just don't know how to deal with the issues this address caching causes. Ultimately, we're going to have to rethink our "no harvesting" rules, and likely also write disclaimers explaining what our limits are. We've actually considered switching our lists to obscured addresses, turned that down as being worse than the disease (for now). But now we're wondering if we have to go to some sort of address cloaking ON lists, maybe some kind of address remapping through the server for replies, something. And I'm gritting my teeth at the developers who created those @#$@$#@$#23 caches (which are nice in some ways) for not also creating some way to flag addresses as not cacheable. Because, IMHO, that'd solve this problem. But they didn't. Grumble. I'm curious what people think about this latest thing. The good news is he wasn't trying to harvest us. The bad news is, he wasn't trying to harvest us. And the b-tch of it is, I really don't have a comfortable feeling for how to deal with this new situation yet... But I think it's an issue we have to come to grips with. Are we hitting a point where mail list servers have to act as blind front ends for all of the subscribers, where replies are processed by those servers, and the server then takes on the job of acting as a troll-exterminator and spam blocker? And what does that really mean for things like Mailman? Happy Macworld Expo week, all. If you need me, I'll be in the war room, beating my head against a wall. -- Chuq Von Rospach, Architech chuqui(a)plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier.

15 89

Re: [Mailman-Developers] Well, Chuq...
by J C Lawrence 19 Jul '02

19 Jul '02

On Thu, 18 Jul 2002 16:37:19 -0700 (PDT) Dan Mick <dmick(a)utopia.West.Sun.COM> wrote: > And I said "you all go" for a reason. ;) Aye, there was value in that thread. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0