Mailman 3 July 2002 - Mailman-Developers

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

23 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: 2.0.x Status: Closed Resolution: Works For Me >Priority: 2 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. ---------------------------------------------------------------------- >Comment By: Nick Arnett (narnett) Date: 2002-07-23 22:25 Message: Logged In: YES user_id=390959 The value for PRIVATE_ARCHIVE_URL was the problem... but I don't think this bug should be closed until the file is modified to include a comment to that effect, or the code modified to allow a trailing slash. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-23 22:08 Message: Logged In: YES user_id=12800 Check the value for PRIVATE_ARCHIVE_URL in your mm_cfg.py file. I'll be it ends in a slash. It shouldn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_i…

1 0

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

23 Jul '02

FYI, Outlook with Exchange Server 2000, does the "right thing". Here's the To lines on an outgoing message: From: "Dan Kohn" <dan(a)dankohn.com> To: <dan(a)xkey.com> Cc: <dan(a)nixon.xkey.com> - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600> -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Tuesday, July 23, 2002 13:38 To: Terri Oda Cc: Dan Wing; Keith Moore; Dan Kohn; Jay R. Ashworth; mailman-developers(a)python.org; ietf-822(a)imc.org Subject: Re: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] > Actually, the offending client in this case is Sylpheed, much as I'd like to > blame outlook. (goodness knows, I blame it for Klez.) I take it Sylpheed is the one that generates bogus phrases? > I'd have to find someone with a copy of outlook to try it and be sure, but I > think outlook does "user(a)domain.com" <user(a)domain.com> which probably > wouldn't have been a problem. it might be syntactically legal, but it's still utterly stupid. Keith

2 1

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

23 Jul '02

Bugs item #584917, was opened at 2002-07-22 10:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_i… Category: None >Group: 2.0.x >Status: Closed >Resolution: Works For Me 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. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:08 Message: Logged In: YES user_id=12800 Check the value for PRIVATE_ARCHIVE_URL in your mm_cfg.py file. I'll be it ends in a slash. It shouldn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_i…

1 0

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

23 Jul '02

Bugs item #584989, was opened at 2002-07-22 12: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: Closed >Resolution: Fixed 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 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:06 Message: Logged In: YES user_id=12800 It does look like it's a bug in the German translation for that message. I'm about to commit a fix to the German catalog; can you try doing a cvs update and see if that fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_i…

1 0

Re: [Mailman-Developers] ASCII Prefixes
by barry＠zope.com 23 Jul '02

23 Jul '02

>>>>> "BG" == Ben Gertzfield <che(a)debian.org> writes: >> Here's a tricky issue, one with a high rabbit hole probability >> (which I'd like to avoid if possible ;). OTOH, we could use a >> simple heuristic to try to keep the prefix unencoded in the >> common case: if the prefix contains only ascii characters, we >> could choose to leave it in the default us-ascii (or really the >> None) encoding. If it contains non-ascii characters, we'd have >> no choice but to encode it. BG> OTOOH, we could make *this* the per-list setting; we could BG> have the heuristic guess whether to encode or not if the list BG> owner wants it. That way we don't have to have a ton of prefix BG> character set settings, and we make the people who get angry BG> at seeing [MyFrenchList] encoded in header QP happy. Is subject_prefix the only place this option would make sense? If so, then I can probably add a boolean variable to the General admin page, otherwise I might want to add something to the Languages page. BG> Sorry for being absent recently, I'm finally at a job that's BG> challenging enough to make my brain not want to do coding at BG> home. :) That's good (I think ;). Welcome back, and I hope you'll stick around! -Barry

2 1

Problem with 2.0.12 configure
by Bill Bradford 23 Jul '02

23 Jul '02

root@ohno:/usr/local/src/mailman-2.0.12> sh ./configure --prefix=/usr/local/mailman loading cache ./config.cache checking for --with-python... no checking for python... /usr/local/bin/python checking Python interpreter... /usr/local/bin/python checking Python version... 2.2.1c1 checking for a BSD compatible install... /usr/local/bin/install -c checking whether make sets ${MAKE}... yes checking for true... /usr/bin/true checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether #! works in shell scripts... yes checking for --with-var-prefix... no checking for --with-username... mailman checking for mailman UID... 10004 checking for --with-groupname... mailman checking for mailman GID... 10004 checking permissions on /usr/local/mailman... okay checking for mail wrapper GID... 1 checking for CGI wrapper GID... 60001 checking for CGI extensions... no ./configure: test: unknown operator == Same result with sh or bash. Any suggestions? Nothing relevant in config.log.. Tracing the script, this is what I get: # attempt to figure out the default hostname and URL from socket import * import string import sys import os def barf(fqdn, www): sys.stdout = sys.stderr print 'host info not found, set \$MAILHOST and/or \$WWWHOST environ vars' print '\$MAILHOST=%s, \$WWWHOST=%s' % (fqdn, www) sys.exit(1) fqdn = os.environ.get('MAILHOST') www = os.environ.get('WWWHOST') aliases = [] if fqdn: aliases.append(fqdn) if www: aliases.append(www) if not fqdn: try: host, aliases, ipaddrs = gethostbyaddr(gethostbyname(gethostname())) except herror: barf(fqdn, www) aliases.insert(0, host) for h in aliases: parts = string.split(h, '.') if 5 > 1: if parts[0] == 'www': www = h elif not fqdn: fqdn = h if www and fqdn: break if fqdn is None: barf(fqdn, www) if www is None: www = fqdn fp = open('conftest.out', 'w') if not www and fqdn: fp.write('%s\n%s\n' % (fqdn, fqdn)) elif www: dhn = string.join(string.split(www, '.')[1:], '.') fp.write('%s\n%s\n' % (dhn, www)) else: fp.write('please.change.me\nwww.please.change.me\n') fp.close() EOF $PYTHON conftest.py if [ "$?" == "1" ] then exit fi ./configure: test: unknown operator == Bill -- bill bradford / mrbill(a)mrbill.net / austin, texas ------------------------------------------------------------------------- I'm reminded of the day my daughter came in, looked over my shoulder at some Perl 4 code, and said, "What is that, swearing?" -- Larry Wall

2 1

[ mailman-Patches-585643 ] Mailman 2.0.13 candidate patch
by noreply＠sourceforge.net 23 Jul '02

23 Jul '02

Patches item #585643, was opened at 2002-07-23 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_i… Category: None Group: Mailman 2.0.x Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Mailman 2.0.13 candidate patch Initial Comment: Mailman 2.0.12 had compatibility problems with Python 1.5.2. This patch fixes these AFAICT, and a few other small bugs that have cropped up. Note that this is a candidate patch. The actual MM2.0.13 patch may be different. However I would really appreciate folks using Mailman 2.0.12 (especially if you're using Python 1.5.2) to give this patch a try and see if it fixes your problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_i…

1 0

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

23 Jul '02

"user(a)domain.com <user(a)domain.com>" is not legal under RFC 2822. It is must not generate under either current (section 3) or obsolete (section 4) grammar. <mailbox> is defined as "[display-name] angle-addr", <display-name> is a <phrase>, which is "1*word", where <word> is "atom / quoted-string". <atom> is defined in section 3.2.4 *not* to include "@". In other words, you can't use an unquoted "@" in a <display-name> under either current or obsolete grammar. However, you could include the @ as part of a <quoted-string>, defined in section 3.2.5. Thus, the following: user(a)domain.com <user(a)domain.com> <-- illegal "user\(a)domain.com" <user(a)domain.com> <-- legal I'm cc'ing ietf-822(a)imc.org, which has taken the place of comp.mail.headers, for confirmation. - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600> -----Original Message----- From: Jay R. Ashworth [mailto:jra@baylink.com] Sent: Saturday, July 20, 2002 09:12 To: 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 keep meaning to email them and ask what's up, since it seems like a bug to > me, but before I do, does anyone know if this is actually an invalid address > and other servers just deal with it? According to my reading of RFC 2822 3.4, no, it's fine: if a mailbox can be a name-addr, and a name-addr is a display-name followed by an angle-addr, then the display-name should be treated as a comment by any mailre, provided that the angle-addr is syntactically correctly constructed. But this is more properly a topic for comp.mail.headers. (Does that NG still exist? ;-) Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") _______________________________________________ Mailman-Developers mailing list Mailman-Developers(a)python.org http://mail.python.org/mailman-21/listinfo/mailman-developers

4 5

Mailman 2.0.12 error
by Kory Wheatley 23 Jul '02

23 Jul '02

This is very critical I get this fixed, I'm running 150 production mailing lists, here's my problem. I keep receiving this below error when messages are sent to my lists. I'm running Red Hat 7.2 mailman 2.0.12. Does anyone know the solution? If I take them out of the qfiles directory and then put a few in at a time then the messages are sent rather than piling up in the qfiles directory and setting there idle. I've had this problem the day after I upgraded to mailman 2.0.12 from mailman 2.0.11, is there a patch fix. qrunner(18056): Traceback (innermost last): qrunner(18056): File "/home/mailman/cron/qrunner", line 283, in ? "/home/mailman/cron/qrunner", line 283, in ? qrunner(18056): kids = main(lock) qrunner(18056): File "/home/mailman/cron/qrunner", line 253, in main qrunner(18056): keepqueued = dispose_message(mlist, msg, msgdata) qrunner(18056): File "/home/mailman/cron/qrunner", line 157, in dispose_message qrunner(18056): mlist.ParseMailCommands(msg) qrunner(18056): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands qrunner(18056): precedence = msg.get('precedence', '').lower() qrunner(18056): AttributeError : 'string' object has no attribute 'lower' qrunner(18059): Traceback (innermost last): qrunner(18059): File "/home/mailman/cron/qrunner", line 283, in ? qrunner(18059): kids = main(lock) qrunner(18059): File "/home/mailman/cron/qrunner", line 253, in main qrunner(18059): keepqueued = dispose_message(mlist, msg, msgdata) qrunner(18059): File "/home/mailman/cron/qrunner", line 157, in dispose_message qrunner(18059): mlist.ParseMailCommands(msg) qrunner(18059): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands qrunner(18059): precedence = msg.get('precedence', '').lower() qrunner(18059): AttributeError : 'string' object has no attribute 'lower' qrunner(18066): Traceback (innermost last): -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him.

2 1

ASCII Prefixes
by barry＠zope.com 23 Jul '02

23 Jul '02

Here's a tricky issue, one with a high rabbit hole probability (which I'd like to avoid if possible ;). Say you've got a mailing list that accepts both French and English, with French as the default language. The default charset for French is iso-8859-1 and for English us-ascii. Now say you want to add a prefix to your list, say "[MyList]", and you're users like to send messages to the list with funny <wink> non-ascii characters in iso-8859-1. What Mailman 2.1 cvs will do now is encode the prefix using the charset for the list's default language. So you'd likely end up with a Subject: header like Subject: =?iso-8859-1?q?[MyList]_?= =?iso-8859-1?hello_world?= or some such. Encoding the prefix can be considered ugly, but unfortunately we don't really have a way to specify a charset for the subject prefix (or footers, or other added text) apart from the default language's charset. So this is /almost/ the best we can do, even though it's kind of ugly. OTOH, we could use a simple heuristic to try to keep the prefix unencoded in the common case: if the prefix contains only ascii characters, we could choose to leave it in the default us-ascii (or really the None) encoding. If it contains non-ascii characters, we'd have no choice but to encode it. I really don't want to go down the path of providing a gui for different prefixes for each supported language. Eventually, maybe that's what we need to do, but I'd like to avoid that for MM2.1. I think this approach should be good enough, but I'd like to hear comments, especially from Asian language users. -Barry

2 1

[ mailman-Bugs-585484 ] virtual domain lists misdirect autoreply
by noreply＠sourceforge.net 23 Jul '02

23 Jul '02

Bugs item #585484, was opened at 2002-07-23 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_i… Category: bounce detection Group: None Status: Open Resolution: None Priority: 5 Submitted By: Byron T. Watts (btwatts) Assigned to: Nobody/Anonymous (nobody) Summary: virtual domain lists misdirect autoreply Initial Comment: Using mailman with virtual domain hosting. Bounced messages for a particular list are going to the wrong list administrator (not even on the same domain). The particular notices that I'm seeing misdirected, are the <i>useridi> is on vacation messages. I am not certain whether other messages are being similarly misdirected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_i…

1 0

[ mailman-Bugs-585270 ] qrunner fails with RHL7.2 python 1.5.2
by noreply＠sourceforge.net 23 Jul '02

23 Jul '02

Bugs item #585270, was opened at 2002-07-23 17:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585270&group_i… Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Stuart Prescott (themill) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner fails with RHL7.2 python 1.5.2 Initial Comment: qrunner from mailman-2.0.12 (downloaded and installed from the src tarball) fails with Python 1.5.2 from RHL7.2 python-1.5.2-38. Error message from $prefix/logs/error is attached as is a patch that does seem to fix the problem and allow Mailman to work. (I'm not a Python programmer .. I noramlly use P**L so I'm not sure exactly what or why... please treat my patch with the greatest skepticism!) >From the mailing lists, there are quite a few ppl having problems with the RHL distributions of Python -- is this a compatability thing (that we can argue about whether it's RHL or Mailman that is at fault a la gcc for years to come?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585270&group_i…

1 0

[MAILER-DAEMON@mira.linknet.com.au: Undeliverable Mail]
by Terri Oda 22 Jul '02

22 Jul '02

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 keep meaning to email them and ask what's up, since it seems like a bug to me, but before I do, does anyone know if this is actually an invalid address and other servers just deal with it? ----- Forwarded message from MailMAX Error Responder <MAILER-DAEMON(a)mira.linknet.com.au> ----- Delivery-date: Sat, 20 Jul 2002 11:45:31 -0400 From: "MailMAX Error Responder" <MAILER-DAEMON(a)mira.linknet.com.au> Subject: Undeliverable Mail When we said... DATA .. the remote server gave us this error response ... 550 Syntax error in 'To' header: malformed address: <courses(a)linuxchix.org>\n may not follow courses(a)linuxchix.org : failing address is: courses(a)linuxchix.org <courses(a)linuxchix.org> This is a Permanent error, and we will not try to deliver it again. *** This message was automatically generated by the MailMAX Error Responder ***

4 3

[ mailman-Bugs-585229 ] opening holes by changing permissions?
by noreply＠sourceforge.net 22 Jul '02

22 Jul '02

Bugs item #585229, was opened at 2002-07-22 22:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_i… Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: opening holes by changing permissions? Initial Comment: I was having problems adding a list in Mailman 2.1beta via the web interface, it was giving me an error regarding permissions to the mailman/data/aliases.db file. This is the error I got: ... File "/var/mailman/Mailman/MTA/Postfix.py", line 46, in _update_maps raise RuntimeError, msg % (acmd, status, errstr) RuntimeError: command failed: /usr/sbin/postalias /var/mailman/data/aliases (status: 1, Operation not permitted) To fix this I changed the permissions on this file so apache could write to it. chmod a+w aliases.db This did fix the problem of creating and deleting lists via the web interface. Does anyone know if this would open up any security holes? Is there another way to fix the permissions problem that is more logical? Thanks for your help. Paul Marshall ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_i…

1 0

Mailman 2.0.12 error
by Kory Wheatley 22 Jul '02

22 Jul '02

I keep receiving this error when messages are sent to my lists. I'm running Red Hat 7.2 mailman 2.0.12. Does anyone know the solution? Jul 20 12:02:00 2002 qrunner(18056): Traceback (innermost last): Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/cron/qrunner", line 283, in ? Jul 20 12:02:00 2002 qrunner(18056): kids = main(lock) Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/cron/qrunner", line 253, in main Jul 20 12:02:00 2002 qrunner(18056): keepqueued = dispose_message(mlist, msg, msgdata) Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/cron/qrunner", line 157, in dispose_message Jul 20 12:02:00 2002 qrunner(18056): mlist.ParseMailCommands(msg) Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Jul 20 12:02:00 2002 qrunner(18056): precedence = msg.get('precedence', '').lower() Jul 20 12:02:00 2002 qrunner(18056): AttributeError : 'string' object has no attribute 'lower' Jul 20 12:03:00 2002 qrunner(18059): Traceback (innermost last): Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/cron/qrunner", line 283, in ? Jul 20 12:03:00 2002 qrunner(18059): kids = main(lock) Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/cron/qrunner", line 253, in main Jul 20 12:03:00 2002 qrunner(18059): keepqueued = dispose_message(mlist, msg, msgdata) Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/cron/qrunner", line 157, in dispose_message Jul 20 12:03:00 2002 qrunner(18059): mlist.ParseMailCommands(msg) Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Jul 20 12:03:00 2002 qrunner(18059): precedence = msg.get('precedence', '').lower() Jul 20 12:03:00 2002 qrunner(18059): AttributeError : 'string' object has no attribute 'lower' Jul 20 12:04:06 2002 qrunner(18066): Traceback (innermost last): Kory Wheatley

1 0

[ 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 18 Jul '02

18 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