From Dan Mick Sat Feb 2 00:04:28 2002 From: Dan Mick (Dan Mick) Date: Fri, 1 Feb 2002 16:04:28 -0800 (PST) Subject: [Mailman-Developers] Bug: Usernames with spaces Message-ID: <200202020004.QAA25573@utopia.West.Sun.COM> Somehow I accumulated several users who had either embedded (luser@hot mail.com) or trailing ('luser@hotmail.com ') addresses in Mailman; bounce processing wasn't matching and therefore not working, but outgoing mail still was, so I was still getting bounces. Someone somewhere isn't (or wasn't) validating by removing spaces or rejecting fields with spaces. Thank you, clone_member. From Dan Mick Sat Feb 2 01:29:18 2002 From: Dan Mick (Dan Mick) Date: Fri, 1 Feb 2002 17:29:18 -0800 (PST) Subject: [Mailman-Developers] Bug: Usernames with spaces Message-ID: <200202020129.RAA29138@utopia.West.Sun.COM> > Somehow I accumulated several users who had either embedded > (luser@hot mail.com) or trailing ('luser@hotmail.com ') addresses in s/addresses/spaces/ > Mailman; bounce processing wasn't matching and therefore not working, > but outgoing mail still was, so I was still getting bounces. > > Someone somewhere isn't (or wasn't) validating by removing spaces or > rejecting fields with spaces. I'll try to examine the web-page subscription stuff. > > Thank you, clone_member. From chuqui@plaidworks.com Mon Feb 4 18:11:22 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 04 Feb 2002 10:11:22 -0800 Subject: [Mailman-Developers] News gateway logging glitch. Message-ID: Looks like messages posted to the lists through the news <-> mail gateway (2.0.8) aren't ever logged into the system. They go into qfile and I never see entries in either post or smtp. That means, effectively, if you're trying to do accounting or usage reports, they're invisible, so reports are understating the actual usage of the list. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. From barry@zope.com Mon Feb 4 21:45:56 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 4 Feb 2002 16:45:56 -0500 Subject: [Mailman-Developers] News gateway logging glitch. References: Message-ID: <15455.276.894348.183866@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Looks like messages posted to the lists through the news <-> CVR> mail gateway (2.0.8) aren't ever logged into the system. They CVR> go into qfile and I never see entries in either post or CVR> smtp. That means, effectively, if you're trying to do CVR> accounting or usage reports, they're invisible, so reports CVR> are understating the actual usage of the list. Actually, messages travelling from news -> mail should get logged to logs/fromusenet. I believe this is true in both MM2.0.x and 2.1. See cron/gate_news. Messages traveling from mail->news don't get separate logging (except in the case of errors), but they're posted to mail first, so they should show up in logs/post. -Barry From Dan Mick Mon Feb 4 22:34:42 2002 From: Dan Mick (Dan Mick) Date: Mon, 4 Feb 2002 14:34:42 -0800 (PST) Subject: [Mailman-Developers] Bug: Usernames with spaces Message-ID: <200202042235.OAA18726@utopia.West.Sun.COM> Here's a simple fix to prevent people from subscribing through the web page with addresses including space characters: Index: Utils.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Utils.py,v retrieving revision 2.26 diff -u -r2.26 Utils.py --- Utils.py 2002/01/08 04:43:27 2.26 +++ Utils.py 2002/02/04 22:34:27 @@ -180,7 +180,7 @@ def ValidateEmail(s): """Verify that the an email address isn't grossly evil.""" # Pretty minimal, cheesy check. We could do better... - if not s: + if not s or ' ' in s: raise Errors.MMBadEmailError if _badchars.search(s) or s[0] == '-': raise Errors.MMHostileAddress > > Somehow I accumulated several users who had either embedded > > (luser@hot mail.com) or trailing ('luser@hotmail.com ') addresses in > > s/addresses/spaces/ > > > Mailman; bounce processing wasn't matching and therefore not working, > > but outgoing mail still was, so I was still getting bounces. > > > > Someone somewhere isn't (or wasn't) validating by removing spaces or > > rejecting fields with spaces. > > I'll try to examine the web-page subscription stuff. > > > > > Thank you, clone_member. > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From bob@nleaudio.com Mon Feb 4 22:58:14 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Mon, 04 Feb 2002 17:58:14 -0500 Subject: [Mailman-Developers] Bug: Usernames with spaces References: <200202042235.OAA18726@utopia.West.Sun.COM> Message-ID: <3C5F1206.FAD2A51C@nleaudio.com> Excellently simple fix! I added it to my 2.0.x installs. Thanks! Bob From chuqui@plaidworks.com Tue Feb 5 18:09:22 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 05 Feb 2002 10:09:22 -0800 Subject: [Mailman-Developers] News gateway logging glitch. In-Reply-To: <15455.276.894348.183866@anthem.wooz.org> Message-ID: On 2/4/02 1:45 PM, "Barry A. Warsaw" wrote: > Actually, messages travelling from news -> mail should get logged to > logs/fromusenet. I believe this is true in both MM2.0.x and 2.1. See > cron/gate_news. Ah, okay. But there should still be an smtp log entry when it's sent ot the subscribers, and it doesn't seem to happen. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The cliff's notes cliff's notes on Hamlet: And the all died happily ever after From fil@rezo.net Tue Feb 5 23:14:15 2002 From: fil@rezo.net (Fil) Date: Wed, 6 Feb 2002 00:14:15 +0100 Subject: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ? Message-ID: <20020206001415.A12439@orwell.bok.net> Hi, what should one set in order to have VERP but not always? If I set VERP_DELIVERY_INTERVAL=3 it never verps. If I set VERP_DELIVERY_INTERVAL=1 it always verps. Does it apply only to lists not yet created? Did I forget to set one variable? (I'm using today's CVS version. I had the same trouble a while ago. Personalization and other verp features work correctly.) -- Fil From Dan Mick Tue Feb 5 23:35:57 2002 From: Dan Mick (Dan Mick) Date: Tue, 5 Feb 2002 15:35:57 -0800 (PST) Subject: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ? Message-ID: <200202052336.PAA00948@utopia.West.Sun.COM> if mm_cfg.VERP_DELIVERY_INTERVAL > 0: if mm_cfg.VERP_DELIVERY_INTERVAL == 1: # VERP every time msgdata['verp'] = 1 elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: msgdata['verp'] = 1 Other than possible precedence problems in that elif condition, which casual testing seems to disallow (but I'd parenthesize anyway), it seems to me that setting 3 should cause every 3rd message to be VERPed. But in my testing it does not, and adding parentheses fixes it. I'm too lazy to research further, as I believe the parens should be there every time there's potential confusion. Index: OutgoingRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/OutgoingRunner.py,v retrieving revision 2.7 diff -u -r2.7 OutgoingRunner.py --- OutgoingRunner.py 2001/12/27 07:08:00 2.7 +++ OutgoingRunner.py 2002/02/05 23:36:20 @@ -49,7 +49,7 @@ if mm_cfg.VERP_DELIVERY_INTERVAL == 1: # VERP every time msgdata['verp'] = 1 - elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: + elif not (int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL): msgdata['verp'] = 1 # Fortunately, we do not need the list lock to do deliveries. handler = mm_cfg.DELIVERY_MODULE > what should one set in order to have VERP but not always? > If I set VERP_DELIVERY_INTERVAL=3 it never verps. > If I set VERP_DELIVERY_INTERVAL=1 it always verps. > > Does it apply only to lists not yet created? > Did I forget to set one variable? > > (I'm using today's CVS version. I had the same trouble a while ago. > Personalization and other verp features work correctly.) > > -- Fil > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From Dan Mick Thu Feb 7 03:28:13 2002 From: Dan Mick (Dan Mick) Date: Wed, 6 Feb 2002 19:28:13 -0800 (PST) Subject: [Mailman-Developers] mod.py: query/set/reset moderation flag Message-ID: <200202070328.TAA23660@utopia.West.Sun.COM> Sometimes the web interface isn't what you're after. Here's a bin/withlist plugin: # mod.py from Mailman import mm_cfg import sys def mod(list): for member in list.getMembers(): if list.getMemberOption(member, mm_cfg.Moderate): print member, "is moderated" def set(list, member, value): value = not not (int(value)) if list.isMember(member): list.Lock() list.setMemberOption(member, mm_cfg.Moderate, value) print "%s's moderated flag set to %d" % (member, value) list.Save() list.Unlock() else: print member, "not a member" Invoke with: bin/withlist -r mod to dump moderated membernames bin/withlist -r mod.set [0|1] to set moderation status From stijn@win.tue.nl Fri Feb 8 12:31:50 2002 From: stijn@win.tue.nl (Stijn Hoop) Date: Fri, 8 Feb 2002 13:31:50 +0100 Subject: [Mailman-Developers] mailman 2.1a4 and moderation Message-ID: <20020208133150.M99534@pcwin002.win.tue.nl> --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have this list, run on Mailman 2.1a4, for which the list administrator wa= nts to moderate *all* postings. I have turned on the 'mod' flag for all users a= nd this works fine; except that now every time someone posts a message they get an auto-reply saying that their message awaits moderation. Is there an option to turn this off? I'm mailing this to -developers because it's using the development version of Mailman. --Stijn --=20 Help Wanted: Telepath. You know where to apply. --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8Y8U2Y3r/tLQmfWcRAmPmAJsGKFrEMyQAO6vYXb9C+qpKKqhSZACfTWz6 FzVugeLKKpCep+p0yD/2apw= =u0nt -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From marc_news@vasoftware.com Fri Feb 8 22:13:21 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 8 Feb 2002 14:13:21 -0800 Subject: [Mailman-Developers] mailman 2.1a4 and moderation In-Reply-To: <20020208133150.M99534@pcwin002.win.tue.nl> References: <20020208133150.M99534@pcwin002.win.tue.nl> Message-ID: <20020208221321.GJ21505@merlins.org> --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2002 at 01:31:50PM +0100, Stijn Hoop wrote: > Hi, >=20 > I have this list, run on Mailman 2.1a4, for which the list administrator = wants > to moderate *all* postings. I have turned on the 'mod' flag for all users= and > this works fine; except that now every time someone posts a message they = get > an auto-reply saying that their message awaits moderation. > Is there an option to turn this off? I'm mailing this to -developers beca= use > it's using the development version of Mailman. Send mail to poster when their posting is held for approval? -> No In the general options section. Marc --=20 Microsoft is to operating systems & security .... .... what McDonalds is to gourmet coo= king =20 Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP= key --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPGRNgH4xUKZ2O+kBAQERgwQArtQamJx5tjreBtTZBopaPFqYYskFk8Uu uPM/H4vfHPN1F2FXDHWaCk3vPJXgJWjTMZm6H4JoMJk5LaDyiYh/KBHIswaJqbn0 nwPc7jzXRsrSDulOK7RVkm5JqpYSYgyj3+xXvqLvY/NNk/ABSt5wF4J0YHN3Tfmh FNMGWCIoy/o= =hQ7m -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From les@2pi.org Sun Feb 10 06:58:10 2002 From: les@2pi.org (Les Niles) Date: Sat, 9 Feb 2002 22:58:10 -0800 Subject: [Mailman-Developers] Database version updates drop nomail settings Message-ID: <200202100658.WAA14442@mutiny.2pi.org> There's a small bug in 2.1alpha4 in updating a list's database to the DATA_FILE_VERSION, causing "nomail" settings to not be propagated forward: MailList.CheckVersion() reloads the database, taking care to make sure that the reload doesn't trigger a recursive call to CheckVersion(). But if the list wasn't locked, CheckVersion() then calls Lock(), and Lock() calls Load() again, this time generating a recursive call to CheckVersion(). This recursion is only one deep because now the list is locked, but even that is too much for versions.CanonicalizeUserOptions() since it clears the old-style "nomail" flag after setting the delivery status in the new database. Here's a patch that fixes this. -les --------------------------------------------------------------------- *** MailList.py.orig Sun Jan 6 23:04:01 2002 --- MailList.py Sat Feb 9 22:42:36 2002 *************** *** 146,157 **** # # Lock management # ! def Lock(self, timeout=0): self.__lock.lock(timeout) # Must reload our database for consistency. Watch out for lists that # don't exist. try: ! self.Load() except Exception: self.Unlock() raise --- 146,157 ---- # # Lock management # ! def Lock(self, timeout=0, check_version=1): self.__lock.lock(timeout) # Must reload our database for consistency. Watch out for lists that # don't exist. try: ! self.Load(check_version) except Exception: self.Unlock() raise *************** *** 557,563 **** # We must hold the list lock in order to update the schema waslocked = self.Locked() if not waslocked: ! self.Lock() try: from versions import Update Update(self, stored_state) --- 558,564 ---- # We must hold the list lock in order to update the schema waslocked = self.Locked() if not waslocked: ! self.Lock(check_version=0) try: from versions import Update Update(self, stored_state) From fil@rezo.net Mon Feb 11 16:59:01 2002 From: fil@rezo.net (Fil) Date: Mon, 11 Feb 2002 17:59:01 +0100 Subject: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ? In-Reply-To: =?iso-8859-1?Q?=3C200202052336=2EPAA00948?= =?iso-8859-1?B?QHV0b3BpYS5XZXN0LlN1bi5DT00+OyBmcm9tIGRtaWNrQHV0b3BpYS5X?= =?iso-8859-1?Q?est=2ESun=2ECOM_on_mar=2C_f=E9v?= 05, 2002 at 03:35:57 -0800 References: <200202052336.PAA00948@utopia.West.Sun.COM> Message-ID: <20020211175901.A15319@monde-diplomatique.fr> @ Dan Mick : > Index: OutgoingRunner.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Queue/OutgoingRunner.py,v > retrieving revision 2.7 > diff -u -r2.7 OutgoingRunner.py > --- OutgoingRunner.py 2001/12/27 07:08:00 2.7 > +++ OutgoingRunner.py 2002/02/05 23:36:20 > @@ -49,7 +49,7 @@ > if mm_cfg.VERP_DELIVERY_INTERVAL == 1: > # VERP every time > msgdata['verp'] = 1 > - elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: > + elif not (int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL): > msgdata['verp'] = 1 > # Fortunately, we do not need the list lock to do deliveries. > handler = mm_cfg.DELIVERY_MODULE Dan, I have used your patched version for a while, and the result is still very random. Some lists don't ever VERP, some others do. I can't find a reason. How are mlist.post_id modified ? -- Fil From barry@zope.com Mon Feb 11 17:15:18 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Feb 2002 12:15:18 -0500 Subject: [Mailman-Developers] Re: [Mailman-Announce] Verio VPS Solaris - Anyone use this service with MailMan? References: <947853235donaven@scseaside.com> Message-ID: <15463.64550.771944.764236@anthem.wooz.org> >>>>> "DS" == Donaven Staab writes: DS> Dear MailMan announce list members, DS> I'd appreciated any feedback here. DS> Does anyone currently use the MailMan Mailing List Utility DS> with a Verio VPS Solaris account? DS> I'm interested in giving it a try and would like some feedback DS> of current users. DS> Thank you for your time. My fault folks. I was modding this posting and hit the wrong button. This should not have gone to mailman-announce. -Barry From dmick@utopia.West.Sun.COM Mon Feb 11 18:56:24 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Mon, 11 Feb 2002 10:56:24 -0800 Subject: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ? References: <200202052336.PAA00948@utopia.West.Sun.COM> <20020211175901.A15319@monde-diplomatique.fr> Message-ID: <3C6813D8.F4278D56@utopia.west.sun.com> Fil wrote: > > @ Dan Mick : > > Index: OutgoingRunner.py > > =================================================================== > > RCS file: /cvsroot/mailman/mailman/Mailman/Queue/OutgoingRunner.py,v > > retrieving revision 2.7 > > diff -u -r2.7 OutgoingRunner.py > > --- OutgoingRunner.py 2001/12/27 07:08:00 2.7 > > +++ OutgoingRunner.py 2002/02/05 23:36:20 > > @@ -49,7 +49,7 @@ > > if mm_cfg.VERP_DELIVERY_INTERVAL == 1: > > # VERP every time > > msgdata['verp'] = 1 > > - elif not int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL: > > + elif not (int(mlist.post_id) % mm_cfg.VERP_DELIVERY_INTERVAL): > > msgdata['verp'] = 1 > > # Fortunately, we do not need the list lock to do deliveries. > > handler = mm_cfg.DELIVERY_MODULE > > Dan, I have used your patched version for a while, and the result is still > very random. Some lists don't ever VERP, some others do. I can't find a > reason. How are mlist.post_id modified ? Well, as I said, I don't use this; I've hacked things so that every message is VERPed by Postfix. So I'm not much of a testbed. post_id is incremented for each post, by Handlers/AfterDelivery.py. From dmick@utopia.West.Sun.COM Mon Feb 11 18:56:56 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Mon, 11 Feb 2002 10:56:56 -0800 Subject: [Mailman-Developers] Database version updates drop nomail settings References: <200202100658.WAA14442@mutiny.2pi.org> Message-ID: <3C6813F8.DFDCD936@utopia.west.sun.com> Argh, not again!!!..... sigh. Yes, all my bounce_info[] seems to be gone. Les Niles wrote: > > There's a small bug in 2.1alpha4 in updating a list's database to > the DATA_FILE_VERSION, causing "nomail" settings to not be > propagated forward: > > MailList.CheckVersion() reloads the database, taking care to make > sure that the reload doesn't trigger a recursive call to > CheckVersion(). But if the list wasn't locked, CheckVersion() then > calls Lock(), and Lock() calls Load() again, this time generating a > recursive call to CheckVersion(). This recursion is only one deep > because now the list is locked, but even that is too much for > versions.CanonicalizeUserOptions() since it clears the old-style > "nomail" flag after setting the delivery status in the new > database. > > Here's a patch that fixes this. > > -les > > --------------------------------------------------------------------- > > *** MailList.py.orig Sun Jan 6 23:04:01 2002 > --- MailList.py Sat Feb 9 22:42:36 2002 > *************** > *** 146,157 **** > # > # Lock management > # > ! def Lock(self, timeout=0): > self.__lock.lock(timeout) > # Must reload our database for consistency. Watch out for lists that > # don't exist. > try: > ! self.Load() > except Exception: > self.Unlock() > raise > --- 146,157 ---- > # > # Lock management > # > ! def Lock(self, timeout=0, check_version=1): > self.__lock.lock(timeout) > # Must reload our database for consistency. Watch out for lists that > # don't exist. > try: > ! self.Load(check_version) > except Exception: > self.Unlock() > raise > *************** > *** 557,563 **** > # We must hold the list lock in order to update the schema > waslocked = self.Locked() > if not waslocked: > ! self.Lock() > try: > from versions import Update > Update(self, stored_state) > --- 558,564 ---- > # We must hold the list lock in order to update the schema > waslocked = self.Locked() > if not waslocked: > ! self.Lock(check_version=0) > try: > from versions import Update > Update(self, stored_state) > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From Dan@feld.cvut.cz Mon Feb 11 21:02:19 2002 From: Dan@feld.cvut.cz (Dan Ohnesorg) Date: Mon, 11 Feb 2002 22:02:19 +0100 Subject: [Mailman-Developers] Czech catalogs for Mailman Message-ID: <20020211210219.GN4569@ohnesorg.cz> --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit I send attached updated versions of catalogs and templates for CVS version of mailman. cheers dan -- ----------------------------------------------------------- / Dan Ohnesorg Dan@ohnesorg.cz \ < Jinočanská 7 252 19 Rudná u Prahy > \ tel: +420 311 679679 +420 311 679976 fax: +420 311 679311 / ----------------------------------------------------------- --GZVR6ND4mMseVXL/ Content-Type: application/x-gzip Content-Disposition: attachment; filename="czech_for_mailman.tgz" Content-Transfer-Encoding: base64 H4sIAK4KaDwAA+xcX28bR5LPq+ZT9DLrWwcrkaJk2VgdxYX+OVYiyYIsZ7E+HHxNTlsccqZ7 dqZnFPKbCQH0Qe6NbxJAYoF7sgMYuKrq7pmhRFnOwlEQrOYhFmf6T3VV9a+qq6qjRRSHXIu0 0U0b3I8C6Xd8oXkQpvWejsKvvsCz3Fxefvr0yVfL8Dy79i88T5srK18tP3uyuryy1lxrrkL7 tSfNta/Y8peY/K4nSzVPGPvK5/KT7e76/jt9NlHkQaoTroNcTlmsLrjP88GQRaqnMtb5qNlI dRI+EnLI/HwScTaKP6SqM6yzreyfXouzXiLebdQePU6zKOLJMEvCb9Jau5eoiPty0mrwNuNM io5iLRG1jXbhe/hR947eB8w2vYqKqaasn8Ls+bno9mDekqpYdXvjkehPu1OmfC/Voi+veopl F0EOahyKKrXKDDyE6aMPF4IpJoNuj9aUqFFP+TLTypO8L3ypsjpDWix50xlaBBvwC/8ji99P 03iSi0Hx0Ut5pECFtJzALNxxc6xVYufI+jgx9of12QEGGRvl4fj8p7q3Y+erTKc6Ke9hN8nz abdgQi/keXA5wNVcjlMQC9OTkHujOBnnw7rnteL2UaKAQyMOBOVCXhXTDVk+7IhEC4ZLzahr t6cV44PudN1rZWHba4VBu9VpHykJ03HdanTabIkdwg9GU2TsUgy4Zrlg7xIl9WQRZBqNGYyS h0EOxAInzcRT9k4lZzzxVT6W00VsMpI8EnK8yEAMdjgUCVBUNOXa40BxoBXwyVJRzuY5AjcH XRFrbG5JPFYjcR4GblgfmK3kO5EI2RUgUzXIfJYKTwpc+xhkYRouMh6iZKxugUwlTd8DueAS fr6E1cjpgC+atzz1eqpekPGGR1MNWuOo+CHhPzkSlC/SKaJqGNTZgVlmll+BzEC/PuTKX/QG WiQfWSfz8YvwhWQ5G+GQPL+C/rHKJz50foMDctNuZDgx9PJhxEdjycvFMbe0WxazaEcgmjNd XQVoaODWkOOWAK0BLXp1tHlQTB8rDfsG1CYKRjCWDAYqyoinQReUIFaw2nGd7bGBP7z4LHIA DZAgGII6g6Avxji1Gskx6Mm07rUaqJSo1D8MO8kYN2Suws6QXddRq0aSx+/rpd5YSeTCM+pD i0rxZRenTXKRwIY/Ad0dAnT0cQSeBkAjyCI/h8kyM8QiQ0ldofYgIAHsXQLifIxgLFDoyChR PoRlZv0p83l4jriUCw2Lgc0lgNWvgKpIAV4R/Uj+e2RZOEv/QMWB1eEhKRAyRSKkJCLNjMIg Ig5jAAtoD2qepzqL5bSHfEYqhA//1Ve4IXEmpx4gvffAblyjJyd9PqjiWATifwfyhO20SKtH 1ILJieEOVD/AOqMsxWnTwOuLPrY0S0AS0xwIM3QCNsWo4IhnRgIjo2FIjL5iXbf7vCxOAN20 KEbuA/fNkKN4ome3MZI2jdGasNThIMzptbRub8YgWlj7eqsBv6gfSgz+sJzqwXIUyR9suMq8 YljYX4dCB//IhNbcCRHm4p0h2BXYkJoDYwxqw+QTHFuLHzUQj7wOWAZYqxI5QY0GXOtjL7ts +BJNZACNcOQ0n+gQfiwiGZfU0AMxZT4AOGCEwW4SFgAq7BMUDjKeOURFEgBCSV6gByStrqK9 podx0B0MYSNlF9N8DIorVf4RUNsB2IdF3JfYFJTYfz8FSAUkBygGVQAm/ozc+z8ECOAN4ANs 3j5aycJ2LDoVhQ0AQ5IMYBlxdq4nqCWlTfOV56P1CzoZ7DItJKzRET5KsvMAqAaeAqucZhlc gt0RwFL9cQh4gKufwkeWjqMqZ0pQhXVU8FlEM4piae0L2BYiAtOqQDs9q515qC4C0i30RN4F oU6qaP3B+CTsO6BXD4F4ajFk7zJ5CtsbNB/kGqdjqVDtK54PtgNAMY4Pmn+JKEN0BadZwmHz 01BkDz30iNDZcLa59LRg1NF4EKKuUfsPwJ9/Mg5eSgT+GUqZW+s3liCXygdUOD+5MG5P6d1M jcKgO8IXvWr7PBl3sbX1zKqfcMuSA/UYrcA3Fke8igCAERX22yGyC3w/4tacCbMEgGMUugUl 8BEM8g8YaArQHHRn1J+2UD+4QAVDm94VIbCGOIq6OgiDgZwQ2qOagvL1YP/BP0iAB+P5+EMN Et5HhWI65JdTPTDiBgDKE4CiwqHCHTq0Ij+BfrBDQP2EFIj0BlTQiaJmyFWfa94B5xMWbCwI MB0hF2AF91usBkP5wXX0DOyiTYsFaEDhisD+nBiEAtRWF8BvKcg7IxskA+uiIbcA9k0b7gym DGDTMoUOF8AOWAc2+gAIIWFHQTsBb3JHZoD+uY+Dotvr0R6zegFeC0LCQKHfBhsUNjIIAaVw qzf/BjGZjLjohWAl0BdEJ5zWbZzzD6TX3m99onl4fsmj55z/40TwqBOKLxUAuOP831xZWyvO //R3c20NPj+c/+/hOeTGY3RGS4I/O5KIGsXZu7BTMy4ZQeqjxyHYezzafZMSkBo/9QrhahgC wjJyOPGATueerPAu6RRLGIKo8gM/FxWjVfcOFJwC9DgEZ4P87vJQ/+gxmKFuEsQ6UPKblFDr tTlewyx8NpzRK44g4J1YPxOwFr6icx4Y536Mx5CUoeVA7wvgG09qALngHsFpwnSw7rxDd3TY 0RYBsREuwKNTyXz70kFjr/xEdYAZcDwIJBx5I7AIAMxgdMkP80ac4hrg9VxfQ0SMAQpoJied atzFxussUo98YYAYOXPCB/oK3MTA+UVAfy+8MibAYTnRe3sg5zaoL4TyEZ069IC9UleUT3ZM oQRKf1YYaYI/nl3Oi9CAW2xjNBVL5dzOB9PyKzzz8N+K/77iv8215WaJ/09WKP77dPkB/+/j ObIYUOxsOiiXR+TqKYfUw4LCXPS3uHPCnUEBx7UIZs6gzbX5ZuKm3EuFfj/1JyWwVALAFWAp Y74zqOJ9XtyXFXFfzzt0B2NjbPh7Y2vKWWdDg7Aqv/x7BKYiiAKvCFFUTs7GGpaGLu32cjjl Qr/KQbk4ogl74H2wZ/+SPXOh+9sNWx6IMx6Gdxm2gS+KmL93M+bPypj/794mXcf/UJ0G8osh v3nuwP+VleWK/998Bu2foBl4wP97eFoo6rbX6gnutz3GWjrQoZiBdnC5z3oK/i0RsNUwzbxW w3RsdRTAbee0q0KVbNS+fkdPDT48f3l8wA52T1683Nk4evnqhG1un+y9PMTdGHPdw33oPXoc iTTlpzAZknCyubW/y/62t3PyYqMGuvPoUY1tvTze2T3eqC3X2Pbu/v6ro83tvcNvN2pPzO+j zZ0d+r1Ww1XgIMfmD/xzh22/xC4w60rt+sDfwreXMPLXf/nL9vbz5zW2ub/3LbTc3j082T2G 4RZaW21YxuEJcy2N3tbYq703uxu1Pzdrc/nlLeDsVabhIGAktwrKGic7ltyGo7elkwrh7ZYf 5I6i4+C0p2vtF0U820603mpAq3Y5mu26d3j0+oSd/P0IiIx5mp6pxK+xw80D+E2gHJ+5Nawu 19pVahwRVWq0z0C8aczlxgrjYXAqN6LA90EN7Ex6GIuN2qvXWwd7JzXb6+4HmUb0EPTUvAV8 ch5m8PYoS39iEQbecxno9/V6vVbyTvuz1AL9qDhFg7jdAqOj5GnbRP9GKlm3bop9zzY7Q5YO U30VUYxXwbTMdqdcERhza2UxMB6rXIUYEewqNQgw4UIH18gYoemFuMRYZjH7NrVKMaxoYvPW B9CqSDFIAcOLkGJ+QtquNtVcpM5GUlFCAazxCCP/lNAAV4G94RJMtspsv9iEF8HIX06dZUSi XHzWJefId8FF1W3Hl/QCDD18dNmoqjOA7HNtbLjU9jyhEL/yB3zEsjzwcV5+AZSwn8FmnkvK nTj9x5weogGiBsIFoQehz28Ngv/Gz6z9T3TQ/XJxP/fcZf/XVtD+rz5rrq6uPjX2v9lsPtj/ +3haf9h5uY0mgr04OdhnR6+39ve2WW2p0fjb6najsQO2kz6s1lcajd1DtOj4G0C29WJ309iL 1sneCeAumCPyCsiIIxrTW/p7f+/we3a8u79R25O++LHGXhzvPt+oBfiDtK3GrjeE85tw7TCN p9X6o8eU0Htr3XfqAJ7FpjVpcCBROgV/AKws2G47/KJU71QYqjPTAcaQXeUH8tSQCV5IInL3 txQ/avy71bCLa2293Pl7xUco/Bqc+0WzjbGyTl909VtchVs5fDCWaQsa8Ez3VFL5ztADMAja 2vzUCp0JJUaauFx1LvQ6TPPK2DT8Zru15dyJPWjl4wbXjoZWY89+O2q3Xu+3C0ttePH2DKcp h7NsufEahdXGJb4xNQvmyH5lcmLr5RrLpziIIT0k9q9hTeIfGcaTcT3/Rbkr9t94CLutr4Z/ uD+/dx6OB/KO/paH8wegjwOdfXoII9H5I2AeNblBQquxv9cu5eOY3npx3GZw9P3D0lJHgPNj 8XdpCV1iNJHAbvwopF/55HrOlSE2NyxKse3CNZkuPAjz1xCmdWh+h/7MjP2Hv/WQJ91ekH9J J+AO+w9H/2U8/zefNpvLqyto/9eaaw/n/3t5/nX7X3EAirDBJulONUs4GyO2UQPT5VOmWypj vCumu7DJnzTK8LXXvJOOXtM1jt1O3lEmEVrpQ0lMOHumcKwaccxaUpVipXzOnaCOEgVd+67m yWwhOIGNR9C8zn6YwmguTDpl1fi6HWA0TQdjU9dSCVciydgN0ch2v5RTl6utm7CohaHY8AhZ Y7lFYrpL/jP7H2M575TS9x3/WzX5H9j9zacrqxT/W336sP/v4zEneKxqtKkSTNdQlKHVabfA U8ZYYJyoaCLlFW4deoVJAJfcwDJg3kv4CAtgqXJ56lNYPQoYpXA1jwKqoWanQgpTA2fTQ8M6 ezWUmv+I8XYvtkkFW2SHtUxcnoZBd3AVwTYcZFgTkFVSBT2t4/VG4+zsrB4PwYzLukpOG77q NrpZAttLN8Kg08CwVAqGfQkTLvLU3GuptY+ox59Sz7xmtL20xj+TLBSpqdLDzNCHUFwEmnId jhOUKFr3TOU8bUBTT204Bk5N+BaxpsIutsT+54UYDa7+xPrRlZytbqUhVCcfDkLAgPFI2Lrj j5jBwVQKMg2rmcNgoFLN4mkKvMDsGCZbEHhohBH3x1hIXtYduoDUDHlvAwljy7k0fneDNjsJ DVOEssYwy+vjffgqfPAWeUQ5k9EYOEUxLkdp4Eh9bJJInIahLFv8XlCBHSamWMTD8TfzaO3B IHPI3BbhFds5fGV5aQu6mR2fFLNaFso6k4upgcqbU5yJztuYnwo8dc3O8oZqMUFbYakUcD2A 01bEpRnJViyiwNJQ0F0HZcvQ9TQypa8DPhLRupkTI480uoP1xqPHs6Ko7C9oTL2QRZQ4pP2S sbRMt8H+qlqSedyrlMrMruz7ZKwHHxdZt8cTjuxCkrqDjzQEbL8gnacDDO2hUTLczneoGRJ6 bVYFxkZoLJf2Q5X1gIDrc2Gajyr/f2tg/Dd5Zuy/U8z7tf/P1p6tWfu/svxspYn2f/Uh/nc/ D8YL2B+PRR6kABLrbKW+yv7IMHQwz8+3kb69Ssa/BKDWwcHSPmjQ0iFAWbsS//s8592FM4oM FmUBMXG3UWv+sgTgAmX/Fj6Z+vuszB8Rcnf2b3blwD2gwL3aKSG4Xc0ALrj034LJ/S1Qqs3M WMm0AdX2LR1W/kN20vg/bTPKgC24BNiCzdaZb9WFN29d+PPnz5d3lisz3LLW9veVus9rYp5Z UjWnWcRLfiEt1wI1MF0IbuASqtwSblZN/MbrA/S+o35sm1ZIFL5K541B3YV0OUN48yrroGg6 Yuk5fntFQ89SbgTk0rNWOEnJrhuCWsB4nGMQbhPgzJEZIm6763oBmN3ubPEKXb0CN280rdTb XltFfu2ACk615Pm5DnKsn3EkweTm9Cva/MYpeFZ2RZ9GpVO9OtIxho2DLjh5ptuBSdNbnsRG ecukc6OadCed/rz9V1XDW1UQL+XgvUNpbquxitcw/ZRS3kohCXLeXitv5sCpfxqKvjmYmztE 60Tktbg9Tn+E7i7o46bvJ22DCTOvMCwP3o1RheLiptMEypKmeEGKcrVUNl04WGa9+VVR8ZYO rvCjVovXdMSmb9Ffyy4DGWgMQuQTNvLBs1ooc+bVHP+vIayjsljuWtX4lxRUaS3sQ/efP2/q snwuDpFPxonP6GI5YkUWjt/TXii6WbwgKF86SE8NCeiruh1jTNZtlmrlmqVawVoHy+RnyOMX u3vfvjjZYLVm04IJycXasVICPj2FgNbWHtXaVEEvlsyFt7HRVb5uAcyOYNuvrj4y6lkC4BZg qBPAQqVpcwWaGptDH2+IpUBKkE5Z/eMIPAt83asSaE5rj/HKcB5gQGG9qpJmGNvJUBlFS++y MMTDEQG9tXmfS+JNvV6tWY0l673UbB8YNYBTja2sUIyOeqqLNYoZbrseqZHm3gJdkCXqFRia j3gCS1WHR0Gd/WBuMJeXRbEZHpUJPsztZhre3ShesCdpAy7mnkTE+gGOYWpSssq112pXRvcQ 8XYZkJRp3kd8qDNTF2QqbSVuAMU6YsTM/Qtz12vE4U0sLk3hqvn/C3gLP4wjdz8cL3JDPxGK AZbIwJEQbZM611gmO2Ma41JqBswM76TA8yFe67V1NTg4bEl/Ek5hj5kL5jOLgQbFSI4KIgJ1 GStiF0prhOXpIpmHFYzdkPmNDdN+A2KjO8yGgvVS4Wk/HIqzpSNbJ0VbovL9ExrGbptuE4Rx riemXjnD/wtCyqMrV2AN/A2z6yRsI+KDM+LIuEkCu2MjzqXkO7z03eej4QBmFwCIdBvcUkIm Fc7wYFEjE98Q0V9pFlYd9oaTNevp3UkhIjhefaeZQQQ+GMcxGrbS4ekL6ZjlCykni0XpcW7e R96CjwED8Vd2ktkrpRkbybG9vo83mpkfnILbUreesW9nRuJfS/Nt6Zj7gVrayrQGr5wdilLH duY1YJtSXde5amHcDfu0au1TV2B45zrYmlHRMWw1bAtXBFgWsGEf8kt3C5+1UQQbb9S+sc8s eJxvyFvcVuGljsgkrTjit1r5/zV3gLvBZ1n4Shb17sLHWxfQNmerY9Aekcx47tX3L82Bq5Rr yUrjgJnWpll6c5hdPyDPzTYgY3xDIPMEAf/yDlXGQnMbLoRuioTs0jOfm5y5h2cm/qPMau+3 /mulufZ0taj/Xl5bofqvtYf7P/fyfCL+M1MZbhO8dKoB1xJQC9V86XUKes2+LwLB4lNIYLO/ ZdH4baGghZsl4LcHgJZvCwBVncT5AZ92i84dt0d3/tw0G7lybDgs/h9HaD2LK0jrbC5r0GpU ANDZxRLqC1Sx6IPQ1KIBnCNsaO+AMyASWm1XhGhmuoBPuFr6DU6ib3+XaNqaca077dfuf7ox l1Sb0ytFCb5ledwEH/jnS53duB02w5zSRSRgJLMLHnyoTlWmlzrO7s1g5o1jxMwhr/iAvhFP hSE7yYVv+TvT4v/Z+7ceN64sXRR9dv6KKDXcytybmcqL7uWWS75U+yZZx5JVu9xeyx0kIzMj GYxgM4JMk9h/6Lzsd2EBeu6fcLDe+CYBSRRQ+0VqQMAZ3xjzGjEjmLJd6uq1lFiryyIZM+Z1 zHH5xjc+S0uMZ7j7EIRFifvthHsCAz6rHP9QXYAb8S0L8Su3ob6XO3aiuoRbRh28dd17+Ycx WCCcReteIG1oqy3pqWlqx3g9UdxVTGVTGfPSsP3AARUpYqIyUSFIcIScOW4s4NSH4kNxHmUu neIUsAmQF+3RuQKYXvAQrBiyJa5+7NgFMWwpxEDJRJtfvFIpeDwN+JUEsBR3RxxVyYQ2CwDp gp9nGLq7Kx7G9htuYJwonjPsl0mS41jtDuNFeS8a1h9W01OmiqcnBcEX/DRs5wrBjkQE7VNI RUiqafSQzPSR4sBz2zSeoTHPYo2FhP59luA9c5Wgv/WB9YINTiW9ALFHFRE17ErL+Nloynxl ojR7HfpB1vckK/ory8xXO8xeTggfbVd3lS9YbrWJqsOaqDo0DoLbOBPYd7Xtr3Zkw7EgWTGS gnJlKlkxDz23h+TDuPJPiRcWAzkZetQL+m3peBW8X17zxdJbdOQHSdeYOlvubq1t07so2L2B MgLfqossS5X08s0Ks4Rb3ov+1qv31hPHMX0+OV4bvreoe2EDvqLOKbvcbNV3vicijY2HhTsl wzix6yYXXv0SwjGLM/3j4lj/vnkMddO/1SV14xKq0o2wkdhyFdEV9K1JhV6GbhvPWffWjbPX UHJt104u3UsPphfL7f8F/a71hpP4mqcRsbfYJnIrCQl2KbqR1i9IdMce4ZQmkyILUmdD7UU6 xUynl6l/0m/kai4TJbPXUTGKx8ARwTPBFqjnH/g+L5segsYGiLwR2PtHUpM5hQtMmyrJnukI 6X+dQIm+ILY+MDeE8L09F+6tF1mSG+bAJV0VuDwq42vpbX0ACBQzX2Jsy2HSuKNS5ibkDqiV ky5Ue+5JsP/tTMK31SkZ766jvcS/xmnlnNIPnGV1jsJvoKsZZU07Hw43+U5adu4Heuta7sFL amJazkRzJRyffPvoCgsd5wg5k6c8N1PjGq1Pq/3g9OjeD/GkGOcXSDgsNTPix2SOHbnSrv5g 9LV7CKCxGVq1WA3Q9SBnih6Pxr+2bTR0R+cUYPeP+1O6XWKjudvDoX7xOZ7ffbDYfXTOH11z vubjYc5HeKbMVIncnZy7XzltYZb45GJksTs3H7x9gCdywzsMZTg0AXrZaU1fLSkyL7v9045v Wq/ZL/NI53jVZd3RLW81JzCyf/yoXG/yZOAidK5NdSFOztWdaG7O2oVosM7Kdv5NbLRNroLN d5T1CODI62BRtyEWtZ3/2t2emhzm+6NqtgK5hWBqF5qqhC+tWbUwV89H1+ihyT1Fqki3Us9Q DoKlECnMfUSJBqfJYER6ElsAD7X9UrMBNMbxTL8pQWhHJL66AVjma3Mkcq2RHghB9XtZ4JgL PG1YKvrOUQHx+cXwotIhIrquMNqedx2j24/ltvOuGfV6HgD97rR4ZQGUwBc6m6ZtnxzV9sn1 ugtaCenaCR7wX0A6XxmKY8L9Sq3WD/FotQTnrYTerN382lnQmBf0qaLwdm5jlfMNAzSZqNCK iatIzNHa4VvaKeOo46bLOIfDJEtpKRa7ZDnDLaROIdnvzPv5UX9a+50alvnhw2Tp/NQM1R5x 9aRxBaWhjZfWFHFRei8952ZiJ8x/KhGfaJo8T8czO6c0nwa/u+Sfer/kWYxbePB0MCqSWNSW G7LS21g1Nl9M5MjY9mw7SyY8pofB6zPM0RCE81w/DBjCRdOnFlo+V/KGo1xPFxhk4a9MS8BL 5q4ILYP+6G2Xww38yejMPmUvyYMvH3yuuZMZAfOCZOWbrQ+QmfBxYNmerp5JXBpFC0gs0G1C zw2L0eo5B8BfrOkVTqM95aJR6vIw2ZLYIb+G8x/2oieGpVaY7SXZZ/4GMkYftVy4m3gE8YgJ jfb8Ob3kKj1IyUyVyTcXJPrbWKBHWZzm9V/+u+n232qRGtFZAz6AIC/jccrKHmmpLOWNOeYv 1lvNCkQLXZ2702SQkJjYLc5z1hq1uHiYNORK20/v58Hd+7YTEoVmRHPUR4XlSo/mmYRCLW/2 699gJuLBaJdkRFV2TEHjNxvHvuHlqtOfykVshm3JziOtHfsj/OApCcs3AmJ0UgNUCytVfIIE 5fiiXL8AtQoDPLY+0CdU0W6pegjKknVsVzLHwbTGM5zNnuWrrQ+4G5r2zCG6Z+1r+noJmrNa hRNNx2wGLALFUDCzOpQIm6miXa50Yh96DAiCTAlzeAs8ZwnDKiGhqVR3l6GMSe1plNE5ybW5 xFI0BdpbSne9L06Salcz+uxq269jj3T+nvaLt0HtdS2/fBe3tXPOwNI3T0n7o4tQ9sDMUtnX dpwB1JJ+OyyUF2Stt45DgD83W1Mc5npvgrNGDNKFUmDNQ/omdz0m0huUmOCzga7Kbk0N8Tw8 IraUy1LUu7e/xB/N+lk68DGH+nZWvp7GTfFFOkyCTzweTd8EL4q3XaavuGIA3a7dMCKAhESt ZyTRL5WCLZjuXyHTvmY5Ub0cg5ng6aqk9TlbI9BS21e+aKD9ZaQDizDRUObI6uW29OJvffCB ovn3YE1L11sZO4pPMkzzC3qoWlgwnO2TE4Ex4wA3pLlgbAYmgw2H8StsOFA3SI0DNgCo+VFc JSfFNCU1dLmapyULcFurR4qWcMkQOAPLivmo6Dmrswom2VDY54n2DIqNgUmQEjOVfo4H2FCd 317cVaRiD36bxa9faA3Nxs5jmtFxBw2oO5ORmUd/tzRWydEjSYssx4syU2utlEhRoWhXWdg/ TRueuBB2zkzhQXlmjTd2iMmVDFv/nrLXlG/80c8bg8yTkq4sxBZpXIi4ksxTm/gszeMRPVNv K2VUp+yrJMtfvv0qlrPJhEMieZHTqwanCKqqpe3Q6gK/voxiF46lO27mwnMtW2BCMA6kXmCB XeZn7EnwUGEtqK+/Y7YzD/81mTLe453zf103/M/7N49uMP7r6D3+65381fk/I03l4WR8fbiN hHZFbrnrJlhwlJskTDWbQJxg/6wqdmdI7tEs+m2YQuOBsP1f+1+CLLR9auuUoZsn+K1JRaM2 WtHPG7kjdVLRqEkrCg+EphSdlchkHydvwynawXD6S1hN7b9/Fa3pFeE1vfLriE0jC6qmW0YR m0bRe2rT/xWpTf+rcpt69/+UwfO/9fW/+f6/afi/929w/Z/r+/tH7+//d/HXxH/vb87/v1Te x69J/w8FdX8RE4C+N94iv7WDDOASd3t0iblBMsmlEl83d7veSedy+uiR3GbRP0UaYXe5ZPq2 C66e/uUm1SMZXP9OlJhgfq4HJXHKhu5FT8uqmE0YbCSSWRPeKITxS1QeVRI8S/u4rugGayRI i/cOjFGSH70XSdTyy3vbdmHmcIMU09GKTF9G2bKXDrCVYTGdvRCCKgSXFnvRDthSJYe/Y5n8 RXmqVoVM1iuNXEQN+PZAKk6uWDfphOBAZuPd75ITRsCXkt7bv3ieezU/23ff3QYLhQ+s+ht1 WAJY6LA+In4n63kWqMsLnimJtbmdjoK9Dq9LfSk0Y4awNNAkzrJ4aibSSRd0fqUipP6PjKZm cvf+a+V96T/v/jcIxN9WBdjE/3l0eF34P/dv7N/aZ/6f6+/t/3fz17z/D0L5X076l3NGn74B fAHFZxuVQVrM/fPTtAIMBiSdl2nsVCVgfacTd/7LOdj+zv+a9d+MEIgHo73q5+rXv2PT+d+/ dQv8/4fXj26QDMD5v7m//57/6538wZs27ifTnZLJ/cS2vbBnsMah4tLoomTwf3b33//9yr/m +Z/95hJg4/m/qep/3Lh1eLR/Hef/6H3+97v5q51/nQ7jx6zfn/r/Zf/88z9hZPdvc+vbv03n /ybz/7v3/3X69P35fxd/gqM1/nggOvM3lu2OA1T/NiP7F0mKO+Vd8TB9uD0YD1F8GzIDGIZV LlEFz+1FouLRNJ4PLybFkHm9S5UBED+bKah6NFvG81d+Qp+C823NF9Qtrhzrs7rZGqryysTB 4aFixzgWKmMV/SilookjzmwJVcA9psVyNr7IqLPfOiXIddsK1aJYl+EaSlvYsba+ikcvhWZL EDXDooqXi6gcX7yanam0iXI95qR53brtlZlZvoRltt+BqPXOf7+YYdl+4+O/+fwf3DL3/419 8P8f3Tx47/9/J39PVOEKxuCirrFzhABUVUx0fAZxEEaDdItODW0Z9jc6RwH/ZKFhnjFs6bK1 bdj7rqdR8JfaJ3hXnQHe/vji/gi/l79/p1NfVvM1l6Q6AZ6XHv9we5gOoZfgF5+9nhdD9fNH r5LRtGCuu0kB7hLkB0xnLxjE9MZFau+po9efofrXFmSepMDQv7ggkoIYS8YTNQOknWpLCPfS rHjOVPbr5xB7n/HR/5jHXMWjClJMH3k1K0x7/+F2cZ4nUxnuf4pm5Z3/QZHPk2n1ju//o0O2 /zn+d3gk9f/26X/en/938Pd1WMtXtLF06ocXWZyhngPuOiT7zfaib4dRvkDx71HMtSegNRZL XI4xckrfMGzgZEotjXUdixLkn0mOg3BFnYAre9Fnxex4Ne5tPU/AjjhfvEqARNWo0WnRz16O XXjmuHieryIp1Y4KBP2L05mTe0ItlKNFlS3oKN3nggUlN1y9Ga0Arf14a+tgx6H39X0bdNMj J3bBsG3Oxlu4tL8sITBD+rTSB19BhxkkGUC9/VfSv5dcsL4CBlSQNOhESWoFCwH5TIANEwgr FENQdTO4Jn2UFSPO8yzTaiaVFQ53ok+QXG2pNMHtCbg1sEA+m+YyT9CJNeMwBBaPV52lpNWN i2F6zOzJmQP/VUmrPtcTp7Ba+lE0gfYATwanqHpmfjEsxmtDXpwJGENAGGm25xKDogWVJMH5 cKqQkiyxw10qiBBDRCqAESSMDLgP0QgFWJg5CABaJKaqoCBA+ZJHmeF/ovPzc11kxlNJ+WJQ 2iI2JbWA8iWqlVRxHe1F0dbW0Y4awXil8vYAw/rTn/5kwP6j4UI0PklUNpOKtwhxbIBCS+8p q/LpugtS95E//YHW22JWgDqn3WxYoqNYzzL+U30b6AOn1jFRLG1QumFpypcrIFqa6aY9lQaJ NJs55wpyC1765F60bZIm/Ry4nqQjyw712LPpFHFPLLXn0oLP30TUKXA/oWiKk3KZvEimAhyS HEu0wJWJhJ/ZhdbT6Xsp6ZN7O1tb13cMRN1btJEsW57M4+F6L3o8f31Gi5FUeoLpco7niCLj TSnpC+OC3uNoNy91QPiH+FmWuITgdROJZ42rmjg9LrPXc1qK0ySbgMedTrD8ZoaV7E9ph4zp f4fT5+uKKaxUKSSyxFYkI2BI2Y14Zu0MsTD41FlpqfemqB4SGhfdwxWVzi70bA56F+PXl2I2 kYEX27pNsaMdLqyQ1zoNLdx0iYuE/rdkwOZewypKndoRkgCumsHByJJl7k4udc6p8YRjwhWe tszff/b1+V/+z9f/aK8DQvkbK4Ab9D+y9vaN/nd460j4P9/rf+/kz571WFLhWWTHtVTNnrn9 VRZomsUC0onnW0oZeKGNs7lHAsE/U+W5PtxGOS9l9f2wgq/xr1pKGjePSqQUvUZoNErJC3df hOt0S4g2Yk+mlKK5+l4olcg3f1atOXcGZprK3HsjGE8jNkutAkSTGMKtmi625Co379Xa0Zwu EDdWttbXMkNCSYH4mpUVSDB9Ec1MVqhuPAo2viVdEDqd9di4rF5jOq/uqgvnqrqB3MF+xleP duRtSz2ynHr74XbyMz23U+74FxOp7tFVXExXt/ybaT5d0SosJxcVsvukcJeq11XMs9UQ6oML 4Glxizk3l0pqkmur51xZsuxr6GoxF69QHsPe1lJdt2e+/8xcvWw/0z1Dpv/FaHaW/m5r6wuz bz7cBibdeC7fXxjNP0/+Kz6P4buW/7b+74G2/2+9j/+/kz9mKQuJ7tT30ZEeCELLpVLcCz6N VfGcrZTcU/tx8nBVzJFmf7ZmI2TL9b293IvY7TiPVTFQjzpMSFA+3M6ZCazMkmM45WLDv6Ec 8tMkRlJDpfNO/YilFsO+/FmuzkhZRdY2+IeGZHXz0OGl4LTKi6UiOZvpS3HW2yJx5CQ18N2Q caLDgA1WErAluj2PHksx8hmKhpJCrlKC1a2DFARBtJoIinBrKZPv66Ex9oBjNSvCuRHDlNlJ SHRqY7fRaOlQLqwNDDQOGJsq+VG99z6PF3WlFEFS4/ZzQbFsaSSayW1Lg3cfOVlKajWEi8Hk dDj+ibXpic7WQT8CtwSbC0W1Wo4aJs5Iu1Ur61fNYzNC61N9L+83/NXqP2eT3zz6s0n+H+xf Pzq0+v8h8j+ODm9cfy//38XfwxXk3rBBV+cK/7vKJeDIVzYVztJn/0O8AtYTYJy7IV8A5MQZ rgSjPxqOlNnzdRWxREbx51iIy0gvX3BwFy4rLk9NsntLVzl2dVUhZIherYbUuVIE8d1oex69 SEqOTOkeDk63Jq+SEV4/TsQ/Nr8Y3N3Zgy83SybP1j3JJhMXjlw3yusoPXq9ZWtkk67LFZtI bd8WNxsprvTcDqorqQFYBm6mRouWIjZJitH0uJRKtgpclu7Z6sJkDi3h76Uvy8maxbBHuITJ W4r1xHOrZf/CcH87LcMzql6/pSJaRmBzHl+lzTD1LnXvWFekaWkrv4BfZ0RWAg9F6FO4cS3s 603HLhPhluZMZ3+5R2Gnp8rhjdh6elE9S/OZMM7yFuGA42hgNtE4L06RsVicFsOMLpGUeQpf oly2uPPOz8+3TOpgcgk/rOJdMG5rfZVZUxHuY+V5RtXrN8+0WflStb2lHNI63yXAg7r1SG2U +bIyZhl3bzYlhamYuedy24DzetE50oCr4d7OllensFrO9yJlIRqifmFIGq+iirSuaItptn+y m0hblH/Y29tTRb1hOa5R/7omGpy67zqio8pGOYaZ+sRtlgb6NeKLrGOscGrvsvUZqxmj3iVL FFSrpiisJik6oBm78tG9KyDdil/Q3GwpLnCrn+j+YLMLI486eTPVMP1C3jOPwLkUV9h8NgPo yr/8tyvivTZE483GuSU2Q3OandPhQqTEFtvlAmZhtQXubZJtz6rc48Dai37g9y1kMLG8NE/w 2i36/y9WZbXW8oWTWmfz1fDiDBuB5u2xIFkYqbJ2KxWO9TNjtYfN7oj+hffqf4v+xSF6YZc9 faQIx//pIwlQ3ftvlgtLTveaFXgvPKZjNE39buLSaG99wKKYA4WXCjLtWZIdCRR9YNll+jrq pVTC+cJ4ogu33l0yTYshu6R14Gjrgzmyl006FGn4S7j406E4rpbxi1U1Ev/WgKtP+JMkfpqt D7Cf+rO/RFfyQr64IlfNFfWvvWj7k2RJVxFtpBnHQJPR3k5Ui5KAS4YpJkNBEvdaNXHHeiU0 sODTa7c+GGaJM61K93VL3e9YekoIxHi4zpCrLFSVe5oyy3KI8l7jzd1jQZ2e8YWhaBDVm1b2 TU7BCXV/ImozjKdD9nl9YOpX1Cub0khxVerrh977HIPn41UMB6cr1L7VSLTe1gdwAyEJLD1z /WXyePlPCMRgW0BMrZ/hF66ko2mT16Nko6msisilXiQUDcGRpFdJhY6IgyV3aQT6dEySSfyH 42nC9s7e8VROmAOPjj7iHXsPBwrnyB4jlxO/eYTOEKimgfI+1sSScpNIKTvcKOi7umBsTLNJ IOc1b+Yex1GB7EA815h3NUdsbs092b5UtVrOdDE9WGFbH6hCe7G+AZkOD1c/T6qeMUURQPeS mYmn7ERsErLJoKsigIQTMoI0U63hQq41lwbrj0fbBal745qaGmtf4o5qj8nJwv2zfmtLdlkw 9knBGxZN2mJpFJZTrU0+Yrmo1/pnZVJFH4kBfo/+I/+/i+Pje2YbmQYeCMniZSL05hleLWna 16rv2qTgeDDyS5FYJTM3fpQQz6WiPCBxhnrQ/RntFEn7VF3T4mzmcJapxE353Se1tpV80/Fd T8iFRZy048o5VPfJ5Y6wGnmAcsz0aAImVemQDNxWYJXO9iAVYmbs9ViWazPDLThVKzHzLo/s V+DRwt4WRIlloV1E27SX+PFhnjxTWcZMYavsk4UjTakzSOu9ELHMjjMyU5w/OzKS9iSjZGgP G1xgDgeYkvB8t/6FITTDrJid4oRcnOGgozHSw9e0yXNUrybx0M/WyxH/N14yUxWq8awT+Vgy HR4/LyBAR/DRIiorhhUWY8bQWZJyE+5ApoO5t0dlpXiVK8urZmAHTeYzxcRqRy3zXfghId38 aTpMvPc9Hk0XZ4k4MJv8kz1cE88T+1phqhQtjGQPRB/PAQanxfXYofvkVykXXE1gkPVzmqG+ sK0wpy691x6zvGpEe8/AbxdPFe8oCZPc1A9wJMr3DArSvj3+Vm4jRidpZbOvVRl1NQoukv9P kg+jYhrt7uomv2cyFtaqBipjXlRRx3TlgD5rzOBSke/1kmn/Hk6ublMHnl73k0FEmnq2YKnr mEiBguwN/MWWwfe4+AiSZRdVsIEw8Pp/E8+hH/9HSYBh/x3H//ev7x828j9u3nzv/3sXfw0u sp/E5/cHidWrf8FxgIjFLK92hjYYrUuZo2CeEEBxOMnJoshjUj8+UGfrs0/oZH0ALyCHcdXP wAYyALvomeA6SYspZ8NZJI0yhMC8UHG0C15hK4BXUGWjVaxIrEb99CKy/ZwvXq1VMcD/7BX4 z/3zzv+Ybh6k7b/j83/r0NT/PdwX/qeDgxvvz/+7+GsDQ/vSIHRt3sW5Pimqn2BQ/cRGMl++ frKWRQQLnyHrn9TMn/70J2vDGk/sFbdNxxMrGqd+tgk0mcFwFaCIAFqaQMste9+rdyitwXb9 cdMUNfHW7OWysv3UTXCk0TbwNQIHSjEUnt6huH6VLgpnA6lgf3WTwR7rYAX9bCu/GBTi5gO6 HjSPsNbPSEO98l1yN/qU1D9SpUibPq6tj6p5v7d35S0Fmnf+8+ScMZbvNv/j8PqBjf/tHx6+ 5397h3+PdJ6HYPuB9p0vqnnxKlF1hdVB+Fc3IHh1b+uhdkLXAb09ybtwrb9lDO9eUiGKY4ri 9Vxkn+eyCeIDGDBy2uGBdln93VxSGNx026dLMVJq1SBAmUW/fu0i5ePRIKniycApV7XesoiK cNKqQSjw45MK3TDYegTsxsUQnmsJW9nJoTl5GLsufSVhrOSpcZx54aA9z3bRYStd5/ulckCM EtdLBgO8mk0URz3S9QRCcjdqC4M9XbJdCstQ40SSkYm6sUUJnw3zr83j00UvijOdOLvlLBN9 Wk6KvyIFIYvh4CDjOmPHAmix9tyOj4tT6rhwgDEDuQKdvDSXxpbr+LyvV9WOCr5hZ9ToEdfu 4RSdvegrTg7a4nKG5h5S/iBTyuEME+GiMFVcybldtnQAWqGG9N2o57Jumiq/ky1UYvI4pjPU RLH7zN3EqkNVPNqaISHLXzk6beYQjtOoFqwzdKfizNiyFHFc+roY6wsKJVWCEUpMlj58+hIG JtYeplVVTMvRS+1YcKFKZZWc5W/GpLO/Lot+MlbuDc61sOEZB24k5UhVwdAO9KhVSc5cY/7D bZrMRMFCHT9zwQGhXPtTjZtIXPf/29oBPv87MnB+K9Yn+7dJ/z9Ezrdn/x/duvn+/n8nf3wW FP4fRXIuBqm5fxWORvE8xIYcigGB0A86uaG+DAZp7jbvl//sKfjf+q95/mfV6Tu2/29cv671 /4NbBzeh/5Md8P78v4u/RwrFLRC0JpygxwCLQkWruexiWcxO6fKMShsOXG85GqwbD7zbpH4w KqbnaHSoIL7VBA7yR3IoQbky9e3Ti8Fd/1sjpfBvlwBCKWBxCfQh9Oz5M1L6uRpnlujaN9AH 6f0IJdWV8JnPyTLsK4Fl4m8MlRPmfOXpWMaojQ7PpyGZ2fu7FnCN80+67bv2/924caj5X/ji h//vff7Hu/lz7/8aBPiqZ/Jr7SCgHDxMWD3QxTBjSQhgMKoFDLCWPqvyN0Z+sEUMywHaN59b JJgMp88FhqUeTHTo3HEM2DPtdh8RbY4smo7ImbR55aq+bOFEKLa8XhgomqlEqyGp0qYt9YYf lfRULjhglUNRw5N6KR7/2Ssd/vPrPyTHs/Ld8z8d4b99/f/m4Xv+t3fy5/O/1SSAnwLmezQ0 +5u+8ULKw16kXeqAGGbeDTvkA2/uyy1zX9LpuWKP+BWPV83lO7Apo9YTQGJlFM8v3CBFILj/ nz3nf09/df73v4H6v/n8H9T5n9/zP76rv6/kVn4pGf5sBcjlmEVeHM/zfzeQVIa97QNJuXa0 eUf1/6Bd73eVcx0ZMyf4g7oC/gFr3jqG/19F1f67/AvXf/htnYCb8r9v3rpRP/+3br2P/7+T v6frim/OWuZ3KxLod1sfbp8n2aDgY/vI53qqAwS2cPNy5EbHP54+S4p+MshftmG4gxxAW+3J WUiUuhihxIREBQen1boyQRWFVVWwRxVAcLDFoN7YsjWDNMIy2naBkj3DdaWh5Ht7Oz3JwYbE 2jKhxxdo09Yt8rrvpV2TlBz3p0mWxfSPr53IpTIuVJDHElGpmAz3MEsTIWdT2Wmaj2rLm3Zn BU0WlreSW1ttUImeYzIpIiqgEeyS7QnMQ5J8bOA16dkoqIF89ALx2mU81Hnhe1tPkr+o+I5a FxVGUuNoJomXGt/qEcoJtVfPZYxzhsED4zLwjFgbbykuPXl+jNggIOlqvREsTPmik1RFN5jN V6TltNnycXLmxkRo9muPq85yxXmEdXoknOLh1SassvjFuhqBFDCwxbAKv8H59+Q/57b89hrg Rvzn0Q1d/+dg/zrjP46uv/f/vpO/X+X/tfrhuOYA1rkq2heiI/tC71tTEfmGuKsdtq0q4m/n wP1fwXH7G/01z/9vTwCxSf87PDD1P27uoxbYwdH19/7fd/P3/6xwScLW4yK8njmFS6gIZjLW HEOf4Z5Fqd9ynDjepGLIesi4qHA1eo3R2V1bTI+kJsLto6CUV0JvU/yUwjZjeovrFcklutNb ivQA3mBLk8M4n++/+ybsmt1SIkBn6ocTSxT8RzWhGuCmUAwZzfzAVMAcRX2xVvqZ4EAbvEIC 4Jkmk2wRbQv50PCi2mGeI2gGUIgMNFRzcSZLoedBHpnkuLyMgAt9kSrN9M0WMtCYJBjsbzq7 bKyURgbAQE3asaR4icrTRaazXp9UjPDqQmfumCVNT/JiCtqdvciF5rgFD8LsPG3Mo7KwJJyB GfjPPgz/G/758p/u5XfP/7l/6+DA6H9cC/J9/O+d/UmZc5WEyymUq6qLitMz1Un4Hf/bMP8p k4ugt6VMJsVoY40hwzoTXRHtj0S8hwbuoh9C5K9mCN4XOrZxcUq3To33WhFqNq16x2RH+sGW xr3WiNG0jvhQ7gSxrgOEzsZ2bgYbaqDPTxiFC4tTkKSLmlVNHZmN2Kp+YHCOb0Sa1mIds4+j R+kzuUxqtSN+4fp7558M2vR48a7jfwc3b5n8H0AAOP53/T3/1zv5a6v/sLvraoQWB7/1LVjK k6ayt6zpei4rbkO96wWhg0EFT6op+GrI1qQQvhDSMJG2oE6pDh0kPRO/b00SZrgAIO+7SuGi Q/VqNaSBgA4s2ta6105Y60I6zhVIhSy/yF/Ssfd40VvVrh7eJ1xlWfFcKmBVF1w+QlDkjgXL vdmLxIkENHsxRNrCX5kgHhLCZVWH2tdTAzBESEzMBnIBoUVj1pt1Dp9TngypEYcHh37BVAkh rXb7KZAfYN+6MEODT4zH9lprilpSii77F1Z37d2yR/tmvhhlDNYmZTx97s62UnlzZ65B5u/Q aEbjdVkVGokvRASOeu/OW7uWbzzG/uazDDVaGe5p4Aj9ilM7oMDz7nrBN9tWVbs1yfgxKrMw tpwWf6kMI8s4KNa3FJ+ljXiFaS21thz9LbTlcVKW8YmI/28+/enB548f3//nzx9fUwRee5Pi 17+jS/4f7B8dHSr+x8P9/euH8AUe3CAN8L38fxd//xA9/vbB59Fnnz/+9LsvHz358unn0ZMv n3zz+d7WP0SfFpPFND05raLtT3eigzt37kR/nCZklxbH1Xk8TaI/FrN8GENr6kVf5gM881mc R9+SfCmL6Un0Ef3rD8cAFA7ms2pvsLzX42boh1vj8iQdRleu4D9IruG/rpDgh9Dd/XK4+1RY I+9GB3v708HRjzm+/vbJ7qfThF+4+xkpLXfJRM6jPyb9KDqKDm7fPbhx9/rNiLbRofr9ri5s rn6Or3bp/x0cUD/u7t/65wdP+JffkK64+2Qa5/AAFNO7UfQRrfcfCjUQ9Fz9Lj+Z0XHZfZLE Y/xqUP4hS1GTQr4H1YvXdf5UpW3uPllMqA8Q1deYiub30eA0npZJ9U9fPv529/btG3d2D/0H 0CMSU7uf54NimOYnd6Pb/bTi3/xfu/8MLjTp7tefxP0ki/b37uzdwLdb/3BX1+S4dn86OE1J s7s2SSfJlLmsJou7BzdvbPzFTb1IDwvNqWmXi0F/huGDvx5Vl3nz4c0bul1ZzPwkiuWX0TCd 0kuKKdkJ5kVPF9V89YouUxaDq1fsd1Zhx0u979Yt/b7vkqyIMY/RhC5q5LTpF5MQqBJncIi8 kL4OkwJ33qigQcKQkN/P9i7z4qP96/rFj/A6d6D8PlL96Raxb/1eaEnlrepNdF9c5l3XD8yk fj8ZyqSm+TD5OTpOs6SMjoupefe/fLit/nOn/G/27ffp4qF7bDk7S+XRYs5YzT49ynmN/Ix7 cdYaukQvr9/RvYyiJ6e0+kP7fv3vzc3cODKD/QfFSkEW5f4NuBv5c8DGdLPtv3Bf9AlXvpzK vj/QrWs+fNvaMh6tlqu86HjanBr5NIoHzMkFOvPjdMDCy7b3reXYchnSkRTZ+orDg1vm4y/i fJiRvLl2fzDKi3Pq60nCU7TvPmx+9SkpdV/QLNN/868CDX1RkLjGW/bDTZjvj242v3xSfCaJ 6NzADbeBb0h14TRN/u7wUM/Sdm6Ey46dF//T1okw2+lfSERJ9VJUqaSflhEuqHgO7AEtobPP /+X/WUGDr1cjEjJO1uZmk/zlXm1Df3qSXruPyCi2sVniBwAPQwTb5h9oPHHH87f18/dtNrLb xn03r7LZTqyn8eat5ufDPr65fcP7RunBvOY36s0lw7Q6rcZZoEWNueAHD+oPKocJvry1730z mXK4D9/cuVV/bDpmkgG87dD/guZeVvZG4yEDTeLnDrybiYwRtBh9lIzvfbhdxqRxGEP2o2v0 oXtr8Y2VkRrvhjnT9mf3Oub/9mHb/B/sN2bLneba8jjTdWBPBrZLMU2XLDKiY/p9MtyzQ3mc ZKec0U6WJ341SLq6enDryKpcV/5MO/2ULOmomk1J7kTF8TGdmwyidgFyiX5RnRrUSz5khSOq /eWkVamfaCNiD1KdTCL6f6QGpqS0jCfU+36mL7ziONhUfEyjm+JxdIzs14o7FtGwE5q0ZKr7 Yvs43dQn56fRophN2WbEtchb5TzNsqgflySQswyRlWBzs3zGF8Cep6X+gDsgzlTIvJihrt6F rain3p86nUG9Cyf73NbOoNYkBbu/cDEmeUI/eEYKnaqSqNlD9qIHEtzSmfRCoSip1WhMZWau mcWwIJW7a0fcPgztCLOk4z5JdKB3KvWZiFTZMcHpol1EIz0twDeeFBNadZ5muvkiUusS6B58 hfs6P+pJ3XVgorYglOqKITTX5rT6HFUKBUgjNAc8fk15CFKY7tHfCo1+mpzMMrIHeZOoOeAp sItJtzidGAyE9nlwHuyh4gORLGQe3DmgrVXR/6WNSQraz1F12tIUuwiScXDKnrryS1wMyW59 zgTMdJZouEPB1JuczYLtmvKsCeUxrV0KylI1nZefy8MDI49dxIZ34spoV1gaom/SfOToZ197 gcFQpTD9pGXtkJJdi64uXd9vvcjumJX/kwAZf+cYGwKH/F1n00etTR+Q0qRVA1UHwSoG+oOO lt09+dHkHu0dOnGD2ZTmpyIxhfOHSgCzfpYOssVuPES55rRMWK+VJmnGRzvNzeSvBQlWd4b9 7UUvftiyEkpJmku2E0hDWUS9jObJq+SMa6GtRX/CvnJMBV1fk76od7VzZ9048mfkE7LgznG/ 0K0QDYosS0S7pjsrMCuNWai9esOsRNGn1OIIn8f8k0Z7+CFXLk7hPpQ+KaAed2uCW5GNrwpY P9Z76nONSq/zdCiFGpiGuD6ZNQSipiMWKplJMYw2jrPlZNEIv3YQh41muEqAa/GViYOpZNa9 M4fn3sJfF52LetMcEvEuOcePt0nns+6l9cSd+djVpcvAQogRnHujnOXOGcLy9KJikmC9v//u m6hMxyluA5SQhl5T5IlciOekldBvrl67in1e15DQG1Tbo67slHyT8D6JJxMkMg9p1r88ZtEv Ktgpx1vJvoUqB42vWvS89vDTASlUcVYW0UdxRIby8T/9SLJ2AP8JXflwb/945R7/M+HyAefe 1v7oGnp5b49b9Zqm/SdupEyuPGUP8ZzhlX3M2iwfRrG7TOKqa6VckhAw6zv1rbzy3q7JxjHX AmB5CQqpWaUwuEJBlQxAPI65Bq4FD3iNyCY18y3j2Itc1zvv2Sp5ka+4rnnsT69hWuJ+dMwv KX3Fc4QJCp+FqXN6NyDeEUmR4hNx1LnvjamL/eLpsgVt4HlKS45NbhdJvc4BDDuL1PWqW+Y2 p+5vPwbzL0fOYOvBGqCjNR4zDZ3nvcKPfzBZACpVL3bz9DYM8fZB+716dBihOC2HJRgIMCzv HtwwdjicC7YnnxWXHGnIfhMb+aj+kN8bcyt9lsAqnfhOnUeIC3W+93ZH23eifprzZ8yCSOPc N6/7F9rpQ/vKsH9DGQ2qfhFKBCCbelIs00Ea8GqYbh0dumb1PM7ov+bxNEX7IsFYFOy1WdPq vVlccd3qZTKHXBtf5PnLrrceHTgSXfIWlLbxwN3ln3ry/Iskm5iT9lF/ek/sd+quY7pH39YW hn7f4LtV7/Ia84piMQc8mo/q7XddckdHt2uaoPt4hA2rusdjcebUfbeav2LmPtz1VnskoFxQ Hz8CKVp+cu9P9DQCCB9dUx8g9pCfYHrlapO+QOE0UzEoZhmd9niGihJshtPOS5KcDz7dDGRg 7hbHu+UiH5C8/QSFt6asDk3Zz06yAn78K/yoaVRUIlaHoM5iZ2bxot4PUZlSX0NT/gHcSxC4 dBuaVn2lyhm32Ep21CpphmZ17ZP8m6bE+uEbw+ozkV9f0a006UyCss7P2LDXlQjoVivmkor0 HCIwB2hdk9Zzmo/KS5K4t1s8sktcHllH8zRhbwlrKdjWA7rrTorpYkdPZ8mz7hxcsBqsK6nt y2WcJWfJfbRzc992DD7nELlmGi3i9ofbGeJSO+VOwLcZ+6hQryHvyY5uHAa74d2OsdcnnG7T dvRYrAffGFW5TK1985ro7J2x5nzZ9anMcZqUgRfjuh7pH3S2buTLt3w0PRM5ie7TyGjXeS/5 jF3eNQZM5r/sMqWP7pjr5wl0AQBx6H8xwWPt/tblxpyXPaItNkzd3aVfbJg3La135+tNsOef C73HT9p0Vl8Favah5Dp1rJChyFgbbWJ3h8y6fj5UtofYnkxjKQLO9gG/gTOLv3tGd2mRS4nc psmsZY2TXt3Zjzv+xMh2l4iZ04GvZAYa4buOpq/v37AKDqN6GrLY8UOP4+dalNoZ7GzdSK6I UVkp6oWoEAUv4w7O2D/m/XLye/yXfdfeNhdO4mrxGiDW+HH7iw+MvPimOCHB7cThdGZC1+M3 bzuX64N4lIhjmS/SBBycvBeOiywrzjFPpYiXHj7mEPlYtsvYN0FLufwSjkE8ll/9GQ1/Kg2L LkNmZ1XAIKPG9+qm2Dz5i8mwzNVN4r0kjmYCOKOZa0syxOoN0stY8NdvmxW8P6T9TYOkw/iA 3aXRk7gcNYSOsG0y16sh/ex8wR1Xj8nSe39MSfQYh+wi6Cy1pttpVU3uXrt2fn5OrZFNnQOi cW1YDK4pZxrp1/1r0wTXdhX/TGO9gtDMj1eC7d57xG0Y53Dy8wTlrnCdXIvvRdtYN/qOPual 2vH3rBrAF1lCtqt1zMLgJb363Q6ER7CasvSdv5mi2KCMbdY1kvZlunO9JTBpZdN33NxdOx/f 6T5ID+52tm+aeZxAgDHBuW5IZlQ4z9tauGExGGodHidVlCAwVOTJ1VJfYbg7+lDS0nyQzXC5 NSaw4sCG3oIIaljHLLxQZCU1Fl3KCnJO8ssx16VcojSUvBSukvmLpKI7gIvuOEWGGi8fVcmr tXa/Los+TRxyjDtHbhWE42NH0uEfl3rKhSl0ua1vHOzbVXIRQjz4rgdvmMV5GmczZ/q+KIY0 wXFX6HvfFcafxENaBdzliLsonZeWZrq4K1MJDW7AyQPeGj2xFaXyZLzSia7InUJjqyrweHuX bprh4Bx9DswJy3XOyWLB3YuKKW1YPly+lMATPyh3mIB5ARH1f9vxZiOPtS1MT5aTZJAewwcD DBA0hNkEdlno7fap+YL2twQ2+8VUnHlvhFdtUgB9a53Jl+ranRYfy02r1z0pJqQ8fbid7rhw oJfjOHqxpz/ueIEZu+gqvmbS+eQtvwdQ8O+6lvgymXeJp1v7/tgcPMRt66d2XERO4+wj6m7c vWPZpZtWydiTgI/YH6r8kZOCbvjRbK9bIN6y54Z+2E9omyfGue00TV8iRVEqhXY3eMdpMD6W TR9sbxlvbu36obuTtz9TYB74Az7q+x6e/r0dfwerX5PJHf5tx1u9wJs6DNqF8LCoEutB8ERz mVSVcV3MIcNQjBaiQxAQY5JHKfvkJUzFwfQikeuDbgE6nl57DHLLSXAJXmKvhl4JdK7m3/Ba +4HUQEVMeMoClS6qBUm7VVSM4vFzLi0dj0ASL+z47BXxvPpeEE/3pn0aLS7nQVyWyF81W9+R u19MizEnUdgUkc5Gb3uNfpeMSUBnofZsevFldMxbt4wAEs21PE0nke9JflyrW9rV3B0zeLqN ArriXcdJ9enpok93zLSmCnX5e25fd5wdcZYN8gquDqWOVHRbZj3E/fgD+bI8Lc5rzg1d1gbl vEwjjuLhN4ACW0rX6ArK3b5+Y1PXnKEn2SgZB1/f9Qq7C5ikwLan/tnxpJFP0iNdrRYnSX0C KWFblIoAlvEMP5Qgk/mo6323jDaE2pK22RKFJS/3IEkG+xz/o+Mps+2kCCh6+y/CnugEBZzv mHixKw5w+5bZafFg5DgNtcV9uWdZxCVVUbi9MB91tGDcTarGtnlc//syzzLA3um7/LPjSaO7 ZQrjbx8+i5eLUdfDt83+/9g+9XHnE+Zy/97Bf3c+Ya6o+44ztfMJc2Q+sU980vHEHRuYp/uT DxZuTuQCGiAE33RQJZ0y2ByR5JO0517IfgtPF+x3uFDZxU1ZHXfpBXe8uD+1TadCt/yEXo+c YrLm6P4s2RfhmHXHWXwiIfdKsIn1G7zHjA10jZOaQVcJe2gUQDDRDSXDnoRAztOSB7zQv/Dd LBOAMzyYZqO7mgrn9bhhD3qlUyWdOWALOiYpSqTXCx4jKVKRYhgWHpsT2NFaOTidr1CP1zIz k74ZPSWDKn6BGvKS/XihIiQdLdEPx4WhcObC2d2Le9NfXAhOPV1fls7+oiVW0hv+wkESI4ej 8CEd+LXExY8js0en5cfe1mRhrF/xVWI2IZA4jMB/E6r+23Wk73jeQXqFErl2GAaRqpzY6vLR SQYf8x4tAX3wBxT3+9Nknspu1vvyhJrKVSy4rx2IIvZV8CwxLXut6V7cbazfR7PsHpwW1Pfv dbc/030+j0vTHtCqlTp0NGEx/pGGAblKqZVD6QWjwo4vef39S70+iMgyk+ahgTrf9sml3laC cWAcDWewpFtfm/w8gLY3TyQbAQujZUpjC3d26mNXujnrarpldlNa5lcr1tRzUvfCjeJPI7MZ pRaXCg5Fu2lstN8yOj9FdPIcsEMGhgY2kPuX5lGRDbELJOeNKxOq49HsyUfXaIfVJaN/TD4D gNmUk1bV0wQSZKQZU8nrRBz/LUZ8aslqxSh/mE6KMxSuWY5oX4xi8W6syCoq5xdVNjtLfGSQ JPwmUvBGeqXfe/cSh0dLeiaUX42Q9svdSemT1VhRbmpTy8jqvRafcO1ofLJg2kDpjV+Ji6T2 pfa73wSDTdivQ9vcSWfvBdvSCPYycW6eOS4xsr+5mJ6bz/TycntdigAwZgV5US17+YmEx1E9 bkyLWTFDQN8bC3J6EXVIpsu13o+z8EAitQeqhZQox7YBxfgEieyoJ5fFgRVRW7n9Nrh95N8G pEnbPZ64d1p0klRRbNO3xrrCZ1OqQk+pXWRGKbetM4kLl/mjVeH9Z5kcmEvkLKns8Zp1Xmq3 b9YvNaXBtw0mnhcpEGKTNLGDiEgwbRpIo2VwSuNGpsOjyjBYSPoI7esSbogka1nRqWb4QaX+ PbEnupZFJ7ZA0KkkiI+9gWwbpRChg2FK6sMM6qd6bqcu7eqvlLUy2oc9SnyE5NcfR9tNHcwk O6yE8NTkiERlPBbwykUURymoHva6fF937tQ0azaVjNpyjHlgH5caf08cWLWJ4od8NQxObz1n /kQhS7oxM95rNXbTzowW5KrJniYrYroFnqwXJL/eYF7wZpqzsxQXADuuxZfPBJYSdVM96JiU 644lpC1C3TudBU5CMDlOplNfI/J29VcwHY2eiX+ohyTIYKOBl4v5H+xb962YZJwhAAcfqcyi FSUnQGkYAFVVS2D62qkHSf8ferCw805obUbiLaRnZll3CPhg3wbT/Z5IBO2XdEZ8Tetf1hvv bE/YR8rwcECh4eM2CU0Da8omYrBNpvDRert3isg7X4lYXIRu7gZ8sfIapkJWbrK15JWSSHqx Kiv49ZjXxZi++fq5ynM5gZzX4RVqTNHwSUNptdHZerB/aLYCq5gfbuPWg0OtYjh07gW7mItR /2Do/KDjBdbjyCBgRfuthZtBxffjanDqCPMfhEeR164czSbgjZnN1xWAc8LL03Xl0Gtvtn3T TAt1vqzBh51vrGcW2TO2o/Kvrp7cafvm5n5XT45ae2LESrQgIep0Jd7UF5sJw4vhppOX2qIU sxesYB9H3nqssSCzCWIFOXz86uYcFXMXud+9LDdbAnk0KqMkSMyzyBNjpiOtIUvpAwGuuNEr He4E8oTvMGEEOkuGuS492xUgox4F0p/5G2Tf2pgUCZ+2UKgTkHu70Gd3x27d9tbK+MoUaNvX 9fTi4e5oniJ9Q2ClnAV0HGjdq2bdhpfaNr/1rjmw2ABBMzkv43iLZvVzRJWErYRyUL8yvhxw jd7n6t1PFKiqDgQtpgpUxQmtpzZd9bSQnJxZVqVjxO0GRV5Ni4xhzHOFYobNrMoVI75RHAeR ypz3yRwEfdlxAhNjULTxXPhJSgZsb2D91PK0mJ2copNlUsOykkDuC9rQyTyRrEE7agPRVCPm 4fGFmKXjFLcbYo4pR6jK34tnU9IMpYctvY/CPZfsKNNIDCRcMpQ8EdLLVJ6UgyCtjUjDSB0c jvKp4r8YZwpKCPwDdQq5Ne9s2QaQqMJpDwyvo0XCA8bTSwv07TEA7lMopNRhmbyuvWIysKoa Cla/01+FL3PqL1wjuAUnmQKK1nb/cAaErvDA1PLXdFKZXcAeJ4JxdnwJk5H+L7ZhlTg4XH2c DBgxpVGXCnwiC4pkLgyDZ1XpaczLp2W2Mdyi2g5SjcoInTQp7jknSV1TwNwfr9zTEF3t9FNg SODMat5xmlwDXiYt/ZUrXGTqGfWUpcOXPQWEGsdn6+g/JllezLg3IzmmyKIatgD196IHXFOe Wdpe0R2TDqo5KZ6qqj01co7qFOXozeBU9pWuc8/0osbNbuqUx3C/Vy+fq3pJXNjCcBQir4tb WTbw1sOYFNrVMvG3C2ZBU4e8SmXYPMpJMVsmEeldpF2q9DXlj3iYjHlE0kHHl9RTD0nHZme4 LpxCjCTQlTGlh2pdbTGyeEDDQRqsV//Jr/rkdd12G96gZQwWI/R8nkzKFVgQVUV3RfeNpFW+ 3aONe0isXFOcXtJds/WLZGQw3QMH0A1Qo8aZrnmjMefhkDsBZCRfKdQga+EoSSekTnPGX3Pd 2iLrtr8Ojg59XQe4HO/kmiN4N6DpFKZ0CTMquU4794br1C4OjowS+alia7TI+vD7H8H/A4Sw vPuXvvdOc+hNybN52LbiZvf7rh/Ux9n5NhnkL33ZDfOyAALbCdFKBigDrLvaOzw0k/Wg0WkE F4YCAYLp5CBZeIPaLnN1o6SUQ9y5Lw+P9tu+ISuu/bFbbbbW9f2GhSPpxSob1fvGMvoc3Lrp PvbPs1QRNilLweyg6RQUFj4ipgtWQeMwK3Q/tN03TGptz19+Yi1KCLAe76Jkv4ZKWPtwW3K4 q8VOeZez9TLX/GbAz0qLwFWkMCac46dulLYmOvp2xwM3T+BLN2Wf2OkUVyz0K6vPNd3fkdLt hr+Loi8r0S+G6TGJBBu6wvJeLSUJtL/g8FFra0WeLfaoM3VXyX3pSqOPORMJ4kRd5HvRt0NO 6I5rrAPleE2deJZWYC9Bcl2SpSOI+WiyLsmKkhe2T9WRFZr3M/DM4f4Wl5CTKZNEZ+lzY3Il 4+4WjWX1j1n1+34W5yO2dP/xpPq9bRPf0aW9RGos27fydVe7t9u+ue4izK59mUuKrrcl3dxc zsRt7LnOd183s/QFFOXM2vHbaZYlJ6TPgbIyHsDy2Qm8TO3rbcPhg0AKE8+8jDiy0uV1pfdb w3k2QCT1eAZ6psc6jO/K+/9JKsszzp/SLPOdEv7oxqEnfEyjyIqtySG02ar8dL7EZiR6A/je omVCQzB1N7pH4CQUxjkknQvCAUGR8nG6GGboiDNTDw+18khnJDV6qAip7GbvfrfNxIAYrMFr BPrakHYCOo11VG1mcS5dr7rupqFXFsIxdEflkpJ3NnbjTnBBGEXashZQ5EgWdS/G9ZtH/nay S9y2obAI8TMOI3e2bCF0Omk7crWcpVycwQYU+dyNG61f2W63Zu7Ok+gz2Cgk5IPgUe/B3V1H /W09HLpft9/m5bRI5SyrwlxR9U7M34ABfLSIQLOH9F1tZtks0+6+WQySsC5prqW6kW97IzyS unnEjMkwgeFDt5euTdu209VLLTWtQNeToSoHMRCjWSN5Yn+Gho3leRQqKKEoBFZI6tPzsb7s fNxuqFvq5XomuHOu08vZ9N4jTkmphV/nY8N2uR3ILpOvDg9v2mPN6vr9LOON07AHtOEejza9 zqaDwMNXHCNGUoKxZ7pTkvLD/iPDdGjfYzwDxRKVEXDRSbmmYuhUTXba6t4Th/sWfRvBd5Ul 3qudN8NTHpv3ruS9rTBK3bw3yssPyoSmN7R/3ckB4F+0Hm+Wm14yC0YQDwRo0zy/0fZ9ec8O XcjPyL4bkTKy6F9s6pDZKhoVaN2r7vZ1h6+IuCxLz4ZXmDk1/JU24mAIoPai6AtIFoXBAps/ yLnsWxV9hFRHFQIVl1ZpOeT0Xea+c57u6pgF9Lq5GCRYG9n6VorFm/MydOuWqlS0xGs+kP4+ K4PXGDu/oaVAxEy+cki02SIf0rSWHmcDFxESVxdCyRte1CpSjmzO+3cWbjdNjmelm74gECVI MVMxsvuNt1rv4qPDcBBRfXsjEHyUr27YTIHPgCVw09izoi3lTfcnYPHr/jQ4a8MvvS8oZ/e1 qibohle30hUfHYadFJeaipq/4RHIdAcLEXY3Wr+65WQo+8z23w6xsG0MBnosAStNj6VBHvXu xvJZWg7iqaMq/4BKJN1DsRivRzr9DJS4JLmV/Z+WNcqHJ9M5MsYYbgeCUGGwuJSZpA+buSW+ 94OjG0RTsYGnQTdvtNzvS5vxc607z+fa5ZJ89Dq2cj/fsGruH2kC77o7q82m0I0aGXRfEgYZ /jJKmIKSrmsJA3qXtmtqFHCVjFe6fLiQnYxTc4uD8kSUhHGrddPcpu277T5ZVBNnX9wf4d+I hHQ3ftPcl49Q2WY6TyzSTqu8ZK3WOB0dL2w5OCUBdOYX1Gx61BXnZXdnbM7QH4vpOR0e25dt C+nLFju0GK67+VUyIS0k1dreNrSxosrS+cUO7dQN02shKZ9mSay5rjRAHMEgnXgioSBY2c6h ns6ecVFTxkW7EAGNezYtYDE6ycqkQ9f3HXV/KOmzRmFlNx0ilJF8AhBFlXiq2xp5yIGnADOn H0/hgkgYUJBk3YaHww4j26t86/3lNKHkYfk2AtF5HMUOPFHE5+jSb5ebpXy7q8Up5cHMBnlo Xlkyg8YicrwOGpHV6pp11V3PPftDPIqfexsp8M48nj8fLmp+MQnov6yKSyAY1fgO953xfeqi 8TSyLJ8xsLRS+D18ZU9ik9pYnuoppnfFD+eM7pPZXzShGgPxihmznr1YI0gkx7cXxVJSskyj s1Sj8FDVi1+XW062DWMzKjH3XNIrtGQTlJ6ZVNtHDfozxqq1IL3fd705hJpT99FNN7bFVe2c DGfzSWfjtm5Lf1G5ATH8e8OBtg8/TpcuwcJT5cTf8PIbgdCWHtmRPWrQ2e/WFPVNLVvIoClh 8hmIPlSc6/pt92nzk8eD6azfV/VeQjVU/B8YbQAuW2N72p7+IsJONQHWmn8kyBawSQrgVrR0 13Z5ZDDiiLhYGADOsVLgZ070ccOb7ZbYViV2dobiNeGM752hEx9wf7L0ftH1CisoGB2hhANz L9OH//Dhdjqk9pCslRUesTajci0gPvryM/NrjjWxqzLvFlM3bAS36+0pMhGn09mk8rI+N/RA l5Ta0IVbzlVY4w/BVdi9u2/cNtNX17J4f7wrBevGbRt6M2RhGUncY6VuKd1Hg4pdb7cUv0Q2 q6kv6fbIVt7d0AOzlIp4W2Bk8mZAwnrIjJ+QJkb6SvIzpyJEqh4w7VMPZMD0oWz6c2+kMKle 6R6zQ0o5R+rdhGv1IotsQwdtDgYKGXEPcgmvcJ6ny+77SbIk/Z49ZJBwsw0Cwjo19Q5W9Z+c QX2RxfP0xcjmEG+Yz5vWRakb/fznQTKduBfLv6/KSt1j3Y3ZYl4PC53pyKN2ktZrY+5u8I69 Cf2iU7c9+9r7zgnc/UutG7988m8dWhpF7fTk6mwkKlwg9Gfa1UmigXa0qsMGN2i3DL5lMwC4 5E5rYPssceJ8nTa6UyjK8mZ86lAzAnWFawZSNxlPqoWbzaF+Bw7TV0l1sUwGIu0k/t35tnpu lo5uD5rvvgtt1GiBUrRJV6utcbCjlEXB9JVxFWqqxFlLpyoP5GfG/GYLp+1hvCiRMEH/E2lu IyijJMbiLApBTw27v03d8158GuuXDnuREjmVJIWDxk+iGcwr6bZuUyG/tXlUHlW9U+n2xyv3 qCkUHp4yrZ+wVDqdMI3JLDTYClQ4/41KHCQtYmBW9C1nP1nGTP8OIBgnagaaBNEUF5Vg8vAU DqW0n6XP84sosBQcTlKwPhMcmGnqhPlqbJqdLyZTVFHaVS/IVPuWi1qXi2abJmb9H3mlxXxm J/wpGQQCPeTUOyAj22Z9WUziEar38rSbLpoBn9rEce5j0FRyDsWBk4Ej6ecJYia9qB/zycDt c1fKHOM/XZPisr/vertFTHwSB09iLeL/RkCovgTofoUNUAim0HuJbKsmnjCwhbrf4tU+e6Su eUPPFxiYWabtdC/ZY2+KdEZoMUWeiCLBNZ0Yb83HTNA4xiRVMGxqrV/8bCnGOReGcwRIICho uGV/9QhfK8YxDhKB0eOHefJzFZYttOQT/zA/MgXR1dwNC4HQjuLQNNpx0x21aI5bKntw4bNC 14Gfa4SRCnxemEZiJ+/NYZqtDdSY3uPiNIOvcjSNXzCaeiTJdOOZnTi6cx0HxIbTY9NwAjfY 3c57K4SwcJu+7QbWaCQ+QrQNH+q2cKeBbg3dJo1wtsCzUw+c3fmiQ48o88/1qwCKg+Jg5k1s chZQu09RP1usX6iLhs7EcS6pcor1UorM3z8Nt6ao9KTIHDOXyTH5PTU8ksSTPAGAJ6bLUlMu I5kBwG5HpqvdJZghOUm10fjj58NVckIIcCV0iK/Ok/rxorlpXMl6/JKWoXlZpOf843jAJq9p y6U/UUQb2l2FCgvUy+PZlLncB7OyKsbpUhFMW4KOelvNC/fbKQsUzMKnMQ0o04kwcIPa6ZCv 2P5xx2Ra0spMXZi0ouLCK454NTN2Q5ktomJ+8QrHll9DrZ1mL4csHso0+o9hfGZA+dFckrZn 2epVyuUSheGaz1WP80F2WVaA8DpWTroOcfOIe10qiaPyJx55o1EVGebp8KIKcf9ArRYfInXW o9AuSfJJ6Eh8hcLxUakKs5b5WqsozqTlyZJp4P8KqGRZIxvs6T6NZ8j3kXQSxgaU4PsUyxer sJzTGCqdwMCy3UmPKNtZ7qOAvmaLT7i+Uqan5aiDktkDSDn6wKhgkpPhTKhak3IcPxdMAy0r L3K31D703MNvI69ykh8z8dA0CKF+peDy2vtzQxK8leziXG8WXz7LEx1TfXJ/mfyixiDCvFZF nF1OjPFcmGQFRrFgBSXY77VqEvHq8skxgv6shaIue4nUU9RLOeZcwAa3iQZ2hKtofWtd+5vE W16c10ScT/gWstnei7n3Yu5vIuaiLxVlIpORA5qZTDl1cwKMaiyaP/JJQVbHeinZDJXVJuij ySQZ7nUJTFuN7M/WAlGQBzfaApxUsutnA2zQcw+PfPQVMLd1mmxul46a2h0B16HXoB+mckuI W8H/qJndFSGNZ2Pjt+stRNpEd5243FS0zehYU0VkQ9PXTee+U/JMc9s4fjxTMTdI47PhBT59 hU22OjpoYKOcL2/4OCSbiXW47xV6B4jjvtSGEZCS/w1qiKOkNO1Pie40nq3/4nbn1zdv1Ruw aWC3rntffCYlshmK0fKFX47P/+7WjZYvbjfGoCpdsvl1eKftq8P9Rgqb++3RUetXN7veeHjr oP2r610P3r7e/tWdrgfvtI7x6LCxPg+L3FmJ2+3f3Wg86oCD7rTChg6a+9H9tvZG96vbjfVw 0Uh3rrd9dbTfmB33WwcIia++L2l6KgkL1x9zvrvT8oWlZ3noEB4/7Hax/xc/9O6Rbj+gHae6 9Ui3t3Z7v21P05HuOgz7N1u/OmqIF/9UdxzpzgPfcW67D3y7bLrTNUY61V1HuvPE37jVdlCa r/RPdceR7nrw9s22r5DW2nFu91tFzFEz+dg91b/8SP/ZRbzcD4HZvUNtQlmPDD+cppBzQ8kO DxwzjG/QQG50lJ2/5SJ8xHT0EiuQeLah9ettX10/bLBuOd/eODSz1DTIfMQikzEEwXduR266 GqfQ1Ygp12W87vlvSjPxUbfo7J0dOLLB7fvncVr5dQ7j3x5U473bhf65GDczF6WbxXgJs15z 75w2E7Y9v4dr0/ai0+KcwYXHKXib9aA93ws1BkBboExWnTcmUlVmPDepyepUTmHd30Z7iJf2 kyTXcBEbB/HfIow/7jtgpDLdVYDAWBHcmKevltYB4TkD3Id0iqjEP8jIp30m/vgOrpQmz7Y7 1Y0vH6YDsqIu3OaYu/0seVZdKIr2tLIbqsHK4jb2LT1G1rJNjtGmtpjK8FZ0O+NIDWn96lYj zcEVGrU0BxdXcMt18HXE+feYjyAAZ50UJZdbs2E4JpuqKgASFA52oKlRzEFguuu80ZhOcOe2 sNk0jII3nZNhXSP1VxFPbAMvhGZW4Stsr+f5S456o4Iyp//OmG1z6Sd2JRJY63GHzlQYevac WcckczvbsE6H9QvAFwJGUHjZq42Ny/gTbRJvEFWHN1tEFf5AQWaJObBCHG5NDC+Vv9xcVZr5 O+TMBgHMTOvRI5kqwq6YpicsnTypZ/ivtBCYlS305ciSpXXW4sd/kEUtbwAhI6qE4lXNBXqZ HgdbxVCz5FhVhdVtahYucERgV+fsEiYJm0v0KMyd77hVG8MqFXEg3kdTarnAgi3VGQfZRdTg 6GC3SM+N8cKdlQkZgmGQVtuF853V/baOSmbcScbKRdloYh5NgJeyj0utixlqUAnBojD2LM3v FC+VepcpjFFyCdMzeBTRcI9LYHAD80U1L14leaGayleQeS+Ve45/QldzBv/s3LgSxzIVs70o yB/i7vejo9/8aiaJ1Fgu4cIaToEnsRW97YVRpxm8377y3hkbG/xqYwPVXIaoBlYE6l8y8nXh nhW5cqUyPJ0zGrhXixlfIkm1HqXUfzTlupw77c7m1w66SbkJNc7GAUTUAxBZcZI2hfyE2Zvr zHP6W+9ep7aBGVI+/DFDhqRwLRydp4WFHJFS6b/IkaRMDqca1J+KM9BfYb8BP9TgLnudgv5h jO6k2jvOglu2d6wyvHqR4mBZ091k+bCapYEd5rgE3v8caFvNYowTmrxg+JN2r4eqjroHxTJp tSjwNTrUbhX+6eqZr8abDMAN3bBZat8H39d5J9rqRG9zJd5+OxHh6haWask77NSOOu+NLa3O v3OCvBOjzUN9ZFCh1lJQXtVNN49KvZp6+7HB3yMAfozKopUVT7/x93FT4V1AxZVQjIP9QTCm Yzh07YBXolRl3WttdsSC1HC6lvFOg18vvGNbsDnu9ul80fX9Vh35uqVURkjqoZs4UuMh5+/Z 6kjIWpMA5HNmJqlejuMWFnH3VQe/NN4ewAeFJ8opgXMZjJB0w6LISLe3lZadI2MC/TayZ4uw fGciVZy79uE2zlzA5lI//9wLmqlHlJQ2raPmh//CLxzsnsPx1KzY3hnDd/GoA1MY6NehevyV 6Mb1fO3Iu+XGYDe3daarzVvhuBZSUhznwL13t2WdvuKY4eXXyAldXnqVvg4WvMfgvh068XKW YJNpPB9qwqx1lTTX4j5XZvaC8LWwceTcUsI0KFXhNiBfrh+2xkZv3G4Y217ktD2oenSzcQ32 PeYGmYDujh3d2nClK3ZocKsoc/otHHNQSVScP0Qu43bkpvGPfdr2xtC9Lozi8ga50QvNWLHp Ur9+887b6f3CpagQgKprKr210/HjiUYWmJyCW2RD2eA6CZs/zZNz+2lTZOq/kGJwaVW6qXFA tb6EToDZ1gst+ql1cdRFQ4fG23j/I2UaKt4GXsfAHMVR3iKDWufucvqIVjbKrvl0yafLOdiF G+P4jxfVbLMacv12AyDcesraNRH3bHW/7o7BTpxkRR8ZerZVfLLK8ovOFm5YCoFfr0i0DtXw Q/zdqhLfZjVOTv2Y2aZdd5V2YrNkUWOW4/nhtl4YpMGoCWqa77o6YWgkD5PzcNfMmbissqPE ry6lvFnfuaKKHfwNVZ7GntmAZlak2D2VBtTzDotPVJfaU9yx1dp0n9b1eAvlRwu/JKwEXW5v yb2rXNBCG+/vKuVOaO0wSUEyMQwq7622zw88u0oT0rg7rZWxBiU9kqY1Z8kvge2Jo4P+nXgZ Yt3SyzI3+Hu7QUTkKC3dLR61xk6cnNdPNWw51sHGQIiRr6HZWTSPXiQj5JThNmpj3PK64Cov 347iRS8Un2OfIOh+lePbFcTFZFJMqxktDKcoKjSwgwB2s7f3XCxc/xUdrVCcSpyx43XF8RHc U7Z4HZMFg6cWKy1p1rTGG5bOaoWPhZ9GSYnEUPlwldrzpL/nar6aj4a3Spq5vXiVlJEqB/GS w2fTeJPD6YYlNboilWdcmibxnmLuNeFGM9DJedlKvpTyK40vHhSzTMjN+0AMz/KhZI9FKPUH 0UOHwU1c1X9eQWBd/jWuQpvADX3pMtYcgGr6qGXlcStZzhaN+E6kdoyteiMCmpY04Guq0nHi C+Uf2HcJXPT8gqTu3eBsMGM4wL8ZimKEynM+gbOTDLmLSTEELaqqFbriWJzdk4pGAKTfKrLa ZJdRrlx+I+2ERHyssexQUMVgk2Z70WMjaRKWaEr+NNszSfbmqnjGJTqXwxCTpbvDLBU9yD6c 3a2NsTZUQkmDZdfQhvZvv52po01AjnUp+pHiWNsRdt8HMQL6HHTu+0CGRmc4vcNRWQzjV3Rz wh5/uhrLma+8sihmXdTuC1TIDvXRN2E2da9r/m0OvNJ4PAmiZrjGZGWlVncy/8EvzALU+pW9 EdpW+tLZNHdb1QsR31qr0LxHIXVI7x79U70kod8qaiD1UxGJb6HpygyoUddTc9VN4x6BVlXW tNh65ddbNzlNTsVxrqkVEuAtt3MSuJw97fc5p3pwgV2O154WwxS5F6/PnBvR2+TdunD78tor 9zJL/PRicKnlFaKnt1hd1x3ImqN/jvQiDBNn/CLNQ/wGAVdgl76mHYSuyvNitHJjiQ5cx+LG ukXHTacmkLdff6G0uH7TlxY1n1/FNel36e7tZ74o0M4jZsEwIzpP3K1sMsL6jB9WxGiuw4xz YETnIX1nmMCKbCLOmlX3fFWizd9ICgEdElqVF1mSl9V8rdEFJaumhbJ/UhQTW5EWw1XNnaQO SVjicLD2RXlec+373bRmlt3pgZtAJ9PqwY3+XXVUVTkHP0WkymoUG15ye/+t7nT7+kZk3Sn+ 1na/1cEJfnCyqfG2+NAkVum830udZtdZo61Lgvaw9LQp9MpHDsN22n11t3oG32JgnhPR9RSi P3HbwDo5eozV+p1eOf8Gtgvo2pO0dcJz0Pm2W/uuOfmn5CqyXYvpdCFlH43bqhVB5w3OkgvX ds0TzYQjTxmWHBPC9m+Bjigxz8DmgPZXJLlJJczWVQHwC0PveLswWVxUY7c059tfKyNCdCFn OaU6I7MXXbrXeTx/VqVzA9NkXgq1by4Rv75lVT1cRvmG2HGdcHBzxPhWM0O7ISb8+hzejnQA ndYXS68XqTOUKyL5GTLJuSQ0Tq+mtXouvob2aqQZ7hBqTGiW3JuGmv1T0vR6HBfQstBld/fA kk6zpF3BETled67K5ISVF/WE611GHeB2P+A3MU2hzIkln7HaLcjFwg/etwxXml+Vrm0mtnLw 2fCQTxwWcGpnKqVymoZsVOMHt31YlMBAXl7HdmSX2Uh1XRhOwbEeM1aG2tHVXO26hYAGoPao aeCsyDR0eeRjOBvK6jd15cb8yBMjrBAEpap/Gjh2rtMErGJPy1MVAhWGNMoTMliBJZ/O5J6x SaV0jUgCuXHE2h6JGFIyyD5STC7I2FX5qT2GlFdOZ+VerGwz/5PT1Auno1Zdat//92uM6pc5 AV/5pOuXOwWPClT7QUnq6WqQgKjMcm1CYVtVdMkP82TzsXikqMbAdfaCtDw0uuy/mceMmyOz J55VBc7/YIRgXhgo8XY7/1FhfN/aYvgW828m2FogUFnclXOqsJjmgiaIj0YoF2X1cixqK6u0 KFRUudu4S9y7qc/Nc+p4VL1BbGjzwLdXfJhA4FmT/Hi9LffR2ixgK/v+u29UDRZV7bzGVXah c/Xph12vq1UmcSpd3nC4h6vZNNcOEGcoWLogvsA2f6O1eePs05WUpXwN3WKglrZvqSsJdDF0 Mjzad99sfbdFn/Wn99qGh+8uM8S2BXOYkWv1rVpG2v2r9h7cMVP5ja7FI/Qm0I2k0HgS/Xjl Dz9euevp/PbNIqQ8RgtUpGSELQvn4NPtPTrYb0v8Pbh1J+qn+bU8Oec79eCIs3K9j2zdHR6P VreTn1HFqG0ITu00+Lv5x6DjeJtOm3mEYUe77qRgDLml0jO1jly/w6QY5xeZTQdo1jbqfuud 8Ft1hSW/rHr3i4WlBPW4LvnyA9cR8k2i9ERDAGryMrYRnHZ10x2V9BFSmyQRJEqFi/g8ziuT WVLJhaOzTszggs2YDJu6aw8qQJ4MTldsqb5YAcItIHDELeaLSZZf5Cvz0mi+4BdyvU5Om1ip H1Nr5WocsjfsFB0a19OXalZ4NZy6vEV7WV4J1UqtvNr5Urklne+2SRlP9C4wSzKQGpn9RHhq P/rd7m6UnuTQdHd37/kdKerhfjnf/TeVIq99udd4vqNb172DEuuQ2Kw6LabpUuAc8nMpou0o q14F1zEv4HQ1RyxUKk9L+N0BNHd2xC9ezAekBgABdgAf74RKxyrvljk13q87XnvbrUv8uCBx O8uRgZQLH2lUDNjyG4IFj5QJfpLz9tQiNr0grDeJGwCexFi5tpsc5pLmR6YjCGUHNaf3U5rM 1/2L05mqUr/yN52uKpcnS9LAX0p1OdUVQ6Q5wutHLDpLLA3XJ2YW9M6lODw88IT4Ya2uWX0f tIlxNjIQy3M7fnkZfnhklLkHrlEuS8CQ7VrNzae6sKZOsFpfUnYeHgWdyH4IkX89bA/yMWLP DTAA4JdzKNxodjZFWCc1+VeC35javwr853go7/pC1CY2/IfyIMoRzNo8hoGu9lQujp+fk5oD hUIrlsO+2ZrfV8f/GKIKsBNvFfan9awPKIvsBXNOe7u7aeHlTnS/86D1nXw+W1+q3xSoLnDJ fWZJkj8VmRrnkpPml7n5QUlQ4SuzwwrxMjmV7vfrjdNZOy2Mx1ufom+8dz3ls+J7AOxDnS+8 VUNR8vYc6HfXxQSyUln9UuLTcV9kyRyahevASnN1OPCRy0IsOrFOig8dRDefluSrBDyn6RiM hhp5CNGro8Om6o1zHHusT1iPB8KMpzrKQ31JpigsP3TJA9UNbtAkAs1il1MByecOWXkXtVBp Buv4Ms5KVL6WO9gqrj6EUk1E6uozfBYdGnb19vpbezXhYyaOawl4counw8+1NCihNKRKqbWq N16BRdpOkmlsXAy1fmyUIshOGqVEiOHXw79UTQ6n4QAe88t2bZXdI4AQRp7e6o2Bj7b1dZkM 0oGu//Svf07Kq9p77OnArEjLbpWM0yyp+2uD06XTrqVMQXA3sBWovb8QQRO4b5WeFusKfG2q mt0Nn8eDU1FG1IaWOAi7Yuz9CpoJBVA04/d4gE17sjHVZMj4FWqrX1Q04bgNTF2DsCJ0tWzM NosSPgD6ILOyNMMGqtSmbPFtPpCwl+gAATU0UkbFeszVWsBlrHgtEwXPeliz+VSEnXPABZ0v 2mYPNyJyBah9HZDlBuj6BHjAjcOyyxQicExmHivr5SqnNcpQ6HCyLsdJzqnjju7CTXmGhmaf LKD2cycFGuvsGNotn8FtNnYL9BrWcwUY1pf6a5eSA4m61aJSgxOAnhq46BPsSvQSd+nOnS/z dDRzJytWBhlzFkq5TW5rWESeV4TZMQ1gMfKG4LqGmXRdJ7f6BqIyBrn8iDIHL3r0aT+ZVozj nsTVq/RFrpZlXmT9WaTtyr/OzpTfOZs9IwtCEXX6c/lo6gzem1POU96LvkpggvLq/yXSCf01 5QBXiejdCozHresfz6YvuGj1VNZ+5eutQSinvYJtzZyH6lqslTevu4M61TGHUOjLxoUS4Ol8 ZNajbn5d+o0HtpgjCdJdI0mDYvLjutqC4y3kCbW9UXSqSkc27hh0BASHeNrG6mmbdQimVB5M 3fvitcz5L5O3eYEHdvGX6JjMFQZAOxReiBl6dWWUH0fcHJ4SX5ISRpYq/QamK7WXO2ugmnMU Br7NmQr+VBuVXnPD5Dgm48w8KtXW6FN84BqJsLqFZfdV8gIQ+CGNgZnG6K6xp4CZPc6SMxLa +jjK2LQHiQ89hCMSimmI1FrP65Erw9PxhO7ytEIOBOjMtFlMA0QtCe85r9ddRIfmJAIaGP14 xV6myfDHK0ptI/FqT9THrsZfZo7TD9aWZ+2j3h4pezD2merBkUr2d917/qbZO99413y07V+r O6HNKp6nav566vnsu3ertQ+UQfJN08q5pNF2dMtaTlyF9o90Z7vSYBw/N/d4s6GEFMfTapxJ iqhu6Z/daEUde+H0czXK4qGaac0+0WXweW8zvhNDd6cdF7XXGO9FF/ub17TxmHHlaB1C8hBI rhmrg6P6h6MVXzp0IuYAOm4YiN3fNjLhQHH32q8cn3I8cJ+5r7EXmheI3t2NPgfWEz9jVfDD bVBoAaH5E1auJXwQaoODIM/IAilyMeUDTXX18MBW7OYuffHkwTfR3ehzuAv9yB0T+UV4NiaF jX8n7930gut2DlCzSndPxnE30kRk+nP71vDv5zF0FHl1IP7lv/tO+3eWfqE+rzy2R1xdb5j6 YM4Nq4GzxE+zcyUE9vS7YMnD5MKaKDw3fuUyfYsO2NPquQx+5sKHE7UXNmzIA5tR/hR1cmnv 4Wt7FQ60VFB+CyNGnCPxA1fNjeJrUp0X1i5pzWeORHHl/aYeWS3gT7CnNRhmiDt7HI9g9Kmy DV7tvq+HCwUWK+ldL+g2KiW3Lh6ne/zL7rfeciQZKr9J8plz8LrqCXlN3XAhwFeVWcu2rxzw iY8BZ84QJqjjVCwJcziLikNsDIG1t502DcqGrvmp73OVFO+83Tm3C8nnWfAgNw/TsgdKlzxG HVVcseU9/BbtzXXLLIZoB1x+VXvntvr+3NJrrPf4bkI6mF93XG4emeu+SyNE2tiT08TLW5Z4 UjSZ9Unfyha78ZBeV6UhorsPt8fyFvBw1YB4TEvgdtKPldCLnwK0/iIuaYsMi/5FtBzCXkZV CsUww0UdmKySLVL6JJAk0NaX3JSPrfeie3Zu+bPzCacbo/xlJL9jOHosfjE1SY1xBzrn9CCK TFXy2Ia0IRBPEmRcTBNPsYEXr1/MmjFa6/eU9AwH0uqgYsWnZTybYmIzNzCmsRlALvJAecj6 0j2BY8QW2+C64o3l8q0BflHbongUKvXwPUTesFjO1xxuHk6RcXf2bM00iZqHKVLmudVMTd0P fjpiacRpWAoxq3JAJSkYFHfjpJqKB0WIFcCjsGm3HJizNE1PTl0PPfIDA0TO/tMex+WTwkKQ bSBF8YrSitpzKKvurVwsiKR0nGbxVJzi7MNOBDvNjt84unrtKu8GQdDGw7MaaM1uxngyQe7M 0A+V0sp/Y7yt2hNY9kztHOl/o9qN1J/HhRAIAZEZyPvGPdy+NccGIPw+GKJkXL40omM8E0x1 zu6LZAC7K/sre3yia8FB1rdXY4iPOe7qGXPj4rSYcUfWAS4bb1EtVarRNiRCpaFENR3f8zsh H1hNzKbXHLp7Bw7RNNeBzjxWRJwp/LzHOB7YRXysA/FvDBnmL5MYsBVSAAg9RhOlEDw7Czrx FrTee9c9SO1uP+KipizhK7LaFbdRgaZXr1gWsd+Va0fSEgaggt6ob/tq/LdiNdn+ae3UlAsK mGN+gz5AzqE2unn7Rv3JKdJipzWdlhVMqfSN45rmDQ2SS4rrxIx5YIguE9N+a3/MxfTpP38Z iWgWvEPdgJlH/IsRfhHgEHDfZqZTmyfaDqUe29d4ah1jN15aiRkNTlL9soC4dN52YD2VD3Fb 0fUgOM+7qs4vQLmenkBKJJKwgbFKxg6It/77rpfeMArdkzoxsLh3vPC+8/LPGg4c5GsUQ07R 3vDSm62MWYcWb3YfMbKUGQV0hpsJpZhOcR8NgZLTvU+Qq8Wpxop2lm62CQ4WcL+KS5Q97hu6 ao/Ufc+lFB3zi5030vf4ehnzlZydxpvaPjzwkZGuSlEqj4CsYV1XDPkarSrRQwo1jERoGGcu HYr2i9iGXY2D2uoMk3tddxOaPX0tH2ExnCQyr/Cm4g/yJKzl2WlJJ/QvSSu8GrlBLg67GI7i 5YYFuGE3mwQCkpJ5sA1g7nfO8kqcyULjftfdtl9JgSnSFVJ0VgpcQEexmlwnTyASVYTLFmED cJTv2PmqClgx7sutmWYHNo4XOqDPCMjQ0MbraPm6rAAS1UDFlxvm8PZNe2CDnMcNfJDDWOOi tTn6VpIVWSyLqQQzPeCOger4DXT17Y4HwPNRBsjVTocua4MB3tVYfja8w1w8X2ZZchJnf6v3 mL3qDJ8tL00bYtI1jy2Uz/Wj2aewk1zB0L3ER7aGsZMwFSTea7hMOWXWQLjYxRByl7pvO7AF XAyItX3vPhSLWOXjxsqTsrqMbD+y2Fn7prbj/4WC77YDY92Wjxpj2DRdEo34BdN1vUYtIagK XYChg/IZkXukFoTojZWly1Spp8lg1C9+1sxi3Xyrgh4KtsceMVnEWmLq77z77FuT5ANA9Iy1 KcQVSXdVIfUf4mejacWCXiLcyJQaam5RUoUa5KKi0j8l6TMmAVSM4vFzhPilrAecKpVNLO2W 60c3zXyD1UgYHhpZ0nZATGZk047N5TVOrcLW/UKbQ96g0m4Di3YwIHstX/e3TutOMSLc5DyS mdxYZFsipsg9HKhhyRCtRvNtOEizRltu2VqDNC081JfTKm+tcTzkb9MmZVK4uEw7ubkUE3qV nsUVk0UkQwBbNBsERzITxVlkKs267/s2mstSzJolX7oNnKPbd2rH2RbD2Exf3uiIB1b8cPv4 34b5T15WvcaVwcdpkzulZGZgGjmNN02kqAiEMlxy7KOHW04es60KDCvnPFZjPTdaZe9dSFCZ 1HMXc+6g5KI4REfE38k9t9eUK6XmpCiTOk16Y3LcohcpLJv+esrVNKixz778588fP+HXT5Pn KdwsyBKM84RLZECsTHSW5HAF/jvVHCcV5Bdn8Ugb/QxENLj2ygDbtUeQlYPkbtsIu+zXAxfN +sTztxjEPs62zf/mFbT52qEaGSbj2FaDMb+Xl3ObRtKXCbbEF6qmFTUWLLkimGEtQ51Nn1Te xvfX9L7rX/EzWITLDtShOkisBjf+f4cSX2HHg4tHS+Uk38/oMoASDGOjyPoLryqLqryc9SSg EY8GyaRqC2N4i3HjLRcjL/Ld2oKEZO4vXBBqSK1Jo1Ex2/5WC2Km3k34qS8SNYV1+tsuiJfa 1kyPwEhdC9YZqeSBmE6/vdrmEF7+uSZKoSFoUeqo0yxTEDFcRUV/OH2+ZkEzpBWxgkY/1PXi 22YbQkv6c1L2oi+5sjSNmOHFtDKzmnLnc1bcz4vfR+VoBojXheLcSHX1iaqFwcLrgmVak7jL g0Wk9eQ6bTjr8d3N3fETMscLtXc9f0rD7ag3lFsKzPWbwKV2SQPphmVvlkoGzngQt3jgJWQ+ y9KItD9BSrL7atzZ+s19owBOGpPErWx43E5PcRLRXXsZ/nmvARfvgyg5Da8RKH8E6rO/tIXK 3eYOTHNI2LctDDc+eNN50HkuCYBPvOcc/A1euTOE/ytPq9J1QIS+62rVAUaaTaycLRxEeujn 4Y4v/kqn92ytfRix1Gvvfoct5iN1SOhsTtJBKcVGkuFvUYvEe52re7Lk1a4rR9fUwTOFmVQZ E0gd2Z1AUZmyeeBQQAtN3WAiHkfNLOzcGfyrz4qGN6/G5az4kYuZPqYvIXumxTJLUdePPs3S kSJkFfR5x+u7puHWkd0vDrpH8gJrxp5l5Q/B0nQU4LUCZSmnays5yYZ+mYPje5iw2+zba06l KO42OBwetM2jhbaBMZih/O0HfceHBzvcmA4Fu0OAVCjTYaE8IZacJp3S3qD1QmJHf4GMIEMu 8+F28jNpYDtlqOifygMpk4FHna7zt77U+GOgfqaJmrF6t2zKiQ4Gs76R2v75kQz0kJNzGFEh PXAZ3u2Lz+DuURe3acy5wGs0QU7Oz6bSObKvrliCtcuWtGtm+3xEe6TIT+7hdV+OAemmDt/l t310TX0X/dF0dFKkOZQhu4zoCGbM6UsxgiGq+fJShcvoT4tz2nA90QHOU/D5QKvSISSFIpNu U1tkddlGk+NjWuVm9x+DDYvGrF8KkcgZPPRWtXGvls1dWDoR5ite7p0pnSrbRmfETZNdB7is aKsTpcgnAsfjNLS0FEp/dMdPEkx+nqTTpJYYdq4xdcnPOipj52nazH/6WbDk2UI3JzWT8DZs zNO0MgnjWFHSK0itkL3DAaBtzqsy7VH7V8FxniTiwsH7PE1bTuVOS/bT/f6i5BSh06wBSIks GMXwKpWJhbFIk4odDsQCk5imRTj4T6XipuIULFNV2nKAtVkKeN1lyeeWdG7NS1PJyHuD4Z/T 2rDplEuYb4og6V/tqRwt1uMvHE8CZIJRS4VDiJ3do0VORtBZPML4Hb8Veqh9pV7Sj3sAHyHA Uj98j4WkaL7g+JLd6VJJUSdfcXMMWBR/+0uTyVQoNGNz8pEEg3w+oFr0HtIU9Lq8IyBIs2U8 50ShYsR+fFru9fPkReImGA198iYzf7hDUNiVpQcdH9oYaU7bG+67csKlFcV9BCAH8kq4xDET nRr5RR9NJslwr+M2umVVUL9kmQOx8K/fQDaBVzrK081dcMQjPYndDRy5ZICfNO+MDvlOS3c5 yV6LsSv54/1KPH1OLjCiwFrGqaRMe+/UipNwKmyc6WIk0XZdHnHSpI5oIOUaHfo9yxMBg9GM zQZa4rYXeFNd3vHVTzm6vK0SCR17Rco8u1aRz+Z+/U8doaTGpPSPQtuZ2mx70Sd4zBIWcXC6 x/XBn9OZo7O0QrwTWDzo7ilyCS9sAWpUQmOmMTl/IrDsqddHXlmTPQ0D5LqpIjKEsW5BWlj1 UjIdQ3T33s4yNq0xZTUew9ulk2K8zkeXMdRvXT/cvFm/43f4+9RzGDaKMbdCQNoLzz0qYISz /Jc3ASjiFCmOhV5Y8iE3jMm4U6TnDnRcAtmBHCDn+ds2UvjROC2BDHAtOnCgrLuttts3HII4 W7CI7EQEh+H0Y+gSQEH8aR1B8oRsQ+1PswVqetBJFElV49HO3pj5eMJ9OE4zJFMPk4oecP0F 5gaHcaoJ/vDraTco67blLYOJXc8L7Ra4ty2hxCNUrJ/m0XaMjJ8TUnR23EzGaTxPh3SrkaFy MstWU7ge30zj5U7gBZMpw2rE2WDalw+j+9PBKSJZwWQasmZHpPVi6DH/LjB2t3XfaQi9WPNw xfV4/wM3s7eTsch5gXVkBbsf7QJHXnrZjhpUZ4CqYz0U99cd73So/PRLY/VS8L3yFuaiK27Q HwE6VYEEk9gH9wU9vKo4BVt1IDBWy393y/X+gku5n3AxgKjMk3i0cAJNTnj6Ej9tf+PBgVfI MUxMJXTrTWbmNmIqKaRR86d39sImCz5w2pcXd4SVQe45jpc+aVP3i4KhTE/x1+Tyb8NA5N/e Ls+8nYC7Gxro6LUtZ/TIYeJVdB1ePFU8S9aRUXPHPdYecjoZZLohMiCL5fhBWpro6N4td1Kf GFwt16WQsKyih7Gbsod9ZWiFHY4aHlJjp1kaXxCXJmC70NYDvy8e6JolbsI1nc9COK61RSGx KK39zaA4wNiGzl3kNKUqcZuRcf2yyGi2nBpK5Wwa6hsCWcrHmCLddDadFGXCrgruUARCFwkz kiUHfW8aIB+x2eP0xHnMGJiQI2PqsbgLfctxJc2jb1ZDHYjXCcFuKNu4iPPK0vC41FjueNj8 xkNkk9B4bHs+16aYGdprIfzTHQQ7hlJFRf+ocV5sbbMr8Vra6KHu05WtK97xi1WFMS4VFUVf VgI447pXcXYO+uppIlj4IR9j49awHVP7gTaL3Rtm79nO9MgCV/iOhSyx2smmJeoILMkBmQp4 6XRoK1+4uNHGvPxRg/s5kXQhTiW92nE50r4XbWGY02OYf8J+iSexAa7H0YzM37+yGzqc745E f12VSsGYzKlCOwhbRswGz8JixYfWrZslz/q0L7DLYXWLvSEs0oCILrlEgkYbHM/yEYzv5Sor TmeKjhhc9ur9jQn7nwqY9HrsR3AdDVlHFixacy96ijSnXI6wrsZlQrVA08AQsShOp+lJoYkQ VNlAyzsjFNMO4TL174E2gHBA4A5K1S5a7HGaECnzyHlRlVwggIfFBEzetD7jRDKD1AMqdcVa ZuO8eM6k3GBVIPGNWKBOo1o399YPtIeWE/odcNNr+u0Q9XBea9gPqWhJ5bKrCIWMtgt51buI oK3gP7RRwG9aeD1OA1SaAW3VbdNEFO5DbijdQ59Ih8vhMd38wELJpAVIGZxGD4ySSnev5npX xIFTQ2ZcBz94HNH0IO51VVCYDsT/YF52W7/DPriBt8Dtl7nYP3N0LF+3egzOhc3KlEl0qdFh Gz+L5KoYYHBX9sivSB6x/XDBwU4QR35Q45hqZi58b9MCnIeB2LBV26xTr6sfB4e3Wr+5XX/M m63rd9q/s0ZbyIhq9sd7uMZgLEbTbDIBVERMYx+w3WZCiatyFiW7NVx+YEL8DjShHlD7bYBG ZbnSriAVIMmOf+fp+qrijcnLdMS/VxYsYHr43TgypqmKHJlZ8INTHn449fIw+E6h6Vhp77n2 bsNzLtM0nMej6arq+YJu4xxZKuE/u4k+NTx2HYEjlFklExaTqJ+dbX6RVyf0z/VM3nbEq+QJ S63WohDGP67CSTegom37LEFSqOPP8mkUGJZf02d7zWRiKfrBvRBvH+0XUeiYOE7CmGp56PX9 BS8asMiJRAsMwla+9TisDWZW4odtRQgdFYkHC2hS3PSpyrkRDj3GaKaIEc+mjL5xvbI1ICbg S0lG6ks55kJea1sx3RLF+LubtAvSX+Yp7Tk4NSWdVfNMcGfq6AEcHGalszwtzsWr3kPGu/hM JfNSgfvtVEnxN40ETcJtaa+rDdsAYUSWk5PCIxx6UvC01P5Z8OTJNJEaMA65Zvy9e7sO5/Rx AOZMpwlbQ/04zy04OPWRt57KbILJ9DP23PNeQETE2HpIpcyTYlZqVK7XWjtCV3EjKy5dfyPU YiW9aOkAO3iF4mfKG3kGMTxaLeN8FSr8JB6RYoCA23M+KrnQAtGEgz9PV60WlC0rei7KVjdm 0La1XkdPFpN0QJtFSpNIV1b5QpMPLg1uzGcM47ohK+TKTOIQj3tteesA0e7lNa5dWr7tz/dO 9mBZa+GNsxipEMq//uHq3o6LQBvGzeQjTrZQiUl70fbDePJqjz5gxRhmzR92Nnb/TqdkVT1m RwUkUzKINdlac5wnDI6QHYtA3mA2rZGJiwvQhwj1TBUfVV1E39VmkLwrlMauNtJXpQr+sjh+ rtkQPv9ZAUxoUl6lw1i4+9MhGQUZtUyW2SikB/tTcse9bD51ha0tuugP3hPCcNtMkzl8B3G+ AIrBVGDU71EQFkYKILoMN0/KYAUcajcwFhu/pePg0BD6D7e5G5wSoIjec/hImreT4QUmWTet olmOWj8csJPhcXMbGDIeTT1B76f5LDUnJxZwKdeDXkfN9ilR5zwdDQvx9DA2wOhIgpy/GJFp h8XmMFs0vxgW4zVTgioDNDKjFuSwWLYLK5I5wC4Y8dnwIgvyKnkLfrjffQa0dnEel1Lvauqc hA+3f94xhdZcPYSagirCo7I5NsEEG5e8WafQyAYTG1ZvF9JF2IWV+FrB1dKkyghmhJ0xuP21 P0z1q7aedi0ZCQCvplNjS0JsSzGNZ3dRuEYGS/Yz3eteFg56QyolX9w6wcZnUUjGnlrwVTwa I0rg/Uab/gy7aWTgpOrGBgPDpgU9sJnq+N9PizH95/AL+v+Z2DW3jhpOfZ2QaUGTrt76fLj4 H6bEoTkFm7T3w0NzOajfcLwjHizg6pg6VuT3xiOD60xAGXB+8PKoeFMgL6z2Nhd1d59WoAIB m2xcybNy+HS8kn6tRcPlRlVpK7JNw5NlEKYtXj2fetl10HIBRLlmhHmIEyJSdlpOCpKKTNF9 ykld/VgS2Ehgltjt8DVOF+whZR9K38k0g5sU3mavwC77ws81f7pCB6klmadFppTqY5TfzRLu 7Bh3C4amWGeQMTXMr7qDM6YZgNY6MhKUITBHdDke7XblNC41o9414cuLnpCWaySiKqtSOagO qxGWM0QYKxEX6raI7YaAmsmXit4VA/C4qJqS/N8QJGwQGGe/k6fs+tGlZxiW/iVZgFMoO06G mJphNYLjJMnoTkxkPwLbwyAMNQgxCxwx6efaNHTTH3NPqn1C+sXsRUoniZ2ppW+d8L2k1L9A Dfrabm9DN6typzbPwO4E9gp77lf4hjnEunJgWTjfUkUcaWW4ELmzqaRULqHVQCk+oy3DFpcY 6+sxV4pDcEcU6P5icEoaiRXEZKvEAyaf44b6F8/JXKFPX5d0NMZgpF5O4yEdUPUo94Gbl4bR Rc7gZ9yehAOYI1xEUSEICy2P9oCeZ3Nw/gygtnQ8y4AJSrlZO+3qlBX9i1NwUvMskNYAb8gq o/n5j6p4ka9HpBoMUEeGR585k+qk9DF1eRY9hYd6aJZ2BHQdaXu0EV+Miiyd6/y/53pcNY41 ZVmwz1DZdyPSyfMLOVbMxuhmEpay6FKflnVLWDkYqxwt5PTksfjcTI5Nodz5BQY4cqrg2GxB L4+FjRHp3oq3CIxr2RcVGi5oy55mCVfgUVPmkoSrQpLNlrHjmmem+yq57hSJ0mkDwyIplROM +Z3reYfOfdk8BsKnDJtEPcUJmBtVMwvUsf3gOKTqQ/kWnbBdoNVKgdh8m57c8PyBLfm9Tcnd WtPX6ahXbtvx2mY1GeW2VevvZ0JzrSiJLEXuExx3Vari09M0JyvZmSB8iRjTi3X+rErrlKy1 Ng3I5NNl4hYl+/dk87NGwf5nDmg7rtKL8YsNDzt+5PyEZu402v7+8X3HNL6Pj2Hnq887mrKk rZM456boP9Lcaez/S19cZCVa0191tGf2xB+xQs6k/HEa54NitizrnGe1Bswxe8xU4Me4OBvr 9AOkCynhJEtXl1ory2LzxSw/iaepO+UP4r/E081NmIP3ZUUS3W0AH2wal9FEv4ppQr3R0Cdk 2W543lYTINMpOfHeTx9t7r7Zrd/NSIV0H/9uFnyaxYeKD7mIRyiud6PHKsqdlpY2E6qQe6JJ QfQRAGLRFlVKAoJ+MUr8ujKGKKuGYbDGuKMhB7EF9EaQATaz5rc1l2X9fllFxjckEeez1CMp JK3ne8GGLuCnTzJlixWMl12zpc3+Nq9+hq7GZXqz0xBPzvTaUxhtf6ayu8mWdQ6hfNrVhNkf f0qyQSFEo5jcH71Q2o9XvAX6cJskPr/KxUmtKybq8zKd6s38LvKebe2XTcvyL4kg70P73VDL 9UQenUd7UO9eR48cZlzRAXBRhUrMN2HCHmF27dFJJ4SYA35yEm38FoCO0q1rSCMo3fjxD6qI 4BsTkG9t9fAg9Ol1vzygwbozVvQsQeDHWXd4MEwFbGHBG6+rfFbbd/88S68pOKVoJCb4zh9i /hqMjRYmK7H3uB7krjV65KME6Fgdgz9fPZyBLycdpIl7yH9gnd62b0r8vN7rftWR3//EwJ0c 4IB85VdQ/7i7WbPMCiNqG1PWwpvLPs8+APu4GE8bnjbH7svSh6HSy6eKKVTRGivMqQWsxpkz 8q/0p+J2AUJ1OZwWZ0grR10c6YyJO/HA1BMbJuiO941IOMmVNC4isg9OMydH+sFFuSZD4te2 +/+ZxVMS/W7L/17NydxPql/f+J+T2Gv5u2JTj6/vtzRq6e8+o++dNj9L8l/f5p+SZOQ2+uTN cFOjRg34ojiny76Cti+4SCkqqHfavMhm40TSkTDVbnmgr8jWBTCriMiogymtq6iiHNgbkjnD dcYNreez0A5CGlZSQmNStRXN8UWVIvnKk9r3dQ7hCK1Pivl6GL/Y3PCRyyrlt43syynC5lMY 5oMSHljH9yVR8yr5udLF41TZuUeL6pQpMCVva0clVk6Ml61E4AP+XVS1TSsJw0mpRcSbIFpH yeIandCZuNOqlCx2iNq7JkNult2zyK4svRcqfrrLvu2TpBKMbVvdRvZ4hxubTbNwW/jyahlp +l2wObc0o/kyJXbR0dau8RWKjtfSHqtgl2hNeJq722K/wCXa8spv2bY+uqZXQS8L7voE9f3s trA51EnKnkVbSJJ/NEyndEMDYawLbmIz0DfihCp+dpNenQQKFvOa3z0rgDMVBDRTokyyIja1 N9FaLQbCZZjWNvGW81nMsUn8rf6UW6BjSwMDhd3gVCvVOSeBzs7WvUgRG3JCJpRl/c2AEfhz VqfwZj4crDKb41GqslDIfbKPQRuaF2d0dY2y9YtriJAUVfxLTsBZrR7OW2x4ZimfFg4nnmGp H6dexduPrjHG5G1OQG3Hx5u72LL5vc1+iWZa9r23z8PNNLc8wqOj+Llk+mbFc5ok5WUUiBVv ctTmI41qDFeeZMyaJFmAsdQDeVytTjnteJkoLYQhuFkxgr90DC/9qI5gCwn1Gy705LFcXToQ JY73nLf+rn4IZyaY0WH+JowNdJXFByvTpi436RwnOUwXw5Q/nL4eW0X1EtfdjdB1VyqJoaMH tT7rLrqeQPq58q+6CYPSJUC+dZ8uNal3fsGk8ibzMgqaU6t3LzXhS1pPN6enLjvjtGW4YJtC vKCY3UudEh98s//eoMpfmwzraepeoObYZEZ8cdy2TlzqVIb1l7ZR6Vewar4LZL0aSgDtGRyJ jQgjreH8GkJhscvaJAxa1KfTAnCH8S9oUwEBGm2qzzlyc5l2b/+ttmBN9/jYRBQHpwVSdhYY B9AGtDhuiBBUJs3mdJ+QISezKQku0/QkzTXnMt/ragIkzai1e+pij+GBy3H7ZHzyua4Dba29 tlNiT8fCXO5V+0ZygZze+2Uzfazxa6bUY5wXvWhJZgBAb8thrHV9GSjHuK6ABmGSNok09X7q yc6dvErADEebfpQ44Tw5Ahgzt0byahQvcSM322NXJLPDX2LX37pxyfOrN0bj2Lpn9izxplp5 DKO5J5JMUzL5l+mku90fznQYGsxfZGtU5/Cwedud8QxKzXS0/PBcYfuJ7Ljmi10npQ4Wg1wr e1H0WJA1CNQmoQXYpgbz5IQdtTvseiCt64STHsjeSYthtJ3uJXtul6WyepArspX/4AV1Y5iv wRug8Jc614ejlGryY2dFVq4MpcGcARmP8KXIyOarLT0UPbDvJTbplrSYXmu2d6UDGeBsoNnt p0XWl7rMzZsHF0/dfYxN8Ynkz3EoTm8H+Qxp6kLz5LoMqkRys4ZIIWL8H6vtWvnoesFRDbFb JsYDxyjNaZGZius8syq5T3NhMFyPRVVj7JZ6COyqJD2uIkHRltGhbX2K0lwVYBSjekl5/Ufq Jhfci/WLGYCoIe9G6jLnLzYWaLKA8z3nXTtJk2CNrGOvQpfZ/Gr/3ZUhq6OhzWfBhARJjB3v K+x+TjWk5numWFOJDZ9WC90YEAIAdVNDwNaFDqxUc59JoOKJ2waMQtBKyKGHFn9K94mA2AJ0 uPhBWRwr+qNxEnMyqXqajMq4wvXE2fPFgMvIDQWj3+zSNM7LFJeq/3PqIK8RrTidhz5AMhG6 ZLssdFBgpGpfZrp9SXioadaTr8cqy+pGFGRuFM7GwQq6rdotMytnTDSl7mbu87eagKsnBrx6 NYJetLFPAE2/4rKLuROqWi4HJL1lYrHUwoSFXFRgpxKERdnyN5vXwGP9lU41dAuPpflgKuWf eOfgDThAmE9ppXR+0mfu6oNGm+en4hI+rsIP7e/dwKolKtPZeyX7IGahGn3cGaHImoAzI14w gA0IYAUk05hOOBBP3S7zugWnU43cNMgM6epVHC7k3gHxS/3m7h6ovOCYUV/00EbZIe8gAeSu G1b6hKsdc2N58Gx/RFt5mhz/049XPn56/7svPv/m0T9JG9fkf37ipn6q6EflaZENf7zi7Y3A YqsffnQtvtdroudSy6+MLcoyX/2717bN9d7RyGe9CMjbxlVO59254VkREFh0mIzeBys6XGvT ZFez2W0r+VHP33Hb8dFsUleH2Rl3LN12TxC8Hh4YBs1gEJcM5Wi0qoN3pYFYpl702CRG2WlT UrhszpxtTO+0DJe8ezkItg83lfDfyQxsnLr2Lfln5dfT12u/EIrSt996ZI38FNPm0yP9STEF lHjzlXs5q4+hy88MG5vQvd28dVDT9hb9MpKjvWs/sWMcaLLm5Nw7Zn05Hyy4X0wuKMlbvHrO ajHlK8p9tc7yE66KKjUUFd1yqnkda3lvc6BGqJO/V9wJTRE1ADMEaFRFp8UlDhm/uxsNZ1Om ZuBeopyMK+6UMJW5bR4PU9GAzhM1ZS81b/8F7KiNGwPP/0T6bJb8xEOizUBDLsmSnQaqwPIP ecax4u4N+eR0htQDOskg8RR2BppSjlL0WveHCFcj6Kw3XO94HKZ/m5GWTjKFe8z4XMVhgTsi IDcdofhnS9pRzfJEDpAoVqVBR5itFKwEosPOKpylaRpqYDV66IehAFfZOpidkTkqvEui0g9Z 9U51XhK0btbq96KHFwBnjqIyK8gkRFkXmLUa8Hs8y0/AW+V7VTVD43y6qtZOwF7sYVe77zku EIFNrkFwdCG6RR6frZHnemEd13vRV0BtjpRZ32PrRap057bQM78BoXAX6TkSgIK4xJPsdMWZ j/RD5on4jL8zqYxw+kI9qnDC3yjFSKx9fDwsUPPzjVPxRgbt9MEAggseN7wxi/4M40RvyCAb r7g0RkxzKthbqNIvxzDI5a174VlV2eJr/QZMgbxBZduUiTPnTm65mndO8UNnivlKoMtSEEz5 NGJmdkBJXYRrVll+QSvy7wkKgk4TicfbvgIRDkP99bXzpM//wS2KacuwXN5qcfUqfZGvou/+ +ClPPxZzVXEnzBLQ9HIZbjyA+miLEtlf0s+Xtp+L0KxoeLaddGHxnJnKP3AYO4szKZ5VM29C 6Lc0aa9Q+E7cA2xtjP7fqW+PQgmRVdezxMbzmzGpfNmz9TgSFo031mVOxlGaj0Qr5XxWBVJW AYQIKVXPFTOnmon5ggNGg0StrOyHFffTb4s210FPQZbPzLJw02qLhh/a75HW/LX9HCXkAZYe FmdDbNCcNynoZRDG73FuF+OYZ+pg8qYVyWDMc7WdUShhPgWHRxRYqsmrZDQtXqwjmVuJjM1M hQckWGMY44tcka38Ar2V76r451T8bvwiUVI5PQ3ocuYdYTydyZ1SzLCx/EgdpdlzXQic1E9B 0gkbC6+2BdqQ/JAMVMwdN2TpWgSv3/Fm2vnPJbGfE7IUu4wWK6hgzYeGP8f28JuZlOytqy4G pxw81a8dnPon5YGOU3ENj0rJxN9QV6OJn8DB1WhSUgxxp9jeyXqInBCoontSdX4gpx28/A37 uElpG80lHBrfOzMYEF5+23PjOGtX2R6ZMiGvs+R5Wr2hm33opNEzut8pxFL0F8Yh2DT9ocfL YUG+tBxhfeb5OpBrFvvyjX+72mug6dB7GC/fzPkG+iVKGHU5JjE1mZpUEbdtu7d5nUlUImdD H3XNHZ0B5Y6ytn1wBSHdYzzL01EcMNe5tJsD9UTGBCk8EeCQ6piP1RzNpi84W4CWb7oYkMiK NBJ2FC9tlo3butp5qNROS/AK188Yueeah0S5WqMu96P1yddCOwot0+V39OOytCLm2YJu9WdJ VYuFqDSWyhwZRf30ZhzUgTrhgM4I3ETET7gmT01RhkYq1TEUQy/zj8kRQ7Z5IPbS4Wyt1VM6 VVWrWhw2luBNuDIqBb82Sj7cN36qIjvJHcO92WZaghI+zWf5MK4UnomzB+tue1bteEuvdQaS vbjEj/YwUZMCxgKWtHbRQmUa2zRus6ivSfdOB+OXYDNkxUejwNeD5hZmPWlhNQi9509lz0OS +mm7Z+k41bGHol9dPMfPOj34tw99B7scvdlYW9yeQ6qfHBeKzF57rAKRwXZ30RO76ZTjNI6O syLmHck1C5rNiZegFk/0tQChPwMT9LAo4+cqJd69edxrWd+zIjxxf3IqG1kHqCknOWujjIvK T5MVtNUX6yaNcW0Wb9VmMfdDY2K4ixXe9PY55nRoN9vT0IMXMy8Y8agteYtsN8Z6GnYVCuYv HfsLwYQXWImcvz+pz7Uf3SJ1hsbwHGiuBZPIn7XfYnP1axIPr/sXpzDl5sscLOF8q4mVMmD2 W2uwgTJKr8cgyS4z+XfcLQx86BiORS7OBaP5gfW9fVlGn6ndKLafViACPhVbRk6dBGXSI5nf noPUhgI48DNm1iBqKuhJb+AcbQhzn+mrxuNkmIJJzBCmxgYw2N2qSscb6F555zb5eZAkQ4W8 0xq12gbN5i63L75mK8FRoKrFZMazzompLUqxTPuZYUFsvt07tq8ShPbZfAO5IXwdiHzOuPnX Oi/UyvD9ZnssCxV7iSI8RFk0KWFbXbBKwb9RsqOIajZGIGr6SzbpnW4JoYPnpWLA0nTutS3c 7Evrnv6Fx5y2+1Kr6sC3zX01+S1WWeTr20/Vwb4rTVF4XIYA1aJdq/1we04DV1k4TSvA+RrK K8Ce3KpXgknXFVfATmOxXva1nW+pD9gi4w/NeFUOVtGexaJzbEUNXNUrFPsNHznl26vBaTLc NXUtVTt1PLmTlKMLLaeR1GqV5NwQfst5oc1MpY3mcf8q1JIQxbL/PnMTbPo0m6dyd0nXPFwj LukyBaWo8CwC4JNW2mZbiyolThV5OqAT217abAKd3daV7db27HfgtY8duP9DAwkqnlVxZyMm 8+dPrBKYVUFWGy4SnP6hZFEKaoUufESmSj+d4Y2sibMbXBM04jzWQQrm7BlyHACo1lOYdM+Q sRoefPngc2ch+F+Xee5RFrvVWF7QWr9hKFPn4zaX8NQoNLaeMnB7PF+iLrFqJJPkTIspVWQ2 i2DDVBtc9IfhUey7MVO0Vt7LzmmxjKRQM/opl0L7um9TUdSp6htVmTYpQ/cZ6lfMKn/9Vuyi NNeNKcAnzYSSUJy+2KKSzbeT7jKRE0+3S6oLWHEwN106OoCylabAF3i5Mg8ENadapF0pODj4 RNkTiLuZrRzx+wmLX30cafcAjKz4IomHgqlILPpKvdt26YssnqcvRrEG+vOlDWqx1Rx4p1HC 3YN3WE1f58u96xgIu7iqeBK4ngXfkmmVAtUoFmrPNX4qto0L5n+saGXLHR3W4fjJhG912bJ7 NcrrOqyWszfhmW32fy/a/sT7Ccu3yXQuGEbl35/rn/d02WwoTWxUksW70zUJFjH8x6KoNq/A IzJRaAHUpIMD7+0m3SayB2Y8OmYcqobY6QntFxWCU+EJbZ9NmSrtsFNTNSzM1HZ189aBe8oD yWbqVPwNc82czrjGjUKLNPtAklD1QSAb6mOlY4aUfAOpAT2QQoGlZTlzHhKTDgtxEPKcsBJ/ ujpDOAPFUo1qsprjkNLXrOrxvxe1WIXtT6x+ZWD/7g1WwA9z0L1YN2ti0EQemV4vMFlt+RI0 FJLWM1kmZk/FlamVHx5F90q5Wutj182mqghoQtfSBWO73ZT+NdfKFInNJTuLB6NvFH9p7o8q 5CCvhS2Ja30rzqE1E76zHNf6Ek7LFPMMN9XICVQJhS60PTV8FXDlSUJDOXOyYk66j9LtTVkv 9VFN05NTFJU4Z1eHMI+5VTLMH8izFq25GDxQVCEUF9vcWcWBVH65IGXkLx9H22Yv87bl99DX Sw7lakeazFoBUqSQQP1nxDfjjDV5c6epD5sJ6U+fJUU/GZBRMTcadmebR64H949wanJoLxP9 uabA9xRGiJWmRPnh5s09xRmSOPf9uIT2nZzS5Vp4mTo/rNgLtpZXjNQrRrFHZDF/gcxlxKtS rsm8VA95pP/dw7tTnzLJHGJauZi0fCdR+EtpEjw5umxEG3d97S1WbYftrfLPbfap5jPaHqPA Ctdi1nVOgehzAd9f1TL3AF0QcIMOQk9JxA0vdB0JLuhtVaJIKit3z4m1D5SzYBBPUnC/LH0m bB6A8qRKf1UK1sirjGv+uL50LtoL4EIwohKuJQiPGd/C1HsgHXOybhllq5uLA67JeDAt8sUY dPvMSxvNJngW09eLkmpQg9FJdxXDSiijA8R3KarCqiRRn9l1O9k72cP+dogT4UAMFSo0f4ry ZUcTGap7HA4MrqfCVfISp9ZtjGpr7KympraZYDnUVZUMZmpQYcyQaCUqDyZCT8jIQYUEk8/d CsO2MakGwyoX6KNPoiSjxu7u7njS7Ycx3Fb1fRRpCq0VFwiBvQP6YeGc4Z0qehEnsxYi2bl2 YgI8WOxH31R4gfbymYA2JMhwWo0zdd4WkVCVVMVd09LCUODhTfJSbPoL9gQjxIf2JDsO3YRx TCts4hQMauCbJ9bnoZjXubxrB+RGPWoRoCf0dg8wT9EDshTTSRbcex6xoX5GAa8LXFaoKVHh RbnA9kbxwr96P69zJXuhmdgTGQo0UVSvaA7ObGbqfC0pydxCL5pBkIARR2VyiKb1Jnq1Giaj DTNU48IGbySsl/NCUYvDHz4tsoTR5MUgtaEyAZt35ekoxD9OUXPiSwWrUrbSJCloyskALRol qM0f1mUcsygSBB7zXkKiqEoecCCF6P/lmFJfAsk6UhcrS5xa55BycmsGAZZRPKe28V8hH/u0 mJ1opKdfdyU6T/pcRawtSUQBPu2EGcJgNVkcxBnDvMzScYqVsDzU5e+DHv+FrX/3VoPsCY1U 4HYwjWqKcZhgKulMF2aoDVzlj5W9oIGh9BAppsBlHaaK/Qf/OE1IEIeYWUvuYggWyX6NguPM yM5BAxo/DjA67PHZtJSkCzPZG067WgHcolz7qz5i3amOpf2SbuQpPBjQ5ydwTNZo/HHWhrMq 5SyH4B3g9YgVM7tFbFWRwNuNY9pU/Pjxyr2Sy00YmWWaMoRnjNMJdAP5qpgEXrChHOCA7/tE 5Mw10/AVBnQnm25LlV3UOAIAk0Q+LTETVWDg4YPNe1120VRhGo85xap+F/AbapErEqarRqUL VNOuSew4cmpYcD/ue9F2Mu3/Y5KpkmKQWzO/roZb6FGe/xb8+ingtjPbtrwfXgsuCs7gDoak LmPqlIv0CHaCfePxuFi+Ss7GTHUqP2e6CuHx5iaBuWowuapq68s4K56nlTNeENROsr9WidAj vISuzR5TW5JDADTGNBwyd5uU/A2Aapy7ycOkPGlsiLe6ue1Tv9Gtbafg8je2uq6BD/zlN3at MOX7G/v9jf3+xtY74/2N/RY3dk1+tly7NLDQjoIrWVK42+/k5hUcgIE172T77vcX8t/VhXxg a2PejyC66RI4ncKlQVsqr9LjhfFl11KQvqbOjV6qWnbqx+nIcGwFK0A2Xu4b8xzV9RCEyMu2 EUyPYEj1yGWti2p/klznPlWyZyvNqdsIPJaSKlZyAkt1KmV6qSHxFQXb5Lq3zDdOQrPCf+sc MsDDkHuiEpwZ0OpOIjV2rstA1Fs1ByVtkPGAiI2drIrlAQXSULp9/gz/rOIxSPgZgA4vD/Ar L/eiBxcZsuMYeqPq/JyN6ACi8ALIrJBJguKuZ/9Bs5BfnD3b4Ko92HfZP+4zkmhaDGcD2p8L b9F2Ec9LzlkZOJnGk9MSH3GmahCZqIuoVYaAWaW6Iju2ZA9UL1JSSMVXVbRV0/0FnJ1ShuPT eErX6EmiSqcqpLGUujDdo96VSaJgFxVoVZrtAYfBFz5e569PLZvObvy9SJZOMY65K8cRSse1 xowdCOvGL+hIzYzDTQ+QhvIDamY5+qRy2DGX3bQSZ92Qix6PXktTp/GZJq4D9o10lsGGJT6o e9a463pVKk5HH+o14Rsb4MKJcqVWwa2dJ+dQwEunmThHfEY0ln/Mqt/3p/94Uv0ey1CYo4Sa TrzC+SikrkymieBAuBmOBCfVQFyvwwKwhskMMHBqq7YDqCXpdCDUxno3396JCtDpO9nuZVqK +1yLl3lCODNTRwuovd0ABjEeynxtM/W4ol6uoDDmPAtfPHnwDbQ/FSDc4fGr0mVhnSqLDVkH hMs0scSXvPED8sNuQiH/nApeV3YierDH6/k1QG+q5BTvJLvhWM1zs3vCW0+FuNV+i1SKkhAx xkCTwGvMbQGrILgbUD4JQMhUJRkWfRJPZTR/Q3cRvU2qeNfPACdXsS96eCFXtbx5kGzY6Yfm zntEOyn9mQ84abfQdsVgpPk1LHassTpQCH6kjj1AfH9YSCOjaibYCLqi6dJP2P2Nf3QR3Hn9 O6hfi95RpOWbqKLxhddt1vd0XkXg2BRl1ahmxKRgGOMMlRi8G9ZkaKR5UGPEj/vFz9SF8TgG zQ2djk9wNIRWZYKk+NmYlcQe3YxXYYQrzia6YKdVEmgzK7ggktMLhI6YQAdnR6IkLIvpzAyY IYUkEj8l5d5CwS/vLtZ6qWeadp6Z2bxYSt1LWV1ZXBVh3ovulynftSjfJvev1NgbXzBv/3xZ xacMlzF3Q49TM8f2jparWR5b9hdSuSZPZv01oqLjdVmFcLPeljEQhI+q6t53ySRb7D4p7n50 jf6llB06L6y1O7BFBlvw0E4FYjWLmo9veLOlTafBfiJIKTJA2Jjkyd1V9sAg0LbqWkDGa9gN SZfkZ9mhoefFMGEgDmkgE0XD0wK/l/3cgA5wbSVAp+QcI+eX4/NrPSuL0JuXXv6fY8I4UHPu OV/DgRGqxuNA4wG0iTflJsLzuaJA0SafVzdgNH1Z6bIQAVBquMVHTLDmiLtXKWQWwosblPmj ZpWg1jJAG1pyvYR/Mv4wEnuZItPy5ZOwFifDjwM2N82mDElWjTrGeeCkveYn2UIuO3q6GI8N OVbEUdkrSDnu8KvVFPVP+Fa0PKtCZqguRxc3oQgG7ax+HAkTGzXCvXW+kj6fiX9k+JrUx1zd z8NioiKne9G2NhLyC9iRuKini4mQj7MUO0u4DFaWRmabkUAms2HxHJMZS+meN4YpEdZu9nx2 lnRDXg6uN+4phXdSrkFS++BA0NAcLl3VxirZLrbo9jErfawYya2HL4Rwq3kdGTun8GyYSL0f OLsvL+qvptbog8B5Vd0pFViSZLUaGeQ5ashSh9JjpnWR64+BWm0pWYZ/08BMDebJCDNJEmpm bQZAUZZyzZw+zbvGn9YlhfakkaodmEEHpoYawoxT2yzGMdZg2qhevx47i6epyXOxz3mUpJq2 Lj0OmRRIOI3J7NxuH5d0Wi56mTTSjD4KpHq1xbcgaxY/VcVPqtkfr9yrf8Q7Jb63o7KE2hzJ SnhxZpoUW5E15qkVIxoj1zOTvOXxYCoulTkAFaUwJJlwpkBPjELoGEkVQwGYQMsqU7iUopSk 5y/U77lmdrMxsa70CrCNpHiNVK/GxVA5QZpvCx3fEZROVORGcKNgBD9SRZAToelQdfkQdSnw SUm6lvi0qiZ3r107Pz/fm+UpCfw9+v/XJuey1LtVsXsaT8fHs2wP9hqt979KPyHaiquhTDDx gX5q6IvAhIcGmLAI94giQKENjTzOGUcI6qU7vTYZhhseSnMUpA3HQnAZ7xXTk2s4FYvSDodO NkYzxnAkSqsn/lKD+Z4fd8ZCY4BAY4f+JM3hJm53sz/GPvQ8bxI3oQ1Cso35EpVtxSuZZgmL B45pXQlx8bERnmWJAgkOk3mhjBk7t9gFn/8cjyeZwmf9q6RClFfZTAwkjP8rfTsYpflV7R0U LwDYCc+Np1s1pswnkE4JSnbO1Z4DqdsqMCaLo9wSdgMYZ5hpndkqgTcMJqMm8yQDMq8RTXtS mCKQimBqMVE2YKfi0gNbEmxGHMam/IQEYK9o0uKyC0gMjdTjoiMckUFKtzY19dK1eP88PYp0 IeZZBm0CW1/6KhqcsqEyUnozCc2AqeK40x0wOTvY+Oa3upXcE0yv0KGIc3vCAQ3gsBgIiEYA Qr2exMMLIYNJn2tdX1WbzVOMgbFwsSaiUQwaY+aiUj2q6cW6V4qVSi+O0eJt7QNF+XuWPqsY bvfczpSx5VR2rDZnaMs8JVE6nZ2+HOvuc1tnGiYY61D4UgHIlRB6i1tSFUBlfhthJ4YI8S5J /j8kIz7XMzbOUW5eqo318OgLmUSuopq/xDSmKg6TW5MV/VIjbdsJSBzizDieH1KPmQ3EUb5f mrj+mqNOyxjbbJXP7CQqtTywL2J+5Cw1+4xjTppkZDlZwY7XZflQyZgphlRngJOkX8lcBKzL UYH8tJEADhRd+ko4oBWVEcDpKDuQIE4sefdw9HMhY1KSThXphqVaH/rgZdTKENYjQ8ZGrZ9m L4f5hcSapHPxr71B6fpEz9Qdw42GL00TyRBPPNDl06I/ZWIBJRLGK+tNjFUuFLOza244wH7M id5Tc07nZD2O5y+dkTIJEA6ht8N/4fVav1s7r1OfxenhhXhV3RgouGro/lwye5apQYxdy+Mu UR5aHArCMielSMqUE3NercH5JjI3QU5ePfD5MAZxfRYP/bqU8VjmxFSYtHO1jD59+ljOX392 QjNAV46AOPiJol9ms1NFSyIcKVzEev5mXpytXqUoYy3EMqNZJSFV0ibA81+9HMcofjlMXMk9 X1Tz1SsmZolHHN50sMpy1hAn1cn9M54Cc15bTtRe9FiHvRRf0VwDVqbi9dJk6kNfIDvmoKHa gnCcedenI6GN9NFL/Agp9Hc1jsgQ+ZkaoB2+NyWesR/wa0MuzxfLBsfcraOGl6jdiviNnYK3 btQ9Ayq1WSsKUC6U1dfaqWCMRj3z1qbcSZGUuKnELXXF2HPu5zidAUPdRKMdH0LQ7OxGFL03 BN8bgu8NwfeG4N+VIagq+HEwueOW0GIbkyI4zj+H8NlMNcOgNN1wu4nZ5hfFEyHRHJQQGijZ sQEtkC09DnsZsUxxmgepoNpDVlweRPPa2yy8WihRVQBXZpXlNvas0w4DVNQZwwc750hBBy6/ OXN03B3NBuaso9zErmLjGMojP3o0q19v762399bbe+vtvfX23nr7G1lvh/uGoeX7cX+aZJmA KYxK7kX6DQxhmDwTBr2Xlw22H+775BXQqBXw3C1oQmc4OelFP16REmE/XrHkhzmdshilJ0Jw NVVOGETWpWdm/qBqZs4mxXgNtCMUl8wRkM6rGACjSrZqbqcQw5A7rIN9b1iVBFCpmQXQiGJH 6tz/1CmOBUsnLgfxUAoQBQymIoQrdsLMvQjCR+efR8D9BVVDk7suOQSBWT83nLiCb5BgfbMx vRT0ELOAOlXDFN2o/sWu0VpYCQ8qYCZe+uOVmdp6P0lDP5Uzsr5+xuJPLAKtmxM2HnCpKYZx +brRQy0LmH5Xlet1uO8r3zVu/5MZu+nefyZg8ysotMTk7cWQxadQbrviEWdwnFp6ZZGVNKML ocZP85fe5fok5iPktpJyNGKMkPWSGuBXvEhK+k9UgazsyVt5LT19AyIi1Ayw9OAOQQvaZIXi isdtnELv4VcsV0w4znn/LD5cGW8Pix5ZLNAy84VmZL8CHJoQsC5VeT9p3zxowU+AjMyiGW2k hFGLc4GO/HjFDPENmRu8DzbIsAOvQirvHTYhAe9tHkHgfrWow6/4lLVaLthXU8ERFIbamjYt oLNpMSvd3StqcABjJo/52/LxrAXeORKKA2eya/sMhFy+/BWxnG7IwTg8bDA9NTrvuJ9IOKSD 2Gbn6Ck8jQPHLyCqAJRU1IyqRp238xIjua4Agf2LhVeeiHhQ5pGueHslXChMU+2qFEWTzwmT mbp1KglbbL5xiUoGQINVsqWEkZHKX+YyT0JN4uFBVMaTbB1sQCvUgn4yR5w6Qk2Bh7nIEs8b vfRf5eq6qryegdYWE1rDDEHNVJVRdPqCQmF5ESXHx4jSngc2BLtxQm4j+uHDgg9miLXLsGux zHF2Ln3nnO/Vj1d6us6oLmajNJlxWhOiQnXTlKCFV6h0/oxMmnyhMLO9KxpLTi3M03IN24DN RVM2AjW0T1n84ypNfN3WiD1PgLkCPyAEV5GWgEbSLRncq+UcNfYqqS6WOqvX8oijgs7L8cUr hUcHNF2D2lcRP5MMVO1UnS6MbU62PxvCwasBQEAyh/iSE6te6j0kx8mo2iBXbWnUhwUQzYO4 xjQlH6PywoaGLJNkwmmMeXVK2lrzNH/cVNyEEXJ8Ua4HLksw3Blg4NqgnnkQzydwGgtfGldr 1LWsw5qokSZFsK4AeIh4IKzsIUNDCTsvqVFz047jhal4IKIpUDuP3eMQu/N0OIuzQLdC560v +VlmfeMR3+s9vzwKKRbOORxy0ZlQJo0q34P5BjjcmXFbRUCzrvMCcFIpzmCzLUeTGkqVEtDA yXF+lZ5mq2dJTpfWD5pjV5WiEeq4Mg0IbzYR9QxJianFJId7c+5ehMwaHW/Y3R6q9BsPQM5o Vi/9IU/Odw0pFIqUZoMiRKSnfH2XKnTv8pA7azMp7Oys96KHick/wQJIYY5itEBlyymyclc0 XkP4B/cvEk4L1BxYqC0gGaokOxRZHTx9LJsWboEQsn0n62dcY7TkrIFCSv1UkUpSEAo23gBF 9EJq93qyvYckwJK5ykjUjpEDOMDU+fk2m5blej2kp4rt0YGN80XPWCuGSlSK3RU4qcfhazC8 enqxFHPBlHloxXerf3EFtQv5RwGLI5uSPaqzEvsq3cOWWHQovEjmff/dN6UqXRLaNo7i1NMZ apJipvUbXZkTYT3uJWRjmocN4rIiLVh70eXOlzwHVDHUjuhIkQnYfY/2WB8Ltck5MaQqcYJZ UqX/NiM1wimWjbEl8Rh+bzDA4aoQfjdVpRaNB0TesTR8Kc961chROp9CmxrW9PTgHB8XmUJ1 T2dZUt4NvGuW3fsoS+99DrILm7lJ7zym1zmlYvLC8H0gJYi2FMv0kM2s/27tWyLFMkD4z++n d99npoZcDbifnKScUCp1QKuknMRSzhnqrvSqq7Gon8X5SBrUaYalm2cYmIRrNAudeUqaq9kh C36xKqtmtZmQnILfU4sqVmL0D4q5okVVX8+U8NKEu4toJBatYOSkFHA8ep4IDm5W6Xyo/oJU i+U4/av4GudIvVf935AQd3jzwNNTanJC3QPUupElunRH6dGDMzFoXgiQTwT5mzFpgOsKBAHc /xAlr9eTw7Decnys6lWL9jLJQEVq+Qo5vCnkKphCFPwOCC7UOGXZwsoP6hZhaKMckErsOinP hO2upYfFJkAiFiHWCfF0i4hD8i1tMto31NVxejKV+jtiFrLXiGEDYjRe2ZAAg5HEJ2KYqemq Bb9mSveZsTaAsAQTFl7U0JNQhOESXp3hlsRW0TdwNL8YXmSRpAzOGbVoLmDu1FPOt1PoRabA RzyInRniZpWxJdN5MoUdQNcC6mcaKh95nTUj4OZZZGmkeAyVFx0bdgMt4eFN19fBJNfa4lXr niXxXKc96KT3YyGz5SwUFvaBqtK+XPUu11lu+TD1nflWGs7rsa6QViaqDhliaUvPlPs6MZzj F9qFrVwiYrKI9w3d3Iu2v3dPU2zd5EJhAGnDzXmKEaw1UwVtAPAs12LaxLhrCbJZKpwUxbC/ 8KSC1vI1bkgoc5xpGzblA7YOOsO7jK6R2Yv1ZYWDh3pSnMch+hVmitAFf5TbABcuCbEQpkYT 7cQlJF+G/xVqf+2oESDBgO5RcROTTlnWshwRlEKeo7h6hK9EFWZUNnXN+zgpnsfDmPm7T/Nk qGvlwl3KrgBbTHTTpNyuqfPuTGxD5gVoqXZMHW0ZamhatEXIVcNljiz1EdMYxZnSilzmolJ5 oQLBftWxZKj0PZDw6CL1LIBjroRmCJHYS5knCs3VBi2JBQNVz+XSqXKcgWWW0pq3Ae+OUyOq EBwc+A1omGrz2HlQW6Xm2cQe9u1Nsfm4djjXItSlMCO32ilEJB0tEl8ZmRejWHvdLReOjvyh 2oZ26LPg18ZuoNqmrcOEE6cd1DOz8WZ7X6V5POpowN2EG6Tz7cDJ9JlfcSb1ItBsGglRBqt0 uzKkbBbP8Evz2UskUiYkBN2KKyRrsYd/Gam84UTd2fe9NqB84ghKKaXmRNalZvNCPTD7VZ8M Xz58qboYVy6+IrGVbm3gk+5Hp+ATqFReJco9Drk+OJ2vMq7+7M4BiZpNg3IVq/uqk1bCaWnA o5MRT9OTEy4vlEzZamozMpmlrWwQlkxJZkL9doUzo7KQ+jKJ2YomRR5mQSB5G1MpFWncLnrk 0uhvTU+DhFDozoCvnstlulXApGn/EH9vD4LrFI0lm9cuE9KD6VbOFUBBFYdntjBZUXE2kBJE J5whP5b8wxSA1uEj9abB6WKQiFlQpTxJfF+PUz1X08Ve9DCWwP9Ly5XFADjS3nh6SETEKDEv kKINm8LEpu8PhymmkPZEMwIuMBHjZwJsh8Nr3ezz+26EeNsweaXzFBVJsPA70adABdpLAHuD GVSwjfiaDZnjAHkkorv3k3pwRYto//y1vP5rARD6RV8RziwrUlK5VjDXnpdYHp9SEKzwIqth xz1VrvllVIwXGQcitfvcXgTdh/No32Wl97ta8X3D6unAnyyOy3GgTyDAVSg8TJshgy2SsGem lKKHoQnTBDpa6gbOpCOTmRBoR9i9uG+kNyP0rRRnQaK7r2nXuyL6H7i5cBg1G1pSuzyUdwpX 8BUAQvnJIM+i5MNJ0dy6rg5rnk9RhMLsKyyUpoSyJdlfrYa6PPBLmFV0V56tlcmvVh8ne1o4 lo8OSpwpTI6iBaDDlCyFSH7I69kHAl15C0jMDKfPE2GmilFfVRHYce1Pn52v+xQfeVCMB6rI LN0RJxVKRUSjNCvAeULa4Nef7GAuY6PD94shiRTAr0IFHrk+WiECfq+m7zYqa9kyM/Po609M AclEVekxvxPoFh0bg1WCvgvoUrS/aaDGRfpFoZhrnPgsWKtwXx1rnlu/y1JdwpiqCipKUrN/ 8XxdB0Og+3QNOFXD2SzL0mcpWJC4y9RerGj4VbBNc5DBHpPYgBMK6EVeJBtVLSxNv0TJNi50 nd33xyunNBE/YSIkhC27H/MAVJ0JnyZKhwk7YOlVu9NESMMcakvlesEb5KArDCz8QKLhUWOh chOa/YcfvVqiRipjdw2RsPZp1+OyoOZqadPxskhyLVshY+YlgizPVWidyYx4i+PlxgcbjN2P FfWxw4dcT5Xtx6rsgto3OMuzKRdUgAiwmBPBfPQ0/Fivq1pJA8pkOQJ+wBWbZIwTcZCqe5FS cD3AMO80bu3/MvuXnpzs6S8Lkh70PwtBiOo0VexrQG1MgIzpM9E6NhxZBskLLhqBDT5eqZab TQgP89nGyipHh7ebNoAlFhHIVI2y2Dj3g4ol/oL42uP430pGnU6PB/j/h0c372hU7Xd//DTC vxV7RLjV7XSP5hqAQo5//R+MJtzRpJUfS4HyPyea7IIOQXpyGrKS5SIz7DZ1IXm2dpQ0S1VG J3HmihsVY3RzwnBBDGlr/uaz0jollUEUNCZGTch9p8gwxDmKIAOHHG7QMOhsoNY6OnKVH91R lJ9kxrWYYTl0oqVDeo2MvyD88hzYXEiqWt09fe9p36HxHnHAS5cCboksPOHcjxMQNaJl6jEt +i4XD2VKb/Z9MSEzHd58GE8lpjRgrHoc8jjgjyXlVEYlETkjX+0osnOpZExvlIrvLVEj3hyT e6Y2EFNik3rmvkSMPdND0z30dZGE1Cr8sWouzneGNsZRFk9P3GLL1hnoTEXb8uS79r1u53ri RgRsgEsq58UCt5JKvAm3dmom78/UOzV3x+mUa+AyNjYZzhjR5cIVFJ9d6FLE3/npQiX76B3H BARyE54KCcOpyiIcK8UzNU79cJuDDBFCztsreQJRli0pkVekmTk1VsJ7dTtNOf4qlf6JtXaZ trbFmoqO40HVk6HH/RRlv5SHTr2rrVV37FgPpszk0Ep0QitMO3LHl3f+2WUlKB7qXBFQXDrG rq4uunAKXXJHtKYM1koUv7ScjkqjNLELDRCCwZilpJzQp9yEsDa/iUY83T1FG50oiWqKp0VL DbzQPfTB7ZIZxAGRErzD7LQu00q7avN4/qxaA/COapPp3Ie1f1Kczp4DcA1wVjo4zVPVn1R8 SUNIx7O1jKpEVd06bIVbKquL53wvsItfgi9nKVTHs+GrNZ3D+aKcX1TgWVc5IOYCKUfTN3O6 gtjBqKDy9Nw8HV5kqElVJZPpPGnEiqTWFMpe6dwK625EF7L4RRoCUH1DKt4MERJ2LGiRrj/9 x7xfTn7frL7N8xDLt1kx4kJsIVSV27qtFfwwrmZc1059Sxd7rpRBrnAnRd12dNVvZ7vast/q iYF+gm61XdoF41nOAC+o6qtpIYX3zsj8A+Xvhv4ZZ+hnqtC06Z8AIZpk319Rw+qAvBk7yCbH ZNASGyka2Wy+cQ1u+MaCTRHX1a/z+uSZznnpj03x8OVxKENON3PNFI74SX8E3pKxVPgVDb/I Q35E9WvOhIVVICmXyVBAtOqe1XE6VedBMe1c6YSWiUWEWSyVY1GHq3jxY4BAdSFQFTq8nzG5 aAtGWj/G4Q7dpUGRg7BbKq27E60HpsydQARjYogX+wUQD0l/tx+Xqn4sG2/q35boDcBdyW4P ODr5RrVptG61+JpTROVPzt8MTovlmje4lqxgDYaRY84CYAxWZw1sDOMFmf+CDcKvBtiB61os 00EAB8dbA3EQZL2JYUJyKenrMAgyDq0A1fILv4fPMFXDW2rrfBZQr781KA5A8/Ek6evSNxhT Y7aPGHoRj/D61XIlVppJ6TwNrIiTP8CH25EvSOJbQ5mdm2UYywtDqA33hN+8WZey7qHpL96V pPFD81ITRiqniNeuJmdaO9mcNq9IRmA7dGwy4wUxm4z2mDqRG2QPZ1k7RPnhI6McPLxSxpE/ FkJutePiaIY9mHJBCgcUoHGkSoPJ09DQk2U8KcbJXyuJEv0Go1e7K4B9xRj00CWOjQoa6qAF Vv+BNZUYm6HX334uN/oDRrCgqK6dQo6SqhvfTMmmV1gS5PorvvFocB/zorxt4wb99CAuS3n4 sRPRts1/MS3G8TB/Kb+xYJmNbzhsvuG7BNGdrK1xC5HoGMfDIrcVoa3/hT7elarPbWqX1n7k +/7Fc0boc7FQjpVueJVFlz/SKEjQhZMexeFQJ44+JNV8zim+fAlV0xj8Iq4iJoGzOGIeb4HP lZxcYD0nnk1g4tqb+ugW/fo0dmrbIqZ5WiC5hU4yWUwJPId8ZTo976m0mGAACmj1qM+UF0NV X9uLUjNcu0ydu2g5R0VgybGc2XBAqnIvpY0Q/sUbk61e/IUQuxr3BndfezWmycmMrHPv3nf2 mWZDEBsMlWOHhRMBUfVkAVnPE7WPHOEVEAd+Hz0ccwNQ7tQZEZeMM+e7arcEHG0GsuxQXnPb NAYoKjqWQ0acsMcLqsbfOYpRftMAzMb5Y1FUv3CSH5HloecYM6yt3PZ+hSAWXr9u7Ncntp4l SspjVYz/BlMrKHrpunFjYoOYXbOx8+5prJWrNwXJSTHjenu5kV9afiwC1OP403ZNcVyJiaCD BPAczUgi7TJqVOU0QmcOERfhr36VUh+kC9ec7jGrVTx0q9l0+plVuS/L6+NwE1nAPL2AXRLB dBv8MVtRTXN/sKrNHxKShMFT6iPyOtEyMdkGwHXRNkMQtKzZaZvS4jRLbKxABQpeKlPAoUQY slNFpAVCpLQA09dL2usF/R+689e9KE8H45ekRv7aSZ+8Sl5UwLeSTIU9Pi+Gs3ZX9vA15/S6 fBa42yYkMaU093QxOM1gGdgLL5RC6m3gmy7C6aFyzPbMGgBWIua1lgt659oYSJur0cTLJARj 75Zyz+5wS9GV4AYNAtjw108Y8YZg/BRuT5WeEY85oRKBdLmC6YfVeUJrpkdwpaXMYKCHl/U+ M9hZwM/wbfaTPDmmfnEsKJbBwMVml7rl9YypIsGg003TUqWbGu5aGhNQeYwQ0D7+4xBYEH9S 01PyYRXOr7FomvlpJipNmEUMf8cJzBuQGUiuW3IyjYe62qc515h49sCWKfT5kv2vwRK8+NOp LwMyo0igkQAbKKoUg/bgaxRv2gU0nibkHAXWpEBLiwe/8J5WbHkCRefoAsgPBuKVL0+lsgC8 0tQU4PItMRHH4868VLbLYxJJwG7IsJkqJsqKWF2kobRn/JWYSyHqp84kk6qLfUrtN87odneR zsOemnhJj4u9SiZPdMr3ZsuA/oi4gSqaOSiGyT0mG+H/0mz6Co2i/Ct6u2HqW/YIs/KlTh4N 70An4RG+LVX4gAPRLedA5ytB9OAsIIhJc5UVxUh4MCKnDAstaim0B51tKtWB1OB0kko9Bc03 4gbINizB4wTeL1WaTqTUz5M4L91iq6VOFIck4OlS9nXLpaeZKDtuCZLIPykuyyv3WhPW8Ce/ Yhu3VcptfNUx64P2VZF8oFSADVOkHCMOzo7skSqtZpU/SdqdiDbbS/Di71ifLh2lgbdQuiQE e0pWahElWSzqRNzt6q3KB/uofw870xZk6N+LdjlnUPOdqKOAX7VIHf03KIDq49OPgrpTluAt Z5D74LzfGJE/VYXTCbSwy2VApmBlsXu9uyem6Ko+dU5WE9zAl+yULR9rOoTPr5YmffmSDSHo 3mwEQlRIXS7XirLxZ9PMbWuamVwWaRY+bf5l9xxxobuWzYE8ufBXnoL6Q8zxa4DEUCNxVGRw xq4Fzjy32utItDB4OhxAazRIsjfjNOpnxWghSBnpzxN2vuXJGStxydmzNeiAimGsWQgAnBvj HkAAsuifJWPX2zpOlqlNjSGB9fjBk0dKrUnGezp69/ACqUxxUBFeegn6FhHMeYaritTdOJqP spUilcsvzqwi2hM/njgL2TnIEwLereUZqnBVBplmqs5a57Fgw80LJdlIx0VLDT5UcUv9qzn1 ac1sCPDtkWZOsmaI9yDat2JfJP2G04KSEUnuEdi6nFnR+U38JLWlgtvKppizu3hucr8wXaT0 mcFg6hU//oXOWcoTGkeslz3ei8ysJ/M3KOE7o017Cjfrq4Q9YGcc5ixGK7qmnqegskBi5Irm uX+B6LuG4uqpgFe7UvFbjbySICakbF5RbxXL2SR5QaLlIgKJEBtPy1V18VzhqWccOS3F7MiT 5eR1WSCALoHZmHYn/fsi+uzbx9F/VMVoL5JR3AcPAfaaw0Mkz66jIb1rfgHGmq+QYj5iTjqp YuCwVNb1DlpXS2hnFxbg1JVAygSC/MYGIcYzL80ek15nOKQDyrUKODROrVaziQqg56roKiee wcqH3ZjD4Nd+7mypCDoqtgv1VTZoCf203NhqxKvBKV/MChmrwuuXaMjcxxN4W4RvU47wV4za RtJdVC2qQo/gZSD5mWVa54WnSi54TChSmxOeHVo5EjeraLIuyehtMXTr0jpwozXeUhrM7Fo1 zhuB4/xnKROrZBy9Zy/04LIXRe3e+oLrS1smlre+sz4FT6igEN+2lcad9f1339CwuYqpAOm9 nAOp2zvb+BqVyV035x/povB+zMJ87HhI4TgJNIBcsMFCsu5shVP+MGr42B8XM/hbAq50px0b enADDuKV52x9297/sxoyS1mxOfjgvsDL4Uym8rDKu7GN/xGweJJZOvagEamBmIPbuHFHP57o qMuGppHUMuts9PotJ4zhEIrk6aD7udtt39wyk/ypEGu5+JNqPv1Ld7t3Wts1c/td8m8zFArW yV/2BU8Xz+Ph7CwyeVud77qx3/quo9oYWNmX9zmTNMF4lm7UiJUcmzVmqt4n4+6eHLb2xDjC /sSZOFUyKVX5SJ6Eoa72a7bzxx/1pw6zwqeCOMDEwPUmKVN2O9vjHYiGuD088hxyOWA7AAUk U8PYpDrHdeweFi0OM/v3nQOeY6DrDjq+6Sm9Htv/xw71QKAXLoEbd8JODnSES7Ra31HUtGoi kM67qTGT7ldfmTJ6mxE6O466w0iVQfOrTa1t+p40KEwlm69wIEoCsM679bq/weSMmt5ZHAaV D86Inzgiw4Da3tSQ+1aTMaWgr9qeXAhwgCmQu5Cl9g9JldOhMDwYI3TPLMmmx9k1rEqZlyC1 GZymyRzcjNsoshojMkv/2lEMCZuaY7fsAOhmhjB728TwRQonS9GGRbV/AoeF3xJpmp5lSDcZ mVG7gqJx5EAxv3iFj/i8fibVWOlHCkhO5txYkhp31Bli4U2mjDp6vlDRjYmRtB7LyUTapIkC ciNP5RGu6DEjhRQcrjWBBHtzVpF2rX/BVHrCs+BwIbs9+j9RpVh+Tf/atU0wSFO+CLbSY6hI uPOzPTobPFhj8QmfOdjMVb6pgqh6qr45BmMkmT4T6j7OUVVzYk1NasRmgu9F3zdY0MDukI5W sBF1ve8RK2cv1tAjVerjqjLF4+Vztk/AlHOB2VBVfC+Y6pr7YBhsaj03q7CnBecToKPqldkU ahX29EvMSXGqF7A5Gf1kqfNzqQ8Fs3U9rxlHhkk6fhUzX3ieMHH9Ss/YSvFZB8Ke7lXpQjA3 3hPminjn90P8/n74L3Y/+LJ/UzsbrwZf9r/NYENXQ5fstwpqSGgreRfJrzQKU4Qfhj1X2jT8 L0Zav0hGyRkkif7I6LgxnrFv/D8dEe++l7M5rVyuJd/2FIefboV7k4wboljJYmqLxbEVPw3p K2e/NJJ0zMITtGD/U+c2iK+Ok/4qzluWZ6zg3NUiVclXEqxqYwTlY6q6ZumFRKxCGkblnGmo tTAsVSUAfpJZDS1Jd57AozpfS1ssE1/am1USGrtlosdDobI/BSQRg6au5JijlMNiy98nlwkG b2ziFqJOBYcQmZ1voVKCEHKS6KQqGGTjoIGQnebLnsz61EbEOdCVqhXFrYSwqNZX9eE275+d 8pqkhQC/cJ//iwTst3Jo2N3lgEMazWnOOpVakpj83IlyN2iSBv90AY1X0YWsWSvWDkBHI5uR VVWlu0zBIZwSPWBFstQ3vjhSMIwG6VIDmmNDZBltP/QqoVxq8OKeY5ZOrfJo1lLlfZRo+EiN +fU4xE/l7qTbNd8JWOAc094hguls58Ajqrg/hGsvLd3M8nMJMLOkjMuRxMZtjFllSgeQVTEN JE9ccl/ODxdntEN9PzeAdCcnlI6/MPg5FGvdJvHBvqtwfFkGyLGulva29wx2Q+7QEh0yvBqR tqdNcqyTdLbjp9y7QrYpndnVp5TsscPOE7h/tj9zjIDIVBrhjhijoHNmXPwZAwZMumIseD7w x3FaY6ri/wsJxQKrEKwK4c+YnqBelKQsW5i8gylV+5Ah+KewEoRg7irPU4APfSgPKrjLqAwI xqiYAOGW+5dvqQjfQ4zGkjAD2ZeQFZKhKOK4kKIU4zLJ5jor2yev3+aRU1snSaBNRScym3B9 yWOZJnrF1YoJnoBF4WZ+t9PBa/pHaJkWGgSd4eSUMxQZQqMXBAA5EPLqrRvMm5Gd3E+OgTmI 6xNkVDFWlpgUJBlKfTVdvi6QMXQsdPPSO0M/S5fHFLlqlV9uTyUiS7pQQk0WiyTUquchE+Ya vQOL47oUVyoFKxIm39HkHy49HB6rChPFrSfcXokKF6EOtlJXdFSFZgGlPYZ5OqjmdOrOz8+Z d2QaM+eyBGwvmMmkAKs8tzMo3PRDKT2tjWO/M0xMGjnU7hI/1V0XAT9cMP1gVK7GTuyvGXFV L9xTBGn6jeLMJG3ISBKQRYNGW+4pvPmNMxW20TLRzM4yEtDB0KFwq0ClPYQ0OcilUyZJ5Upz Mv14SMK0T/fr+ILGF+eDEPLVFTyH5nL5hLZnFshWoMZGq6XgaS/reT/wSlow6x9ILwx5h1Bn MZ1enOe6ZI2jKKXtd5aT+9foKmt4Pct3kiegu/ZMbY56OnHGDeO44d29uv+pW7vEGQZZF9P0 5FRhCB321wBMv2gmM6q6l2RpHM+mUrnDEpPp0ynygfoSOMQOOwrj+5hh+PcIgUttSGEcVqbj f7fMx0HsJ611epKzlmcAiKTA4g0pwwmrwakvGe4LY4im9tVKA5dEq6ZzbHTeTOxVtw4sP/Db 7MhXKh2J84CZ7lVzU+qCOON1lc/Aq07mAmLz4q8xBzCwjWaoNlVYtkHNbkQrqMP0EG+iQOqB zJANkQbvHZqe1RT+wjekQAEkMSH7JlG10t6AtikZuczMS0TX//uG3RdKKzI2RD1lqSsRx2vU HM37+cILYX09LFjyXfb5b4wnh8mP3bAVioL4LIhd9cg6mm9kLigbdLC+fItHNiJUsMIxT5Nz 327D6fvYmwmAKlgq033CxgQ8Byqproup0XvzjbpWx/XBjNrrEk1OS6UFVELiiv2rMMAh1YJn 3RSiiGfIQa5UXCl0XZ95tSgMf0+Pb066MYUZiu8vtdnNINkVaZ0g3BntAUapiWTsmGV8i2+k B/MmqZZ6ca7HDWlWCiY1WVydMh+iLSkHrf4kT5ecaR2iTxKXBDfik+39oEiwNMGRHSjjFyA5 GAJEVmxO8oaJzybFEpIw42RbOsQJykH7foUNe8Era9HBBKsGb3svAp1VssAtAkpvgLcADvRY jhl4mAsdsDITSdOfMNJ/m52faagcOOftwBuKyy0flTu9+goI8V/2dksg9FVS0IFr7Wnecga/ sJtQ8eqp3zYb4ytV2HdpXabHNLLZhKswq6qVQx5hOcBVrHjWkGnQD+QUwbswbmSbP9R0WWMP GxUDLLZWea6NPWNKedDLi3k5gpoE/x+DQVbQxdTJwr0oSOuRkIegh+NVNTMItsSFTBlPPlwb gr2Rch1SXLe/pvadMiFvxul8wbyB8/hFKt0U7BPTdCKFpHt/3jioyypLwwfBJGhyB3LdY+6j KZeYaJalcBQXG4KvYKsinTAZgJrGTRaIrSHFJDWzAJe9cOZoF76LJTdOMM9jZwo7hzxiytcm +8TpLclkPh1aCOVDzvdS/9Tsli3mIxkKD/wf8rgN+67zHrFOA5QQH/XvOT87zuITRh/hrMym rGTmjt+w5jJscT763bE81/2FYYFQU9g6rofNSdBYebMLg3UNAjA55SW8VjLm55pkUvzElD4/ 0WSrOz9Q4eye/DQZsq/uF7zqtMiGgRfd4xWi1kLOTrsav/St0+SMtuSlBig/lQFCTiNJcLjT CykBm9+LjL54Ghpw88Xqt21Tq7xGNikEJORTpmyNTqbFbAJSkry5+pqDWiVVOUcJPFyKFkqX ngeVmFrgZg/0zDAvu+ltzy9n6rBeC9JLkzh0ucTbpo8JJdOBnbifhFMFJ+TKPUU32WjXGSJD 5GpVo70uTO59KWkkUsWl+DmBey0rznvMWAsrTqcyBKy5QGigzbrzjDkz8vrzHl/fZFGdkqgB Y9+wGFwbzKYoHHItS/vX6ETQyHanieLva+6mR/xwwGzk2VDFcqGeTLFU/XgwKrO4PIXxLpGg smmQ0l7TxeESQ2WnXxSfA3/JUknYE/E7ywgKV0noSoGCQNcYPZclthtt3kGv6BHWmcZHQxNT WHGAKy68IdaOL6wWbdwP6KvCHAY93VNZBEKixRceCFij8iVduEy6/NpB6rOBbQ1YTRCtVHvJ tHWjLTPluyJt1pL6cnvW+70XPRUtqExGpnI3Y9INNZWiJxNucTKnY9HmiogJG7i9NNKJ0jaV tWVmo0cmvaIYOgoW87E59dAMNfFC09+OV9afpy2bZpye7lUaP9vdPEqAanCz7kUPhBVFu+0N wTa/2aW94VQCmwYSvilUKXVFwtaWHIjK4ma8y4DjSo3IKy3PvA1cYMCZjt/ywr0H0qBJxUP4 ra9Ys2w1Lmkn4PIO7tdiqHxFcsHOUZAmX+yo9fob37HLmPZR0ja1fHzgEy9jlHKKJVWHt9Gp cK9cNJ1jDx0iEgleyh5SkXTF8S3VRcGmO0S19diJ6PHP4gmQ/HNQRf2G96Tl9GEyqqZuMC2c nKpiaHf96HX3rfkZnaz188TYVjC6pqtx8oL5QbgcojjfJAlKed8S2nAKSdacSM/np3JH3sFF +Z3vOVT32UwSTuIXHMKW7kNyJePov2v3pFPGin6JbK5G64BdkIzPCtrznIUzTM64CteZ2Jhc QWU4G5y+jLa5GjrblobHEbCVCyBPEtriE8jLHRUQCYozYSQ3l5ZIzwXfSQMRinwvRHP6HQnI 5/h/9C7SC2vu0w0QjYPb1323aBQG9Tc9WRuaNcj+T4xZ1DNct8m5S6VibaC+Y0+5HDu64pLd 4HmB0+DcbIgUxZlMjQN83+BIuu36y7gkotuvU9bIEXhuGJEIh0vgpSQNpekU0eZ4nRQ78V6g bD7lDzDuuCthwJh1FsD6Bb5MjPi+hgYa/bwGBJAoB9TEcKO10XnmcS+8Uoo3rS1OmyhSXjGu HS+tX+uBWXB9/8WVYDUpU73T2kxXS9sbnUdtjfFOC9wQCWgSCR6blx3cUwYQCnylceZOESxb mqXAVJJMIbW6UtVcHR508UoqjgnPUYkouqqhxXpEILpSPyPmPAXby7nIuBTi0+cu0KiaqEbr zqopKBVr4LrQIhN0o7OBneRwHJji7s609dMK3RJLYwPFn4IWzabZTnnNaj1OTHNs2OYCm2Uw TRIBXvn2wtd8gRn11tUGVypxdc3H3dNtGc1EHyrXYgB8MQVWxWq6To2n0cJRNC0RFIQU04O1 qUrRcog7Q2ED9S2gouGVGw1/UnBu8V8B9hJFsAjWvF7Os9Wz/xGZng1Usmc/ezmuy1JDeqyg NwxLbDapZwmyeOxSHpLyhYrwMRgF6XFb3Ih62C+q14Ey2nOXJ40Tx6TaxjHpXM8QpuyMcAZP +Nco4lQadOaa+2m62TPrxGMotcmyFuroZot894JP23iz9yJ+xWyZo+SmDdssOQmrmDDPnixz cPLKCbKVe5pIcsyeb/Z1D7o5IFuORyk5tWYhAk1AE9JDXk5nz4J8n27u4/6N9rRIc3d+QVaK G7CUgmYbGnbha/fFxwyHOLza58pjbqS5I6XK1trHNRTD/REzVzFPAPb5xWmeSGEvbbHmjiyQ Sm11V8KmyXHJUJ28YsyHZLnu6roqmWKMcgiLDKSpOZTgLd7mJ8deVy/+jm0379WeP1n5/fyu UHPBsI4u/xiJ41Rj5VXUYiL1XhAsZQXjiXa8tZWO81tRmk+ILGyDgaSsInuz/CRNBgyC6J5B FrNmtChmHaaQM4+fiR3qTWSZjgHmVyaqN4XM2Q9XYbPNvNAjdstQ+JMXOqf1+tTO7vqBrK7n umu6euDalZ/WNRUDMc9560EnweaZ+JZN/FS/jgkmNMecBTClZEe9SrPi+Tqi62CtieqF4RO7 IqgsSXZ7Yt1M82bduTCf3G+5RXRxXYN8cVx7e5fbLj/Ep8Vf9BQpO/BZoqcJjoohwPY4ilwo Nk/UhZQO2he/S/B4iDAmcASGUqEXUyDnAwe66Xu4tnHetO8hMG8iSiC2ZXL5bgmpCX279+sS XQqITLjwQBGksL4SKLw84a2W5IZo828+VlWwObhHwv4ndfGcaW+0s/qtzKTeCruZ8ToEEjbN pUShdfcESjW6LR+5CHiNJnTiLC6wsCgTaxoo4z1o9HmXjA477YUhhdG29qqxV+NFxnXvzZ27 oxiznzs6tOACXEet41vdMJNeyaFHxs7hEBq9WK4rqH9mCpzKA53BWDPQLqSh8P0DaHh/qLf9 3x/Y0AsXCOxVBSQclGq0nSdYrdfuaik6fu5EywIxklAcYQudGjBzbyE4Xh3nIrdlPY+eq9Hm YEmxzqIJF2zx9G3YJXd+4alQWyVgDjvM2AHMgj//b3M+em0HpNGHuaq2o6u+wGnZHTXYMEvX D3/5WXLmI7D/82FNiIRgHl1qsdcclFGR8/J6TfwtCZ+GMsKwJ7Ijj3+JXYwUjKCjbCxEnbQI mXIPcS8NqbJzxGsn+gpTn4Zslsue8tChDoDE3vEpt8WrO/bU38HxvvFLL73W4x2yq+rlI97R qXYXxMC3N03I3+5WNHPBDL6KdBakS9qnanziukGFzGHMQJfz2xxpPh/eUUZGhO5WZFTT1io8 yluqIDNsiJN+iMMFkTPKUUmIsyblleXvnZJvqvcBi7ldQfpNQ5/RPX/zeWijDmulVTpt1Dea zW0STe9cEplYtKdtzBdnq+ErjwzpHckjbtUpyMrRQKecLKfjMoZD3J2hSOSczJy00nwd0k+V sAQjaHC6WsrTvWg2vMg4Hgm7+jfebU7Shi9qTuMlu9H8ZCbld++SPh7B+t9AHJsT8XcgjwWl sGlCbv/NxLGdCwjDGPmRPZ87WrVTnU4h9lDsURs0zda0haMyLOEglFCbEcV7TfULMvYKarmz FhZYvJosnxqnYw/lN0EwH1L8oIq1iXbeBpvPwRVGqZ7jKGAaf9LevRaPh2iRg2KSqsrT9Myu mWBzsW1yG/0vLYj1jv97ksMGKKjgGJKY4udUgWsjYxePI9bYV7MCF6oEabg1i217HuQsr+2x y28w9m6B+XHFtT2wzfR0ms5cQrre3m8PrUC9mXjyxRUpUjAxHYTPvkYWR+Ipg/YklZtrYvZT 3BdcZrxaVVFpBCitB3BJTNkEDuFCLkWHvdBJL7avl/uSo3XqJuTHbNl0gWMxRAAM1FKsbxsZ IKfFnG5Sbgo/Qo3ZJZNSM5CKA6ACt9zZNKWuuqygA+y2bEKxhSQBgmLoydmrIY1RhCRnrkqB qfgESRaVFXco8GMQ3b9Esbx8QsCmjIBfmRKgqPN/UbuXByW2o/6DtQB+a1XJVcW9ZK0voeDI MmO9j6lbsj8UfgNzMwjTcQCOQ2e35jLi2LMpC/QqPRu7hNGhgwYR3nbI9N8EPuocnO3ugSt1 CcRFN1r2t96OyofIsvg335Pad/Fr23+bvcnmuXkdILPxgIU7QLN/893pXm1qg055c8r9aG98 LWEZ70oKrghPW0RbNkMAYACsZ3omFbgtIJX2I+fLYj03CNo7rmWgaof5GDrnvuo53AeX1YJ7 UHXVlezn4FnNcgP00AJrvTLnAdtoxbj6VwldFaBocpCJxTzthiYe7bs5hJcizwLjPWjfDOdT YxpUAKmW1mPmEUF5ktQTVU2qVkyK2go2ymVJ3Mp4EW1NpJPKNUjvaXpo/QBfrDIjkujpaqxL JRj0EQqNvVT0VREgRV6+espp3gozJMooo48KVH8Ar8iLpOJsUNrDtTp2PWtKnyG+9BbQjyML X7mP2X6sGba88By+ihzyrQ304K7a9gD4SsG7cDoWzy+Y2LniNB1UWj+xlraB9xsMdugddMk2 dz5IAPu8joK7c2ot0U5K45KbpT2gMJbwwyFrasdP9H7A1DPWWgDBGFOpqivCAdPN5bPk4+hr SaicnXGdz1Rw5tTYjDNwXsr7N9jGRweu7vUA5vA2TcEx3ZakldMM7fAUl1x/w89/w8BaEkOj 8WKaxkN3Jktdhsjoue40W0NtN5jsjf6o0oRo40lxVxZEgYiromKTtF+czEztp3DZsqJ/PCs9 WxrsitWUFMPKlA/nUodKeJXVDHXB8jDuRr9L8Sbhgat/uBrBUJQqiTRGstEHOu0qy4QSiSe1 w4iVjgnfkimzI7nx2uaXnRbN8tMUlxXXOA/IZmOPgPhuoQlsxHFspr1HzWS63k+gQ0VboRpg NJ5w1StqnAFNakKwMDx9MdOMjROTGPqWDfE2Sw191FAXmlNlAtpZu/CnT13ZOJeqgP2mqlwf XStqWKGnF9WzFFBCWsHXEWgcNRmgMp9M0RkHngB46fylKkwCxwv9dMJMvHMmWMSO3oukaXpS t8k5DZyzz2xTBbMELcoMvxmsXb5hbuvbMTSKtZa8y2Gi0Y/WqB5poUGdAAyWJMeLFX0pZAEi OlZCgUxzrQz9P8D7PpyJ6oEKFb6iK4DW0hiNKDckwsflKJQLZe8J4zyS5drJ9pvzwBcyp4pm asW8WclQKhP9xwuyhEdySxYv1vOYwU9M38OOAkmvM8pAlVhhykhXPZNnPL8yZz2Vvo9UQS4D 8hKsVNYbixG85hEMufinM4gNxRxc5eK+vQWibcnCLHeUSvBvM3rJ8QL5okYswjk0pSsnCDww AlPakx3cxPXcl8nfXsaTEmVxjTuHFkbyVnb0JpmNQDAiHIk+l+KmQV73BkmNiWvM8oAwndvU uxLPg1kS/6oIo37Sk/CTM9SrOPyq1JqmTVABJkkJuBLMadDmfdNRR8LO9QZq9cy6CQJSXvkN pBiwrfCnZZS62myo+gmX+axAWnnSVs9QFbXUABdJp7oKOb3Hj26T0kHWNdMvU9OxKp8ppCmh IP/gtJhapVt8nKqsnCQcB2L5wcsHtIKIFp4zFBOFLGklUK+pUr5rbRgf7B30FD1EJFs7sGuL ROKAiuMC3IL/+oerxjpHmm6F3RNy1FxpSYYWuV2QOYIkXzPMxsqIa4B3ojgHjlFpmA9+SDlQ Q9Ed4q5fptuQI5v2Dus+pLJOQ9285MI80FvKc2TZaWCfIe3zAVCAv2esIu0hlCwMBZKzhEu/ umNh5UJlpfSToN9MxhBqrz4on3BNSYgUlGJy23j2HcwEl7ZIXUgug712MxsnMdyTEv+L/pXp 0WZntm6XEvJXHbpexYllpKHw37BAhLnCznLc7DqplYzyV6vhiC6KQswghkmOxdU9LugCogMK w0ofWWqNTq26YmGgSpuayd8iXzkLEVxWilx6rRMgR95hY/3A1tij43ZXTUPNQe/qIZx+IFtV EMBy/+ouxVxfGne+nmP3pqfnkPUCy/dU4qfC21hkSV4IjTb9fCDp+3RA+kBBz019M5KP7Pk1 rP/SSrHhLrlhkE+fJsIxCJvAXhuK/53FudplpSoFrtTbPdep8HPKxRKVeapm/7XOwVco12Q0 pa8dIgPdaa2WbOqze/+RkDFdUaov0A/cbUkoJNHc8wfQE5LaAP5ag7OEOk0nMpAs+57Ur33+ KqcFkqmqRZw0zYBTTbFKzrj8B0rBrQeJMyF58py1VBq1aH5FT6YHy2zARx3Yox9Unu6+qEkW JM9BW6kNYfHyiFkVoqNumlwTsUW2hzLV+epRlYMlB9BcsbFjX8tFtNdMmQmB+I2bQh0f6JRa S5cqkC+5emJ1sdzotbjhohy/17zXWldhvonTtJ9qzwNKRE85CQQOGpWCGdoNdsCal4yudpAE yyQgDUWrObtOPDJo/o5DN4idO3mZq8DwnUL6UtDpR2+NZQhZggtEStFG0TekV+ECOUlz1lp4 5a7+w1VWB6EOneRQVQKXJasbSDzsMo6hnyTCOnz3Ixrvvaq4G+39H38Qnvk9aoHsNnzO6cOY XnipYXx3mMcqCIwERS4YiRxkJoVTC6D0AAznqn7TFTD6jq+GlLHFuVQGt44hE65oH5ilbKG7 meeVdNOKTEUUwYQnYMo4T5vurPY6ZyCHsVgqFWiQTgez8Vxo9lgvsDIVt30vSvZO9oAB5Qx6 QR4Esg2mpBYmLOXSUCHz4Kg8vn+eYNqa/XRI8uYnTs6eljLd6qiIYL8CSANT9Qd2Md1ApA+X 472mq1MUApTXETgQ/T8lc+yhlyxEc+iYCU8yVFEjUtRDyIPXPZEFyYhF3WrOwq5MGjQAwLPQ cGo8DnvR/4/UB77Gl/GLdS5Gq7pp/0H0Hj4KAuRmvYcUAFqk1auEk34i5sljqkspFCH1BXDN 65KWqqLlntC0jLJ4eBe5M53HAh1SdVQVaHmt4AkNueiIQ6xcpcjqjbikplg6JoOrzouuRntM MLeEvZQjafPFqqIbgNWp+sB7dLaeC4MpteZVCGa3x3Q2IhVWtBHQR4ifWcWWuZLTYzrjM7X2 1DQ1P0+laBLvBnT8B6GGXqtcxDl0zZcyFieZhDNfYskUpVsTsCMynOjGnm2Q/bduObL/C6Tc O5BKYFlsNhvK1sQDOUIidbQTqr7RtXm5/R3zzZfRH6dwd0j9SUZ1f4cSOLtPCvGGln7RgMej 6eIsmrye08WN6i+cI2NJWKC55fHpNP4L82ewVuB6OWgHbj9dVqJUwvHCNCWxJk72+2J6Eio1 8aSYpAMpFmoCUPKZ7e+TRKI7L1u9+bYVm3TC6LYKX0SjZFErPqpKRIyyNeicopLUX0E7VK/W w4tc5SJH1Ut6c+frTKc/S0v2QzjvEJLoyz3+eV57+pEo1p1Pm1CIitcxBxuPWCIikO7KPaLo 5vi/3SjbSpHA88uiSs30G5npQKDMefttL0xWezPMzJNimpK+HCWg96CjUoyxs4VOVW35YGqP VX0CKYgqLPtLmGuuMOPdZSD8KqDEoVpE++Q2WEh8RjsOOgEmUl768ayPELWpMU2LIF98rXak +cbXJNo8V6J2af0s9qbcxxbC8VecKFQmhErorkxR9Ei3AklI+i9d4Sz6aJRMy4ICF6wpsHOD bDbAQoU4A6GQoLHPYL0mAYtX0UGZaPGU9ht74bgXAbWCuyTBNP7PckdIGs1Q2YFktptSYbpb oz2QlsKraKQsD1Th0k3laDdMfSnljPX64ySGY0ViRbTOI6VCaoejan7B2kQeqpmq+ebUDzdE g/rFUENVzayYckz9xEVmCrHwMGwBhDctLhNv19Y2LSmIIdpkJ6op2UP+Ya7DK3jBymvyPz9h RPDAlj9l6Tit5OSGv8MhDei2Op+Z1UYuSU+ir6YTvvSkHd3xkP5rVtPY7bSG3wnU/JJPXAqj Vooo928rmbRYEs9TczTih2JxZCI4pHMierN+nmiQpk6o1t4eRz+79FqLL6BFSCl/kqBTAnws NkDCF2dPFCdV3RFgdnSQyTlY2owWfbp/kcgLedNsTlhjSOFjjcxQ2c8XdHdzgRa43EhEqXZe 4xeTV8mZA+U0oZ6OE6QovyqtJapSD3CF6XcLVGE9Vlq60H2AB+zNOBJtORkHIEzFsH8xlefl QNPEzLiAJpTzPEF7XVIlphkvR4sq0qbGr1pH86Wp/QIGTvH7pez1C/jSLzJHK+zRCi9XpD9n XCQ9txT8ayhP44uc9PJfcczpGERfF2S7aCxx7f1wXrG6oooZYMUmjiUk6hy2BBS6j1sQu1aF ueEQqZyD2WghopS7pLOKrFIlLu8py1C3zMJv1+Ouzt48COpbulPsni/louZoSa7H4V8MgTuR h1wUIwYmFVNfada0sHTpfoIf8gXC9PX0M9ZTwoE7RbVc7wxjavoJnS28EfEDYVUTJK9cKKhK QFPa2lXg8jnwNwBCKpFqMp+Ycn3yTnGA0XSTnVn04BSFAUnPh+KBuZMTp29IIeAVuAdur7BI hJ4WhLcGj6W6MOvv2vH7z7CFkMPGjAnH+wQBk8Q4klk9A4bE2cH6NbDQ5E3NNmkGUd3AnX7M fXCWm0933qfsLsZOR91nA3EYLRRNY8uMBtTe4GTuRCjpR8ct0QJZUY8O2WltAAfK1W8zHbym WUwO+frM6Zai+43j3WTpJgNNGKGuV0senM+yWU/HBKAOX2TiwpXKBQE5On/dTwY6ymAbWq4m xZRkJtcXVf51KQbqJzY5bUcDXCf8xlY+Cys0bh16RrWxhOtx7qqo2RZss+mgtQ9/btrMvtUI f5ibS1LwT8Fqpl1fj/lRnEemlxBhiFiRQ5HWPSw3wMJmii+z4PceVEKcF0rIsYH9FhvLCWwO kikHeWGqlMpf41iwBr430BTdYYq9ls1udOu6qHBIopTUCNY0tHaHIuom4+PcF/xt1gFEVxZg KLdh7bfudcDrq3r/4xXE7WTWTaABywQTxcAdajuNDgHYfrPi+Sg2uwzqI+8zRlGJa/aimZUk tDUcoVTAermkysQmrEgMdwEIlhDN0EGAZCq1qIrHaescOPyBwbnYi54sOB2HaQjnCyhyjNsE +RL0KLxjLZFYxw3K+kPryf6+TPKkEkoIQx9L3/9jVv1+9x9Pqt8/TM7Lf8z75eT3dD8kcN/b Kf1kilMGeG7UeKbrVbaYFb7frYpdPMG7AP+BD/BFpN6IeirzdJC4UX7n1ZPiGWwqZgANQlCd F9+oqTxf4iLKE4uu0dtaasAKIpo7J6Vcgwd8OhMFxqMC0S3bqvO4N9ZV/CLRsD2Sx6Ty0wZb PeO+q3d0j+BWbQR+59jZoFEqJqVkWkw40AYqUCkJETikcTalg7WQHyAeXpaiGTx8+OSRegOn 3oh8cD7lIPSVcLK/LoaUeNPaKPGHOSw5EF+yOOSfhQJME47Rc2xbglbokA6GYxL9E+/OjlQI KmYwTNZ6cmZ70QNB5Y3XlS5pzIYIQHxvSMRT75j9THrjNhhHY+dROmCFetBSQoK2jZokNd58 zMaj2F2PpR2mBpXXJ8NkTEe7mhevknzGA2LgZTmaTVL6gFMxaDmLMx6MU3i4c9dcN05sbBlG uaqNLr+RWiVYbn3ksPL58Bop0vC2OZP61fglXcCy+twplkkWheqAaMo53NVxZ8dc7sjHllPa 5Yf0N0rf498L6V/nJY+mO/WD67CTouTXmxBMJ+d30BcPP//T44AFZXvvcZG09d50qNZ1Paww nLAG2e8cAO9Jp+upP6qPo22bG8zhwdDQWflkJ5XNcTHpQkptDMVbnNm4XoseGPkjt7EKeDM8 fTZRob3cnyM/kkAbS7eBJ8tFPjidFiRNpEgFGihF6ncvU6PeICfcJGTL6Oarwuml6mGjcwGH jAiyJM4VBJXLsKhKyAKKhFVFe9c4r9XiX5E6ea3rb93IOUgBhdxaE47OcmYho/4n8TRLXXLy UNahvwsNi5PgIjTMFaqTX0lGSdhN7eGKLJPsWO4GKQc9ZUMcuQjiobT9Czl2sbZ4mQ4TfLKQ JcC80azLJewJAZc4ISACCpSkTBy+hcY8hYBMHLOCOFebopinkl3u7bvMOYOy+SJVUgKXu1hq Ey706RSgUOHtZZ6OMohJBN9zrpEY8WGDElcnrI2+Sp9zdWpzAylHrkUWlKm2GefP1uwflUrO cZ7qXGzAo+whL0BUeWrOOmLWF8OLOnPwF08efPNHFDcHzMaX0h9uY/7T/Lj4CXUQd0pze8Mp /+F2cZ4nU/WV69AyKV7NBkpE12dnyfZ6p9FAZ6+svPlwGxXOca3tlC4vPdwZKKs4PY4HTkHX ++4v8rWppM23q9vWpg4YuQKwPaPKNRNsuuQ4gRMj39vmYqFwo1sG7J1NbzAh0W/n0IFJCsBe pIP14fZpgVLWPGSvFryrgkKgxbzuVlHA+sdKhZl57WzojGWJxoHdPog4gdUyz/OxO6UF3OGD bPvBP/9wO5+NfyJLcEDTmwx3hqQ+TBeVR1f+4fYkm+2UoqnpIiaFbq6zc7cPvM413+Z3tvzP 7a1TAvf3jMwg0auD6Yre2Hbo96rUeBadlRV768rVeOMLbnW+IFzFwX1nf5EV7O3Ulak9jg0v J2djX+6092Uo/sfkZ+agmWsGsbKrK1zQpyqkNDznXWcLRyqLdE24tFbKKO9NHbRFaJsd5Hqp ufCIkWQoi7yzb9D0k2W+GmOrDAGHeb3x7UY5h/flrpOFq6O1uJzVTSqUSNI1FlXUoR33Onv0 7Q/ffhft8gQgZoWYnl8KiWduvKoSXcLeJClR57nLs7t+2xv6b24HNtp1p22XPjNFzthWX2xs 8Hb7l4d3zFpt2sN+ueW32K/XXWztR5N7JAxoYXZaEhbpB39mpUeZzmZ5akuoy/vCq9fUJGmX oRqEboQDGtU0PTnRtRrVuRDwA28Rxr00GnKSUXIdMxlI7gWodnYFvuMgBoBuPEmCxhQua76j FVhSo1U+hT9vUNH36EJV7BjFUZwHgdTQf5shywo5lACUJ1AP6byTiiwJ2i4/+iUm3N1RRhti 6UgqkZaWJCWb88zueZoJsKzRb7iKhSdPsEPFCz1flUq6xBvqYtkqfjRTFwr9xAmQWTpiKiMA Q4ejeHm3fY4b3yDlOh5V7Pa2M22r+/GLK87H6Bce2xwnjNRz6pr73AsAopBOIuunSW+ishjL v/Kquf86dt6fsT216s8wIKkYUA7o5hC7jSTah9v8b2yvmaYlaMZqxsiwmI3x/YfbnHu9wzwX nFBEEzDDbh6cJoORscCmTvWftl6ySC2mKNNkfVqVwKi5ordUVEnGCmljznHYzyUFGvwJcAcd pnhDZm5S0dkJtJfYDqBDqq+8KHXKYbdookVzwIbndOjoafwsdfhf6HLifb0O3JTNjU4PU69p G3KWC5vho/8XM+Q8BvebLOtZYpeVobaN9uBiX7O/4blGCb7Ui3zXXeJHU7KMkMqN9BmdSMwn vNGmLkAe9yLDqsjSwGja4pmaJiNO1sID8NRxwhHQE03eeZ4/D+8RfRWPxmmW6CmcFMP41Vqf ffenyD0JgP+lQs9rFZXjeZWp5F0QSl1qHtlbLoPCNkdrdlnwYo/oXa+wjrHJS/XsA125HnO9 mOD4CWYMlS1MGNlxU6nEIMtzoOxxU8GpF6GKzXBKi7ZDW9HbmtuMhaE+qtI9KdcPFVy7Z+4y SeN6TCav8DcybJszvbyUbjKLTbdV1hdXiPXuei7MoNDDpMrUu9c9wx4/GC52b04EawpjLxGX M8PC8DwHAQOSYTJNkAkhJAhKfJ6QpjJLq2JWAkDnrBrNrH+0v+0Pp8/hk0gy2rvwQQyQWa5C Hs9X0PEiFv7zqU47ULal8l3gpI2L00zKB1cr4bqjb56uSrsqoJii9Riky7ojOTBDrs/W+I6i QVaUSuvR0VBxjLkSeRLkxdJTbJPRbBqauwTCLQns8XErjt1y/1wtuSJdqfjGeekCORyOewSJ HMt4/irJV6wuAXrG//1cnVendpVfz4sBEaqkl09G6G7db4WKy8lvwx6u4KSApQ4RECW7yjWY jDevxJ2OL++YZeKQqB24+Ig2tX3n4D/5HETRt3mgOqr7Ip+hj/eZ6lJzS0G5aKvS1FZqsWvv Odus0d6GbffJIouZH0kzdgTPMe80XOixOqxyRM/S/I060pLwKCe44oRHbFLaYPOLYTFeA2bi tKgLrnCzkkBazCaJ5NnW5acOd6utCg8S5LOqBRGTckmbef6mJDtnNNO7mNqxGzkNiqyNW/rO 7YBwIQFOW3gHIVTlxWlKGa3ANRbDXILK8aOZwufUBzaFQHVimchqEgLZyazU6B5oAeHdXSBu GqdjXp2XPU9uqDxwasup3Z3oSCOjieAstjX3Nk3RYZNOzJuiU052+5UzZGfHpSdqWtubZou9 ZisVKYz3IsXb7E0F9r4zE4HduHlKrnfvGs4V+zVTwv/25gVOKxgERV4HgdcuFdsNGispbOp6 UfsCp8qr2Aj9uMjyi4gJaIZpOSmW6WZj7nDfBQZE26CDOk8A3R7MFFeUZUsRBXChLJ0wnRGZ VylbKBK/5zH3hTVnTDOy4w862qZjPn6J0tySs8X6G8lIkpkjyTika0dk2RkHG+E3Y9VbV5Um +cXpCzq9/z8QF5Da3fxSpJ9v8pcfHhz6Ju12LZECS5hHs3F/mmRZrHYEu2aEQrCJwYdBzGdA WKw8VRoRMy02oug+p98WGqWan5RN90MgXjj1r7T6BdYV7P5XsrWOf94pr3KSE8j9jHqubdGd uqW4rdHpAd0HSawMUx+B62gmyzVm/FCs9PKgSv41oNos+06Lut5k7jZzdbhalCYA0DehUduj q3psvSinLUTWt/MlXZ6ppGfSlbJxU1j37kf9ex+l98Qr9tG19B5XenNc//y1Qrrbrze07qnD RTTLjfdBtBw3otSLkEuPNKWyZGDhNBkzo5q/VUDKJG65hvJsuMg+3JZx7GCHJGrZoYe2adqi s6mN4TuikMQ74Gbu+Qhc5g0ZX+QzJ2VZaxn/8aKa0bk3gH2VkeA1PE2ep+PXYiSzTSILvSa9 rMxUTkEx1LvBe3TpC1E7hzvO0E3xds2yRVa5BqNQW74TIO0adPci2yIr3zvLC2qAIaleakns zH1LQ4qfyfDwi9kZQFnU+0ayaeBVt3wRtre3F8nGLOyeLUm5GijxQUOYLnirBQW5FjzWP2Au tG2OkveLeeKKc++dGIJ563xBz8J4nzshA63iOAXlN15WHnsFkh/hwsgShqYx7hRaez+L81FP 8AhKGCInhMu01bPNrENcb3A38RX+0gq6yaRAXk/BLKKTLCfDuqeV10lBkorsr0KacenuNo3m prti2x8Jt+CH26xo7PCdwxeIpzu0mq/403cKJt4R4NSybRUOrcioB6xSTguzBC6ZkW6mexC3 Dn7DQfg64lsMQyEnprVwY1wfzqbR2HDwp6T5jSJ27LocjOJv1l0yfnoA/Vnj4C298S1GKrhn 667TsD0TdzfKmNsmJvw0hUH32DTJPW7kmpc1XXpj+8a0UvvLtvg/FVhkXYuSIYbEKovImDQv 6fwzAQ5QBbEm6WKjWGjfekI0oHQX+mgySYZ7GzpmpMF9dTm5WA34de++u87cObSdcRyfjS7V NujdTbN/x5godTFsW37bFbUuHlxmn7tqgNmA9IUmTuI4wMY2zS4RaK1WVJDLyNsyeJXcbVEh Yr7oSdHUBi9zMzcujPrjnV082jfH7pHqnXfkvsAbNx63I2swNY7bN7/BcTuyCAz4sbgIel6d KjeVmVa9O/nSkfRwducLz5Lohi76NmEutPFFuX5BxhacSJIUxbMsRO3pBLQu8C6KsrUxqnB0 y+BYddAung5O07mDmTIRIPmm1iLtlIy2wrX7AwAlaBwnCWcYhhFaXG4jtj8FCU0ALOZrfYgh GF8WD/MscYv3yjWiKLdauvdpnA2+Ayea5D+6riaO2M2mJw5YUd9wXi88GCKAIuxLUpgvRzEx ifZCb0XfnqR5bJJ8sMAmzEpGlsahwj6tyEg6VclxjirODmjpYb7WqdnDok1LFmVaUfXB6xmr EDFZ3Lxb9qIfJAsdm4gzpbJiKXgaDruRvc5NcGnvcsy0tQXCEVwkHF8F5/izZFAgRZnha0aW wsGmKAgkfccOTeWtSOnjIle/kgz5y7zjKPCO44LMfucdj8i2fjGKUdJcv6GtbXDA+eC+x6a0 i0NIblilXKXfFF04s9Tj+YXGBm16oRHmf1bxPPMOsSN1loMPJW4S8j4w0B7gkWwqAu2V6mXV wYzf7JK5mB+pwt627Ld/cz0yDIBD9SMUp3jZDrqpv+rmvjN6g9MVKFaSCFm+W9xRueytt972 5enqmcNI2F9klkUwGUelJAeSCWBYQN80fK6N3h15E0Evd8oEcahVqVS7rCR3zA2quXAFrvrZ LYUsag0UyVixiL0Zw+fBjpdNHTSS9qFTBEr596TMhFwuLHs37aDPGjslKsdrZyudsZ/obG1R xhtn8JY7gyZCTZoUieyB3lDsYZTjZgG1Kmrjdc9LXOBaZOxJlBmMJRgSqE+9qZPmRniiZ0VC TLqTv9exb7s7TdXRuZdtWPcCcy/nySumx9TO/1VPRWEdVlDarrbg9qZZtUbbk6KQrHiHtFTn mUhvHYWmRusB0Z8+i8Z5ccry4iwZD+rqTePNRrQrJA7oAmu8yJi/3wvxKPWliLLCYxAVgEcv Wo6m8f+oTKREd6AX2a4NM1rLNxtnw4jsB2qBkJiWjps1IBpz4VDaapgIzcU2p7+cFju6U5uk 2C3XF/gJKQrDaBBP+0VuKg1OlYM41KvSkG07hxYKBPOAa/Hv7UAEGO2l9P9v791628iyNNHz PL8iSgUfSd0kdbEt2yrbXUpbztSULftIsnO60gk5yAhJYZERzIggZRqF+Unznhggn89vmDe/ ZQIWDnDmJauBBM5et73XjgtJu6r6dAPWgy2REWvf117Xb1HZAobudpp5BTkcClqYfjwacF2L isvreBiPf+GSdZBIAGZdxiSZWfOdE7vQrA/xNLGCiQE7CwEem8ZYEOlnwaNHu/UiIx0p3MnR QDMJ/TGN/TiMXfgq1gLMpmjYE2cC0rYiTmMFE8wYVxWPoG+cf4f+qmwclljPEPwSk5KAAKls QMwlXSXSEMDFQYdqxa2vbQhnh5AtCSGeNh9aVMhkmoS1PQn+j+jjOIuyvuEZ+rRehu+p2gF6 ITCSf1E/9Ma0sXPBP5mN9k8sj/tpE+yGqObg4bThbRGI2e4qKS4wKF30pw4ripTqMcmH67jv ga87aEKKqltxye2oDb2BmkWrsFETG38kDhHexR2UcvEjMKeDTYcrmSIZyLDPJwhkX03yYXaT xhjbxVZjPxMEgb1DLA0V1jeTrkBZxBL8aT3whnQ4/dEQKtHY8CH1rHCWYkwHQs2OOyCy413r arCCGiVwmBLAJ2nijIpgaK3SNIbB++viEqTB/jD56cdrDjMJFwt+zgiiOWlo1rgYG14Dpamq YrwvdY0+gIBlhOEU4Rgw971mSK21erNRBrwIo6amWyW+z2p7a9OrTSTsFZAO+PbqJ+cQn1gY NW8ddLYytji+iDUUZGd2Yc2f5pk/faXkAYevoe41xFX9xScLaKhR/FOZMVn0pzuSiwdSU2u1 uMIj+UMwVtc2HbYhZnxfcCXeG2uXfWwQTiP0rlfXRlkJrYznAzptkYHzzf4W4/Ec2WKJcWxv 3W3cDWXGjEXSva7CxLApqwg0yIv+9qiqzIrWz/HlB0yOwlAur8ZtXDUG1/p7y2owHk1XW9Qs Moq268U84XblvyiFIYv0W3N6bnPLWOjF/FKHnb6w73rPMF8H6NiZ1RAsOMllHI9FwrCch8Em E0wL6FhrBrB1ydDksn34HgZluQImj7mNxIcUgTp55vJ1N430COnpXqGlkms2gX9/j+Vx2zEP +dYZ3/Ce6ehbqFpJWyR7XW3Xg3Ak806tQalnjaF3hkgc5iJ+EagKoiE14KngGJuyU7PIyEfX dDcgshzfBiC7Di4+IDSOUcjskhgNKEbX7cyuB/YIqhBH12yQosoFst2gGIMUccL8CKhTN/4V a4aahYhHDriIWyfxS3oG7vvp9QBuRIQSFN6rpqd6d2Fth3JCFimkpgVDpcV7xRK4G3CuL4eo asTDHuUWmdmYjK45TzYBoCiKWJC+SPln4EmmkwFypnEOlz8BrnkIUG0H5xmbQXxMEbENhMpM Qqp4kzHAnG1nKDHKBhoFlmhva7saodym5tuzq2yWlKXtcoxWVMlvW29T6u66owfxLDrBwiLZ Q9v9GKjLS7DP4zzPOKRhwLlCNSAHzPQFtw0xMvxzvQbfgWkuUhNEKfh1YxagdYVk73H7RlXy 5N0/ui6NlA+FRPIPg9juJW5nwLXA3+JFM7iYQYVx3jGXlI+TCR4Xgk8O4kYZrzaoxcvq4I/3 VC16jjsdVNTWl2OI4kk/YnVNNcpfpMq4UtGWafxWFQtQrNBKCitox/gZLLYaq/lyEE4KjUXO kbFKcJerrIOyCOMrtBW+FQb7hN22rHkQzznDfthZUsUFizj288ZurE3DHCRikrS9izZBEPYP Isn0ZxjrhDMYurQw5Kyqpu6aG8k6iTVvY0qqJr+WET9px0ISKFfmlR4J1oDL1iIGZWVzgdpk cwiLspYSnao0RPTHj5gDthvMGW7j2iOAej9DdIydHW/fQbFAozvFOtPDSl7KCWq33Ae6mj7+ P+5a4Ep8i5u2RkFY39eel+j1isculK/eHbfaG0u06fywsM1FUpEntDUfbrUI0qQwSbCF9PEg n/T7nINutSZwsfERAueWESjxqQiZb44A+1HTnQDMazr7Gcs0mX2AZLB6Em7MLAJN1Rz6tmtC d+be7fnfb23pqJW9NKj2GU6o9LvXI9335dFTUFas1qrOEr6OTqSLsNrdttcXDmJr23ogUrQw wBXjmtWfLaZ1c1PRMpKBsoiCudh8ssy8brmCi5IWTrxAdYsSwBXHWIruTX89gAlGkeLATQsC hRF2MUwnYzuCFQANj6Jf+YvHISSX31iDkcuzRq2zyid99DIftq3wK80r25b4ebR8dyjhT/Xn FZcZWdCnxXPpxZftobOmBBidBdv70PARaOksAVlsJO2fzMb48YASz+pTx+YAGldcDHBY5n/X /6BtUg9j6BiAxC04O4i71dy5at9q06j79yIbJ8WiDjbO8En2GD2nJDAobVc5nemJTvAqA4gS cwdOzMdRJzgoigkIRQn8v6543+e9vbh/d6w01eJ2/jO7nR8rf3Obl82j7Ey6/Oo3fy/K6mrK onC2WgQEULqr98zjNP4RDBNxOtldaqm2d7aayYIYY77AwPF1y2Z0XRfVVuVhHNR6Neipsfm7 dyor0eacn++X92je26yswZO/meZNl0OyTzFkXkhKPKhGFEGQEIaIUfik5ypHNMiziviUlBDg AzKL44QrykqlLGpGO5t+RLQk79H25u/Z5o20DKVUMXnFaqF1HyA/honLVg21lQnmNHXTxSkc xld+aLqY6kvyTPjxKGwDo1RcHZ2LJvcYMUtVZsCcyBa0igmd9o66g3rc0EnXg/9hs+9s63PI 3tra0uO30f7+DNQC/wke699t8LdcKZ+XjT1sGL6Nw59Hd8fKuM8lpOlZdW+9oCpQvJnnUrO2 kyO3dTwrgTd2MTE0TeCcKQOpWhT/iir+7GRvY49KtGOHNKAjVrpKwbs1MMSU79UzpyDg3QQA riETwAJjbMTlYEOKv0OtGbD4TkNzdZfrgDaMrluzjGJKPcvAeENk05jTM/Cf3//eN/Xq5uUB 7GAcOXEKLvMC9FPla4KYsJW/GOEsB4NkLrZpTfz1Cj+PjrH6CxgZj3abxrecq6rhvcEoan6L jSTel13sQFVdzxFZPUt/RsQtKqCmQ5YFjxVCTLNJP8snDWuByjXmYceXU16SyXowNdTMAqYf IKeVLJSI5fxlJWQl5pybnZuN5wY13X/AubF055+c/8yT3brtrWZQ2/iYijN/27sdD/Et60Js wb7/zzyP1U37LEwn4bCGCntStU6/0eRWnfWTz3cwTUIq5HKRZ5Pzi675vXsV9zkGgSEnCYQr yyOKEoTi9ujex2zcQQmp7JjRd9ZkpxeXFKF3B4sPBp6mfhxMxsB5InZNmdfP85BSw96k8RWT WMVAFHRPMSI4vJpPUlU+6BtBQ+JS7DlEMEkSjdcfaH+3vm2L8tc4SpNBOb0eBWZ2smmBaPsW cJPtrVwJ0+1n6q23BNSvPUBCc6nDNZSejlwBb+Mfy49mPBAlH2Xjodnj5Ia0V4M/gnIGpZdx 4wdre0XCoK4YD0RnwxAqxmaKmRCF4QRuRtd78/fbjt5vHH70eQJGbS8gtU8TMDoCnF4kfUjz Zgh72XTeTuEttORN6G2C/xyLtmA87WvqEsCeaeZBy6nVgSwXcda10g5I68KQwJDuos0gKVpz pXldu1etprkUe2Pb9N/O3qK4u5DDKb+7Du3+j8Lp2F9fY3TkBuViXkCK5qzK/1QeS2W2ievl kx9j1Pogjoh5o+WMbI+c6bBEeMNwAHfL+12r3+DkmqoejHFWGt2UT0VQOxG9dTst7ZvLDzKq MLNPk/qWZ2bzpL5/T3b2//OqfDaz2treaeRWOK/hcFlm5dksaBdft8Ul1bsD1rGz5B2lnVmL G+I3QoeMpDNKsKISuodvrD3+6snB033d/vPpx18nb5OALGUy6frJeW06ju3e8FoV3rK5s/Mu WDvPYBqyQQk2snVtG33R0jyJ4lCrgShgaLNPYm7/brd9dWvzZtBP0g2cq1PocmHO4RYQq328 3fDore36Zzubja/f3ax9tr15q/7Z9q2m17dv3q1/drvhMxfvuWbGaJZfTe9aRrDwyYL5cpGq dg+hQgDAhIQZWt9BFk0yYVQLlFCX3UK3NjcbthA0GikMfPPRmmwl+92IKKphHuP+0dsHotGv K1Su8dOktOVDE0Wq2tX/C77Cudn6ZGNW/C4eTPgGtxyWw3hGpoGocKF0rJe4s6MYajwwUv7q X8Z5jHFuc5XG1eDhf0cut9H7AXrT9bS8BdSaNcp5JCFwx6mHi2hXtc65nQXkPmaiivb/WVdM a1RwCG0DX4aA9whSc4sxuDCcJ9i5dStof2fOV2qylqHUlWtk/jy5PrYRbZ6Til1kjhEQ4IF8 uwZnTlAgGMHX0HlLfk5/G9GNMvuyi7/s4n/4Lm7l2V4g9ieK1KSHWJkXqoSwOoOh5mK48aPn WbycZ2efL+LJcXOmxOmPZsUBwhei5rAjpo1qKC38/4juFHbHok1OxyRhpaZyksPlCaCidYwf AvHmGh0STvht3DeHmusSo6qGWVIcWk6RhbbKn5vIyhRglB5EgYZcxBvsVGMjq4cdhsSmOE+u vyPlP0JVsnxFQT4uNfqdzTmjtwDkhBDRMBNSeAAgjejoaiQ4DKcvsaazBUdXtZ8mRXw2GQqM /3gYpjifIUpUhMpuNN7crG5IsaifMF+6FAVmVOoyZl4moKEkOIKEEl1+GGoAL4xQhwzD3yBw /JcAgijD4DKa/WT239vrnyIOkEez6Yf3kVECbbXdPtQzU7aUKPsRgEkoSP7DqFPB7R19ELyU FU7FCqnOOWTsch0lQTsNS+mY0d+j6yHVpSwzKQCP1Sn/bQyZ5kDPOlqreect2+LW/EPBkHJF DBBjEIbvI2vwRrniumdkB6tngcfVUzB3STPBpVaItZnNDsViwxdZWwhyyzAXnH2XrwjjlXxa DrKAMDypuscH3yZoPIfkwKsESmAwmbkE1mZgTkBzVRED/P6KlCUYJmUJpggzwRA7UazL+Ymy mBPBz85ijnWHuHfMwjYtUBQKIa/TCUN6DADigumT1D1qYc/CIRRdbeqzXUC+2CiYGgNaPu9w 1iqW0SGEorVQW9Aw8oCssRr80Wz8EA7pMAQ4Fovf1f8Itl6LR9YL/pctSDadTX66noYokwE9 CuGZBunHEW+sQDQzF8a+3AXi4eO3nRU73xilYdOC+hMgA/kLvId4LepbCIhgPeskjZJpEk0U sEsyGsUR2DEBLK2g7Hd75ig5o+GwzV8lb5HgcP2mc6L1zQxsOhyZZ8My/djBhXFvysWchm8J RmgKkJ9J+csoMGuTTc3/aNuFqvDIi7P+dHY55KLb5uTEafrRLDjkXZxN0kuzlOYGNEL1B7ft lliiReccZveN2U4gINrjQKi9YKKVOtw4qWeMYxSZC0xMg0dPHm1t3b4V2HAzeESOKv2F5aoB dSksEjJe43EMqVyIV8sGg0efHTzbJ/t2AsUdkaHmlIUaBDQGIM5lciBhlIYEc3h21pHLGIfG Q4LDjmSpR3qEo4n5pR8DPJNfVwcbZtaBaWZkiZ6MxxmUEgdyn3DyGfiQp6kfAjTijLdLCOfx Z7NHzZ6AAFWUZsaZWUOY3ns3b5HN1zC4DAfwAfNUi/SDOf1UE+Q3KVSD2ZcA/g2eDU7XggSJ yHQaMhZT8zqSx+4Hrz6WPyYpMVww0PwYXgbuYcrxgYw3sFLI/QrVsGFQeM9OfkqoTAgCWsQj AqsdmV6aI/H2x2uadSNKva+mQTfv1+1Nr0YtxeNR/h6X0BRYUR9GgR+E4CN8DkAE6Mnecu26 QLNnXAOHjTBcjR0iMsN3+Pt6tG7kfAzOhHpRHWpRDgTgl/R6amd8BQFR4zwcYMUBLL5CmYDZ z2aDUh6cT70TvIcQYk7Es+PpLTmUbXvm91MPrK0xsrKNiEJnoUFVi9CDKMtLosJxqeMu99qt xlLNurh8/vJfVP9foEnhX5Yj1OAAZtAWzJcr9BL+wa7cUoO0vgnD8d9TppzCdIE8tl7QPhHL LeJOJWFkksbvxpTyJ2k0OA70JmYDhJKLlJONYSfOOEDVK9fAt+LFBKjgbexBiAKzHFyE+XnM daKA3bJMBs+WwX0bdPKQ3YEllO4CWU2DqlEJM3QWSYov94e4dUV6rPTCS33zOe0hwCAjonEG WeTTMP1A6YOgvRhh6GIikzTRU8KYFFj4GyEakVmKg6WKg4/vGPXGG+zhtVFKJlNDACH0x6AT m4bR5e5RmCbYzgc/6XNJwWr7rlVOX7asu5uPw9okTO3ol2ts6zO2mojBDTRfhHkRq8+LNZDd 0eubkGXA7hZn/9OpL7EIPMsR54Vq2RJSZOuQbZNmr4URCMM2B9B1YonJuqeTXU4cyj0vcQwZ Z5TTp3beCSLiYp1nv9AZmoxQwLEmfxBABIZepp8DBMjS5EPHiMHBBnRx9SXVeGbkfETA0XAt YHAwomei1tjrR4cgZOhDPqiVNtwQML//9QrkQb5eEVd+oS/vzGbkS/79Sg0HQPVZ0G64uHeO 8r/jWZQDjfKY+ZPU6nrEA4FukDUlTqNafiWf6/qEeR5vWF4jjJsJxAqqscKGP/Mqx/Wa9jIi k+l81+nsPE5jvAh0KvFMtf+KMxM+dgRcHTVDrCQ/VMW2gDN5C/IQmphxSdRfVAyOpr7XnyG1 6+ISqAkOmKS90gt/7Qg6jsCLdFSRL6RTbzxCdqhABwgix+6LNUj8+7dp9j4z7HbdcCkR3C5L j027FHEjQoaXv1EVHq7oBv0YJz9qOCFVhey+XlNY94eK8KHyTmCCGvJvwxE6ATbDLQTESvAq sXKbCxP6a+8T2MVNl/cpxwxmcFiShdgvf21zU6jSz2xBheyWFp0E9RI2+q4D4PjufjaMxlcP g/tpfGX+/16DYAHiGEjz5bX3hpmJnCFM4T2ook5/fL9UZ25Za5pAJzh7KCjsEq7dIV4ytgjD N9bkdz0z/7VSZhBALRyJArsWj6pvL9NPK+0+MTJhhBUpZRJooSQFXd+7GGaXihDoUIH100s0 brTn+U/cunlnGXv2PT3X5wLvf5VDoRQZjZKj/my2sxQI/HEclhaqdrlO31nU6VvLdNqVkDme DAaxkat0F/9XMf74I0A4IqBJXANXbuvbvUVP7NxeTObWzZsLe2+3jQIOStg6KZXaJRyvYoRS byBcpRjvvGLfy43X2eGyszMVuwN/LPO6VbmpGDrXyDmf5BUcjMvpX82GeRX+SP4pfKIK/9zW xh3VhhP2FeT1kgXP2+jfVfSpFmy139UaqsvRtYdqbmnyRXXIW6g7yduIE2uuCrgm7H28DE2t OJ5kUtomlFo2HcSwgEq49+kDw9ez9C9m55hfhE08dLfmcxJ2APgyZORMEgC6DT9NQQPVgjaI 7CKlZLgn9mvdGbpotGAA8oWjNL8bSxxwr5AZ35ZLTcwrFJylNpC51qrhqP59utQQXwyRBdvH oMpILee4jdXeq16z4RCMljOGPQc5VuzrKuGYbJGj/83S1tvkp0AKDC3FeG7d3vLa5Ta5MDsZ Xs045zRJlsQq1mxba5bNPUVII6yQMgD03kLsqvWygj58cQEg1hfgc7WVHN/GUQKIn1H/Izj0 hr9IGvOSnbrtdQqcU+lqyf1q79arCqBSopGVwWgMVbojO1vL9cXlnvNmRl98m5THXy5DV9tk abNSjT+tbxUQB6zi7v54Y+0iqwe0OiXHR2fW6OV434OaEGK16iZyS/TaBZ++LhXAqjaIvi7H Kr52OcvoLYfu+rpU6mCVLgA/LEXPq/2Kc8OrBwYK0eDBlwF/U8FeqG9ltMbJMMxZ13UKrjPy WePaGwmwWfUqS9twjQ6o54Im9QYXc1UMAUSk2gGOdsFHe/XF9TeaHUdF9XQgTHgQLvNfSh35 klgdNCimf30b6KVygQKki7q981DG2gk8kFcO8l6l0UnFVYokuVZ1Q9FtZ6tkml8t6Wqt5rbl dNgEqnzqLrErCYmBJAkoBwZToObvOJtc5tnIL3daLYXiVfEEbPjWaqYtYT/etYfzB6BfowwL 33NWCS512AcuVAtj8q0sFgYbKYFR7zxHHSpEmEhlcYKdU62anoovEaDgEMlYhQQSwJZD7a1c smLUJeBdSOTnYpaysa4Dj8PqQZjGfo6hXARZdiBBk/3GYBIwJ4x6fjm4ljovttC3xR1u7+kS i7ClaggwSjl1hVD+bOUvtTv+B0bzVAHMGM+bd8Qvy22B7c265HN14XEbVXQIoruX5TvCL5bh O705MpP05s/+CXWnwIuKQNcoH/EipqS3D85iVWMSq7Zny03XTvOZhqVLY3uaPeiHygAbj3aa QJFpvPkzsPilH8HWG30sa8Ndclk/hfegFgbVu9xC+wvS0GUOOfGrUaD3F6UqYqdJqfipPTmG ly43COe5O3wePNt/9tX+0XHlFLSXwmihecvSZAn0GU2GJ7e7umxZFPevc4qZ4RfAhZ0sKY/f dnIxFAiZ0+RXH3/Sg1mW/p179eOrK6F+J+rK98F3aMHv8vn7Xk54rW7q31ummHe2deOsAgXf 3edKkB+6eGbDh99b/u5qlr5vEhTMQbLXfKk4gXXgNR785nqTLRN+T1+ZVL2qGYrG5nY6R2dr Oe+AQmrIq8PQ1P60Yeyrq1f/6zVHZpIrgfyLYd0Q3oCROmEHDj6LM20u8stYGbiXmogdB9y+ Z1PZvIrKNQRT8GVVoiEAqm/4IfUluixiNO3mMOjlundzc2F4pzWPiMLfeGpI9fpLmtEv5hPe 5Q/ueweq3Yiu6OIWX4Ko3vxLDddTzE6sL1EOJLoSJ+PxMAF/rVmPMIU4KQ7Eq/jLetrxJgjE qh4Px1qBJziNs0kh/rVAYw5bcBZKC1sAOLzPg6YtGvruLihUnmBxL4X1ioW2wio+K4VPYnw4 VU4S3b4SPLkIfJiIEfDwBMOaPhd0uGW97tSqBXwiE2ngIsQ+yqBytoEZ5/E0ia/+o7OUu7qK vHjJrjJlRYGRnyfTOK3sb6ySQU5sqcCOfVrb7533IBgUMzUomi8N/kgI9JUi7eigjbv+TiSR DH2iH0iNhBrGF9kUQ+jCHxO0T0NaI5QPAyknD43cNjQaGHYA/VQFVPMpyoR2WUEo6O/J6VKQ tLdUKNOOMzicyD3CPoazCaBCn01SPJ7hkBKzIdwSPRA0e01bTB/E5uJZbIMhyHsMxZdCWQgm gULdktEsO3fvzd324jBhQHWGtraSRp2noW8LIi/SIh5M8kqxDPTLBX4xcocujXXsf2lZ8X78 fhz/nH6oryIuIsjq18H+OzapY1G7iIJOzOqjY+GXwDCqy9lyC+uVYPHMts5L+jtlM/wpmv1P c71Uxva75dpyQIKktMAucXcU8xe2OGqXlerAoVf8jXks1TaqwsNPhRTWpF9Oytq511ARDlUX G3TLRPX2KX7XvpVdKCtbeXWnlurTnc1Ffs47t60ubV2YXtk18lwu1ZjzhrJwwqJVcN+TsQqs t/xQKxK+7GFfu+TXfjYL9/O1+BqW6Mm2NkoepMRkGzrRC4wSXDJKR8P3WMYzyRXuyLtkRPH6 gNk2K6DSCmRchGdlTClz5uIpk3DYyLeoRsIKJVtRKqBuEy5Oai/quJo7Mwoh6hqCI8HBsCVi 5c7li1RCkSochcJjgl/j8uP7eEAmIZeLY41D1hYkPzbaJ1Rvv4053IaqDcksYIxJjYIrAsfx JxMfvVLFt+i3KNYRq3okIFRjxT+q6Lbcvr/plwhdUr9xhYHOVHEg7ffwQi4JKxJ1gbrE4WkE y3X61laVoWpPPAQhws0xU74qpYpG/6I5HfJY55PvBYcxqqFFwndLETcwefAB0ZV3u/Hzrc1t e8QdbOkoKz0fCaKOuo/bGrnjapN4DJFi2zwkTyyANLdsk73S52F7cuGja1v4qK3Yp9fNu4SF YW7wU7ZB7W673FOvAe/MNxfj8J7nyDptoG3YKbYnzjbvq+/LTVHFDOFmqK0s1DKzc3e7Gdtb 20g+ZSJacGV1k/fcMWnYN5U9U4nJ/oR986l75qIcDTl9CGNrrMnlMSXjerW77/fzh+YzQMIA 8HL6TZ+hxxDrAWFZ/EI84lfex/4L87rgig3NygvT0osMYnj19V75fB4xK4B9nU5WC7g2g5dp 8s4Rq34ucC/ewdEa/14UWasuFvhFHmzz7HQCi7omSLSwN4aiHnzHIQ3fB+IpqcaBFBWnR7fr CoFLJeQuYEg9gH/cY2ng/Q0/e4Q1xeU5MfNZ6sq4LAw7uD6GOsO9boRXj45oBoCPgkPl5DOx b4/jbAyJpLGZjzhw3fWIiIce5Qvsl6Hwprvawcwz1TOc3aI00mSvOhOLZyF6UJuF42SUgMm1 RHfbNMZ88gCr81R6XoklqLZOSknRNdvjwf3ZX9KH7rtBgB8QFtbr8jguIUEZfU7mTMMVCRVF wdrrLnKZeTD1wpOx2ZrnGbvt+rwvyn5yzgFGhU2Vh/dXXcG5KD4LMeC1hIrztW5fxUMYXVO3 rwL/A5yuT+h7GDBxW0/PI2UmO88ThGy8MtJrPGX5E/tvFh+InjKFU9O9VYjjKSkkvDYMZJNd ZNSz6jjCzxyHx3oLTI509wBmO6YeTQq6NypIUWycGSZkNGM+SIXvmyo6bYP36MlEYD9OaWyn I17uubOBAd/2zwuP6gujFpSkXsJjXlXB+F1SVoh5jEhogB0EPhQ+IVYjnLaZ6NIEx+l4CBxu sgn5/INFQdN4oVv/V4H6QBPqDGyZoFGUqD2bhg1Pgz53bSCYob8HIrB7RGYUTn0habCGq/Sq cXIkpFt5MzQSBvkwIOAakey8AHlS85pZOOASjGKj9XwfQILo9LQC9Ir/PCMlXh79wtS/MPUv TP0LU//C1P9Wpt4ks285nf8re7TAGaEDkv5If0CMYysm6qt4ePkBA6pDH12nlVCvpUcuQGGP J0qMJJA8Q795iTcUHaxyFPRTzU1Y/e2rMNoQE6JnzDdvDcP0Ehm8tr2w40V8omyi3w0IZeg3 yplva3ZniWabhtje7OKhWrv1NxC4PXRZmWvJcBifg4/8wty1g9I8vr6gefZHrHEeXezqW7Jv YX2JHu0om7SYt5rbfSGGkyWoOvPJV3B95ueTESeqdgcb3mUFxMz3uqFHF7M+pPGxzBFM5r3U qPpu7rQ2f7XhXTrLNd/+UmPzWzdbmw83/MtiufbnvNXcATv9j8IULheUYvpZeSFiRIipa/kI EXKIQ7JoY74JsQb3eFIJzTmMR9nFBLwDhKvMj0JEZDCFmMIJ5NlVEYY6CA1i/8TIWQU05CHU 1AayfZvgaTGH6BRD1LY2t/CzsySVB3fvEa5ukmJNw7s7QgteOMWJK3bv3nYf2X26dQc/JIg+ 9bHF3y1m6UDtq+1gkGfpRn8yGnPagqoueghlLwcXHEnXjNJ8GGMWIFiGdepSUnm8cTJuCdQv nIPT8ZVhJxo7OOqbubnX0GuCA651/I6KK4UoDhTtIh1kDAF0v7F6oVcoH1zsbmlP7VHcnyTD iO1KqxCYOrhIpr4tKaZbX2xN6Gmh17DuBr1RcPioF28SBHgZhzNK816xeBCRq1AP1z6ClxdK 4kM0H0i5J+IYvc5wjP5jcEmb7U++p7Sx++hlu7H24uj510d7z8zNe18WDELSRv3s3cPvg++6 F9+7l77FZH76TgANxiFkwmduqmwgNTxmWw6ClwXCKdEADTHExUCyfe49kuJceZm+jTGHc0ZJ bs5Cls+4UnP8LoR2dPmYG3Y1g9GMRM4KlQ36vAdd0787Im5wJAWFQ9KhEF8rQATi9LzDfw7C IUQNlgw/4liLt7NcjqJMcJBYK7OyqGLlTW1IBgBCMCFDRElW3a/3tqqHZ3Ozxlu2N3W0sz7P WB9QgYVKlZtqxspS55ux5vlt/1g5Yzaz7mwcp7Q3UC81V6/5fZ1Ek+Lc5y3InzMjzv96XdI7 DY87bHA7FfosP+IsQNmfNh9YmRXyJMs16sR2b6tD0yRPF4RhcQlhJQASk8/G5WokMF/dLuzo Ce1wInwMO5qN5BBRb76hFEKzkyOI8LmQNGWkBb6ByVBFvyOIn/l6tkqJKGeQeYIwM1C6LrpN 6DMQyBBFcYrnqrE9s2fPL8rgPAc4GmqL3L3cHqQrGMrVwUrRiX6eXcbaNnCQ+rNkXwZKRQLh GZYKZr1DUitcv8HxN3tbRkd6p8wVMH1i3+ibO/2yqHZEcm5Qm0Hk/jzuqg5QIg6iyEnKjjmh A5jZrKj0BWaduxOmsytkZqZfCAGHsAhYDGkGig1sVLYK5DGU6ZhyUW0pBeIm5ORiYnEcUSMN 0PFtnoL05qvqWDjCGGgJh4EwjxgAUAy1xKYRSKYRxxOyajj0lToJlpCt7/wYi90X0MCGkcU8 7ZFPC3F2BQMgy1xXjqPM3G3pA/pP2YaCyidLURf2P01yQN9jGsEb+n+1B+BnKwe+wgu8+jLE UAcIlTNK7rBMwNCkVNlqp4V3Pajp491hs47e1HWM0BG8Y3gjkvv9oKx2yzfP2S4OW7sorTwA yAr+3X09Dpo+hp+XnM1mw1/d/nY9f6PeXoVoQhyB2a2GUCNVXKV0ZjGOwxJPN8HR0PaLgjWo dT2OB8lZQi5LoNoNO2YlvBMqRN3o1+mWhWOH4Y4dbkjAs0yXknOI4A2D3FDJRozLKJTkyEXe kavNqbly4xI2/Q/e248x5JJUEbazeofOo4nC26rpllT5gf89cijMUGLTVYiIP0O2LVlbGNOH nPpaCx6ttTHEm45CqDaTTcpudtbtmwlYb7RRwcg+wzpVl1vUVXrzbpPuh/cvmPLy86Km6/1i H5tVHmugf8uqG/ujcTmr8n8byUIhkpWIvIjMA5nhp2a3NcQsjz4O2XbiQ3xUOuFENKi166X8 aWAW2iFN8CyHFh6mWkrLl5OaaDT1R2e157g7vE55k1Qp7Zz6XWnWw1Rbd71atMA4krIW/ABB 1i4JGWOh5NDXmLkNUNM6j9cPyyDN9vf3cX1+lJRGUW2gLYAp2Jy8iehgcoecTUr4qmpuBhhx p3OB7mHULrlnh9k53Dp4EpXJn+KJG5g+2LXNAScNE1NHCdbVDnuYXFJ44CtI6tQUoUeIGW8m tDpu/NKmUTYdSdGJfeHWfKp1L5D9AyOihH3EQAQJ+wwRyMr4PE9KDw7LTBgzOIf5RaZdOHXY oICO2o5SC73x4LLhox6E21U/j/r1TxofLMKzuJwpSRNGhFeoUYfh7rHGfwSvJVWsp9unNfO7 Aw8juXEyuAQcMw6Ascy9dc6MdBneRJL9eJalkWsKNPU+69ZRZVTYObMxUeRFyTXMhwD+K+2S 7OcGQjI7H5i8uAiHRa8yJ4TERgMIrswyljHiDVR7SODrpS3omRiCMz0/7KEE2Z4kXDSkzTcL uMiY76z+6n7r9Xrff76sCZsXg6958ouKrKkQsUnYsqn3LG41e410+I/ey7VL06xJH9QE07Wp R+UVf2GuXDAbkosG0K7RDxJTgYQYgbbFuzqGq1baEDqV7g+yPJ8YDcGdsigpjHw2a+jbwgsd JbqFF7lwDS/rGtkRzuDu/Le2PeAR9bCrOijYEf6Lt+yLyN1gwHD/wXFub5HLgtUZHDJgVTxN ZG5RBLXCu2A3d8/AqjWtmbYAhC3NnIDTCd6Cs2xADDYFcEsIxLdqGS0hCsIoCPaz8wkDsOva cjlo3pOxKxYGQN7QVvfMiMtAdpKC/J1nWbneMVTfSQsVWg4+8wwwBiyZKZxi3sdNOIxNM+zS apD9SkEz+AS6BGGKjP0GJjnfItRE754CA6M3gr4RFuGTNSMqwArgLAgAgQVZvbH2bO/g6bO9 w9Ovj14c7j3b90rftWwPF6BvbYKNlfWwGB6+Q5LXcmPZulmv9KYnJI/NGi1B5tZmvZfSM+t6 3dy+c+c21nBfgqIDAfLKGHIBQ7ZwLkNHr5a8RX3jSwF1ly5cDWCJWkjQ5fY5s159qDs7m3OY jVT/23Z9i/pm5rBIN/bn9QoP11ZO3NxcSG+rPmeD86TbBznMbZnFZO42HpgiLrvw6aecle3t 7dphkRExvYUkGrao3xVblmsxqR3XG1XM6xM7dGuncWt6FTbHV3QJLCTmcKXcS40HPH4XDkpz q27u3NqcV0KzpR23bds6jdckyCYLad292bhBfHrLM6Fth4yEp6lp9PZkwcFamrICST3MKnfK 4nddVLj34sJzfdNts6O4y1eeY/7Pvz3cP1qnIsx4ERImqrkiz4YhuvHOdLS4asPMQFp33z2C jwNz65p/e9oNhbypgnfMXxkdLcsuSbSAIPTuE3AfUwUELnlE4TeeIw6Jgx5ARGx0DDupwBdm 3usbPbicodeIzWOI7K5apHaozEYZGjEDJoD6uYIdMdyv2w2SnqGMMjBW7QAP1Dgxkk/3SScA +0g+MEJ0N+8EWScYdUxjIUBESJEGpIeyKymv8RDlUhaqvUj5Q3SlD2cdNvpVeuc6VYG2Dq2F ydatplYL01Nz4aP/iayHwUMXGoIKDtdbYekqx7AjVG0xBvJAF7iB6sto4p+cMznsAPXTmoyE IDcujgay0pP6ZmZxNKZgPhC9SCvrQ0YHBnAGBAAAwWSqQkJle0CcVDpj1b91oiAMErJoMzLc sMPAIw8dl4lCB6k5A6QxqalqMP7LIVCq2n2Kd0Dm8ZC1GBur6SlpqGwYdUppHqDnTIoHaYPi EQa/V6tGelDK826YCcTqxVFFk/kBtBgyvTZYXVFtssYkKndCCE/ovQJri4RwIBR/VU9KkXqU z4CtNNC3u4AmAfYz7v4qnQuk40X6VfStqu20Rc62LMndL/6GkcFSSEUap9l6M+t1zM2P/6H1 CdKJRK01B9wAnGU2/S24/N9RQ3yNoq4FQuFv65Fjde2XwzBLJcqkyoEhZNACAXsYBfgPPEBH zH/E/Bmm4mBAwyd/bz0BEDUNGFlohARdacXB6RcYRCngpFCp3RmSycdhs18rPdPJvLboBxQe DiVR/yxMcuBO+YQckcwMAIIbu2O2H5bhAjZdSqk2JGNOiYtz5ZxRGBm33VHPlxQzC+Bz9XBf GGlcDir3l/WM0ohWixrEAPulkbwRjsg7g/cXBKDMdGYxUnW1B6TQZ5ANI9ddwUvs5ng/0/uU WlpktnLBChQrhY3OhjINfuwC0BW1kKhV+ZszE6rdplgdxLmY7gFF0yyUsje/KcUe3Lw1e9Tn +P/EEIBTOHP2KLJEeYCgNCWGFAM8kE+raqci+6CPJIou84GHVhOrTfrMOQ49arLnOSZXfH81 oxItqfsg96gcNS6464dn0Ke09QSMtJgWDesNK1Rv1JXExb99I+AxdNmPEdfpCWzo8fYfGl2R wRCSlNpmanZNl7N6fL5/DdX8gDRMPCMDDtfAN4azGqU0o42grqKGmwOi0V00RWQ63WFRwLuc jGSQoN84vTDSIlWR9V2l7LusHBFnKlQ32ad7AJmYPkprb3DZ1cSvrkvMl94cig2Sd94/g4YO JEo4bueoqA89KvOMWPrCuWctLCx5IBNUW1SpJYLMM/2gg5h22yjf0docHke77cmQp0hfDOPI UOU6kpehcj+20d9y6bXQAExEM+3W920H11LBOW9WeL3Xtj27n8w9wum0q3EehZtex+kQWkwi uJmXoXG3nQboAdWwfEdxcO1hZqWhwGZdGiKTtxB0+LYart+6Bi4VHBmoyAXSE+KUy4znngqY LS0sUy3uvsyoWsziuHvv4cY2tzd1jbd9LFEFcXV2l1aj+4wueJmMx1burQX62WZ0ZLIn0XHZ g9hLtg7JC4F6hkKEblBSHN3lc62JuzlNBv7xL+uk/hle1raz9mbpzziIBDVfKKpEEXDd82HW N+s+DfMErJ2s0XrksHHE7IUCb3liGLhSnOHgYr2nDl3qRTjVsR7kPPLokcQgjqOhWWsQaUHd i9/FA/h8bZ1EDbb1UCYFR/cNsij2vUxG/XT9RxE2ISh2OUpev8+q/RbFWshx2b9gzYigYZ4q s4fyc0HEznEck8yH8tuApZAGXJY9snvoaaY5eDOi9DqgOymxJC5hnuGiFEE0keqSHj2ZJqlm CuGDiLzMr9O9Ggj0A4/TZlLGZaHlXaEaZSyQGekLi5f0k/dhjpuIo8lrCw5X+Vf73+4d7f8O L7+XhdhZnCSSkFhWgLYM6D/o9mEjxixITANgXTK/rwdROIJZpnJdfJOtUPHB31UvfafUN5yL rPlcHKRFCZkTZmxS6ERv1Q5r46R+eDEFXBHFoyZrScYwiYUtJkmJK0xxB7CsUjPXGl9Q0vHq KwpNo49QdV6YMiibC17TcFzKWfZ6Izl77Db2CFUwXQmTezRmaQh8u/ZlMDOlFK/FB5ateLX5 Y8lF+AGbFDDaTohRXt6ZnX+beAvqKVsyfNF9UpKS1iA5ow0VFA332cB7+VuqQ2fD1TtKgOVo RAsyJ7Immx/AuZ5WwuhMJ84mQ7a+Jm3ucveJ7zQXUdMlMyKfdaxH6lT7YYPcEYqghvb9DdHS l7+TzAsatChPXUJlN5cKVUcW8+G7wdDs4Ol896qX0aNv59//vnYb+4pUy5bu/lM3GBPHN79i 04YUn4WIfCoQ79EaMKR75CQ/HqwKGrNlV1redQWM6BqCst1kZm0WjnT+gYN1c7sAZuMSp4Ev msVUbs+jwttoIRWX+YnbTdJeE9AizdKj6FkJMmyjdNNRqhGpJ3a0UbHz+lTCMf7GxBCKrD9F q56Hc082/ecn+7uBFO6kIxjF4zweYOAshc1zzREFYnyRnMHX2ZQKmIf6DjCyX5yj1CxOlLUk RgU9NzrN5WRwAdvcXCKQJENQ4gXXj1yBiCzwDpkGe+v6QKKMkZ3n4YidCCDKoMMLjfUUWcxY AmB4I1V6AhXFkMGynMSovlAFDqo6oE2Ks7r81KwzVr+K4GA1okHnE9L4OGI/4zu9TMwSYUNm nt5meWTUZW3TzFIzwNJ9Z0sBgVjhEiFg57mgAJR5YBYkD8kWktcWSVdWCGKIQGgzTcS2tKgh V/G4hMPxRdiPsYgwPVvlenR5iRS6d/Tom4NX+71n+7aKaTjS/dR9CDFzwnQRqR1NuC69LFs/ PoO4SIRTzsO0OGMoAjcxfM+qHlHphbLSMV6qqBMMjChbKnlelgG3a4co5dIRkjJspF2KOJ06 zlEZBM3u14N/+DD470x1Q/7H3cH5YhvSpR5868j8q9g/05iQAcMIA4gwm4EFJc6TOnz57PTp weH+8enJ89Pjk6ODF6dPjp4/M3+9aGblEWQ5ViI/H5vPRCIC6He0oYCVVWKi3khQ3WrV6zk3 yM+Te+oqmbqBOVpxozvyZf2imIxiJycxIApEMLICwy9a1AbENYCur6h60R7N8wmZd+pJEhgT udEdf2IX6L16Dz6xeZAuNj5R+HA0Ds5sF5H5Yw4QyjtvelF/ldVJkphCHFLk2IE/MJg5pOlP MYmi9nHdwHhwudrYQCZUa0Rp0kh2jxOUl8Hf3JF0VbH886TSAjBeChKDJsZWjXj9Gvz9SbV/ EIvN1IvJGQRbKR/BGO/ZEZpBi5aYRz4trhrgodOGyBLf0zYYQuKEcuUIGgRgff0sF6xQRdDZ G2uZEONqHkT97LpMTI5jp0iAmcykDK3XRETnhntc4Emi8ves28x6gpRZrcEoY7etIq84QR6f x++C7/i/SqCvcqvQUfh0j8oBlk+Kq44U0ln4CoqB29aOHUrkUVNT75qb2qcXqq1Yx0ZLO2SP dR9c+Z4LfMnL5wkhTdSsBmA9tuAa/R2xZHBlKnYWPqrmK1R943eQP1Sw49FwNtDHzoFlVJUg MOqAWx8eNWLDFYhBZuVQIXpHDIKvT/ZuAbu0CVzwAB4tkpOArTQtqzhxqXIWSUNq/h3dd0LX UGMLAcHgg8HFCMP1hjvOo+anjhFt0OIIUF8UWC8Sh3eU1sCP6lNYzAxjxMl4EefD22bPX8Yd a92I3eSzbZEsCY84Id5v1RbQNHKtulovynK8u7FxdXXVI+Wvl+XnG1E22BhMjNyXlkYY6W+w 6TKPewC16d7eEyc6LLTkcUBIEODFp0VSJoLIhZ/CwOIcU1utx03SJRoC0xfwJRe3xyejYRPO U448Yg7GhcPVCwKUAsKLX1alaydYi61RU/XeuWN7D1mMVNui6aVzSIhPIFehChkhOYjBC6NM m3trtcDYwQ1+HI+S/sDc8RxFTkglgxxWrZlL21Pumv+EVN+LjU+LbGm5WBmOxBv2AX6m4r7Y LUBqRepy6lfhZh9kIzgrP0ziSYNASvR1wolc20sMcWH4Tj1dQr3ecEXNu9Lg56QC2oUMzoyX R+FNLBoFj3jvV9v+geaj0jh+9qD+TVPT+JTXduw3fSIP4VvoVVgB3A3fEGlBvqzWl6BttxBZ 7gfarhqKwzBss6ZGM6cM36qh3l/yBjunNpOWlWFh4jIum91cbHilcfrNE3v14H689lr38x0P 24k6aocI0t0PGIc+h8Jdm1uz51Jr/kZbjob68U4cGovq4ABhQ0kjX9tj7Xy9CewY8rgahTu1 I02b3SkkgT7Af90308oH8IO9rPSQ++wHvEiEB13vkvcPN2FW1I4p9MH9FX5ei5kYCaAk6+gf JaC9kaldbdrangEYyrZZ07ntPWesDtjghklGlG56EZINSQlW7Iys4V7Xt6zeVy7KHLO7KmVC X5fPKR4Bwurxt+ZDgBRxals2qh8atdzOXLgZIzC1JRJt2rYfWAgFd4+/CSyCwRjrOaMQWKGp WuNt2YU92QX1FqpL1SAvXjVBXizZjYts5ApKeGfBo0YNiCMTyV5l+WUhavSrg6OTl3tPT795 fnxy+vzV/tGrg/1vlW/bd7YVcf2ELbn9W27TubvjntbIUUStRuzUYk0Zfsj8C5W7Ur+GKAR/ fABjMBaoAnD+EOrejK7Nt83b0ynh85pXwiK3PgvSD8UwBjD/wXVzgA824/AC2xi2gNMtxbF1 2iLZMCBtMYd/oFJfd0xZjA1hFM2HRllW3adZHcr42xwgAMS7mSlMDxbrrBfZ3rfm4YZgQ5T/ 3Sd5w26yRlLRFtYcpPF6qxZdgTzuRvMoL0AaFi3IfeTLkM9pHvyAYcQ/BYAhq0JBSwD3UQKE EIJFUagyhcJWBSM2gNv84I6vgkmUhSSR2+SOfw9s2mUurEnhp4uIp8LwIbHedREKuIv1FyUg tUOgjbLWFtrYjZilwhyiEcjeQA4ffxE7YggwKpxEVoslAEO9M5lPEQvLSbGQTdnju+nwJm2y POKWWXAAyMIHP0ITLXYbDMqhzwhecEI+poZ0MT0pCoqLSRmZ61XAo4C4U5l+AE8UFMgO45Fn wVOZLETPTElRZmMOj4XSlfChrJ0D7SL5lsgSbtYovJSgFQLWEBMzXBvZpED/V1dcYsWk3+Ve CcAXGFpCKFSCTRsylwmmv7EHjoPbcRv2ES/pksztEcbxrIr1xKcMaAZhQpH2KNwkxD3GSQQG qG/Zch3FpZHAwbJvXuc4UC6GlaBSArUQzankCQlqzn+vVfPUOKMwouODrw8OTzrw/8n+0TOa VvPHNy9fQOQTfivj5WeQJu5vLONXHxTUWzTdoowdSK5ibHTTw6KUHIeMYyG4x7wumorNOacx BhEpfyH3irpn+kndKFQLSEz2FO6+SvcGw4w6nuQIjIIKn2wpPAFoZZuMMxcllyKyFPMrwUn3 J5nHZ1sGPxnPdbFgsm2IF89EMgLwasjriEmUz+rzDCAyah/r2aUBChAVjwkCruEI2hEHaKoa xHC68KamvqyzKt0wHCRnlhXcykJOtmNi7ZwUJwk2ICIhXe6ZXY2bAdwoMKWcfkeWOEKnYrei xbyBV0hNHc64X29wx6x24JdsDP/zJlrt2CG/gRGviqYAZwWKiAUqLZAxfJZGBeFUt78g/zH/ yVH7i2yZxdabdAPi6bt6y8sdRllcQrO21IJ4MqOTxRU0yRdKCWOcJFDJOqDzu4ZvYsIgQsZz M3DvnimqScq7taCDViUFe3a9J9BrIpjDPEZxf3J+Tjg1GHXCEVYsrvOCefREh5PrrHrjT8xc mdF3w6IL4fLeuy5tU+MR4sbPTbvUffCSJyp5iVEfCKfCEEt8YUrSKYu4lMP2hm+4VSLg3gbT aRSfJWnMWDTVEEuJdTLf84XEyG8KBqOh84LDlDXGDFY6wdEHqA9j0g4Y4sKoKjrBz4kEZ5JP AuI30gSgrdEqEVNeFdptZR2NvpiPM0xckrhXQ88fJCYtqzw23LRlPKa/Cog+JXAp0znizpMk 2gApgZBxMVRbLFp2GbiUgsRYgHWJ5gwHSs6BylSInogdqkwaoWjDZotTEFPPsGwDAmibJqIJ eYLi1GihWYqOzupGLDYwVXQYd4fZ4LKLl9rEF53NwjphCN2MBZ5Lm7LmM1Kggzc2LnqVDwpR PJKUHCtH3FbnqAVEph3dA6E7jnOIsqlMMIQz5WEwNKwAkbEkjZ/9UpafW90RZh5MAhvjypmh UPi+c3DByGyoDYtS9Z6RKAXjQ8HMXAi+MRUAEl3r9nphtbVOTyXwrWANUgBBLSvTiUtIHcSQ 8/AytuGwHHJFkkGYjPR1Cm/UTNkbixJ9OXdVckvN1O7rFdQipYgUZVbt75x04M9ydUj4Fl2J lcuJLh5DOji2V1Bl35J0brF09QXV49aL+h1EP9UOWVNOcxsuQaaBFm+sXnUA5lrmARgF4dMH sHdWVu4ZWYkMU0o6uC2B59pVFOerzQmvua5pWrvBkdZUdMOi4jXNuDC2FesdrkxEjAY9kG3k HjZnOhtj2QKREYCFQPA19wUHUlXTeaCexMECCaRtoLNactfJKVtlkywDmZFij+mckxBL3SD1 XgRPKg2Vx114q9VzoTVMBzT04uBxMEkFtge8nmBbTaJ23BWPzl1lnTMcZsgpKYYA01lM47aC +SgneWo5JJgSOkCKY/IMV4FeLaC3vXlXqc8NkjdyLQ/PLhyQx8WusrkrANUmpOiM5IxwaAlR KEXt16OoEtD0aZrfTYet9qndJGAL1UGLaQEGJLe9Q2bTDYThLOSg4FoV3bsG8DqMAeLBpo7O H8x2FQ906cF05k46gGaSBs/3FgRUOKRc2CWoqaNma5cRs2K/xZrt5tRhEDGcZ5wN0rkyEKLC QZ6B4g9EMBMoBN8lymgzH61XSiyY4RJauxHM8w73UcRVi8uLg0WgjhDCBWmSF04wnf6ncufD 8Xn6/NGfnhw83WdAU/wOeksAuXAnaqjT/Xdo+egtWisX6FCLwWVhGrQflhFtXVoQErF0BCxV d7KolZubOhZD1JN5gXQ/NdfZ8Gh6JWWYKEwG/7qQ19x0SQHHFxOCV0Y7mjOe+Rt3ET2Hy3Vk L4TPJ6bxjiQz0+P0iyioOkaLOtO8gCPA8QU7iW+EPOYoaw+qHxK/MgjNBPVfguJKAJ2CAhgV g5l+UZQnATzFamHJmUA2gwt/ECs1CMysxNA0vrCqyqAJWtOP2dpwmTS1BfwE20CqHP9IAeIF 3NZNdJe2bMjLiw0YUM8JWsUo9cwXlmTGKdmHHnD9Us6U2rKwWWeFMgB9RZrpwH01MZdGnrzn 4F2KkyeLHYr/6NkS1AFGGalhluOCZyVof+Bq8LrjrdWnCtyLHA9Gs3JzodAymlzaTjck0ZKy Qc64U3PPgOOU8NGCh+/Y06vXbMFLqm4SwnWPr0AL9BDEF1GwPHHvHCH7M7KX5KNPoOEg2iz0 DcNOoeL4h8ACBrBVZBFBK4IdQIQowNeaE9Rb9Nq9W9V+2HS/RW/utLwJCDzDlvfT+KohZZ2P AgAsdIxkPM7GVK3nUxyvbejHVL4MoTK+o98tt1gCENlcBGZIk/Dcizfjj+rfwc8zUMyFjwDH zOMzsx4QASLvvZHfVoV1WrDAoLzy1WhCkHPvuqzyReq8GBmxMz5OPB1gW/6BMBDWCCkm5BO7 HjCjrvKfhDN1beoZsTKL28YBv+BKZEcp28PAQlEtLaFri34Wy2oLF+SYHBu+H6IoKeDkLi0A vrBJEQ28jHYEPtHA0EjnJYhziPXRWuU+oq55NUJhyswCS409MozD+pMx1kvEQBkZ9/EK5poh TaMHUzVcXDKbOGVfenn01EJzX8V9ihY/g3tXfHEiOtctvJ1gEOeYUGJr56J73FXPosuJs0hC UnxYmSEdTVCPJDxMBg9Mo+DIb9XdAhUJ0U7MdsnGeQKsQI3Y3sjSJu4233pSXWtsgirSuJt2 JhUaJHEBK1HEw6FYCPn6tgEaEDVuFJMKS6Dssj9C4PdoZhrpSSAR/kPFit543666jD9sB9Hr Rdm2mwhWrmSdxxDSQUXwbLFaWMiq/d55jxQa0Hi4ZIkkWsImhagnClDCUOehE+ckJqoAWFIV w2476+XSAcAf2JWGRWYYVW3EblhhcBnPxIaqY5uOzQqj7QkFwdHp4Oy8N55tPOb1N7+jZk1z x+cL0DZjqOBkKwUBVeJRMm2SMEVuAco7ZeMqbDKipztsTy9KpTDp6ADGYBB9TuyJim3aoP3O l4ZgP+L+cUIjLqg54hjR8oZ2yqra9v4YrJWb43tLc3GkJNY/3n+y9/LpCYWHAd627dYkH9qh NLwAu2gtJCFbHDxJSntfTTqZuMHnxnl1VKfA5rTrxdIlbFz8iJwUMgSb+RyQWOsHwMwRAJwt 5mUKanxqrziMbzS/+xA879MPo9+Ct+H72aV+oE7XShb7aRm7kk86/FtLZ382stVbMypKKmsM GbO0HTquo01rKpHQhqNnLi15XnuMJQRMDeJfJg1VcZq64NCQDtKkBKSWlio4qn5u9vOHMv45 vV6m8E1Tk1ZUPZGNrrU1Zt/gf1AlA75pasrcj6ProP9bKbV+eg3N7XjpexjQWgdpwo9P4dMa oGYdpqkR8qtGpNYRFy3+jVFnYlrxTMpPedOOlDxh+7hMisv0o1no/cOT/SOcifdhMfxgloFx U81aw2fD7CcokaRCzdNQ9oRXjKenZms8Owe58F1pDujuHSVL2y8A35LznCC4fRoOwaZu9uk7 fmBtS2XzPwPRiAKti2DtOBuGeWIu7KdJOnnXCb5OJ+swgikkGACWQFogW86yIdsMMFNSjPLI MNOQiuYl7ynqy7T8SIxeiJCYWaDeQkhRunoUj8HVib21IgC/iTkKVhZG76wyNiArhIvR8C/J hXUt4jDBQoNEp+bLp1l8lRSrGJr73db3KFAikA5kUiDUD91pmCFwHuZ+OUGzWlD4Jo0FnpuN wn+wU2xrr7Ktj/zKA3A4F4YjD0iaZ/NodilBHRaauQTUHzYJJFgb8pJjFh4hBvejf/5ncMvz UGnm0SccizUaMBOuDJVLDA9CVGdw/YNs9sMkKxndhet+m5sqR/ENvgKkCWnfhuGEV/KhadaO 0kE6gFoh2SmJJwvj6bGbU9QeDHui7q8WzmNYQi3L5L2k52FoK6zziqQ4k/jhprAjheVgQL1x JpVbEthGiKxgSCDE49eHL23Hv9v+HkjaMpBIFRbgEe4sM7ukbQXBE7a15XGHowS4p0CO9m6z 3WovQDYZ9sGBNQopoo7Xi2cSFsS8HCURlqJEeRDAGIZSD8u0gbTsfEM4wDnMD6Mc2aJQRghD S8JuYOc5cr8N7K8rrsQff3aaZhmEIXw1EdQlHg+gatA5hZYxpYdSdEHDQKwRlC1QoRDF1E0f +QhgWw3MrY2BOhJwB8wgZhdDlgtDqLAOAth+pJeb24dIwt+z1gRTJkxtHfp4av7DqI+QgT0v QvHYgVxIhZmYVdF6Mm1A7YdUYQJxhYqhzJ+whiIKjLw06LnjFayl/lFXXq+c6IeP8eHXK+v2 wdP5j+A/vFcQCGySg+IQwiHzJo/GmhRoNgRhGPgZfAg5zjwOClJxtwNlaMYqBAomDeJ3SUok plPEnM9/aVRx3l3oPkFq/djsO3z3goqyhZNzKjjvH/4AeWtjwiwmRVxk42Jj6969O92tzQ0c VQxAD8XGEPmzy50N4MQqQufpBKkU2Vl5ZZZog0cn/1eybglYx82BRpXvC7wU7t0zozFCiK3U BRiSFxqPuzqJSuXDsDRBvDdz/o2Rg+Ej8pyNXRYxxUxYk0Fu47aA90wkhgYczzHMJZpVSAGT VlfRM0RbQtXPKkwPcUWxp5nDb3CmDqzeC7yVDAe0+QtKPTZs3s0MKjB0uhCcIKEDSeeQ26nb 49z7zhrnQCG9zLUWc5sLvADwgBLuJS+VDH726XPG6qHLqEImCipJmryppQZuLVHziHIbtSVF o9ugXGFDYeB6ATkQ1FDze7XxfT0GrBJQaQr9IHBRdveOHx0cqAuYl24A5n161ZzAHyYgFNbG +FgPLxvwTDTOFN2iHQgNAlhmqImYsYP/bJJSAJkjQc6MAiwoFNrlGwAlvrUPFe7AeYz7CJgH XG8oRfDeOoO2nYIAfMJJKpVgIZG5YAlGXmfWfPDK/8Y7u1ZY9ULNx9/i50AKl4FfxVd434Na 3dc/8ZVLum92yWiK9tBIKKZsK6Nii/ATamAO+Lmxxmr8n/b/9dvnR4+PtatZHhJbF+UZWpjx S4JaaU0wVIP7kxpXmtmzIcKD19rjpGCwUm8IwHzk+WANbgkj4UzjdSqxETSSit+Nh8kgKTGB zwKp1m4X4cKWVVpppw67aHo/zAZ1wMvH5Ei5wvQoyVzeoBoOgbwRUExlPV5Sl9gwPW1u4tvl aNu8F8Pr+aIIBxeVecFTauVtGycYeMKJPZZcPAXDNjiG1qeHmLmgENpyiLOhvS7kHgDsoNwI jqr+8zHGic4qOWaMFRtYQDq1Faoz14BmKslsDxpxOj+H7wohNAF61CpQns7uxjTRWkrQR/Py 4cYQrl8bQNd8+EB/AT/PXWdVLB3wd1w9B8pmfqs2c0wLU5ktWqz6N/BzzOZtYh/0JGcaYG2i 2sY2i3aV0YMOMESogX8mgxj63TqTYQNAEPw+eIKBMTK1HfKJ4L9dKmzivQgCEv783r2zCw/X 23BbU9YME/UUAgrpPvzQ/J03VVNYRT+FHx/y1OLY08IRxGJbCGT3lU+7qLICR1vBJiops+WO uTLrNJyMUoVb1L1KovLiQfVzXJEYPOoRiAdnKuOTH63Sftd0EBk7pwtfNR9H2WAMC4L6k8Jk owz2M6u42qRouuFbuJqNUyGoB5xycGKEuIdzRmzGMnEMNgTOUI8YMztbZgpYVlIW8fBMJ+xU J+G/NU0CXHhWuvibZoH2zhraf2KqDLYe1Pyl7CORWA72n7ouuIlSLDbTGSj+ZjMdeSsym7tA H9trE65h30/xxorgiHDQ7TjmZ8E3bHXhusHeszRu7XiIucHx82f7weP940dHBy9ODl7tBycH J0/3qf3fB4+y8SxPzi/KYO3RevCv+3tHwfOjr/cOD/68d3Lw/JCfenJwdHwS7L08+eb5UXB/ H2rN/XHv8eOj/ePjhx18i+nhv9T665XXK/In9Nf+/Roq3gHWR/cg6r6i47gbvNh79Ke9r/eD V/tHx9Dw69Q9/vyki/EH5sHu47BEwzDghxrZy3usexRPk8I9BR3rPnvefbwXfPN899nBP//5 +eG+fuVpWJRdUe+zfDd48vLp0wCdOZVR+m+RbbN7Eoej3eDp3uHXL6Hr958+/eMwAW3Xe/zZ wbN9N86t3qb+8hEhTnZPZmPTYVSMEarlD6hyGDHuwaNv9o6O908aX2JA0O5+OshAHd8N9g8f PX98cPi1fvxrNp5F3a9mSgMEH9ONNeaH3lQu3mQ3d6ybRa4fKkwsgBd0Bc0vyuVTvGNN+R6p 3U+gceu28rxQ6QgEWMarl+9t06nGeMEKIeuh8qZrzdr3nKa0vhRBdyj5BrHRDS6uJKXS8liH bAmSrlbGo5DC6MOocoUsRei2ix89MiQwMdnjPktQsIFN33JGMkBqL9G0c5WFwSRNwD7JF07T uxyjWQELmxCCCxjlIW/C5Txk4KiBMpjxGINfvMJDeLcR6gsHY6PqLblgkKYIAn43z/qoJxcX JGIfpBxkjdqTy3KgKoseQSZFoWeIouoXvOZEM/JgmLsS6WhAqG9JODZ3mwqpp7pHKCbBRoSh Nze04pAS2NKeBhummQ0n85IdwOjtrD3EXAgPZS+MYExKLtsm1nOk1xpVuGQA2EIjU85z+N1u YRTSeDeHoLXvlYxAXz+Y+xT8UCy34PvwNFYjuhRal1z5OeZcoObl0cOrfOg0Luq/mSjVA4i+ YRxFBs1CwytWTPGIWdOALK/ItwS6wNhuQcBUCxVZyutkiGW+gmVzayhoJSkYpcCMGJQW6KXF pHBrjc9xJ2C/GHnQo/rdZq+HvajadODHCDAOt1HPA7hQqQJFnyLkMCHOASOgGrxis+h9RZFj bizYGe05bAJ0EWoB2TsFmnDD9pw02MU0uOXW7lZLqQj4cbXhcmsZhjiofmxXNuVNhBoRjkQm UGJGqkU0kR+1MhbUtbiyCxN6szccokBoJNQcoKqi2hSFtlX4C7sBwq8yGQybS8kYndl0R9kF ascmdhxS2pAq0TiS8iLH/JoEY8QSSPlH/xSc6lKgWOpmD6FFNR5TtGAbLgOJ1pO0TIbijR1Q 5ahBjPDyYRUbwk5qLlANlfENOYzc1xsusiva/OE0TIZoN5MOcahMiyo43WjWWo/HCRV5wcvH 5TZXCq9SAsx5seFSf84bNSLMBCb4jYoqTvsANBXUPcShjrnhEs1iYRQqKB5UJKCakadybzBL YzJWNWVKG9pM/hHijzA1Zud0MWHUI9aPjfKUZBh/gc4tPvOsAYUAEWxmGL76OyaaqquW8QHN LgLfIG78HMAsHaotGr3LJrYPzAKWn69ghmtVZ4g8Ki36l5VL7lhxxiYI4TanlCF6ij+fk/zi yFkJb284JEoiQaASaZn9PCoq8e8wC9Reb047yijvKAveIroixMTYzBghTckQzQhdXPdS0IgY wrQxONwut0+vCVLxO4gr2gL/1GLZwRlP3GdndWAur6NemUxl16VLh6uQcyWiavY/ViRC4bso jfT8KTiL3AcE9nNgZpSj2xhVTxT/Q+BUwdt2VQh82Toh1XTa2rfzEKOqG2rT6oJtmFE5aSq+ 2tlbhva2PaMvAeDhzY01Kg+46oo3Kjovf0qmRneAED56zEjdkJzHYHb6UIzqWROqCCy4qQ3D keIS/uRSoPBobFSgchZ0DXMCV7kqU3ZC8U1ArQjWwiHka60TM8gxK6yOgRcEX6lIAQlz5KAj qdoilkGu0KhqwGFgvEv6NvJwgnZAqFfaDD7pjjPORPBdN1wGU48PCfdowUlRORt2DGWWYQZm orCDqZ415R5D/oNHK4oBQjzqSFIXxNWZ3ZpgyJWQ/Qcduob9SftmZ8v765ZTyU0fYeJvrJlP mlM55aU77vZRgY/8otveIB3cWGsF4mVqDtDUXBsYlYYzCzFtQ0JhpOnl2Vz3IU9rsJPD4G0R 64KxwVr5a9wPzR07NKLKKHz/IQ3Xzd73qVQ7dbOpU37TPd4tKIWVRcPSLtE5bwa7QRZBWs7/ O3mbBO/7s/JyxsT+WmcAGpmTDxYmrErj0LsknWaXHK/SDf364M1VK4S7bNlV4RSJs2zu43f8 P51ZK0e+ZrvliBTZ5NJc2r/wV7M60e0t/0+7JoT/2kBzGv8av00bSBazdNAsRxybb4yCgSGG PmdbtQUhLpIxg9eAZ72sytMa149UPYaLAo2Uw94k+8Uvxw1nBKvH2wSDXY5p22VXl3gY3EW3 hgEQYWF1fgQK5CJN4HV/QuBZiA5GXFgqiihAMxSUbWopO1X4Ad3HDmeMEYUVB24AbntuDFsK Kq34l3p7a9Zu5Ldkr6FIEDddvXRyV0s0nyGWMqYYwy7rwsQYXYD3ChFbzm4kglzbjRK84SdX XeSG71iq1Dev1Bl/7FcSH0maIGtCPVv1U1f39MqS+xcNaBiq1GntTrmKh0YuiLtm23/34P4s Lv6SZg+Vmeuq6VPUOgH4yswtLUBO0C4Zblk2DV7ZGA4LDBpwc74OSFeVLd9EURCGNUw5eYKP 3BugfcoUTk2HVyUVxSOXFAIc1b16MAPBxOhgVx1O4sGXdQFc8PWrF9KsQ3abpi7a56uzSHCm jRMYtU/gELEuZQ6xostl88SxEcIh8lT8fVzJzY4jsgOnVCcQQXDgFfBceR5UzgeVMXM5JyjP YuNtUBlZJ4qhxcQNiyoEbEMMDqRDYHpp4yx1w9ZpYrRiNVGSqKoy5myeqrVBrSDOpq1hXbXY GE1WfUuqFWCLsBIB16XENFsG26kB4DnTkS2XxUA54J89O/udTHBoFyTsqAHUUdxwFD33GuxH /Tyes+pzsEZonuKysTV7sYTNiEmTbu6WMrXI3u7bMJm/BN2HWo1t+QZ+dGKvsoeQLaewC4lX jdyWyDTcTevRk9pGQbCvU3sg1x0MKNbh73zrtWq9VT2ZTK+oJrdOwJJydh0cFR5orC5y5GaC RAJvLkS7VdPQYubxhZVNa5xB1JWLLKGMJbPV0qxZsvYJbFsZ/3GOCEkQBNoIp+C/d9OKSbb2 qtkYZKCaV3bVp3JLS9LWF2nmocvOi2Y4Gs6KzoNL82Ab7dt2ag6GVOeWtiUmdI3LZSbntjZa WSPFnI5VcwPbCO/Yvj2bFKWIgbYFEv1kCy/up7P4PaIoWjQEiaRzVvOM787T43zSDsLiAGv7 BsFuENy4ucmGiMUEnINYvOFAgF6/uempaGPDEFKbjFd5rIW69WhDuCuyhLPkHVvvzY0ZkRWc GlbmNfCTNqo4Hvntm3YD7OE1Zzp133XqoUVgWkzJ1dIiI0L0CZQmY8j4qUCPE+AlWl/SGMzr AEQ+GZ/nYdQUcv8pHlDi8hvmGoBsXY+LPYFPvLRVbpKcJdEkRwHVwdayPUQC3kCuqgcDsqkP GH2IkaZOIaJMBRR/GRFVSLHjcK1WKP4NoEZhp9BtRYDicbQOqIYEiCwBmCAaf6oboC1Uz0IF s65nmBhaYUDNowW0QjiVTs5jKhtpBi/DtR5PdHaYDTxFuHYeMd2hkAJdcJ4Yf1EE/XBwCeS3 epv9W8Hav6y3XB68k+7Zbf0keeclSkKeC/avzZBS35V37+g/b920vOjbvaPDg8OvdxW2HKPA MXoqG3GWbmp7SyPZPck4acYwu8JIPMDT+tm7UzQpESJtQS4otpwTXGNm855AacfZ7u8grtzB 6sjQMr0gmw3MpybZK0cE8O8Sjxo5iHTWwY/JFvHMOQiKAoliYq9AymQPgUa1reY4IVdnUjiA Bhe3gbmRvikFoS9hPHyk5LA2NYDUumDyyk7N96c4YkKYhNRgxpqDQpJTa6kRAHmaLO+oIJlJ X5PB7yt5HA2P9cyG7++4EyUJDBiPlIe2IEXK58jaXnW12v5MhQGswiMExs0uxbnHYvumTpC+ 8fdfI22Zal0iegjJW3cRt0PS8tqNYr2yLBiN074kTgSursJ/gEm/bSXQLjFKMfB7M90GLipU dvRpg6FNGCyCC9yQ7h+aG4lMofXN6G/91hlbM8r5Yk61c8/78161d5ABBBvlMtZ2QEa5BcHF zOqjV8eyOSjDl/Pi4H3WU7kwC0jf/RxoFIbVoh8CQXAE9xRu0rmzd+du2xpUduM8Ind3/tYl aGAbn70EN7fuuDGdyLHUEw9OeAw6xtm//yAwVyfpYXIJmt3uV6+qt7Ktdi/KdTgSc1UM1wu6 QVL+ay6VHUcFGY4iAsfaUaGLrRNAZQpYpIk5mBMjI83t5G07Fblz5BT5YH6ndtxNHuYp+jnx JqcwT/QUMJUArw+AXV5A0Q6zSgj2Gm6TG2vj2SdQvGMlAm/b/tCKyCkv3rXC9DnjIuUJYjbC 65zlvZCIk6NSqWn74IGVMhGbtoNyYksoqchMmzpY/oxEMomxGMf5CLP1MH0eege5ytrx6KSZ gDk5GbLywPOw9pNzLsRA8liJuPDmCKSTEiNUy6usBQZQ+unkL5Cc3ZMXWZlNs4bnLdt7Kauj Lf9LC363FAaQEDLydgqpLiGgmob55fz377nzpZaH5XIw2s97+9a24o7VZpkIl9wwv52q79ix MI/47focIeONU5AwT7WJEgsMQ7EZAAabR3NHa4ruboe09qDhH18D+leGTyPFjupluAIPoqro i4kgAA4spDMFHl7pDBdR2lBkiHOn3AxnLSD3Bw48zvUEA3mkC6Ds3AvQ2JsPEwKYINWOU48t LYGGlgXHw+EXsWRnFaZEaucU0KySG2TjmXKWyW2xwWo1ggkQ2Y37sr8fet9WxsoYAB3PLWg0 DCyWgPU+EsTKC7HVbzUMWceNeoVqiqpr09z6+TkPV+LoWJJjoh2KI4coSUcIKyrBS27E7Hr6 hL3UujtvO8XoUI4gx4CIHWMeE7q9rZnlY1H1rZrfoU0iG+7G2kX8bmjzS2BSvK9Kl3pivbUE ut1HWB8slBOesZlgHoy39O/mpjvQ3r6d06VKV+aSr53t/aOj50fKzYjgWwiifiYqMt1NbYD1 J2TKtuVtSKpEWnLWrsJC6sKRxiHFgMT+E6HUicg3dMBdFRL0+q64wE/D9M2npKa7RANfBUFL HuScOX7DwehJXKB0DBjrHioywTzYRqV6Nbl9GOf99Qr612guX69ozPhjRjA5ODw+2Xv6FCm/ fPH10d7jfSnqTq5zs9FMn4oWrYbXUBnrXNanjEXsOZrCnzMjwL+Hr94n8mCIT1QpO1nxZaE5 snyv8dwmP11PP4y8lt9rtDgQGuoBY18zGKQNlWWsAsjCGFCGOsU7eJwy62MJb28f5gSIA0im RvAvvHJndK3tOrpT8KFluUXwCksq49tj+xqbZfzn0dVAwKxQdXkYzrBzIHaBIkw7ZJRFlKfJ O/qpRbnEPtPxtOhSqgH63dxVJZYo+VZHOXv96LhqMNIATwigooJJ881o1dodXdi3RHgODbsZ UvD3OMQc/gMEenGV6LIwYjsoZgjZVqxmXqPhVuJFZUbp0gA1n5APQgfvYYhlY0zUoyzaymjI r0gYk5WSXihPDmC52Zx7Ya73+DKOEdUTsR8cDpAhAgs0NueKkzkOOMkIMhnI3ymYpBPCOJul ZfjO8GbF6W7c8HZxc8xufl4sF7I7DDYAs9kwD0/dxMoO1keHfI/x/3sV6GRxqVKlFwgBN6/G frrEWgyYrBI82sUgeppw6NK6qxFudjYemaE0jzIATH6teA9+CxgqECk+w+l+M+pBv9fWV/1B wo9X2xVZuK1yR75jQiwlx7oC4xhghHDv2MgYhtraukeUa7SxstMJCjaHeUfIHC4sKgaQrdZf wCJbJUsmnJSZ3a/mBp7a+Bcxo1fP2RqD34ksRNNfmyhYpBomTIJLr060vwOoCiSKo6VkSAqH ELhqgsQGrDM0yXDOA8F0eNQgBheCFWs+Z7igviMInt73MG7gEO77fM6X8KNL30m6FxaUc6eU s8B5f1YmsFenRpXIza5iACxWm5IR4EGYPYbdWQ3WVCKbi3f1l3OAswEsT1TZYlb0xmF5sW7B qVPcYrh9ZYSrFhXAI8cTEQTynEOhI/ZozpewtD/gpVEIH5ZZ8OhV9xJbVymdUvzSXDVOxZcD a2F0a3QK+06tpnIHNmwG651i3AxoeIjdVAIsmEe7bjZHijzmhowxd7R5cXqrgT3X4fAPcOJp NrIRYNvxtIeCnwhqm3hFdJPIStWiyEVGO6Exee3EXUm2Wv2b3L2qqk8CgumwLGwOILTTlMAA hzSs71KONkFWSjvW4R3kLknSOui05boyvVC+eFJyoV86NRnV665qi99a+RdK7oRS55W4pkcT 5G2Lhah8/BLt0JTAStNn581QM1PnUbWihAsCZYMRz2ZtAhH3H6bwB4/QMaPvi/zsFfOr0kCP 5sbigBjrIHUE8J9vCAoVDQp4+0PHGRNQ8B71mh0bcU7Zx5Uh2dNOtDFCYemI5EXVHaK8N55B HQXZHBYOk/xTRkYVlqFFgyg+C4TAGgYbrzsvOcVf4qe9r+MSWAiGKa2t+wQgDCpejsYRPVoj c5hddRxEigfoJ8Lc2GoaUlEi44KnHAnSn1WB+L15aCY/R97q5nZqGO4eH3uakdZLNj76IlgT cYjGdICcQ55CCuLfOGIB2y6bnf51+wyD649mgJHeG7DbHP/ZM/1unRFeCD0jPB3LDbOnVvIf OWS9Yaqj7vKXzaMvbK1PPmJGFuNTBByPawpx+d0LVfiJEnnHAHwMVRxIxMTys6gIuC8kswcF VRQSx1z1XO0k0ScA4c75MeVEUvtjQPhcVROvzXs9LCNaiLBhbra9Z7GNHLEnSyjRsergwnYg gBbHFalzVuYzH0WPjpy5h4iuFKdZq5JoeAlkYCUAx+8G8Vj30W+IduEqhLjxtqO4lmh3lTrs hoT2DKn8Nuc41rboEHapTIZsQLD99LNo9kf4BVHlABfGLJO5lvNm+4WzCNzSzvCXKdWTDWhD c/Q/VaCiG25k9QSanKCW5XciyLNUE8pcRqpwtdISuGqqrvwdAGpBSJ5NQy1xaANZ0TuF56FB kfFIe8YbElrhTZdQBXFcKpQXBoNJTjIWonE7+Xf+vLigQJoU1G6lsmmBXrn1ue6N51E8ukwT s/QAaRZPhtlPHZ31U32v3gXn7H6SIPxxi3/JveEiBDWnWuh/UQRsHOAa87QFz1srreOC89+4 6+ymUudhziRSnYcPFaD+udO27YxcHM5Jci3g2w0Trw7Vf8W0Y4W0/9ZIY7OfwiibfkizXhNx Z9UmWZUjnwtS7OYOffumnSx3R9xYI5mc8fznvm53pNwj6uUbayK2rxdr6wtpOcwhTwIF61Ui KeQqikmZoQCuZ1BzSw3yLN3oT0Zjzk/wLY0H6SCPGQnaZiZMAarOAoOQhbeIvUf4OzBWLQ33 oup9LZfBDcLuxvKibqWqIpncCbmiQcQnl6yZF2JXmGRht6SvVbLNbcg+Jf1mnYfjfGOd86hf m+wp1ssxMg88Jc5gKloPtz/7HDECnAxSIi8VXEk8wTIOUvWoKOVRvKjPlANnUcd27JaFAqGT tFyP0N8fDnljWcLShbVi3QgwFVe690o3OAyDPHt/kUXppLwmEh8MiTD4Ob78ELiWxr9eF+OP 00tJnPT75hjRC54QzwmrDOz/d3wZvr2GMhzjX5OL4Ycf4/RaKqP4NO/pgsJkk2XaIKNrmvI9 0R5c287OdhtX2OFmyTaFGgRYhRaKY4CTBX1O4PFQMTWP4G7dpTkvqj4novM88qhEaVwnEzz+ 6zSLfDq2kxFhAkeVyGVGA5FvJWGogwC+AEiKWXnAdcdYyXzmnSxndR7kk4SKxhEEDGUaej4J v1gGJVJdXQh6ShQPE3wncb2RelEx1y3GunW2q9EEo3ihIPGA65TNUNBgJxOlaIkArkvWiXts Jgg+HBrA8s9sdRpLileknWWj8F0ymowUTJKm+vcI9L5A2+dnIp8ghWE944VQb5ozYV7YctFs Nyd8CxIpnTvaCJaW57XxE7vD7lph9Tu7WIbPmQ2UZFEyCIqrOKboXaPCDKm+vYxKnDHfNzaB IR1GGagw0xcZm1sOD09eBEZLmgrclU3QI7BSeP8KcVwwu09bkWprZ9tqWjnKLVUVApruK7Ws bavZEsDeMHToLelAtZLDEAgriqPZyQkWdrEFBemeKmkBsWxv9QhLoRuqcVMzsNFKAeo0pEdS 4V82EieoAUjjXK7i3HCAsYPKYWUftONTSgI7kzJluubc6fNX+0evDva/RdEmRwwvur3Jkgth lVRQqpL8CUPDUJFJmpjLCTsYrJnN1pV6hhcIjcFgsNrYgsfC9h4HJUsKFdskOw8oshWwNs9U Q0VwgqySyAMEwNBne4enxwcn+6dPD45PPJw5jOP5ezCNzwFLWrDFXEjeMTglxZvGFTDwLoI8 y1aFpb5ntxQSEq5I4V8PLoO/sLOrKnPhoQ7k1d3g5Th7n+XpxxSv/H/7OQRh1WkJ14OLto7c rpfA3diASo7VOmjyqSWTQoTqcHZ6/j4ZV2FdulKQCNf/RQKhgrBb4dnVKLBB45JnWTuFfJG6 HFpQyLlFsj5AH5Tju26SQEEwZYg13wY0kSPDZZ+yTCOI253HrAB2XnfKWC1WVK8xQA3XUkVC U+DezuyC5xQNx4CKAGyBULxpkj6Fh46XMXPDg7bz3usC0gjud7z6wBGI1iCYtl75rlRxJuJ0 EZgbZEyQ6AtpPx5Z6E8HOSitN6prTlFoACtvODUg5DUqaI+TYgy2Kkkvt0k7Ro7asPqC3Hgw HfTgKSbqu+s39tSj2Zj9urgeCeslEN+G+63Syf/jy8+Xny8/X36+/Hz5+fLz5efLz5efLz9f fr78fPn58vPl58vPl58vP19+vvx8+fny8+Xny8+Xny8/n/jz/wHdiU9nAFAFAA== --GZVR6ND4mMseVXL/-- From Dan@feld.cvut.cz Mon Feb 11 21:17:46 2002 From: Dan@feld.cvut.cz (Dan Ohnesorg) Date: Mon, 11 Feb 2002 22:17:46 +0100 Subject: [Mailman-Developers] Problems with Cookie.py while upgrading Message-ID: <20020211211746.GO4569@ohnesorg.cz> One beta tester of czech localization for mailman has me reported this bug, which I am trying to translate into English. Mailman 2.0 uses its own modules Cookie.py and imports Cookie class from it. Mailman 2.1 uses this module from Python 2.2 and renames there presented class from BasicCookie to Cookie. And the problem is, that update script will try to remove the unused Cookie.py, but it will first import it (indirectly) so the whole update scrtipt fails to execute and has no possibility to delete the unused file. I hope, you will know what I mean. cheers dan -- ----------------------------------------------------------- / Dan Ohnesorg Dan@ohnesorg.cz \ < Jinočanská 7 252 19 Rudná u Prahy > \ tel: +420 311 679679 +420 311 679976 fax: +420 311 679311 / ----------------------------------------------------------- From barry@zope.com Tue Feb 12 01:10:59 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 11 Feb 2002 20:10:59 -0500 Subject: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ? References: <200202052336.PAA00948@utopia.West.Sun.COM> <20020211175901.A15319@monde-diplomatique.fr> Message-ID: <15464.27555.383406.744200@anthem.wooz.org> >>>>> "F" == Fil writes: F> Dan, I have used your patched version for a while, and the F> result is still very random. Some lists don't ever VERP, some F> others do. I can't find a reason. How are mlist.post_id F> modified ? I figured out the problem and have a mostly working patch. There's a deeper issue involved that I want to fix before I check everything in. Watch for it later tonight (my time I see the basic "how do I let the right people post to this announce list automatically" question often enough to indicate that there is a perceived need. Let's put digital signature technology to work. For some post 2.1 release (and probably patchable into 2.1 by suitable people), extend the privacy options to include: List (two columns...duplicate senders probably allowed for the case of a work key and a home key or an assistant's key for authorized forging, or whatever): Automatically post messages from these senders PROVIDED they are digitally signed using the key listed for the sender. Checkbox: Automatically and silently reject (with logging) any message not from a listed sender and properly signed. Variations (not silently rejected, etc, if desired...but sending a rejection message gives the would-be rogue poster information). It seems to me that this can be turned into a suitable solution to the auto-moderated announce list desire, without a whole lot of coding. I didn't see such a feature request on SourceForge...if I missed it I apologize (I've spent no more than 15 minutes driving SourceForge). --John (whose site has about 5 lists which would benefit from this feature) OA (Obligatory acronym): SAMAL -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From dale@newfield.org Tue Feb 12 06:35:05 2002 From: dale@newfield.org (Dale Newfield) Date: Tue, 12 Feb 2002 01:35:05 -0500 (EST) Subject: [Mailman-Developers] Future: Safe Auto-moderated Announce List In-Reply-To: Message-ID: On Mon, 11 Feb 2002, John W Baxter wrote: > I see the basic "how do I let the right people post to this announce list > automatically" question often enough to indicate that there is a perceived > need. OK. > Let's put digital signature technology to work. I think we'd get quite a bit of bang for the effort just adding a checkbox to the admindb page saying "and add this sender to auto-approve list?" So it's easy to moderate a person's messages as long as you want, and then also easy to say "yeah--approve this and all future posts from this person.") -Dale --- Dale Newfield "To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -T. Roosevelt From fil@rezo.net Tue Feb 12 10:53:01 2002 From: fil@rezo.net (Fil) Date: Tue, 12 Feb 2002 11:53:01 +0100 Subject: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ? In-Reply-To: =?iso-8859-1?Q?=3C15464=2E27555=2E383406?= =?iso-8859-1?B?Ljc0NDIwMEBhbnRoZW0ud29vei5vcmc+OyBmcm9tIGJhcnJ5QHpvcGUu?= =?iso-8859-1?Q?com_on_lun=2C_f=E9v?= 11, 2002 at 08:10:59 -0500 References: <200202052336.PAA00948@utopia.West.Sun.COM> <20020211175901.A15319@monde-diplomatique.fr> <15464.27555.383406.744200@anthem.wooz.org> Message-ID: <20020212115301.A23803@monde-diplomatique.fr> @ Barry A. Warsaw : > I figured out the problem and have a mostly working patch. There's a > deeper issue involved that I want to fix before I check everything in. > Watch for it later tonight (my time > If you're interested: Because OutgoingRunner.py doesn't need a list > lock to do its work, it loads the MailList state once the first time > it needs that list. It never reloads it, so it never sees the post_id > get incremented. > > The quick fix is to move the occasional VERP calculation into > ToOutgoing.py, which is part of the munge-and-moderate pipeline, and > thus will always have the up-to-date list data. > > A related, longer term fix is to make sure that OutgoingRunner > occasionally reloads the list data, but that's a bit tricky because we > can't count on reference counting (maybe we could use Python2.1's > weakrefs?) and we don't yet have an API to invalidate the MailList's > state. Is that really necessary? If it imposes some overhead, you could use .... not (int(random() * mm_cfg.VERP_DELIVERY_INTERVAL)): ... -- Fil From barry@zope.com Tue Feb 12 18:24:08 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Feb 2002 13:24:08 -0500 Subject: [Mailman-Developers] Potential risk of VERP? Message-ID: <15465.24008.930915.373871@anthem.wooz.org> I just thought of a potential risk to VERPing, and I'd like to get some feedback from you all about it. Let's say I run a mailing list foo@python.org and someone like (oh, I dunno) yahoogroups subscribes to the list and provides subscription services of its own. I.e. people can subscribe to foo@yahoogroups.com and they'll get all the messages posted to foo@python.org. Yes, we've seen this happen quite a bit. Now, suppose someone on foo@yahoogroups.com starts bouncing, and we're VERPing. Won't our Mailman think that foo@yahoogroups.com is the bouncing member? In a sense they are, but I can see an attack vector: - subscribe to some downstream reflector for a group, e.g. foo@yahoogroups.com - purposely set your address to bounce - foo@yahoogroups.com gets disabled, thus shutting off a large list of recipients. Or will/should yahoogroups rewrite the envelope sender for /its/ downstream members? -Barry From peterw@usa.net Tue Feb 12 18:54:22 2002 From: peterw@usa.net (Peter Watkins) Date: Tue, 12 Feb 2002 13:54:22 -0500 Subject: [Mailman-Developers] Potential risk of VERP? In-Reply-To: <15465.24008.930915.373871@anthem.wooz.org>; from barry@zope.com on Tue, Feb 12, 2002 at 01:24:08PM -0500 References: <15465.24008.930915.373871@anthem.wooz.org> Message-ID: <20020212135422.A13201@usa.net> On Tue, Feb 12, 2002 at 01:24:08PM -0500, Barry A. Warsaw wrote: > Let's say I run a mailing list foo@python.org and someone like (oh, I > dunno) yahoogroups subscribes to the list and provides subscription > services of its own. > Now, suppose someone on foo@yahoogroups.com starts bouncing, and we're > VERPing. Won't our Mailman think that foo@yahoogroups.com is the > bouncing member? > Or will/should yahoogroups rewrite the envelope sender for /its/ > downstream members? They should do that, and also do things like discard all the Received headers so that yahoo subscribers don't bouce the mail due to "too many hops" restrictions on downstream MTAs. In a sense, whether a mailing list package uses VERP or provides individualized X-List headers (which should also be manipulated), or visible URLs in the message body, the reality is that many mailing list packages send out messages whose contents are intended for a specific indivdual. Anyone who wants to "reflect" a list will need to deal with any such customized headers or content if they want to keep their subscribers happy. This problem affects more than simply VERPed messages, and it's not the primary/top/initial mailing list's responsibility to "fix" the problem, IMO. -Peter -- We must all learn to live together as brothers, or we will all perish as fools. - Dr Martin Luther King, Jr From spacey-mailman@lenin.nu Tue Feb 12 20:20:28 2002 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Tue, 12 Feb 2002 12:20:28 -0800 Subject: [Mailman-Developers] Potential risk of VERP? In-Reply-To: <15465.24008.930915.373871@anthem.wooz.org> References: <15465.24008.930915.373871@anthem.wooz.org> Message-ID: <20020212202028.GC17274@lenin.nu> On Tue, Feb 12, 2002 at 01:24:08PM -0500, Barry A. Warsaw wrote: > - subscribe to some downstream reflector for a group, > e.g. foo@yahoogroups.com > > - purposely set your address to bounce > > - foo@yahoogroups.com gets disabled, thus shutting off a large list of > recipients. > > Or will/should yahoogroups rewrite the envelope sender for /its/ > downstream members? Yeah. Either they should play nice and re-propegate it as their own list (forwarding messages to the list upstream to the real server) or play really nice and just subscribe members to your list and implement the very good x-verp smtp verb. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From barry@zope.com Tue Feb 12 22:55:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Feb 2002 17:55:05 -0500 Subject: [Mailman-Developers] Pipermail replacement? Zest! Message-ID: <15465.40265.533837.712733@anthem.wooz.org> --vFfg2VKFHo Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit The just completed Python conference was quite enjoyable and inspiring as usual. One of the coolest things demoed was Ka-Ping's new archiving project, which he's named Zest. I'm excited that Zest could one day provide a replacement for Pipermail, so I encourage interested parties to check out Ping's work and join the Zest list. -Barry --vFfg2VKFHo Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: Delivered-To: barry@mail.wooz.org Received: from mail.python.org (mail.python.org [63.102.49.29]) by mail.wooz.org (Postfix) with ESMTP id 8906AD3827 for ; Tue, 12 Feb 2002 02:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) by mail.python.org with esmtp (Exim 3.21 #1) id 16aXde-0005vn-00; Tue, 12 Feb 2002 02:46:06 -0500 Received: from [207.235.5.74] (helo=server1.lfw.org) by mail.python.org with esmtp (Exim 3.21 #1) id 16aXd5-0005cm-00 for python-dev@python.org; Tue, 12 Feb 2002 02:45:32 -0500 Received: from localhost (ping@localhost) by server1.lfw.org (8.11.6/8.11.6) with ESMTP id g1C7jVZ03972 for ; Tue, 12 Feb 2002 01:45:31 -0600 Message-ID: Errors-To: python-dev-admin@python.org Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Python core developers List-Unsubscribe: , List-Archive: From: Ka-Ping Yee Sender: python-dev-admin@python.org To: Subject: [Python-Dev] Zest Date: Tue, 12 Feb 2002 01:45:30 -0600 (CST) X-BeenThere: python-dev@python.org X-Mailman-Version: 2.0.8 (101270) A few people have expressed interest in the mail-archiving project i mentioned on Developer's Day (see http://lfw.org/python/pydev-sample for some sample output). I've registered a SourceForge project named "Zest" under which i'll be doing this work, and created a mailing list for anyone who wants to discuss it. Please direct any thoughts and comments about Zest to zest-devel@lists.sf.net. I don't expect to be blabbing a great deal on the list until i've got a better prototype ready, but it's good to have a place for the project to reside, so that ideas and conversations don't get lost. (Thanks for the prod, Barry.) If you're interested, please join the list: http://lists.sf.net/lists/listinfo/zest-devel Sorry for the diversion. -- ?!ng _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev --vFfg2VKFHo-- From barry@zope.com Tue Feb 12 23:02:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 12 Feb 2002 18:02:11 -0500 Subject: [Mailman-Developers] MM2.1 playground on python.org Message-ID: <15465.40691.159516.770726@anthem.wooz.org> I've finally gotten Mailman 2.1-cvs up on python.org, and co-habitating with the production MM2.0.8 installation. My thanks to Nigel Metheringham for helping jump start the necessary Exim config magic (captured in README.EXIM in cvs now). This should give us a platform to play with various bits of the interface and configuration. Right now I don't have a public list that I can give out the admin password for, but still, I encourage you to subscribe to the Playground list and watch all my tests messages. :) Visit http://mail.python.org/mailman-21/listinfo/playground or send a message to playground-join@python.org to start the subscription dance. Also, take a look to the new mime-scrubbing archiver stuff, e.g.: http://mail.python.org/pipermail-21/playground/2001-October/000001.html If that second attachment looks funny, it's because I don't have a ponytail anymore. :) -Barry From che@debian.org Wed Feb 13 03:01:19 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 13 Feb 2002 12:01:19 +0900 Subject: [Mailman-Developers] MM2.1 playground on python.org In-Reply-To: <15465.40691.159516.770726@anthem.wooz.org> (barry@zope.com's message of "Tue, 12 Feb 2002 18:02:11 -0500") References: <15465.40691.159516.770726@anthem.wooz.org> Message-ID: <87lmdym6f4.fsf@nausicaa.interq.or.jp> Barry, I signed up for the playground and selected Japanese as my language. However, the confirmation mail is either rilly rilly slow, or isn't coming. (It's only been about 10 minutes since I signed up, but it probably should have come by now). Can you check your logs to see what happened? Ben -- Brought to you by the letters I and A and the number 15. "He's like.. some sort of.. non-giving up.. school guy!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From barry@zope.com Wed Feb 13 06:20:54 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 13 Feb 2002 01:20:54 -0500 Subject: [Mailman-Developers] MM2.1 playground on python.org References: <15465.40691.159516.770726@anthem.wooz.org> <87lmdym6f4.fsf@nausicaa.interq.or.jp> Message-ID: <15466.1478.122250.652333@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> I signed up for the playground and selected Japanese as my BG> language. BG> However, the confirmation mail is either rilly rilly slow, or BG> isn't coming. (It's only been about 10 minutes since I signed BG> up, but it probably should have come by now). BG> Can you check your logs to see what happened? Yup, there's a traceback in logs/error (attached below). Probably due to the lack of installed Japanese codecs. I'll have to make Mailman robust against this situation, and then install the codec on python.org. Tomorrow though... -Barry From che@debian.org Wed Feb 13 06:35:45 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 13 Feb 2002 15:35:45 +0900 Subject: [Mailman-Developers] Exim setup and "mailman" local user vs. list Message-ID: <87n0ydlwhq.fsf@nausicaa.interq.or.jp> The INSTALL docs suggest that you create a "mailman" list where all the password reminders will come from. I did that on an exim system, then followed the instructions to add sections to my exim.conf; most of the mailman-created aliases are automatically then available, except for "mailman", since I have a local user! ben@list:~/src/mailman$ /usr/sbin/exim -v -bt mailman mailman@list.interq.or.jp deliver to mailman in domain list.interq.or.jp director = localuser, transport = local_delivery ben@list:~/src/mailman$ /usr/sbin/exim -v -bt mailman-request user "mailman-request" for file existence test not found mailman-request@list.interq.or.jp deliver to mailman in domain list.interq.or.jp director = mm21_director, transport = mm21_transport ben@list:~/src/mailman$ /usr/sbin/exim -v -bt mailman-bounces user "mailman-bounces" for file existence test not found mailman-bounces@list.interq.or.jp deliver to mailman in domain list.interq.or.jp director = mm21_director, transport = mm21_transport Should we add instructions to work around this, or should the README.EXIM be changed? Ben -- Brought to you by the letters G and B and the number 7. "A baloo is a bear." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From barry@zope.com Wed Feb 13 06:35:41 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 13 Feb 2002 01:35:41 -0500 Subject: [Mailman-Developers] MM2.1 playground on python.org References: <15465.40691.159516.770726@anthem.wooz.org> <87lmdym6f4.fsf@nausicaa.interq.or.jp> <15466.1478.122250.652333@anthem.wooz.org> Message-ID: <15466.2365.671430.465315@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: BAW> Yup, there's a traceback in logs/error (attached below). -Barry -------------------- snip snip -------------------- Feb 12 21:52:07 2002 (21302) Uncaught runner exception: unknown encoding Feb 12 21:52:07 2002 (21302) Traceback (most recent call last): File "/usr/local/mailman-2.1/Mailman/Queue/Runner.py", line 114, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman-2.1/Mailman/Queue/Runner.py", line 162, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman-2.1/Mailman/Queue/OutgoingRunner.py", line 59, in _di spose func(mlist, msg, msgdata) File "/usr/local/mailman-2.1/Mailman/Handlers/SMTPDirect.py", line 79, in proc ess msgtext = msg.as_string(unixfrom=0) File "/usr/local/lib/python2.1/site-packages/email/Message.py", line 85, in as _string g(self, unixfrom=unixfrom) File "/usr/local/lib/python2.1/site-packages/email/Generator.py", line 83, in __call__ self._write(msg) File "/usr/local/lib/python2.1/site-packages/email/Generator.py", line 104, in _write self._dispatch(msg) File "/usr/local/lib/python2.1/site-packages/email/Generator.py", line 134, in _dispatch meth(msg) File "/usr/local/lib/python2.1/site-packages/email/Generator.py", line 228, in _handle_text payload = cset.body_encode(payload) File "/usr/local/lib/python2.1/site-packages/email/Charset.py", line 304, in b ody_encode s = self.convert(s) File "/usr/local/lib/python2.1/site-packages/email/Charset.py", line 196, in c onvert return unicode(s, self.input_codec).encode(self.output_codec) LookupError: unknown encoding From che@debian.org Wed Feb 13 07:27:50 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 13 Feb 2002 16:27:50 +0900 Subject: [Mailman-Developers] MM2.1 playground on python.org In-Reply-To: <15466.1478.122250.652333@anthem.wooz.org> (barry@zope.com's message of "Wed, 13 Feb 2002 01:20:54 -0500") References: <15465.40691.159516.770726@anthem.wooz.org> <87lmdym6f4.fsf@nausicaa.interq.or.jp> <15466.1478.122250.652333@anthem.wooz.org> Message-ID: <878z9xlu2x.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BAW> Yup, there's a traceback in logs/error (attached below). BAW> Probably due to the lack of installed Japanese codecs. I'll BAW> have to make Mailman robust against this situation, and then BAW> install the codec on python.org. I thought I had done that in my latest patch.. hrm. Well, I guess the best thing to do in the case of Japanese is to just send mails in English if the Japanese codecs are not installed. Sending mails in broken EUC-JP (long headers will not work) is not really an option. So we should put in a hacklet for Japanese and Chinese to send internally generated emails in English if the codecs are not found. Ben -- Brought to you by the letters Z and V and the number 8. "You should be glad you don't have diaper rash. Mah Jongg." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From jason-list-mailman-developers@mastaler.com Wed Feb 13 18:18:03 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 13 Feb 2002 11:18:03 -0700 Subject: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: <15465.40265.533837.712733@anthem.wooz.org> (barry@zope.com's message of "Tue, 12 Feb 2002 17:55:05 -0500") References: <15465.40265.533837.712733@anthem.wooz.org> Message-ID: After looking at the Zest sample output, I'd have to say I still like pipermail's output better. I think pipermail is fine, it just lacks search capability which is the only reason I still use Wilma to archive my lists (see http://mla.libertine.org/tmda-users for a sample). -- (http://tmda.sourceforge.net/) From jason-list-mailman-developers@mastaler.com Wed Feb 13 18:35:28 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Wed, 13 Feb 2002 11:35:28 -0700 Subject: [Mailman-Developers] mylist-subscribe / mylist-unsubscribe Message-ID: I noticed there are new "robot addresses" in MM 2.1 to ease subscribing and unsubscribing. mylist-join@mysite mylist-leave@mysite Great idea, but why not -subscribe and -unsubscribe as is already done in ezmlm? I actually get *allot* of messages sent to mylist-subscribe due to people mistakenly thinking that my lists are managed by ezmlm. -- (http://tmda.sourceforge.net/) From chuqui@plaidworks.com Mon Feb 18 03:20:03 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 17 Feb 2002 19:20:03 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... Message-ID: Interesting article on slashdot: Basically, DSLreports did a test, and found that e-mail addresses posted on a web site could start seeing spam in as little as 8 hours. I mention it for two reasons. One, since mail lists manage e-mail addresses (and archives of e-mail addresses), it is yet antother indication of just why we have to be careful about presenting and disclosing that stuff. And second, since one of the addresses presented and disclosed is that of the admin, we really need to come up with ways that allow newbies to contact an admin without easily disclosing addresses to spammers. And, unfortunately, the security problems with formmail.pl have shown THAT isn't really the answer... Chuq -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. Very funny, Scotty. Now beam my clothes down here, will you? From lm@bitmover.com Mon Feb 18 03:39:05 2002 From: lm@bitmover.com (Larry McVoy) Date: Sun, 17 Feb 2002 19:39:05 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from chuqui@plaidworks.com on Sun, Feb 17, 2002 at 07:20:03PM -0800 References: Message-ID: <20020217193905.J24676@work.bitmover.com> > I mention it for two reasons. One, since mail lists manage e-mail addresses > (and archives of e-mail addresses), it is yet antother indication of just > why we have to be careful about presenting and disclosing that stuff. Without in any way discouraging those efforts, isn't it somewhat futile? It seems that the area for improvement is on the receiving end filtering technology. Or am I missing something? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From chuqui@plaidworks.com Mon Feb 18 03:40:54 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 17 Feb 2002 19:40:54 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020217193905.J24676@work.bitmover.com> Message-ID: On 2/17/02 7:39 PM, "Larry McVoy" wrote: > Without in any way discouraging those efforts, isn't it somewhat futile? > It seems that the area for improvement is on the receiving end filtering > technology. Or am I missing something? That you can't get 100% success is no excuse for not trying -- or making it easy. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From lm@bitmover.com Mon Feb 18 03:48:28 2002 From: lm@bitmover.com (Larry McVoy) Date: Sun, 17 Feb 2002 19:48:28 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from chuqui@plaidworks.com on Sun, Feb 17, 2002 at 07:40:54PM -0800 References: <20020217193905.J24676@work.bitmover.com> Message-ID: <20020217194828.K24676@work.bitmover.com> On Sun, Feb 17, 2002 at 07:40:54PM -0800, Chuq Von Rospach wrote: > On 2/17/02 7:39 PM, "Larry McVoy" wrote: > > > Without in any way discouraging those efforts, isn't it somewhat futile? > > It seems that the area for improvement is on the receiving end filtering > > technology. Or am I missing something? > > That you can't get 100% success is no excuse for not trying -- or making it > easy. First, I tried to be clear that I wasn't saying "don't try". In case that's not clear "please do try to keep spam down". OK? I'm on your side, I'm not trying to argue with you at all. Second, the point is that even if mailman is 100% perfect, it's not at all clear that that would result in even 1% less spam hitting home. If that's even remotely close, then it seems like efforts could be better spent on screening technology. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From chuqui@plaidworks.com Mon Feb 18 04:02:11 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 17 Feb 2002 20:02:11 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020217194828.K24676@work.bitmover.com> Message-ID: On 2/17/02 7:48 PM, "Larry McVoy" wrote: > Second, the point is that even if mailman is 100% perfect, it's not > at all clear that that would result in even 1% less spam hitting home. > If that's even remotely close, then it seems like efforts could be better > spent on screening technology. You can't assume your admins are going to want/have screening technology, unless you build it into mailman. And I don't think Mailman can simply say "hey, that's some other program's problem". We need to find ways to not become an easy source for the harvester machines. I DO know from my sites that addresses published ONLY as mailman admins get harvested and hit by spam. To me, it's more an issue of "we can't be part of the problem", not "we're the solution". I have a couple of admins who want their addresses removed from all public pages -- which I've refused to do, because I think the need for access by a user in trouble trumps the admin's privacy. I think at least one of those admins has solved it by setting up an admin-specific account, and redirecting it to /dev/null, which, if I ever definitely catch him doing so, will get him in trouble... But at the same time -- I don't blame him. And Mailman has a responsibility to do something about that, the way we (as admins) have a responsibility ot our users not to make them easy fodder for the harvesters by publishing archives in an easy to harvest format... -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From howanitz@nindo.com Mon Feb 18 04:16:59 2002 From: howanitz@nindo.com (Keith Howanitz) Date: Sun, 17 Feb 2002 22:16:59 -0600 (CST) Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: Message-ID: On Sun, 17 Feb 2002, Chuq Von Rospach wrote: > On 2/17/02 7:48 PM, "Larry McVoy" wrote: > > > Second, the point is that even if mailman is 100% perfect, it's not > > at all clear that that would result in even 1% less spam hitting home. > > If that's even remotely close, then it seems like efforts could be better > > spent on screening technology. > > You can't assume your admins are going to want/have screening technology, > unless you build it into mailman. And I don't think Mailman can simply say > "hey, that's some other program's problem". We need to find ways to not > become an easy source for the harvester machines. I DO know from my sites > that addresses published ONLY as mailman admins get harvested and hit by > spam. [SNIP] > But at the same time -- I don't blame him. And Mailman has a responsibility > to do something about that, the way we (as admins) have a responsibility ot > our users not to make them easy fodder for the harvesters by publishing > archives in an easy to harvest format... I would just like to put in one thought... I like the whole small is beautiful philosophy. Maybe as you add more features, we can add some of these things as distict modules? I still feel the pipe is one of the best things *NIX has going for it. I worry about feature creap for a number of reasons. Just a thought. -Keith From chuqui@plaidworks.com Mon Feb 18 04:28:08 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 17 Feb 2002 20:28:08 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: Message-ID: On 2/17/02 8:16 PM, "Keith Howanitz" wrote: > I would just like to put in one thought... I like the whole small is > beautiful philosophy. Maybe as you add more features, we can add some of > these things as distict modules? I still feel the pipe is one of the best > things *NIX has going for it. I worry about feature creap for a > number of reasons. Just a thought. Then you probably shouldn't be using a list server at all. Simply have people send you admin requests, and manually add and delete them from the alias file. Why complicate things? Oh -- to make your life easier. That's different. (grin) -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From jwm@plain.co.nz Mon Feb 18 04:39:56 2002 From: jwm@plain.co.nz (John Morton) Date: Mon, 18 Feb 2002 17:39:56 +1300 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: References: Message-ID: <20020218043957.9EB4713D4D@registry.e-servicesltd.co.nz> On Monday 18 February 2002 17:02, Chuq Von Rospach wrote: > On 2/17/02 7:48 PM, "Larry McVoy" wrote: > > Second, the point is that even if mailman is 100% perfect, it's not > > at all clear that that would result in even 1% less spam hitting home. > > If that's even remotely close, then it seems like efforts could be better > > spent on screening technology. > To me, it's more an issue of "we can't be part of the problem", not "we're > the solution". I have a couple of admins who want their addresses removed > from all public pages -- which I've refused to do, because I think the need > for access by a user in trouble trumps the admin's privacy. I think at > least one of those admins has solved it by setting up an admin-specific > account, and redirecting it to /dev/null, which, if I ever definitely catch > him doing so, will get him in trouble... If they can set up admin specific accounts that redirect to /dev/null, then they can set up procmail to drop HTML mail, and say they're doing so anywhere they're advertising the admin email address. That would filter 90% of the spam they're likely to recieve for a start. Something that mailman can help with, though - assistance in filtering based on whether the sender is joined to a list that the admin account is tied to. Just a simple boolean is/isn't on the list should be enough; leave the policy to the delivery agent/user. John From chuqui@plaidworks.com Mon Feb 18 04:56:21 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 17 Feb 2002 20:56:21 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218043957.9EB4713D4D@registry.e-servicesltd.co.nz> Message-ID: On 2/17/02 8:39 PM, "John Morton" wrote: > If they can set up admin specific accounts that redirect to /dev/null, then > they can set up procmail to drop HTML mail, and say they're doing so anywhere > they're advertising the admin email address. That would filter 90% of the > spam they're likely to recieve for a start. And a bunch of legitimate mail, since more and more users are using HTML, and more and more systems are set up to send it by default. Not a solution, unless you primarily admin to geeks. > Something that mailman can help with, though - assistance in filtering based > on whether the sender is joined to a list that the admin account is tied to. > Just a simple boolean is/isn't on the list should be enough; leave the policy > to the delivery agent/user. And how odes that does the "I'm trying to subscribe and can't make it work!" and "My stupid IS department changed my address again and I need help!" problems? -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! From jwm@plain.co.nz Mon Feb 18 05:25:09 2002 From: jwm@plain.co.nz (John Morton) Date: Mon, 18 Feb 2002 18:25:09 +1300 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: References: Message-ID: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> On Monday 18 February 2002 17:56, Chuq Von Rospach wrote: > On 2/17/02 8:39 PM, "John Morton" wrote: > > If they can set up admin specific accounts that redirect to /dev/null, > > then they can set up procmail to drop HTML mail, and say they're doing so > > anywhere they're advertising the admin email address. That would filter > > 90% of the spam they're likely to recieve for a start. > > And a bunch of legitimate mail, since more and more users are using HTML, > and more and more systems are set up to send it by default. Not a solution, > unless you primarily admin to geeks. It's better than > /dev/null :-). Let's face it - if you're going to publish an admin address to help the lowest common denominator of netizen, then you can't munge it, so it will get spam. Mailman doesn't provide filtering for email accounts, nor should it. So the best you can do is advise admins of good filtering software, and best practice ways of using it. Droping html mail happens to be one practice that works pretty well for a given type of list membership. > > Something that mailman can help with, though - assistance in filtering > > based on whether the sender is joined to a list that the admin account is > > tied to. Just a simple boolean is/isn't on the list should be enough; > > leave the policy to the delivery agent/user. > > And how odes that does the "I'm trying to subscribe and can't make it > work!" It doesn't. But you can put all the requests from list members into another folder, or give them a higher priority. It all helps. If you need to prioritize subscription problems then you could use a feedback form, and maybe Mailman should provide one. > "My stupid IS department changed my address again and I need > help!" problems? I never understood why mailman wasn't changed to allow users to change there own addresses years ago. Being able to add valid receiving addresses would help, too. That is also something mailman can help with. John From chuqui@plaidworks.com Mon Feb 18 05:37:31 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 17 Feb 2002 21:37:31 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> Message-ID: On 2/17/02 9:25 PM, "John Morton" wrote: > It's better than > /dev/null :-). Let's face it - if you're going to publish > an admin address to help the lowest common denominator of netizen, then you > can't munge it, so it will get spam. I'm not sure I agree. But that's the point -- because it's not easy or obvious is no reason not to try. And because it's not likely to be a 100% soilution is no reason to not do what you can. > I never understood why mailman wasn't changed to allow users to change there > own addresses years ago. Being able to add valid receiving addresses would > help, too. That is also something mailman can help with. All it takes is code. Volunteering? (grin) -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! From james@xanth.co.uk Mon Feb 18 10:14:07 2002 From: james@xanth.co.uk (James McDonald) Date: Mon, 18 Feb 2002 10:14:07 -0000 Subject: [Mailman-Developers] Duplicates, mostly Message-ID: <323F4D4CAF7DAB4D8BEF1B815492DBFEA9AD@asp.cryotube.org> Hey folks, Having just spent a good few weeks with a crowbar retrofitting Mailman to our hideous old Majordomo setup, it all appears to be working rather nicely. There is only one exception... dreaded duplicates. I noticed a patch posted a few months back (by Ben Gerzfield) for the CVS version, but given that this is a production system for a large client I'd prefer to keep it stable. Is there any way this duplicate avoidance can be easily grafted on to 2.0.8? Cheers, James From stone@hkust.se Mon Feb 18 10:48:28 2002 From: stone@hkust.se (Magnus Stenman) Date: Mon, 18 Feb 2002 11:48:28 +0100 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... References: Message-ID: <3C70DBFC.7C11DDAA@hkust.se> Chuq Von Rospach wrote: > > Interesting article on slashdot: > > > > Basically, DSLreports did a test, and found that e-mail addresses posted on > a web site could start seeing spam in as little as 8 hours. > > I mention it for two reasons. One, since mail lists manage e-mail addresses > (and archives of e-mail addresses), it is yet antother indication of just > why we have to be careful about presenting and disclosing that stuff. And > second, since one of the addresses presented and disclosed is that of the > admin, we really need to come up with ways that allow newbies to contact an > admin without easily disclosing addresses to spammers. And, unfortunately, > the security problems with formmail.pl have shown THAT isn't really the > answer... Maybe not unpatched formmail, but a form for contacting a list admin can be much more secure than that; it only needs to know the list name to be able to send mail to the admin. Hard to use that for spamming. Obscuring mail archives (possibly making them worthless as soon as the "un-obscurer" no longer functions) is IMHO not the way to go /magnus > > Chuq > > -- > Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) > Will Geek for hardware. > > Very funny, Scotty. Now beam my clothes down here, will you? > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From dm-temp-310102@nyc.rr.com Mon Feb 18 12:12:42 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Mon, 18 Feb 2002 07:12:42 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> Message-ID: <001001c1b875$944ccc70$56296c42@damien> There are some very simple solutions to the problem of email harvesting. The first is to whitelist all mail. Anything not on the whitelist (be it list membership, or whatever) is responded to with an invitation to fill in a web based form to join the whitelist, the mail is held in abeyance until the whitelist is joined. You can hide the whitelist join function behind a POST operation, but can also do a reverse turing test of the 'type what you read in the image above' type to verify that it's a human joining the list. The second is to avoid publishing email addresses to the world in machine readable form. There are several approaches to this, including the use of javascript email decryptors and/or publishing email addresses as rendered images. -----Original Message----- From: mailman-developers-admin@python.org [mailto:mailman-developers-admin@python.org] On Behalf Of John Morton Sent: Monday, 18 February 2002 00:25 To: Chuq Von Rospach Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Interesting study -- spam on posted addresses... On Monday 18 February 2002 17:56, Chuq Von Rospach wrote: > On 2/17/02 8:39 PM, "John Morton" wrote: > > If they can set up admin specific accounts that redirect to > > /dev/null, then they can set up procmail to drop HTML mail, and say > > they're doing so anywhere they're advertising the admin email > > address. That would filter 90% of the spam they're likely to recieve > > for a start. > > And a bunch of legitimate mail, since more and more users are using > HTML, and more and more systems are set up to send it by default. Not > a solution, unless you primarily admin to geeks. It's better than > /dev/null :-). Let's face it - if you're going to publish an admin address to help the lowest common denominator of netizen, then you can't munge it, so it will get spam. Mailman doesn't provide filtering for email accounts, nor should it. So the best you can do is advise admins of good filtering software, and best practice ways of using it. Droping html mail happens to be one practice that works pretty well for a given type of list membership. > > Something that mailman can help with, though - assistance in > > filtering based on whether the sender is joined to a list that the > > admin account is tied to. Just a simple boolean is/isn't on the list > > should be enough; leave the policy to the delivery agent/user. > > And how odes that does the "I'm trying to subscribe and can't make it > work!" It doesn't. But you can put all the requests from list members into another folder, or give them a higher priority. It all helps. If you need to prioritize subscription problems then you could use a feedback form, and maybe Mailman should provide one. > "My stupid IS department changed my address again and I need help!" > problems? I never understood why mailman wasn't changed to allow users to change there own addresses years ago. Being able to add valid receiving addresses would help, too. That is also something mailman can help with. John _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers From che@debian.org Mon Feb 18 13:39:29 2002 From: che@debian.org (Ben Gertzfield) Date: Mon, 18 Feb 2002 22:39:29 +0900 Subject: [Mailman-Developers] Duplicates, mostly In-Reply-To: <323F4D4CAF7DAB4D8BEF1B815492DBFEA9AD@asp.cryotube.org> ("James McDonald"'s message of "Mon, 18 Feb 2002 10:14:07 -0000") References: <323F4D4CAF7DAB4D8BEF1B815492DBFEA9AD@asp.cryotube.org> Message-ID: <873czyewoe.fsf@nausicaa.interq.or.jp> >>>>> "James" == James McDonald writes: James> Hey folks, Having just spent a good few weeks with a James> crowbar retrofitting Mailman to our hideous old Majordomo James> setup, it all appears to be working rather nicely. There is James> only one exception... dreaded duplicates. James> I noticed a patch posted a few months back (by Ben James> Gerzfield) for the CVS version, but given that this is a James> production system for a large client I'd prefer to keep it James> stable. Is there any way this duplicate avoidance can be James> easily grafted on to 2.0.8? The patch depends on the Handlers method only available in 2.1. It's not impossible to backport it, but I'm not really interested in doing so. Ben -- Brought to you by the letters T and Y and the number 11. "Atatakaku natta kara, otaku to uchi no kazoku de, nani ka shimasen ka?" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From jra@baylink.com Mon Feb 18 15:15:35 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 18 Feb 2002 10:15:35 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from Chuq Von Rospach on Sun, Feb 17, 2002 at 08:02:11PM -0800 References: <20020217194828.K24676@work.bitmover.com> Message-ID: <20020218101535.42036@scfn.thpl.lib.fl.us> On Sun, Feb 17, 2002 at 08:02:11PM -0800, Chuq Von Rospach wrote: > On 2/17/02 7:48 PM, "Larry McVoy" wrote: > > Second, the point is that even if mailman is 100% perfect, it's not > > at all clear that that would result in even 1% less spam hitting home. > > If that's even remotely close, then it seems like efforts could be better > > spent on screening technology. > > You can't assume your admins are going to want/have screening technology, > unless you build it into mailman. And I don't think Mailman can simply say > "hey, that's some other program's problem". I'm not in charge of as much mail as you, Chuq, but I've been around the block a couple times too... and I'm not sure I agree with that. > We need to find ways to not > become an easy source for the harvester machines. I DO know from my sites > that addresses published ONLY as mailman admins get harvested and hit by > spam. Yup, and so does every web page on the net, and it will keep happening until other things outside our control change markedly -- either on the network provider TOS enforcement side... or on the find offenders and burn down their buildings side. And I'm only partly kidding there. > To me, it's more an issue of "we can't be part of the problem", not "we're > the solution". I have a couple of admins who want their addresses removed > from all public pages -- which I've refused to do, because I think the need > for access by a user in trouble trumps the admin's privacy. Damn right it does. You're gonna be in the movies, you gotta expect to sign the occasional autograph at dinner. > I think at least > one of those admins has solved it by setting up an admin-specific account, That's the proper solution. > and redirecting it to /dev/null, which, if I ever definitely catch him doing > so, will get him in trouble... But that's not, and I concur with your appraisal. > But at the same time -- I don't blame him. And Mailman has a responsibility > to do something about that, the way we (as admins) have a responsibility ot > our users not to make them easy fodder for the harvesters by publishing > archives in an easy to harvest format... Look up "enabler". This is an old argument. I don't know that I concur that reducing the pain threshold of people who might otherwise have an incentive to do *useful* work on spam reduction is a good idea. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Mon Feb 18 15:21:39 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 18 Feb 2002 10:21:39 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from Chuq Von Rospach on Sun, Feb 17, 2002 at 09:37:31PM -0800 References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> Message-ID: <20020218102139.30621@scfn.thpl.lib.fl.us> On Sun, Feb 17, 2002 at 09:37:31PM -0800, Chuq Von Rospach wrote: > > I never understood why mailman wasn't changed to allow users to change there > > own addresses years ago. Being able to add valid receiving addresses would > > help, too. That is also something mailman can help with. > > All it takes is code. Volunteering? (grin) Because there's not a sufficiently strong method of authenticating that the person trying to change the address is actually the *user*? Cheers, -- jra -- Jay R. Ashworth jra@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") From jwblist@olympus.net Mon Feb 18 18:24:50 2002 From: jwblist@olympus.net (John W Baxter) Date: Mon, 18 Feb 2002 10:24:50 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <001001c1b875$944ccc70$56296c42@damien> References: <001001c1b875$944ccc70$56296c42@damien> Message-ID: At 7:12 -0500 2/18/2002, Damien Morton wrote: >There are several approaches to this, including >the use of javascript email decryptors and/or publishing email addresses >as rendered images. I don't think we can assume that the user who feels a need to send mail to the admin has a JavaScript-capable browser with JavaScript turned on. Nor can we require it, IMHO. --John (right now, I can't remember which browsers on which machines have Javascript turned on. Not good) -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From dm-temp-310102@nyc.rr.com Mon Feb 18 18:34:11 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Mon, 18 Feb 2002 13:34:11 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: Message-ID: <000701c1b8aa$deef2450$56296c42@damien> What do you think, then, of rendering the text of the email into a GIF or somesuch. Combined with javascript, the clickable email functionality would be able to be retained, but for users without javascript functionality, they would have to read and type the email address manually. -----Original Message----- From: mailman-developers-admin@python.org [mailto:mailman-developers-admin@python.org] On Behalf Of John W Baxter Sent: Monday, 18 February 2002 13:25 To: mailman-developers@python.org Subject: RE: [Mailman-Developers] Interesting study -- spam on posted addresses... At 7:12 -0500 2/18/2002, Damien Morton wrote: >There are several approaches to this, including >the use of javascript email decryptors and/or publishing email >addresses as rendered images. I don't think we can assume that the user who feels a need to send mail to the admin has a JavaScript-capable browser with JavaScript turned on. Nor can we require it, IMHO. --John (right now, I can't remember which browsers on which machines have Javascript turned on. Not good) -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers From jra@baylink.com Mon Feb 18 18:37:10 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 18 Feb 2002 13:37:10 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <000701c1b8aa$deef2450$56296c42@damien>; from Damien Morton on Mon, Feb 18, 2002 at 01:34:11PM -0500 References: <000701c1b8aa$deef2450$56296c42@damien> Message-ID: <20020218133710.57698@scfn.thpl.lib.fl.us> On Mon, Feb 18, 2002 at 01:34:11PM -0500, Damien Morton wrote: > What do you think, then, of rendering the text of the email into a GIF > or somesuch. > > Combined with javascript, the clickable email functionality would be > able to be retained, but for users without javascript functionality, > they would have to read and type the email address manually. I think it's about as worthless a solution as those 'Hey you! Don't steal my pictures!' javascripts that pop up when I right click ... to hit Back on the menu. If the email address is in a user@domain.ext form *anywhere in the HTML code that's returned*, I can sift it out. You'll have to forgive me, but this sort of 'too-clever by all' solution gives me hives. Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Mon Feb 18 18:47:16 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 18 Feb 2002 10:47:16 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218133710.57698@scfn.thpl.lib.fl.us> Message-ID: On 2/18/02 10:37 AM, "Jay R. Ashworth" wrote: > You'll have to forgive me, but this sort of 'too-clever by all' solution > gives me hives. And you have to be wary of solutions that make it tough for the na=EFve/novic= e net user to figure out what needs to be done. Those of us who geek tend to forget those that don't. And Mailman can't create systems non-geeks can't figure out, even if your preferred audience is geeks. --=20 Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From terri@zone12.com Mon Feb 18 19:58:01 2002 From: terri@zone12.com (Terri Oda) Date: Mon, 18 Feb 2002 14:58:01 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: References: <20020218133710.57698@scfn.thpl.lib.fl.us> Message-ID: <5.1.0.14.0.20020218144551.00aaf080@pop.ncf.carleton.ca> At 10:47 AM 18/02/02 -0800, Chuq Von Rospach wrote: >On 2/18/02 10:37 AM, "Jay R. Ashworth" wrote: > > You'll have to forgive me, but this sort of 'too-clever by all' solution > > gives me hives. >And you have to be wary of solutions that make it tough for the= na=EFve/novice >net user to figure out what needs to be done. Those of us who geek tend to >forget those that don't. And Mailman can't create systems non-geeks can't >figure out, even if your preferred audience is geeks. I don't know... I think rendering email addresses into pictures (say .png=20 instead of .gif, but to A. User it makes no difference as long as it's read= =20 by the browser) is hardly something the average user can't=20 understand. When you phone up tech support and they tell you to go to a=20 web page, it's not like the spoken link is clickable. I'd say most people= =20 are quite capable of reading something and typing it out manually if=20 clicking it doesn't work, otherwise there'd be no success in printing=20 addresses in print ads, on T-shirts, etc. and I know I've seen plenty of=20 lower-tech users type in urls from magazines. Sure, it's a hoop to jump=20 through, but I wouldn't say that it's out of reach for anyone but geeks! Of course, if you're talking about the javascript, that's something else=20 entirely. From dm-temp-310102@nyc.rr.com Mon Feb 18 19:58:33 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Mon, 18 Feb 2002 14:58:33 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: <001401c1b8b6$a81128a0$56296c42@damien> I would suggest that a na=EFve/novice net user will be more familiar = with web-based forms and web-based email than the email we know. As I see it there are two issues here: The first is to enable users to engage list admins and have their problems sorted out, while discouraging or eliminating spam being sent to list admins. For this functionality, a web-based email form can be created. If you don=92t know the admins email address, you use the form = to initiate your conversation. The second issue is to prevent the email addresses of list members from being harvested from the archives. I think that using rendered images and/or javascript can help here. In implementation, as the archive is being rendered out, one would scan for email addresses, rendering image files whose names are hashes of the email address, and replace the email address with an tag. In this way, there would be no 'foo@bar.com' to sift for. The approach can also be used for admin's email addresses on any page of the site. -----Original Message----- From: mailman-developers-admin@python.org [mailto:mailman-developers-admin@python.org] On Behalf Of Chuq Von Rospach Sent: Monday, 18 February 2002 13:47 To: Jay R. Ashworth; mailman-developers@python.org Subject: Re: [Mailman-Developers] Interesting study -- spam on postedaddresses... On 2/18/02 10:37 AM, "Jay R. Ashworth" wrote: > You'll have to forgive me, but this sort of 'too-clever by all'=20 > solution gives me hives. And you have to be wary of solutions that make it tough for the na=EFve/novice net user to figure out what needs to be done. Those of us who geek tend to forget those that don't. And Mailman can't create systems non-geeks can't figure out, even if your preferred audience is geeks. --=20 Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers From chuqui@plaidworks.com Mon Feb 18 20:43:24 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 18 Feb 2002 12:43:24 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <001401c1b8b6$a81128a0$56296c42@damien> Message-ID: On 2/18/02 11:58 AM, "Damien Morton" wrote: > I would suggest that a na=EFve/novice net user will be more familiar with > web-based forms and web-based email than the email we know. I did ten years of tech support.. Wanna bet? You could, actually, be right. But making assumptions is a great way to screw it up. Thought, design and testing are the keys, not guessing. > The first is to enable users to engage list admins and have their > problems sorted out, while discouraging or eliminating spam being sent > to list admins. For this functionality, a web-based email form can be > created. If you don=92t know the admins email address, you use the form to > initiate your conversation. Some form of obfuscating the email address is needed. But here's the problem. If you use a web-based form to send email to the admin, how do you email the admin to say "did you know your site is broken and none of your pages are working?" If the form breaks, how do you contact the admin through the form? That's sort of a worst-case scenario -- but it's also a rather practical one. It happens. So at some point, you need some kind of mailto. But once you do -- it opens you up for spam. Finding the tradeoffs here is the fun part. > The second issue is to prevent the email addresses of list members from > being harvested from the archives. Short answer; archives go behind a password. You authenticate access. Don't go over-fancy with images and scan/replace stuff. Right now, I have a hardwired password. Once 2.1 hits beta, I plan on working towards a solutio= n that authenticates in apache to a mailman-subscribed address. I simply haven't had time yet. --=20 Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. Very funny, Scotty. Now beam my clothes down here, will you? From djc@members.evolt.org Mon Feb 18 20:59:07 2002 From: djc@members.evolt.org (Daniel J. Cody) Date: Mon, 18 Feb 2002 14:59:07 -0600 (CST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: Speaking of tradeoffs, it's my opinion that hiding archives behind a password protection scheme for fear that the administrator, who probably deals with oodles of email anyways and is probably the *most* experienced person in regards to email filtering etc, is a poor one. whew. The archives for a list I run happen to get around 100K referers from google a month, and again IMO, blocking those people out just because I'm getting 5 spams a month doesn't seem like the best idea.. Mailing lists by their nature facilitate communitcation between people, and shutting people out of past or current communication to block out a small to moderate amount of crap goes against that. Instead of just waxing poetic, one solution I've come up with is to block the spambots out from the archives, not the users. Using Apache to Stop Spambots: http://evolt.org/article/mmdev/18/15126/index.html I've just finished the follow up to that article and it will hopefully get published today. It deals with some of the concerns people brought up regarding User-Agents.. If anyones interested, I'll fwd it on when its live. As an aside, how many that run 'larger' lists get a lot of spam? Using the same email address for list-admin going on 3 years now, I can probably count on my fingers and toes how many spams I've gotten to that address. At any rate, I know what you're saying Chuq, just wanted to offer the counter-point ;) Dan On Mon, 18 Feb 2002, Chuq Von Rospach wrote: > > The second issue is to prevent the email addresses of list members from > > being harvested from the archives. > > Short answer; archives go behind a password. You authenticate access. Don't > go over-fancy with images and scan/replace stuff. Right now, I have a > hardwired password. Once 2.1 hits beta, I plan on working towards a solution > that authenticates in apache to a mailman-subscribed address. I simply > haven't had time yet. From dm-temp-310102@nyc.rr.com Mon Feb 18 21:07:31 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Mon, 18 Feb 2002 16:07:31 -0500 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: Message-ID: <000001c1b8c0$4a6af640$56296c42@damien> > Chuq Von Rospach: > > On 2/18/02 11:58 AM, "Damien Morton" > > > The first is to enable users to engage list admins and have their > > problems sorted out. > > Some form of obfuscating the email address is needed. But > here's the problem. If you use a web-based form to send email > to the admin, how do you email the admin to say "did you know > your site is broken and none of your pages are working?" I propose a web-based form _with_ an image rendered email address. > If the form breaks, how do you contact the admin through the form? Using the image rendered email address provided. You just cant click on it. One might want to make it obvious that the image is an image rather than text, so that unwary users arent tempted to try cut and paste. > > The second issue is to prevent the email addresses of list members > > from being harvested from the archives. > > Short answer; archives go behind a password. You authenticate > access. Don't go over-fancy with images and scan/replace > stuff. Right now, I have a hardwired password. Once 2.1 hits > beta, I plan on working towards a solution that authenticates > in apache to a mailman-subscribed address. I simply haven't > had time yet. But we do want google et al to index the archives don't we? Ive found myself joining all sorts of lists that I found googling for this or that subject. Put the raw mbox behind a reverse turing test. (See http://www.captcha.net/ for the orginal idea). Make the rest publically accessible, but with the actual email addresses obscured. From dgc@uchicago.edu Mon Feb 18 21:21:56 2002 From: dgc@uchicago.edu (David Champion) Date: Mon, 18 Feb 2002 15:21:56 -0600 Subject: [Mailman-Developers] Re: Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020218212156.GA60@dust.uchicago.edu> On 2002.02.18, in , "Daniel J. Cody" wrote: > Speaking of tradeoffs, it's my opinion that hiding archives behind a > password protection scheme for fear that the administrator, who probably > deals with oodles of email anyways and is probably the *most* experienced > person in regards to email filtering etc, is a poor one. I think you left something out there -- for fear that the administrator what? :) Anyway, I wish I had your admins. My admins are just like my subscribers: most of them are ordinary users, and a few are somewhat knowledgeable of the technology. And I expect this to become more common as Mailman grows more popular and "more de facto", if that means anything. -- -D. dgc@uchicago.edu NSIT University of Chicago Colons and slashes and dots, oh my! From chuqui@plaidworks.com Mon Feb 18 22:00:57 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 18 Feb 2002 14:00:57 -0800 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: <000001c1b8c0$4a6af640$56296c42@damien> Message-ID: On 2/18/02 1:07 PM, "Damien Morton" wrote: > But we do want google et al to index the archives don't we? I don't, no. > I've found > myself joining all sorts of lists that I found googling for this or that > subject. So you see the archives as marketing to increase usage of the list? And for that, you'll give away your users email addresses to the spammers? Do you get high quality new subscribers through google? Do you know? Or does it attract vampires and trolls? Are there any other benefits to being googled than being a walking billboard to the list? -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! From chuqui@plaidworks.com Mon Feb 18 21:57:50 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 18 Feb 2002 13:57:50 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: On 2/18/02 12:59 PM, "Daniel J. Cody" wrote: > Speaking of tradeoffs, it's my opinion that hiding archives behind a > password protection scheme for fear that the administrator, who probably > deals with oodles of email anyways and is probably the *most* experienced > person in regards to email filtering etc, is a poor one. > > whew. > > The archives for a list I run happen to get around 100K referers from > google a month, and again IMO, blocking those people out just because I'm > getting 5 spams a month doesn't seem like the best idea. You misread the intent here, probably because I was unclear. You protect the archives because otherwise, your subscribers will be harvested. If your archives are in google, you're handing all of your subscribers to the spammers. You might as well burn them a CD. To me, that's not remotely an option. If your archives are google-searchable, you're being harvested, and your users, if they ever figure it out, will thank you. Probably with a pitchfork. Users of a mail list have a right to be protected from spam caused by your mail list. If you don't protect the archives from harvesting, frankly, you might as well stop rejecting spam sent directly to the list as well. And you know how well your users would take THAT decision. We can argue the philosophy of archives in search engines -- but I consider stuffing email addresses in search engines to be a fatal error. You'll never convince me that's okay. And I've never convinced myself that castrating email out of an archive and then publishing the archive is worth the work and hassle. Your mileage on that latter probably varies. Protecting admin addresses from spam is a second, separate issue. An admin has a responsibilty to be accessible to the outside public to answer questions and deal with problems. And because, if the pages DO break, one would hope the admin would like to know that so it can be fixed. So you can't hide an admin -- but I think you also have a responsibility to protect that admin as much as you can, because it's already enough fun for the admin to run a list that adding "oh, yeah. Eat all this spam" on top doesn't seem to add many gold stars to the job description. So you have to look for ways to not make it easy for spammers, while not making it hard for real users. > http://evolt.org/article/mmdev/18/15126/index.html Thanks. I'll go take a look. I'm always looking for better mousetraps. But I'm curious whether your setup would catch and protect users from this: Last Friday, I got an emergency call from my assistant (I was at home, watching curling on CBC. Um, well, I was working from home). Our Mailman box at work was thrashed and shutting down. I logged in and looked, and found that the web site was being whacked -- a robot of some sort was pulling down 40 pages in parallel, all at once. Definitely not a well-behaved beast. When I went looking in the logs to see whether it was a system problem, an attack, or merely some clueless idiot interrupting my day, I found that while it was clearly an automated spider of some sort doing the page grabs, its user-agent promoted itself as a nice, generic IE on Microsoft Windows user. In other words, if you are assuming the harvesters aren't obfuscating the user-agent, I found out the hard way last week that's not true. I'm still waiting to see if that guy comes back. I'm curious. And, now, watching... I haven't seen a bot-catcher that I think reliably stops a bot that is actively trying to hide from me. Which means the GOOD spammers are going to fall under the radar, and you get this false sense of security, because of all of the stuff you Are stopping... Until I do find one, I'll use a password and some kind of authentication, and work my butt off to not let the data get out of my hands if there are email addresses in it (I just modified my T&C to explicitly deny people setting up public, third party archives without our approval of the archive, specifically so we have teeth to force them to protect their archives at least as much as we protect ours. It makes no sense putting a second deadbolt on the front door if you never lock the back. Letting your archives into google, IMHO, is putting the silver on the front porch so they can take it easier... > As an aside, how many that run 'larger' lists get a lot of spam? Using the > same email address for list-admin going on 3 years now, I can probably > count on my fingers and toes how many spams I've gotten to that address. Oh, gee. You can have some of mine. You don't want to know. On my home/small server, a couple of the mail lists average 10-15 pieces a day, to it and to the admin. Right now, it's gone from making it bigger and increasing the volume to making it taste sweet.. Sigh. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. From jwm@plain.co.nz Mon Feb 18 23:42:08 2002 From: jwm@plain.co.nz (John Morton) Date: Tue, 19 Feb 2002 12:42:08 +1300 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218102139.30621@scfn.thpl.lib.fl.us> References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <20020218102139.30621@scfn.thpl.lib.fl.us> Message-ID: <20020218234209.9DCBA13D58@registry.e-servicesltd.co.nz> On Tuesday 19 February 2002 04:21, Jay R. Ashworth wrote: > On Sun, Feb 17, 2002 at 09:37:31PM -0800, Chuq Von Rospach wrote: > > > I never understood why mailman wasn't changed to allow users to change > > > there own addresses years ago. Being able to add valid receiving > > > addresses would help, too. That is also something mailman can help > > > with. > > > > All it takes is code. Volunteering? (grin) > > Because there's not a sufficiently strong method of authenticating that > the person trying to change the address is actually the *user*? No, it just involves squashing the two actions a user needs to take into one, more obvious action - rather than subscribe a new address, confirm it, then delete the old address and confirm it, you change the address (keeping the settings), and confirm both dropping the old address and sending to the new one as a pair of emails. Iff both confirmations succeed, the address changes, otherwise it stays as it was. Adding other valid sending addresses will also require an email confirmation action. John From jra@baylink.com Tue Feb 19 04:58:38 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 18 Feb 2002 23:58:38 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from Chuq Von Rospach on Mon, Feb 18, 2002 at 10:47:16AM -0800 References: <20020218133710.57698@scfn.thpl.lib.fl.us> Message-ID: <20020218235838.11759@scfn.thpl.lib.fl.us> On Mon, Feb 18, 2002 at 10:47:16AM -0800, Chuq Von Rospach wrote: > On 2/18/02 10:37 AM, "Jay R. Ashworth" wrote: >=20 > > You'll have to forgive me, but this sort of 'too-clever by all' solut= ion > > gives me hives. >=20 > And you have to be wary of solutions that make it tough for the > na=EFve/novice net user to figure out what needs to be done. Those of > us who geek tend to forget those that don't. And Mailman can't create > systems non-geeks can't figure out, even if your preferred audience is > geeks. Well, it sounded to *me* like he was *trying* to mediate for the UnGeeked, merely unsuccessfully.=20 I get paid to remember what you've pointed out, and I'm pretty good at it, but I still sometimes forget... Cheers, -- jra --=20 Jay R. Ashworth jra@baylin= k.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") From jra@baylink.com Tue Feb 19 05:01:41 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 19 Feb 2002 00:01:41 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <5.1.0.14.0.20020218144551.00aaf080@pop.ncf.carleton.ca>; from Terri Oda on Mon, Feb 18, 2002 at 02:58:01PM -0500 References: <20020218133710.57698@scfn.thpl.lib.fl.us> <5.1.0.14.0.20020218144551.00aaf080@pop.ncf.carleton.ca> Message-ID: <20020219000141.39891@scfn.thpl.lib.fl.us> On Mon, Feb 18, 2002 at 02:58:01PM -0500, Terri Oda wrote: > I don't know... I think rendering email addresses into pictures (say .png > instead of .gif, but to A. User it makes no difference as long as it's read > by the browser) is hardly something the average user can't > understand. When you phone up tech support and they tell you to go to a > web page, it's not like the spoken link is clickable. I'd say most people > are quite capable of reading something and typing it out manually if > clicking it doesn't work, otherwise there'd be no success in printing > addresses in print ads, on T-shirts, etc. and I know I've seen plenty of > lower-tech users type in urls from magazines. Sure, it's a hoop to jump > through, but I wouldn't say that it's out of reach for anyone but geeks! > > Of course, if you're talking about the javascript, that's something else > entirely. Well, neither the JavaScript *nor* the picture are going to do me much good on the two browsers I use most often: Lynx 2.8.3 in a konsole window... and GoWeb 6 on my Palm/Minstrel handheld. The former may not be especially mainstream, but anyone who ignores the latter category (not to mention my blind friend's screen reader) does so at their peril. Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Tue Feb 19 06:35:56 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 18 Feb 2002 22:35:56 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218235838.11759@scfn.thpl.lib.fl.us> Message-ID: On 2/18/02 8:58 PM, "Jay R. Ashworth" wrote: > I get paid to remember what you've pointed out, and I'm pretty good at > it, but I still sometimes forget... Me, too, on both counts. I tend to be good at questions, but the answers aren't nearly as easy... -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! From stephen@xemacs.org Tue Feb 19 07:17:53 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 19 Feb 2002 16:17:53 +0900 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: References: Message-ID: <87n0y6lz32.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Chuq" == Chuq Von Rospach writes: Chuq> Are there any other benefits to being googled than being a Chuq> walking billboard to the list? Yes. I do see a fair number of "non-subscriber" posts that go "we need to do job X, and according to a post I dug up googling for `job X' you can do this". It's hard to see how you can replace google for that purpose for XEmacs ... many values of "job X" you wouldn't normally associate with a text editor, even XEmacs. Those people are not going to go fishing in our archives, even if we had a reliable search function. So there is a lot of information in those archives that people are not going to be able to access without Google. OTOH, I suspect that's pretty rare for Mailman, or even Python. Sure, you'll see the "job X" post, but they'll already know that Mailman or Python might do it, usually no need for Google, and definitely not to dig into ML archives. XEmacs is a special case. I'll admit I'm not proud of the fact that it also publishes all those addresses, but I've got other things to do than sink a lot of time into changing something that's a long established practice at my organization, set up by somebody who knows a lot more about all this than me (and I'd really rather it stayed that way), and nominally a third person's job in any case. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From chuqui@plaidworks.com Tue Feb 19 07:33:16 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 18 Feb 2002 23:33:16 -0800 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: <87n0y6lz32.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: On 2/18/02 11:17 PM, "Stephen J. Turnbull" wrote: > Chuq> Are there any other benefits to being googled than being a > Chuq> walking billboard to the list? > Those people are > not going to go fishing in our archives, even if we had a reliable > search function. So there is a lot of information in those archives > that people are not going to be able to access without Google. But -- I hate to be bullheaded about this, but I will be -- how does this benefit YOUR LIST? Yes, it benefits others, and there's some value to that, but does it actually add value to your list? Enough value to warrant handing your subscriber list to the spammers? See, if I'm going to expose my users to spammers, there better be value to those users worth the hassle. So far, I've seen value in being google to marketing the list, and value to non-subscribers. But what advantage do the users being handed to the spammers get? Do your users know (and understand) that the global archives make them open season for spambots? Have they agreed to this? Have you discussed it with them? Or is this soemthing you've hoped they didn't discover on their own? If you "put it up to a vote" after explaining the situation, do you think the subscribers of your list would vote to stay in google? If not, how do you justify doing it to them anyway? I'm not picking on you, stephen, at least not personally. But yours is a very common attitude, one that was mostly entrenched in mailing list philosophy five or more years ago before spammers and spambots became such a nasty problem. I'm suggesting that it's time to rethink this on all lists that globally expose their archives, because life has changed. And I kinow that my users, as they've learned about then issue, have become very noisy about not being openly distributed (in fact, to some degree, it was my users that educated me into looking at the issue...). I mean, years ago mail lists were open to all posters, too, and many had usenet gateways. These days, the spam problems have forced changes to those, also, on many (most?) lists. The only reason the archive issue has less visibility is that the spam ends up directly in the users mailbox, so the connection isn't as visible to a typical user. But that doesn't mean it's not there. > but I've got other things to do than sink a lot of time > into changing something that's a long established practice at my > Organization No offense, but "long established" doesn't mean it's still the correct decision. Times change -- especially on the internet. Frankly, the longer a practice is established, the more I think it needs to be rethought. We're all busy -- but what's more important than protecting our users from the outside world? Don't the users come first? Chuq -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From chuqui@plaidworks.com Tue Feb 19 08:04:54 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 19 Feb 2002 00:04:54 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218101535.42036@scfn.thpl.lib.fl.us> Message-ID: On 2/18/02 7:15 AM, "Jay R. Ashworth" wrote: > Yup, and so does every web page on the net, and it will keep happening > until other things outside our control change markedly -- either on the > network provider TOS enforcement side... Oh boy. Now I get to sound like your mother.. "If the other boys are going to jump off a bridge, does that mean you should?" I can't fix the universe. I think it's silly to try. But you gotta start somewhere, and I think it's important to do what you can to fix the part of the universe you control. Because if you say "hell, it won't get fixed until someone else fixes it", doesn't that simply make it easier for all those "someone else"'s to do exactly the same? You gotta start somewhere. You won't stop it yourself. But if everyone made some improvement, they all pile together into a big improvement. > Damn right it does. You're gonna be in the movies, you gotta expect to > sign the occasional autograph at dinner. I agree. But that also doesn't mean you should expect your home address and phone number to be published in the national enquirer. >> and redirecting it to /dev/null, which, if I ever definitely catch him doing >> so, will get him in trouble... > > But that's not, and I concur with your appraisal. And that is why I'm forced to write a formal T&C (terms and conditions), which all my admins are going to be forced to agree to follow, or their lists will be shut down. And if they don't follow it, their lists will be shut down. Because I've tried the "we're all mature adults here, and I expect you'll do your job" and found that it works -- almost all the time. And the times when it doesn't are simply not acceptable. So I'm going to have to go through all this, just so there's no ambiguity in what's expected and what's allowed FOR THE ADMIN, so I can thumbscrew two or three into cooperation because treating them like mature adults didn't work. And the other 99% of my admins get taken along for the ride, since I have to be consistent here, if only to save myself from the next re-org... > Look up "enabler". This is an old argument. I don't know that I > concur that reducing the pain threshold of people who might otherwise > have an incentive to do *useful* work on spam reduction is a good > idea. These people have real jobs. Running mail lists is a secondary task (at best). "finding and killing spammers" is nowhere to be found. It's not enablement. If it were me, it'd be enablement. For them -- it's a pain in the butt and disincentive to do their real work. The people you're trying to turn into enablers never were and never will be part of the anti-spam war. They're collateral damage -- and I don't agree with you that "sharing the pain" will do anything but make them pissed and bitter. And I don't see that as an advantage. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From chuqui@plaidworks.com Tue Feb 19 08:06:34 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 19 Feb 2002 00:06:34 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020218102139.30621@scfn.thpl.lib.fl.us> Message-ID: On 2/18/02 7:21 AM, "Jay R. Ashworth" wrote: >> All it takes is code. Volunteering? (grin) > > Because there's not a sufficiently strong method of authenticating that > the person trying to change the address is actually the *user*? So we get back to the core of the problem: until we get true authenticatable e-mail addresses, everything we do is fingers in the dike. And even then, I've had some long, technical dialogs with my elder gods of e-mail that have convinced me that even a fully-implemented public-key auth system won't solve all of the problems... And I have only ten fingers, and ten toes. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. Very funny, Scotty. Now beam my clothes down here, will you? From daniel.haischt@daniel-s-haischt.biz Tue Feb 19 08:52:49 2002 From: daniel.haischt@daniel-s-haischt.biz (Daniel S. Haischt) Date: Tue, 19 Feb 2002 09:52:49 +0100 Subject: [Mailman-Developers] mail -> news gateway does not work Message-ID: hello, i am running mailman 2.1a4 in conjunction with INN. i configured mailman to forward each post to the list to my local news server. unfortunatly i am getting the following error ... ---------8<-------------8<------------------8<-------- (NNTPDirect) NNTP error for list "mobilepm-dev": 441 437 No colon-space in "From daniel.haischt@daniel-s- haischt.biz Sun Feb 17 18:39:49 2002" header --------->8------------->8------------------>8-------- the news to mailing list part works as expected. With best regards/Mit freundlichen Gruessen Daniel S. Haischt IT Consulting _______________________________ [revolutionary and alpha geek] Daniel S. Haischt Grabenstrasse 11 D-71083 Herrenberg G E R M A N Y FON: +49 -7032-992909 FAX: +49 -7032-992910 CELLULAR: +49 -172-7668936 email: mail@daniel-s-haischt.biz web: http://www.daniel-s-haischt.biz -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS dx s:- a- C++ UB++++ P+++ L++++ E W+++ N+++ o-- K- w--- O++ M++ V- PS+ PE++ Y+ PGP++ t+++ 5+ X+++ R+ tv++ b+++ DI+ D+++ G e++ h-- r+ y+++++ ------END GEEK CODE BLOCK------ From dm-temp-310102@nyc.rr.com Tue Feb 19 09:46:24 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Tue, 19 Feb 2002 04:46:24 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020219000141.39891@scfn.thpl.lib.fl.us> Message-ID: <000501c1b92a$4e64d300$56296c42@damien> > Jay R. Ashworth writes: > Well, neither the JavaScript *nor* the picture are going to > do me much good on the two browsers I use most often: Lynx > 2.8.3 in a konsole window... and GoWeb 6 on my Palm/Minstrel handheld. > > The former may not be especially mainstream, but anyone who > ignores the latter category (not to mention my blind friend's > screen reader) does so at their peril. I was wondering how long it would be before someone brought up the case for Lynx. Blind people I had not though about, although I had thought about text based reverse turing tests. I know nothing of this GoWeb 6 that you speak of, youll have to describe it to me, but I assume its some kind of transcoding browser that doesnt handle images very well. So one solution would be to have both public and private archives. The public archives have the email addresses obfuscated in some way, the private archives would not. List members, and those able to pass a reverse turing test, would have access to the private archives, while the rest of the world would have access to the public archives. Once we are talking about both public are private archives, however, we are probably also talking about the use of a cgi script which renders emails on the fly, depending on some kind of authentication. A cookie, perhaps. Thoughts? From jra@baylink.com Tue Feb 19 15:09:00 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 19 Feb 2002 10:09:00 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <000501c1b92a$4e64d300$56296c42@damien>; from Damien Morton on Tue, Feb 19, 2002 at 04:46:24AM -0500 References: <20020219000141.39891@scfn.thpl.lib.fl.us> <000501c1b92a$4e64d300$56296c42@damien> Message-ID: <20020219100900.27588@scfn.thpl.lib.fl.us> On Tue, Feb 19, 2002 at 04:46:24AM -0500, Damien Morton wrote: > > Jay R. Ashworth writes: > > Well, neither the JavaScript *nor* the picture are going to > > do me much good on the two browsers I use most often: Lynx > > 2.8.3 in a konsole window... and GoWeb 6 on my Palm/Minstrel handheld. > > > > The former may not be especially mainstream, but anyone who > > ignores the latter category (not to mention my blind friend's > > screen reader) does so at their peril. > > I was wondering how long it would be before someone brought up the case > for Lynx. Blind people I had not though about, although I had thought > about text based reverse turing tests. :-) > I know nothing of this GoWeb 6 that you speak of, youll have to describe > it to me, but I assume its some kind of transcoding browser that doesnt > handle images very well. It's the browser on my wireless handheld, and, in general, it doesn't handle images *at all*. Nor will the microbrowsers on some people's cell phones. > So one solution would be to have both public and private archives. The > public archives have the email addresses obfuscated in some way, the > private archives would not. Oh. We're talking about *archives*? Silly me. I thought we were talking about maintainer addresses on sign-up pages. > List members, and those able to pass a reverse turing test, would have > access to the private archives, while the rest of the world would have > access to the public archives. > > Once we are talking about both public are private archives, however, we > are probably also talking about the use of a cgi script which renders > emails on the fly, depending on some kind of authentication. A cookie, > perhaps. > > Thoughts? It's ASCII text. It's useful. Making it into something else makes it less useful, and as I noted in another posting, reduces the incentive to locate the spammers and commit arson upon their persons and property. Cheers, -- jr 'closed captioned for the humor impaired' a -- Jay R. Ashworth jra@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") From jra@baylink.com Tue Feb 19 15:06:01 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 19 Feb 2002 10:06:01 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from Chuq Von Rospach on Tue, Feb 19, 2002 at 12:04:54AM -0800 References: <20020218101535.42036@scfn.thpl.lib.fl.us> Message-ID: <20020219100601.41871@scfn.thpl.lib.fl.us> On Tue, Feb 19, 2002 at 12:04:54AM -0800, Chuq Von Rospach wrote: > On 2/18/02 7:15 AM, "Jay R. Ashworth" wrote: > > Yup, and so does every web page on the net, and it will keep happening > > until other things outside our control change markedly -- either on the > > network provider TOS enforcement side... > > Oh boy. Now I get to sound like your mother.. "If the other boys are going > to jump off a bridge, does that mean you should?" > > I can't fix the universe. I think it's silly to try. But you gotta start > somewhere, and I think it's important to do what you can to fix the part of > the universe you control. Because if you say "hell, it won't get fixed until > someone else fixes it", doesn't that simply make it easier for all those > "someone else"'s to do exactly the same? > > You gotta start somewhere. You won't stop it yourself. But if everyone made > some improvement, they all pile together into a big improvement. Yup. It's just like edge providers enforcing source address spoofing prevention. It doesn't cure DDoS attacks, but it makes every other kind easier to trace... and for that matter, it makes DDoS's easier to trace, not that you have the time. :-) > > Damn right it does. You're gonna be in the movies, you gotta expect to > > sign the occasional autograph at dinner. > > I agree. But that also doesn't mean you should expect your home address and > phone number to be published in the national enquirer. No. It's definitely a judgement call here how far the analogy ought reasonably to be expected to stretch. > >> and redirecting it to /dev/null, which, if I ever definitely catch > >> him doing so, will get him in trouble... > > > > But that's not, and I concur with your appraisal. > > And that is why I'm forced to write a formal T&C (terms and conditions), > which all my admins are going to be forced to agree to follow, or their > lists will be shut down. And if they don't follow it, their lists will be > shut down. Because I've tried the "we're all mature adults here, and I > expect you'll do your job" and found that it works -- almost all the time. > And the times when it doesn't are simply not acceptable. So I'm going to > have to go through all this, just so there's no ambiguity in what's expected > and what's allowed FOR THE ADMIN, so I can thumbscrew two or three into > cooperation because treating them like mature adults didn't work. And the > other 99% of my admins get taken along for the ride, since I have to be > consistent here, if only to save myself from the next re-org... > > Look up "enabler". This is an old argument. I don't know that I > > concur that reducing the pain threshold of people who might otherwise > > have an incentive to do *useful* work on spam reduction is a good > > idea. > > These people have real jobs. Running mail lists is a secondary task (at > best). "finding and killing spammers" is nowhere to be found. It's not > enablement. If it were me, it'd be enablement. For them -- it's a pain in > the butt and disincentive to do their real work. The people you're trying to > turn into enablers never were and never will be part of the anti-spam war. They're still enablers, regardless of their conscious intent... > They're collateral damage -- and I don't agree with you that "sharing the > pain" will do anything but make them pissed and bitter. And I don't see that > as an advantage. Yeah, the difference between theory and practice is much greater in practice than in theory. Cheers, -- jra -- Jay R. Ashworth jra@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") From stephen@xemacs.org Tue Feb 19 15:48:38 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 20 Feb 2002 00:48:38 +0900 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: References: Message-ID: <878z9plbft.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Chuq" == Chuq Von Rospach writes: Chuq> But -- I hate to be bullheaded about this, but I will be -- Chuq> how does this benefit YOUR LIST? Yes, it benefits others, Chuq> and there's some value to that, but does it actually add Chuq> value to your list? Enough value to warrant handing your Chuq> subscriber list to the spammers? To be precise, it's not the subscriber list; only about 1 in 5 posts, ever. Chuq> If you "put it up to a vote" after explaining the situation, Chuq> do you think the subscribers of your list would vote to stay Chuq> in google? I don't know. The people who post are a pretty public-spirited bunch, and they might very well volunteer for the abuse if that means that non-subscriber XEmacs users get better service. It may not be all that costly to them, either. I only see about 15% of the spam sent my way, and I don't filter very hard. I think a lot of the posters do substantially better than that (eg, we've got several TMDA users). But it really doesn't matter, because the XEmacs devel lists are an extreme case as far as I can tell. I guess my bottom line here is that you've got me convinced that the _default_ should be no Google and private archives. My basic point was to give an example of a case where the purpose of the list is more than just communication among the subscribers. I suppose that in some cases that purpose warrants considering open archives, just as list managers have to have published addresses so they can perform subscriber services. Now that I'm aware of the issue, I'll have to do something about assessing whether the value to non-subscriber users outweighs the abuse the posters take. But once again, I'd like to point out that _I didn't explicitly ask for this job_. I'm doing it because the mailing list is an essential service to XEmacs users, and the archives are too. Since the guy who was list admin ran out of volunteer time, leaving things in this state, I'm "it". Note: he was presumably aware of the issue---he's a long-time TMDA user. And he took a fair amount of care to make things as easy as possible for those who followed; he moved to Mailman as the list server, for example, although as far as the list subscribers were concerned the existing Majordomo installation was working fine. If a conscientious expert sets things up this way, how was I supposed to know? I certainly hope Mailman will _by default_ make it easy for people in my position to do the right thing. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From chuqui@plaidworks.com Tue Feb 19 16:42:37 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 19 Feb 2002 08:42:37 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <000501c1b92a$4e64d300$56296c42@damien> Message-ID: On 2/19/02 1:46 AM, "Damien Morton" wrote: > Once we are talking about both public are private archives, however, we > are probably also talking about the use of a cgi script which renders > emails on the fly, depending on some kind of authentication. A cookie, > perhaps. That's pretty much exactly the path I felt this needed to go. Remove the password protection, and if you're not-authenticated as a subscriber to that list, all e-mail addresses are removed. If you are, you get the unedited message. Whether you do this by putting all access to a directory structure behind a CGI, or whether you load it into a database, I'm not sure yet. The former would likely be less massive in the infrastructure. The latter might buy us a built-in search engine and a replacement for pipermail at the same time, but at the expense of a big glop-o-code and infrastructure requirements. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. From chuqui@plaidworks.com Tue Feb 19 16:52:40 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 19 Feb 2002 08:52:40 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020219100900.27588@scfn.thpl.lib.fl.us> Message-ID: On 2/19/02 7:09 AM, "Jay R. Ashworth" wrote: >> I was wondering how long it would be before someone brought up the case >> for Lynx. Blind people I had not though about, although I had thought >> about text based reverse turing tests. > > :-) Lynx access is a really gnarly issue. Lynx usage on my sites has gone from about 4% a couple of years ago, to < 1% these days, from what I've seen. On the other hand, Lynx is the litmus test for sight-limited access tools. If it don't work with lynx, you lock out those with seeing problems (and with a mother who has some macular degeneration, I'm a bit enlightened by those issues. Thank god for Macs and the ability to make font sizes bigger...) While I'll happily tell the "I don't like cookies" people to get over it, Lynx access isn't something I can or will easily blow off. And something geeks tend not to think of, you start getting into issues of ADA compliance issues, which is a non-trivial issue we haven't even started thinking about here... > It's the browser on my wireless handheld, and, in general, it doesn't > handle images *at all*. Nor will the microbrowsers on some people's > cell phones. Yup. And while I'd say today it's not a huge issue, 2-3 years down the road, when the version of mailman we're currently noodging over gets into wide usage, it'll be there, and it'll only become more endemic. If you design stuff like this for what's Out There today, by the time it's written, it'll be missing What's Coming... >> So one solution would be to have both public and private archives. The >> public archives have the email addresses obfuscated in some way, the >> private archives would not. > > Oh. We're talking about *archives*? Silly me. I thought we were > talking about maintainer addresses on sign-up pages. We're talking about both, actually. It's a floor wax and a dessert topping! > It's ASCII text. It's useful. Making it into something else makes it > less useful, But it's the kind of tradeoff we have to consider -- we ARE going to have to give up some stuff in one place to make improvements in another. You aren't going to find a way to better protect the admins without cost in usability somewhere. It's a no-free-lunch situation, or we would have solved it already. The key is to understand the situation and find the most appropriate compromise, because a solution without compromise doesn't seem to exist. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! From chuqui@plaidworks.com Tue Feb 19 17:03:31 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 19 Feb 2002 09:03:31 -0800 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: <878z9plbft.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: On 2/19/02 7:48 AM, "Stephen J. Turnbull" wrote: > To be precise, it's not the subscriber list; only about 1 in 5 posts, > ever. And if you're that one, you don't really care that it's only 20%, do you? > I don't know. The people who post are a pretty public-spirited bunch, > and they might very well volunteer for the abuse if that means that > non-subscriber XEmacs users get better service. Ask them! If they say yes, your situation is resolved. But those that say no are likely to drop off the list. But -- shouldn't they be given a chance to make an informed decision? God, I think I sound like I'm beating on you again. I'm sorry. I'm not saying "the archives have to be protected" but "the users deserve to know what is going on and have some say in the use of their addresses". It's more informed consent issues. And this is an issue that I'm harping on because it's a piece of the net-reality that's changed over the last couple of years, from "standard practice/safe" to "jesus, not at all safe any more" and we're just getting visibility into what this means. And I'm doing it HERE because Mailman is one of those tools that is going to set default policy on how the non-savvy mail-list admins and sites are going to build and manage archives for the next five years -- so I feel we need to make sure Mailman does it in a way that does things "right", whatever that is. So as Jay talks about enablers, one of the things I'm doing here overtly is trying to act as one on this topic, because if I can help make Mailman do it right, and educate the folks here, that'll make a positive difference in a way few other things can. I can't shut down open relays in Malaysia, but maybe, I can help educate folks on how to better limit access for the spammers in a tool that's becoming defacto-standard on the net as it supplants majordomo... And with any luck, that's the last time I'll ever use the word "enabler"... (grin) > But once again, I'd like to point out that _I didn't explicitly ask > for this job_. I'm doing it because the mailing list is an essential > service to XEmacs users, and the archives are too. Since the guy who > was list admin ran out of volunteer time, leaving things in this > state, I'm "it". Understood. The joys of volunteerism. You don't know what's under the carpet until you pull out the broom. You only hope the broom will kill it... > If a conscientious expert sets things up this way, how was I supposed > to know? I certainly hope Mailman will _by default_ make it easy for > people in my position to do the right thing. You weren't. Hell, a year ago, NOBODY really knew about this issue. As I say, this is something we're just starting to really get a handle on. It's not something you should have known about -- it's a new monster under the bed. Or maybe an old one we just got a photo of for the first time... I apologize -- I'm trying not ot beat on you or your mail list. I'm beating on a situation. Of course, since you're currently the drum, that's probably not making you feel better... (really. I'm sorry) -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. From fbaroni@axoadi.it Wed Feb 20 11:58:24 2002 From: fbaroni@axoadi.it (Gian Franco Baroni) Date: Wed, 20 Feb 2002 12:58:24 +0100 Subject: [Mailman-Developers] Error in digest admin Message-ID: Hi to all. Trying to admin the digest options of any list by web interface, I get = this error: Traceback: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 86, in run_main main() File "/home/mailman/Mailman/Cgi/admin.py", line 187, in main show_results(mlist, doc, category, subcat, cgidata) File "/home/mailman/Mailman/Cgi/admin.py", line 510, in show_results form.AddItem(show_variables(mlist, category, subcat, cgidata, doc)) File "/home/mailman/Mailman/Cgi/admin.py", line 562, in show_variables add_options_table_item(mlist, category, subcat, table, item) File "/home/mailman/Mailman/Cgi/admin.py", line 577, in add_options_table= _item val =3D get_item_gui_value(mlist, category, kind, varname, params) File "/home/mailman/Mailman/Cgi/admin.py", line 616, in get_item_gui_valu= e value =3D getattr(mlist, varname) File "../Mailman/MailList.py", line 135, in __getattr__ raise AttributeError, name AttributeError: _new_volume Here are the evironment variables: HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, = application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword= , application/x-comet, */* =20 CONTENT_TYPE application/x-www-form-urlencoded =20 HTTP_REFERER http://ns.axoadi.it/mailman/admin/ihm-pavia/digest =20 SERVER_SOFTWARE Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 = OpenSSL/0.9.6b DAV/1.0.2 PHP/4.0.6 mod_perl/1.24_01 =20 PYTHONPATH /home/mailman =20 SCRIPT_FILENAME /home/mailman/cgi-bin/admin =20 SERVER_ADMIN root@localhost =20 SCRIPT_NAME /mailman/admin =20 SERVER_SIGNATURE Apache/1.3.20 Server at ns.axoadi.it Port 80=20 REQUEST_METHOD POST =20 HTTP_HOST ns.axoadi.it =20 PATH_INFO /ihm-pavia/digest =20 SERVER_PROTOCOL HTTP/1.1 =20 QUERY_STRING =20 HTTP_CACHE_CONTROL no-cache =20 REQUEST_URI /mailman/admin/ihm-pavia/digest =20 CONTENT_LENGTH 15 =20 HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) =20 HTTP_CONNECTION Keep-Alive =20 HTTP_COOKIE fmp-ita+admin=3D2802000000691f57733c73280000003662643037396335= 3037373938373764323631623032343539663236633035323262356636353866 =20 SERVER_NAME ns.axoadi.it =20 REMOTE_ADDR 213.82.44.123 =20 REMOTE_PORT 61547 =20 HTTP_ACCEPT_LANGUAGE it =20 PATH_TRANSLATED /var/www/html/ihm-pavia/digest =20 SERVER_PORT 80 =20 GATEWAY_INTERFACE CGI/1.1 =20 HTTP_ACCEPT_ENCODING gzip, deflate =20 SERVER_ADDR 213.82.44.120 =20 DOCUMENT_ROOT /var/www/html =20 Anyone is getting the same error? Thanks GFB From jra@baylink.com Wed Feb 20 17:31:55 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 12:31:55 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: ; from Chuq Von Rospach on Mon, Feb 18, 2002 at 01:57:50PM -0800 References: Message-ID: <20020220123155.18818@scfn.thpl.lib.fl.us> On Mon, Feb 18, 2002 at 01:57:50PM -0800, Chuq Von Rospach wrote: > Users of a mail list have a right to be protected from spam caused by your > mail list. Ok. I don't want to start a philosophical war here, and I'm perfectly familiar with the concept enshrined in the phrase "that's fine, sonny, but this here's the fleet"... But I still think it's important to keep firmly uppermost in our minds here that the spam is not *caused* by the mailing list. Nor is it caused by Google It's *caused* by the spammers. I realize that we have practical considerations to deal with which are much closer to our feet, but I think that it's quite important that we don't lose sight of the forest for the trees. I personally can't think of any method of programmatically obscuring email addresses that can't be programmatically reversed. So, I'm thinking that having a publicly and privately accessible version may be the only answer. I do, though, sort of like the "turing test" idea -- I've often found a useful contact for a project by Googling to mailing lists; having to subscribe to get an email address for an off-llist contact is too steep a hill to climb. I figure if it's a "public" mailing list (by which I mean, one to which anyone is invited to belong), then such inquiries are the price you pay, so I think this is a reasonable analogy, and thereby, justification for my argument here. Others may disagree. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 20 17:45:40 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 12:45:40 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from Chuq Von Rospach on Tue, Feb 19, 2002 at 08:52:40AM -0800 References: <20020219100900.27588@scfn.thpl.lib.fl.us> Message-ID: <20020220124540.45108@scfn.thpl.lib.fl.us> On Tue, Feb 19, 2002 at 08:52:40AM -0800, Chuq Von Rospach wrote: > On 2/19/02 7:09 AM, "Jay R. Ashworth" wrote: > >> I was wondering how long it would be before someone brought up the case > >> for Lynx. Blind people I had not though about, although I had thought > >> about text based reverse turing tests. > > > > :-) > > Lynx access is a really gnarly issue. Lynx usage on my sites has gone from > about 4% a couple of years ago, to < 1% these days, from what I've seen. On > the other hand, Lynx is the litmus test for sight-limited access tools. If > it don't work with lynx, you lock out those with seeing problems (and with a > mother who has some macular degeneration, I'm a bit enlightened by those > issues. Thank god for Macs and the ability to make font sizes bigger...) > > While I'll happily tell the "I don't like cookies" people to get over it, Well, actually, there are still a couple browsers that don't *do* cookies. 2.8.3, I think, doesn't do persistence, yet. I'm not sure if GoWeb does or not... > Lynx access isn't something I can or will easily blow off. And something > geeks tend not to think of, you start getting into issues of ADA compliance > issues, which is a non-trivial issue we haven't even started thinking about > here... Was thinking about that, yes. :-) > > It's the browser on my wireless handheld, and, in general, it doesn't > > handle images *at all*. Nor will the microbrowsers on some people's > > cell phones. > > Yup. And while I'd say today it's not a huge issue, 2-3 years down the road, > when the version of mailman we're currently noodging over gets into wide > usage, it'll be there, and it'll only become more endemic. If you design > stuff like this for what's Out There today, by the time it's written, it'll > be missing What's Coming... My outlook exactly. I like to try to keep people honest; it ain't easy. > >> So one solution would be to have both public and private archives. The > >> public archives have the email addresses obfuscated in some way, the > >> private archives would not. > > > > Oh. We're talking about *archives*? Silly me. I thought we were > > talking about maintainer addresses on sign-up pages. > > We're talking about both, actually. It's a floor wax and a dessert topping! You got that backwards, Chuq. :-) > > It's ASCII text. It's useful. Making it into something else makes it > > less useful, > > But it's the kind of tradeoff we have to consider -- we ARE going to have to > give up some stuff in one place to make improvements in another. You aren't > going to find a way to better protect the admins without cost in usability > somewhere. It's a no-free-lunch situation, or we would have solved it > already. The key is to understand the situation and find the most > appropriate compromise, because a solution without compromise doesn't seem > to exist. Yeah, cost-benefit analyses are hell, ain't they? The whole topic is probably going to drve us all plaid... Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Wed Feb 20 18:15:33 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 10:15:33 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020220123155.18818@scfn.thpl.lib.fl.us> Message-ID: On 2/20/02 9:31 AM, "Jay R. Ashworth" wrote: > But I still think it's important to keep firmly uppermost in our minds > here that the spam is not *caused* by the mailing list. > > Nor is it caused by Google > > It's *caused* by the spammers. And burglary is not caused by my owning nice things, either. It's caused by burglars. But that's no excuse to not put locks on the doors. > I realize that we have practical considerations to deal with which are > much closer to our feet, but I think that it's quite important that we > don't lose sight of the forest for the trees. See, here's our disagreement here. You're saying "put the damn burglars in jail already!" and I'm saying "I agree, but until that's done, I still think I'm installing that deadbolt on the front door". You're right, Jay, but does being right matter? Unless you know how to stop the spammers, it's a pyhrric victory -- because it does nothing to protect yourself from the spammers. Even with a good deadbolt, burglaries still happen. Is that an excuse not to put the deadbolt on in the first place? No. > I personally can't think of any method of programmatically obscuring > email addresses that can't be programmatically reversed. Have you seen what slashdot is doing? I think it has promise, because while it's still reversible programmatically, it makes it much more difficult to do. Will they still get harvested? Most likely. But not nearly as quickly as most other sites, and it's going to make the spambots crazy trying to eat each page looking to figure out if it knows which obfuscation to de-obfuscate. But I've been thinking about this, and I want to throw a couple of ideas out. I'm speaking just of the admin-access issue, not archives. Admin-access has three components to it, all in conflict. 1) The list admin needs to be accessible to everyone, not just subscribers. 2) the list admin shouldn't be an open target to spam. 3) Someone has to be accessible for problem reports even if the Mailman system is malfunctioning. That third point is a bit of a shift. I've come to the thought (and we can argue it) that LIST admins don't need to be accessible if MAILMAN fails. The MAILMAN admin does. And I think the chances are good that the MAILMAN admin is more likely than not also the person who gets abuse@, root@, postmaster@, so the SITE admin mailbox is already wide open to all these idiots. Making it wide open to mailman spam simply isn't significant. That, basically, allows us to stuff mailtos somewhere pointing to an address you can mail to to report site failures. I'll even go farther and say that address can simply be on a web page, not linked to a Mailto, and if you really, reallly want, obscure it further as a JPG or something. But I think that's all overkill, given that spammers now automatically spam root/postmaster/etc on domains anyway. That takes care of the "access in case of failure" mode, mostly by, frankly, simply annointing ONE person (the site admin) as "it" for open access. Not great, but it's sure better than making all admins deal with it. That then allows us to deal with (1) and (2). Which means we can now put admin access behind some kind of web interface. And - we already have 80% of that, in the current admin interface. So I recommend this: You no longer advertise admin's real addresses. Instead, you advertise a feedback that sends messages to the admin, to discourage mailing directly. A year ago, I probably would have insisted on SOME kind of email contact point, but frankly -- the percentage of users who can't use a web page is pretty much zero now. when you contact a list admin, that message is sent in like existing admin stuff -- the the mailman/admindb/listname page. The admin stuff is extended to not only handle moderation requests, but also to handle admin email, allowing an admin to delete, respond, send a standard form letter, forward, or whatever. And since 2.1 has better filtering capabilities, we get those filtering capabilities for free on incoming admin email. And this stuff isn't thrown in an admin's mailbox -- it's dealt with as part of the normal admin list functions, reducing the interruption/hassle factor. And the admin addresses won't end up in spammer databases, because they no longer exist. Thoughts? It's not perfect, but now only one guy is "it", and the admins are accessible but protected -- and can better separate their list-admin "me" from their real "me" on top of it. And the site admin is more likely IMHO to be capable of managing their mailbox from spam than forcing all list admins to learn how to do that... -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From chuqui@plaidworks.com Wed Feb 20 18:17:58 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 10:17:58 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: <20020220124540.45108@scfn.thpl.lib.fl.us> Message-ID: On 2/20/02 9:45 AM, "Jay R. Ashworth" wrote: >> While I'll happily tell the "I don't like cookies" people to get over it, > > Well, actually, there are still a couple browsers that don't *do* > cookies. 2.8.3, I think, doesn't do persistence, yet. My answer: get a real browser... (grin) >> geeks tend not to think of, you start getting into issues of ADA compliance >> issues, which is a non-trivial issue we haven't even started thinking about >> here... > > Was thinking about that, yes. :-) Yeah. I'd really hate to see Mailman thrown out of, say, all usage in the US government because it's not ADA compliant. If we want to turn Mailman into the replacement defacto standard for majordomo, things like that can't happen. > Yeah, cost-benefit analyses are hell, ain't they? > > The whole topic is probably going to drve us all plaid... Somedays, I think that's all I do any more... -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From jwblist@olympus.net Wed Feb 20 20:26:39 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 20 Feb 2002 12:26:39 -0800 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: References: Message-ID: At 10:15 -0800 2/20/2002, Chuq Von Rospach wrote: >That, basically, allows us to stuff mailtos somewhere pointing to an address >you can mail to to report site failures. I'll even go farther and say that >address can simply be on a web page, not linked to a Mailto, and if you >really, reallly want, obscure it further as a JPG or something. But I think >that's all overkill, given that spammers now automatically spam >root/postmaster/etc on domains anyway. Which (as the reader of many of those, and as the person who adds content filters) I find amusing: they deliberately attract the attention of the one most likely to do something. I guess it makes sense when they think about individual's machines sitting there accepting mail; it doesn't make sense when then send to a server which serves lots of users. It reminds me of the punt returner signalling for a fair catch when the ball will come down near the goal line. What that says to the onrushing troops is "ignore me and my teammates: we can't hurt you anyhow...go after the ball and keep it this side of the line." Exactly what the troops' coach wants them to be told. >So I recommend this: > >You no longer advertise admin's real addresses. Instead, you advertise a >feedback that sends messages to the admin, to discourage mailing directly. >A year ago, I probably would have insisted on SOME kind of email contact >point, but frankly -- the percentage of users who can't use a web page is >pretty much zero now. [Good justification snipped.] I think you're on to something, Chuq. It also helps those admins who prefer to use a role address rather than a personal one, as things stand now. Saves inventing yet another of those which isn't specially handled by the MTA/Mailman combination. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jra@baylink.com Wed Feb 20 20:41:57 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 15:41:57 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... In-Reply-To: ; from Chuq Von Rospach on Wed, Feb 20, 2002 at 10:17:58AM -0800 References: <20020220124540.45108@scfn.thpl.lib.fl.us> Message-ID: <20020220154157.03733@scfn.thpl.lib.fl.us> On Wed, Feb 20, 2002 at 10:17:58AM -0800, Chuq Von Rospach wrote: > On 2/20/02 9:45 AM, "Jay R. Ashworth" wrote: > >> While I'll happily tell the "I don't like cookies" people to get over it, > > > > Well, actually, there are still a couple browsers that don't *do* > > cookies. 2.8.3, I think, doesn't do persistence, yet. > > My answer: get a real browser... (grin) On behalf of vt102 lovers everywhere, "Hey!" > >> geeks tend not to think of, you start getting into issues of ADA > >> compliance issues, which is a non-trivial issue we haven't even > >> started thinking about here... > > > > Was thinking about that, yes. :-) > > Yeah. I'd really hate to see Mailman thrown out of, say, all usage in > the US government because it's not ADA compliant. If we want to turn > Mailman into the replacement defacto standard for majordomo, things > like that can't happen. Egg-salad point. > > Yeah, cost-benefit analyses are hell, ain't they? > > > > The whole topic is probably going to drve us all plaid... > > Somedays, I think that's all I do any more... I can't *begin* to imagine why... Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 20 21:18:29 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 16:18:29 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: ; from Chuq Von Rospach on Wed, Feb 20, 2002 at 10:15:33AM -0800 References: <20020220123155.18818@scfn.thpl.lib.fl.us> Message-ID: <20020220161829.34707@scfn.thpl.lib.fl.us> On Wed, Feb 20, 2002 at 10:15:33AM -0800, Chuq Von Rospach wrote: > On 2/20/02 9:31 AM, "Jay R. Ashworth" wrote: > > But I still think it's important to keep firmly uppermost in our minds > > here that the spam is not *caused* by the mailing list. > > > > Nor is it caused by Google > > > > It's *caused* by the spammers. > > And burglary is not caused by my owning nice things, either. It's caused by > burglars. But that's no excuse to not put locks on the doors. A mailing list -- a publically accessible mailing list -- isn't your house. It's the city library. Those are typically not locked up as tightly your house, during the day. > > I realize that we have practical considerations to deal with which are > > much closer to our feet, but I think that it's quite important that we > > don't lose sight of the forest for the trees. > > See, here's our disagreement here. You're saying "put the damn burglars in > jail already!" and I'm saying "I agree, but until that's done, I still think > I'm installing that deadbolt on the front door". > > You're right, Jay, but does being right matter? Unless you know how to stop > the spammers, it's a pyhrric victory -- because it does nothing to protect > yourself from the spammers. *I* protect *myself* from the spammers, actually, thank you very much. Perhaps that sounds elitist. So be it. > Even with a good deadbolt, burglaries still happen. Is that an excuse not to > put the deadbolt on in the first place? No. Well, again: would you deadbolt the public library? > > I personally can't think of any method of programmatically obscuring > > email addresses that can't be programmatically reversed. > > Have you seen what slashdot is doing? I think it has promise, because while > it's still reversible programmatically, it makes it much more difficult to > do. Will they still get harvested? Most likely. But not nearly as quickly as > most other sites, and it's going to make the spambots crazy trying to eat > each page looking to figure out if it knows which obfuscation to > de-obfuscate. Actually, no, I haven't bothered with /. in some time... I'll take a look. [ looks ] Hmmm... there are a couple of ways that you *don't* want to despam an adress; hope they didn't hit any of them. > But I've been thinking about this, and I want to throw a couple of ideas > out. I'm speaking just of the admin-access issue, not archives. > > Admin-access has three components to it, all in conflict. > > 1) The list admin needs to be accessible to everyone, not just subscribers. > > 2) the list admin shouldn't be an open target to spam. > > 3) Someone has to be accessible for problem reports even if the Mailman > system is malfunctioning. > > That third point is a bit of a shift. I've come to the thought (and we can > argue it) that LIST admins don't need to be accessible if MAILMAN fails. The > MAILMAN admin does. And I think the chances are good that the MAILMAN admin > is more likely than not also the person who gets abuse@, root@, postmaster@, > so the SITE admin mailbox is already wide open to all these idiots. Making > it wide open to mailman spam simply isn't significant. I don't need to argue it; I concur: if the server falls over, the server admin is the target. And yeah, they should be wearing armor already. > That, basically, allows us to stuff mailtos somewhere pointing to an address > you can mail to to report site failures. I'll even go farther and say that > address can simply be on a web page, not linked to a Mailto, and if you > really, reallly want, obscure it further as a JPG or something. But I think > that's all overkill, given that spammers now automatically spam > root/postmaster/etc on domains anyway. > > That takes care of the "access in case of failure" mode, mostly by, frankly, > simply annointing ONE person (the site admin) as "it" for open access. Not > great, but it's sure better than making all admins deal with it. No problem there. > That then allows us to deal with (1) and (2). Which means we can now put > admin access behind some kind of web interface. And - we already have 80% of > that, in the current admin interface. > > So I recommend this: > > You no longer advertise admin's real addresses. Instead, you advertise a > feedback that sends messages to the admin, to discourage mailing directly. > A year ago, I probably would have insisted on SOME kind of email contact > point, but frankly -- the percentage of users who can't use a web page is > pretty much zero now. This is, alas, a different topic. When I send a complaint to someone about something, *I want a copy of that message in my outbox*. I *hate* mail forms. With an unbridled, flaming passion. They usually don't spell check; they don't get my sig file, etc, etc, ad nauseum. I can at least tolerate it, if you'll carbon me a copy, but it's still suboptimal. > And since 2.1 has better filtering capabilities, we get those filtering > capabilities for free on incoming admin email. And this stuff isn't thrown > in an admin's mailbox -- it's dealt with as part of the normal admin list > functions, reducing the interruption/hassle factor. And the admin addresses > won't end up in spammer databases, because they no longer exist. Now *that* part, I like. > Thoughts? It's not perfect, but now only one guy is "it", and the admins are > accessible but protected -- and can better separate their list-admin "me" > from their real "me" on top of it. And the site admin is more likely IMHO to > be capable of managing their mailbox from spam than forcing all list admins > to learn how to do that... Personally, I'm a little tired of "But I'm too lazy" (to learn how to set up spam filters) being an acceptable excuse. If you can't find someone to run your list with a clue, then maybe you shouldn't have a list. But that's why *I'm* not the Mailman product line manager. :-) Cheers, -- jra -- Jay R. Ashworth jra@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") From dm-temp-310102@nyc.rr.com Wed Feb 20 21:37:27 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Wed, 20 Feb 2002 16:37:27 -0500 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: Message-ID: <002701c1ba56$cdf035b0$56296c42@damien> > Have you seen what slashdot is doing? I think it has promise, > because while it's still reversible programmatically, it > makes it much more difficult to do. Will they still get > harvested? Most likely. But not nearly as quickly as most > other sites, and it's going to make the spambots crazy trying > to eat each page looking to figure out if it knows which > obfuscation to de-obfuscate. What exactly is slashdot doing? As far as I can see thay are using url/cgi encoding in the email address. This is trivial to circumvent, as is using html entities, or any other reversible scheme. The use of images for email addresses is the only scheme that will raise the cost of harvesting high enough to make it effectively impossible. You can think of it as either hash-cash for email addresses, or a reverse turing test, depending on your point of view. From chuqui@plaidworks.com Wed Feb 20 21:42:34 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 13:42:34 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020220161829.34707@scfn.thpl.lib.fl.us> Message-ID: On 2/20/02 1:18 PM, "Jay R. Ashworth" wrote: >> And burglary is not caused by my owning nice things, either. It's caused by >> burglars. But that's no excuse to not put locks on the doors. > > A mailing list -- a publically accessible mailing list -- isn't your > house. It's the city library. Those are typically not locked up as > tightly your house, during the day. You misread my analogy, or perhaps it's a philsophical disagreement. A library is not locked up as tightly as a house, but it also has a person in charge of watching the door to make sure stuff doesn't leave if it's not checked out, and most of them have door sensors now, too. And any decent library also has a rare books room, which IS tightly locked up. And while the content of a mail list qualifies as a public library to some degree, the subscriber addresses live in that rare book room. >> You're right, Jay, but does being right matter? Unless you know how to stop >> the spammers, it's a pyhrric victory -- because it does nothing to protect >> yourself from the spammers. > > *I* protect *myself* from the spammers, actually, thank you very much. > > Perhaps that sounds elitist. So be it. So, you're saying because you protect yourself from the spammers, that EVERYONE should, too? To move back to the burglary analogy, you've just told me that (a) if you do get burgled, you won't call the police, and (b), the police department should be shut down, because everyone should take care of themselves. Which, I guess, means if you get burgled, you'll pull out the gun, find the burglar, and shoot him yourself, right? Jay, do you see the chaos that causes? You define anarchy, which is, to a degree, what we have in email today, but you then go one step further, and claim that it should be anarchy. My argument is that central tools that CAN do things should do things, because they help a common good -- the difference between a trained police force and a hundred citizens with guns looking for burglars. You get economies of scale that individuals "protecting themselves" can't get, plus, of course, there's nothing keeping you from doing MORE. I just don't understand why you seem to be insisting that because YOU can do it, everyone has to and mailman shouldn't. Mailman's not written for you. It's written for many people with many needs, not all of them as competent in these areas as you. Why force them all to do it your way? >> Even with a good deadbolt, burglaries still happen. Is that an excuse not to >> put the deadbolt on in the first place? No. > > Well, again: would you deadbolt the public library? See above. You don't get the analogy right. > This is, alas, a different topic. > > When I send a complaint to someone about something, *I want a copy of > that message in my outbox*. I *hate* mail forms. With an unbridled, > flaming passion. They usually don't spell check; they don't get my sig > file, etc, etc, ad nauseum. That's nice. But -- does that override the need to protect the admin from spammers? Again, do we only do things that you approve of, or for the common good, is this something where you compromise your position? See, my problem here is that you seem to have defined "no good" as "I don't like it". Your view is one, but not the only one. And you don't seem to be looking at mailman as a global tool, but mailman as your tool. > Personally, I'm a little tired of "But I'm too lazy" (to learn how to > set up spam filters) being an acceptable excuse. If you can't find > someone to run your list with a clue, then maybe you shouldn't have a > list. Personally, I find that attitude quite arrogant. Not everyone is you, or wants to be you. Or me. Or Barry. If you want to design things for you, do whatever you want. When you start designing for an open population, you have to start checking the ego at the door. This attitude, I'm afraid, doesn't, at least in my mind. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. From chuqui@plaidworks.com Wed Feb 20 21:50:06 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 13:50:06 -0800 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: <002701c1ba56$cdf035b0$56296c42@damien> Message-ID: On 2/20/02 1:37 PM, "Damien Morton" wrote: > As far as I can see thay are using url/cgi encoding in the email > address. This is trivial to circumvent, as is using html entities, or > any other reversible scheme. With a constantly varying algorithm. So they obfuscate, but they never obfuscate in a predictable way. Which means if you're a spambot, you have to look at every byte of every page and attempt to de-obfuscate it in every possible way to see if it's obfuscated. You CAN do it, but you make it computationally massively expensive. -- Chuq Von Rospach (chuqui@plaidworks.com -- http://www.chuqui.com/) Will Geek for hardware. No! No! Dead girl, OFF the table! From jwblist@olympus.net Wed Feb 20 22:13:20 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 20 Feb 2002 14:13:20 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: At 13:42 -0800 2/20/2002, Chuq Von Rospach wrote: >And any decent library also has a rare books room, which IS tightly locked >up. And while the content of a mail list qualifies as a public library to >some degree, the subscriber addresses live in that rare book room. At least in Chuq's context, in which Apple claims in their privacy policy to protect the addresses of us innocent subscribers to their lists. That context may not match the context of other list operators, who may feel that the subscribers are out in the main stacks somewhere. Or in a drawer in the librarian's desk for "suitable" review. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From chuqui@plaidworks.com Wed Feb 20 22:31:54 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 14:31:54 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: On 2/20/02 2:13 PM, "John W Baxter" wrote: > At least in Chuq's context, in which Apple claims in their privacy policy > to protect the addresses of us innocent subscribers to their lists. > > That context may not match the context of other list operators, who may > feel that the subscribers are out in the main stacks somewhere. Or in a > drawer in the librarian's desk for "suitable" review. Both true, but I have two points to carry this further. 1) I think a tool like Mailman has to implement to the highest-reasonable security, so if people want to be looser, fine. It's easier to loosen the reins than expect JrandomeUser to implement extra features on an ad hoc basis. I also think a tool like Mailman ought to try to set a "best practices" model for how it operates. Mailman should set the standard for how we think mail lists ought to be run, not be the least common denominator that everyone has to hack extras into to make it fit their needs. 2) admins can set whatever policies they want -- but I think it's important they disclose them, so users can make informed choices. That includes, frankly, letting users know their addresses are potentially exposed to spammers, so if a user is sensitive to this, they can choose to not subscribe, or to leave the list. I'm not telling admins what their policies need to be, but I do think Mailman needs to understand it's role as a "best practices" tool -- and I do feel strongly that whatever an admin does, they do so in a mode that involves informed consent with their users. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From dale@newfield.org Wed Feb 20 22:43:41 2002 From: dale@newfield.org (Dale Newfield) Date: Wed, 20 Feb 2002 17:43:41 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: On Wed, 20 Feb 2002, Chuq Von Rospach wrote: > I'm not telling admins what their policies need to be, but I do think > Mailman needs to understand it's role as a "best practices" tool -- and > I do feel strongly that whatever an admin does, they do so in a mode > that involves informed consent with their users. So should there be a user-settable option "don't archive my posts"? (Or a header that can be set to cause a message not to get archived?) -Dale From chuqui@plaidworks.com Wed Feb 20 23:39:57 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 15:39:57 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: On 2/20/02 2:43 PM, "Dale Newfield" wrote: > (Or a header that can be set to cause a message not to get archived?) That already exists -- X-No-Archive, which I believe pipermail understands. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From dm-temp-310102@nyc.rr.com Wed Feb 20 23:58:33 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Wed, 20 Feb 2002 18:58:33 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: <000101c1ba6a$868027d0$56296c42@damien> Anyone have any idea how I set X-No-archive on all emails being sent to a mailman list? Im using Outlook 2002. As far as I know there is no ability to access internet headers in Outlook 2002 without the use of unusual COM objects to get at extended MAPI properties. > -----Original Message----- > From: mailman-developers-admin@python.org > [mailto:mailman-developers-admin@python.org] On Behalf Of > Chuq Von Rospach > Sent: Wednesday, 20 February 2002 18:40 > To: Dale Newfield; mailman-developers@python.org > Subject: Re: [Mailman-Developers] Interesting study -- spam > on postedaddresses... > > > On 2/20/02 2:43 PM, "Dale Newfield" wrote: > > > (Or a header that can be set to cause a message not to get > archived?) > > That already exists -- X-No-Archive, which I believe > pipermail understands. > > > -- > Chuq Von Rospach, Architech > chuqui@plaidworks.com -- http://www.chuqui.com/ > > Stress is when you wake up screaming and you realize you > haven't fallen asleep yet. > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailma> n-developers > From jra@baylink.com Thu Feb 21 01:36:52 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 20:36:52 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: ; from Chuq Von Rospach on Wed, Feb 20, 2002 at 01:42:34PM -0800 References: <20020220161829.34707@scfn.thpl.lib.fl.us> Message-ID: <20020220203652.42377@scfn.thpl.lib.fl.us> On Wed, Feb 20, 2002 at 01:42:34PM -0800, Chuq Von Rospach wrote: > On 2/20/02 1:18 PM, "Jay R. Ashworth" wrote: > >> And burglary is not caused by my owning nice things, either. It's caused by > >> burglars. But that's no excuse to not put locks on the doors. > > > > A mailing list -- a publically accessible mailing list -- isn't your > > house. It's the city library. Those are typically not locked up as > > tightly your house, during the day. > > You misread my analogy, or perhaps it's a philsophical disagreement. A A touch of both, I think. > library is not locked up as tightly as a house, but it also has a person in > charge of watching the door to make sure stuff doesn't leave if it's not > checked out, and most of them have door sensors now, too. Stipulated. > And any decent library also has a rare books room, which IS tightly locked > up. And while the content of a mail list qualifies as a public library to > some degree, the subscriber addresses live in that rare book room. Hmmm... > >> You're right, Jay, but does being right matter? Unless you know how to stop > >> the spammers, it's a pyhrric victory -- because it does nothing to protect > >> yourself from the spammers. > > > > *I* protect *myself* from the spammers, actually, thank you very much. > > > > Perhaps that sounds elitist. So be it. > > So, you're saying because you protect yourself from the spammers, that > EVERYONE should, too? As a matter of fact, yes, I am saying that. There are cost-free, not especially difficult to set up, facilities for all environments that will protect you from the major portion of incoming unsolicited commercial email -- some ISP's run then for you, and are *trading* on the fact. So yes, if spam troubles people, they should indeed do something about it. That's *not* to say that I don't think something should -- and can -- be done at the source, they're two different topics. > To move back to the burglary analogy, you've just told me that (a) if you do > get burgled, you won't call the police, and (b), the police department > should be shut down, because everyone should take care of themselves. Which, > I guess, means if you get burgled, you'll pull out the gun, find the > burglar, and shoot him yourself, right? Actually, yes. Gun control is being able to hit your target. Anyone foolish enough to burgle my house in the middle of the night is running (hopefully knowingly) the risk of getting shot. > Jay, do you see the chaos that causes? You define anarchy, which is, to a > degree, what we have in email today, but you then go one step further, and > claim that it should be anarchy. My argument is that central tools that CAN > do things should do things, because they help a common good -- the > difference between a trained police force and a hundred citizens with guns > looking for burglars. You get economies of scale that individuals > "protecting themselves" can't get, plus, of course, there's nothing keeping > you from doing MORE. I just don't understand why you seem to be insisting > that because YOU can do it, everyone has to and mailman shouldn't. Because I've been around long enough -- not that you haven't certainly -- to see the value in the way things are if the tool does *not* circumscribe useful things, and I do not see fit to let the Bad Guys make that utility go away. Aren't we having this argument with John Ashcroft right now about US civil rights? > Mailman's not written for you. It's written for many people with many needs, > not all of them as competent in these areas as you. Why force them all to do > it your way? Cause my way is right? :-) Certainly there are cost benefit analyses to be made here, with many different constituencies' requirements to be considered. And certainly, also, some of these requirements collide head on. That's not surprising. The customary solution is provide {both,all the} options, and document the costs and benefits, try to choose a sane default, and let the operators decide. I'm sure that is what will happen here, too. But I won't let that keep me from stumping for the approach I think is best, by any means. And if my approach seems impractical because of "the way the world is", well, how do we think other changes to make the world better have come about..? > > Well, again: would you deadbolt the public library? > > See above. You don't get the analogy right. No, I merely don't value the email address's privacy as highly as you do. I get about 50 spam a day in 200 new messages including about 14 mailing lists -- I'm entitled to hold that opinion if I want. You *can't* make addresses overly private; they cease to be usable. At least, given the supporting tools and infrastructure we have today. > > When I send a complaint to someone about something, *I want a > > copy of that message in my outbox*. I *hate* mail forms. With an > > unbridled, flaming passion. They usually don't spell check; they > > don't get my sig file, etc, etc, ad nauseum. > > That's nice. But -- does that override the need to protect the admin > from spammers? Again, do we only do things that you approve of, or for > the common good, is this something where you compromise your position? The admin works for me. Not the other way around. Apologies if you think that sounds snotty or self-important. I expect people who stick their head up outof the foxhole (or, indeed, travel in questionable areas) to wear a helmet, yes. > See, my problem here is that you seem to have defined "no good" as "I > don't like it". Your view is one, but not the only one. And you don't > seem to be looking at mailman as a global tool, but mailman as your > tool. I'm sorry you think that way about what I'm saying. I'm trying to explain my motivations for having these opinions; I gather I'm not succeeding. > > Personally, I'm a little tired of "But I'm too lazy" (to learn how > > to set up spam filters) being an acceptable excuse. If you can't > > find someone to run your list with a clue, then maybe you shouldn't > > have a list. > > Personally, I find that attitude quite arrogant. Not everyone is you, > or wants to be you. Or me. Or Barry. If you want to design things > for you, do whatever you want. When you start designing for an open > population, you have to start checking the ego at the door. This > attitude, I'm afraid, doesn't, at least in my mind. Again, apologies. If you can convince me that one Right outweighs the other one, for a sufficiently statistically significant number of possible cases, I'll change my outlook. I don't claim to be perfect. But I don't form my opinions for fun, nor in total ignorance. And I *have* been doing this for 18 years. No, 19. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Thu Feb 21 01:38:51 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 20:38:51 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: ; from Chuq Von Rospach on Wed, Feb 20, 2002 at 02:31:54PM -0800 References: Message-ID: <20020220203851.04739@scfn.thpl.lib.fl.us> On Wed, Feb 20, 2002 at 02:31:54PM -0800, Chuq Von Rospach wrote: > 1) I think a tool like Mailman has to implement to the highest-reasonable > security, so if people want to be looser, fine. It's easier to loosen the > reins than expect JrandomeUser to implement extra features on an ad hoc > basis. I also think a tool like Mailman ought to try to set a "best > practices" model for how it operates. Mailman should set the standard for > how we think mail lists ought to be run, not be the least common denominator > that everyone has to hack extras into to make it fit their needs. And, to clarify my opinion, I don't disagree with this in the least. That doesn't mean I think it's *right*. > 2) admins can set whatever policies they want -- but I think it's important > they disclose them, so users can make informed choices. That includes, > frankly, letting users know their addresses are potentially exposed to > spammers, so if a user is sensitive to this, they can choose to not > subscribe, or to leave the list. *Definitely... but people should realize that that's a possibilty *any time the give their address out*. > I'm not telling admins what their policies need to be, but I do think > Mailman needs to understand it's role as a "best practices" tool -- and I do > feel strongly that whatever an admin does, they do so in a mode that > involves informed consent with their users. Surely. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Thu Feb 21 01:41:15 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 20:41:15 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000101c1ba6a$868027d0$56296c42@damien>; from Damien Morton on Wed, Feb 20, 2002 at 06:58:33PM -0500 References: <000101c1ba6a$868027d0$56296c42@damien> Message-ID: <20020220204115.12175@scfn.thpl.lib.fl.us> On Wed, Feb 20, 2002 at 06:58:33PM -0500, Damien Morton wrote: > Anyone have any idea how I set X-No-archive on all emails being sent to > a mailman list? > > Im using Outlook 2002. As far as I know there is no ability to access > internet headers in Outlook 2002 without the use of unusual COM objects > to get at extended MAPI properties. First, get a real email program. :-) Secondly, if Piper implements this the same way that Google does, you can put it in as the first line of the body, starting in column 1, followed by an (additional) blank line, and it will still take effect. Of course, it's pretty much immaterial, since if someome quotes you, *their* message may not have the header. Are we beginning to understand the scope of this issue? :-)_ Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Thu Feb 21 02:49:53 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 18:49:53 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020220203652.42377@scfn.thpl.lib.fl.us> Message-ID: On 2/20/02 5:36 PM, "Jay R. Ashworth" wrote: >> So, you're saying because you protect yourself from the spammers, that >> EVERYONE should, too? > > As a matter of fact, yes, I am saying that. There are cost-free, not > especially difficult to set up, facilities for all environments Okay, what system exists for AOL users? How do you set up a system if you live on a corporate account with an imap mail box and no shell access to the server? What about a hotmail or yahoo account? Show me the systems, jay, that work for real people, not us geeks that run our own boxes on our own desks. >> To move back to the burglary analogy, you've just told me that (a) if you do >> get burgled, you won't call the police, and (b), the police department >> should be shut down, because everyone should take care of themselves. Which, >> I guess, means if you get burgled, you'll pull out the gun, find the >> burglar, and shoot him yourself, right? > > Actually, yes. Gun control is being able to hit your target. Anyone > foolish enough to burgle my house in the middle of the night is running > (hopefully knowingly) the risk of getting shot. Only if you're home. And if he's IN your home, be my guest. But your analogy implies that you don't believe in the police, you believe in hunting him down and shooting him whenever you find him. Once you leave the confines of your property, your rights change radically here. > Because I've been around long enough -- not that you haven't certainly -- > to see the value in the way things are if the tool does *not* > circumscribe useful things, and I do not see fit to let the Bad Guys > make that utility go away. Aren't we having this argument with John > Ashcroft right now about US civil rights? We? No, actually. > Cause my way is right? :-) Nope. Don't buy that. Especially for all those list admins in the three cases I gave you above. Once you solve THOSE problems, though, maybe we can start to talk. I'm really curious how you'll solve the problem of my mother doing her own anti-spam processing on her earthlink account. Because if you can't solve that problem, or the AOL problem -- you can't solve the problem, except for us geeks, and we can't write Mailman just for geeks. See, that's the other failure of your analogy. You assume everyone WANTS to have a gun and hunt down their own burglar. The vast majority of the public doesn't. They want to call the police. > No, I merely don't value the email address's privacy as highly as you > do. Fair enough. But I think that disqualifies you from making design decisions about privacy issues then. It's Barry's call, but I'd argue that you take a position that is unacceptable in the design of this software for these issue. >> That's nice. But -- does that override the need to protect the admin >> from spammers? Again, do we only do things that you approve of, or for >> the common good, is this something where you compromise your position? > > The admin works for me. Not the other way around. > > Apologies if you think that sounds snotty or self-important. Yes, it does. > Again, apologies. If you can convince me that one Right outweighs the > other one, for a sufficiently statistically significant number of > possible cases, I'll change my outlook. I don't claim to be perfect. Solve the problem for real users (the AOL account. The corporate IMAP account. The earthlink account. The hotmail account) and then maybe we'll talk. Until then, your solution only works for geeks, and is unacceptable for a tool designed to be used by regular people, not JUST geeks. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From jra@baylink.com Thu Feb 21 03:26:41 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 20 Feb 2002 22:26:41 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: ; from Chuq Von Rospach on Wed, Feb 20, 2002 at 06:49:53PM -0800 References: <20020220203652.42377@scfn.thpl.lib.fl.us> Message-ID: <20020220222641.04954@scfn.thpl.lib.fl.us> On Wed, Feb 20, 2002 at 06:49:53PM -0800, Chuq Von Rospach wrote: > On 2/20/02 5:36 PM, "Jay R. Ashworth" wrote: > >> So, you're saying because you protect yourself from the spammers, that > >> EVERYONE should, too? > > > > As a matter of fact, yes, I am saying that. There are cost-free, not > > especially difficult to set up, facilities for all environments > > Okay, what system exists for AOL users? How do you set up a system if you > live on a corporate account with an imap mail box and no shell access to the > server? What about a hotmail or yahoo account? > > Show me the systems, jay, that work for real people, not us geeks that run > our own boxes on our own desks. Volvos are very safe, Toyotas are in the middle, sand rails are *just not safe at all*. The risks are easy to discover for each category, and the same is true for choosing an email service. I overstated *slightly* in saying "all" environments; let me rephrase it: For any given business or personal environment, a solution exists to be chosen which permits the filtering of unwanted mail. People can choose this solution, or they can choose others. In the corporate situation, the responsible party is the MIS department, for whom this freedom of choice also exists. Hotmail and Yahoo are jokes. They're free; you take what you're paying for. As for IMAP, the Bat will filter just fine, thanks. > >> To move back to the burglary analogy, you've just told me that (a) > >> if you do get burgled, you won't call the police, and (b), the > >> police department should be shut down, because everyone should > >> take care of themselves. Which, I guess, means if you get burgled, > >> you'll pull out the gun, find the burglar, and shoot him yourself, > >> right? > > > > Actually, yes. Gun control is being able to hit your target. Anyone > > foolish enough to burgle my house in the middle of the night is > > running (hopefully knowingly) the risk of getting shot. > > Only if you're home. And if he's IN your home, be my guest. But your > analogy implies that you don't believe in the police, you believe in > hunting him down and shooting him whenever you find him. Once you > leave the confines of your property, your rights change radically > here. Certainly. > > Because I've been around long enough -- not that you haven't > > certainly -- to see the value in the way things are if the tool does > > *not* circumscribe useful things, and I do not see fit to let the > > Bad Guys make that utility go away. Aren't we having this argument > > with John Ashcroft right now about US civil rights? > > We? No, actually. Ok. *Lots* of people are having that argument with the AG, and I'm one of them. > > Cause my way is right? :-) > > Nope. Don't buy that. Especially for all those list admins in the > three cases I gave you above. Once you solve THOSE problems, though, > maybe we can start to talk. I'm really curious how you'll solve > the problem of my mother doing her own anti-spam processing on her > earthlink account. Because if you can't solve that problem, or the AOL > problem -- you can't solve the problem, except for us geeks, and we > can't write Mailman just for geeks. Spaminator. You picked precisely the example I had in mind. If the masses *demand* solutions, those solutions *will* happen. > See, that's the other failure of your analogy. You assume everyone > WANTS to have a gun and hunt down their own burglar. The vast majority > of the public doesn't. They want to call the police. Hmmm... > > No, I merely don't value the email address's privacy as highly as > > you do. > > Fair enough. But I think that disqualifies you from making design > decisions about privacy issues then. It's Barry's call, but I'd argue > that you take a position that is unacceptable in the design of this > software for these issue. See *all* my other commentary on the specific topic of "design decisions for Mailman"; I'm sure Barry will chime in here sometime soon... > >> That's nice. But -- does that override the need to protect the > >> admin from spammers? Again, do we only do things that you approve > >> of, or for the common good, is this something where you compromise > >> your position? > > > > The admin works for me. Not the other way around. > > > > Apologies if you think that sounds snotty or self-important. > > Yes, it does. > > > Again, apologies. If you can convince me that one Right outweighs > > the other one, for a sufficiently statistically significant number > > of possible cases, I'll change my outlook. I don't claim to be > > perfect. > > Solve the problem for real users (the AOL account. The corporate IMAP > account. The earthlink account. The hotmail account) and then maybe > we'll talk. Until then, your solution only works for geeks, and is > unacceptable for a tool designed to be used by regular people, not > JUST geeks. See above: no, some of those cases (specifically Yahoo and Hotmail) are in fact insoluble, but that's *Hotmail* and *Yahoo's* fault, and their user's problem. AOL needs to solve it's own problem -- they've made the bed, their users are laying in it. Deals with the devil never work out well. But perhaps the availability of things like Earthlink and the Mindspring Spaminator will realign the playing field on that point -- Earthlink certainly appears to think so, given what they're spending on ads this year. The IMAP account solution I've mentioned already. And as for Earthlink, well... see above. :-) Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Thu Feb 21 04:06:12 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 20:06:12 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020220222641.04954@scfn.thpl.lib.fl.us> Message-ID: On 2/20/02 7:26 PM, "Jay R. Ashworth" wrote: >> Show me the systems, jay, that work for real people, not us geeks that run >> our own boxes on our own desks. > > Volvos are very safe, Toyotas are in the middle, sand rails are *just > not safe at all*. You're avoiding the issue. If you don't build the system so real people can use it, real people won't. Which means they'll go use something else, so why bother build this at all? > Hotmail and Yahoo are jokes. They're free; you take what you're paying > for. They're popular. And you ignored AOL, the 500 pound gorilla. Just because you don't like them doesn't give you the right to tell others not to use them, just to fit your idea of how this stuff ought to be done. > Spaminator. You picked precisely the example I had in mind. If the > masses *demand* solutions, those solutions *will* happen. Oh, god. You're going to castrate mailman just to try to force users to take up arms in your personal fight? Convince them to join. Don't destroy other tools to try to coerce them into it. Wrong attitude. Sory, I won't buy into it. You can't gut one tool to try to force people into buying into a fight. They aren't stupid -- they don't buy in, they go elsewhere. And I won't support your castrating mailman for a personal agenda for how spam ought to be fought. I'm not interested in those fights. I'm interested in building tools that get the right job done for people. > See above: no, some of those cases (specifically Yahoo and Hotmail) are > in fact insoluble, but that's *Hotmail* and *Yahoo's* fault, and their > user's problem. AOL needs to solve it's own problem -- they've made > the bed, their users are laying in it. Deals with the devil never work > out well. Nope. Sorry. That's a copout. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From dale@newfield.org Thu Feb 21 04:15:14 2002 From: dale@newfield.org (Dale Newfield) Date: Wed, 20 Feb 2002 23:15:14 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000201c1ba6a$8dae61c0$56296c42@damien> Message-ID: On Wed, 20 Feb 2002, Damien Morton wrote: > I still think the email-address-as-jpeg solution is prohibitively > expensive to reverse; effectively impossible for machines, entirely easy > for people. But it does have drawbacks. It only works with graphical browsers. It can't be enlarged for people that have poor vision. It can be reverse-engineered -- all they have to do is decode a single font, then they're all simple to snag. In fact, as someone with lots of computer graphics experience, I'd say it would be almost no harder to write code to decode them than it would be to write code to generate them. > Web Forms for contacting the admin cold. If the admin replies, you can > continue the conversation via email. Right, assuming the web form doesn't break. > Private and Public views of the archives. > > Private archives are restricted to list members and those that can pass > a reverse turing test. People keep using this term, but I'm not sure what they mean, or if I trust that they'd be so reliable... > Public archives render all email addresses as jpegs. If they're automatically generated, it'd be easier to create pngs or gifs, or lots of other formats than jpgs. Think about this, though--how do you actually generate the images and serve them properly without either including the email address in the html code anyway (so the img request specifies what image to generate), or building a whole database mapping arbitrary numbers to email addresses (so they can either be generated on the fly or stored pre-generated). Once you've got that database, why not just have that database front a web form instead of displaying the address? -Dale From stephen@xemacs.org Thu Feb 21 04:23:48 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 21 Feb 2002 13:23:48 +0900 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: References: Message-ID: <87d6yzh38r.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Chuq" == Chuq Von Rospach writes: Chuq> On 2/20/02 1:37 PM, "Damien Morton" Chuq> wrote: >> As far as I can see thay are using url/cgi encoding in the >> email address. This is trivial to circumvent, as is using html >> entities, or any other reversible scheme. Chuq> With a constantly varying algorithm. So they obfuscate, but Chuq> they never obfuscate in a predictable way. Which means if Chuq> you're a spambot, you have to look at every byte of every Chuq> page and attempt to de-obfuscate it in every possible way to Chuq> see if it's obfuscated. You CAN do it, but you make it Chuq> computationally massively expensive. Er, last I heard "massively expensive" ~ "exponential". This is O(n*m) where _n_ is the number of bytes and _m_ is the number of obfuscations, and _m_ is bounded by user patience. Nor do the spammers need to deobfuscate all the obfuscations. They only need enough that they're getting a reasonable harvest rate. But the people who post to /. etc tend to be repeat offenders, and the obfuscation is random. So we lose as soon as the amount of address content obfuscated in this way becomes noticable. And maybe before that, as many spammers seem to take address-hiding as a personal offense, in the same way that crackers view passwords. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From chuqui@plaidworks.com Thu Feb 21 04:48:59 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 20:48:59 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: >> I still think the email-address-as-jpeg solution is prohibitively >> expensive to reverse; effectively impossible for machines, entirely easy >> for people. > > But it does have drawbacks. > > It only works with graphical browsers. This is a very good point. I mentioned ADA compliance yesterday. To be ADA compliant, if you rendered the e-mail address as a graphic, you'd also have to put the text into the ALT tag. Which would enable it for lynx and sight-limited solutions -- and make putting into a graphic kinda meaningless. So you can't use this approach unless you want to ignore the ADA and lock out your blind users from those functions. I'm not willing to make that tradeoff. While I'm not going to live or die on the ADA compliance issue, I think it's important to keep it in mind because it forces us to focus on more than the "easy" case or the "geek" case and worry about solutions that work across the spectrum of users, from the AOL newbie to Jay. We can't solve problems just for Jay, or just for Newbies, we have to find a solution that works as well as possible for as many of those groups as possible. ADA compliance is a useful strawman that keeps us focussed away from "I want it this way, so that's the right way". -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From chuqui@plaidworks.com Thu Feb 21 04:52:39 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 20:52:39 -0800 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: <87d6yzh38r.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: On 2/20/02 8:23 PM, "Stephen J. Turnbull" wrote: > Nor do the spammers need to deobfuscate all the obfuscations. They > only need enough that they're getting a reasonable harvest rate. A very good point. We want to make it tough on spambots, but adding complexity to the system is useful only if it actually makes it tough on the spambots. If, instead, it merely ends up adding complexity, we might as well not do it. If the real answer is "well, it means they have to harvest our site five times to ge the address instead of once", we shouldn't bother. Does anyone know if the /. System actually accomplishes anything? Or have the spambots adapted already? We can't do nothing until we get a 100% solution -- those don't exist. But we also shouldn't do things just to be seen as doing things, if those things we do don't really help or are merely minor inconveniences for the spam harvesters that are easily worked around. Ah, the joys of design and architecture. Of course, if it was easy, it'd be written by now. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From jwm@plain.co.nz Thu Feb 21 04:55:23 2002 From: jwm@plain.co.nz (John Morton) Date: Thu, 21 Feb 2002 17:55:23 +1300 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020221045524.A5B2B13D78@registry.e-servicesltd.co.nz> On Thursday 21 February 2002 17:15, Dale Newfield wrote: > On Wed, 20 Feb 2002, Damien Morton wrote: > > Web Forms for contacting the admin cold. If the admin replies, you can > > continue the conversation via email. > > Right, assuming the web form doesn't break. Monitor the form. Your monitoring tools should be telling you when bits of your site break before users have a need to report the problem. > > Private and Public views of the archives. > > > > Private archives are restricted to list members and those that can pass > > a reverse turing test. > > People keep using this term, but I'm not sure what they mean, or if I > trust that they'd be so reliable... It's a test to find out if the agent that requested the page is human or some bot of some sort. In order to progress past the form you have to enter something into the box as a reply to some text in the form. If the question and answer can be arbitary on a site by site, or better, hit by hit basis, then it becomes infeasible to build a spambot to enter such sites. > > Public archives render all email addresses as jpegs. > > If they're automatically generated, it'd be easier to create pngs or gifs, > or lots of other formats than jpgs. Think about this, though--how do you > actually generate the images and serve them properly without either > including the email address in the html code anyway (so the img request > specifies what image to generate), or building a whole database mapping > arbitrary numbers to email addresses (so they can either be generated on > the fly or stored pre-generated). I'd pregenrate them, give them an arbitary name and store a dictionary mapping email addresses to the image for page building purposes. > Once you've got that database, why not > just have that database front a web form instead of displaying the > address? I'm not sure what you mean by this. Can you explain? (Not that I think image addreses are a good idea for all the reasons you mentioned earlier. I'd prefer a slashdot style per user 'display address' option. It can be obfuscated by default, but it allows the user to restore there actual address, or render it unrecognizable depending on there personal spam tolerance threshold.) John From dale@newfield.org Thu Feb 21 05:08:50 2002 From: dale@newfield.org (Dale Newfield) Date: Thu, 21 Feb 2002 00:08:50 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020221045524.A5B2B13D78@registry.e-servicesltd.co.nz> Message-ID: On Thu, 21 Feb 2002, John Morton wrote: > It's a test to find out if the agent that requested the page is human or some > bot of some sort. Assuming you can build such a test. Good luck. > If the question and answer can be arbitary on a site by site, or better, > hit by hit basis, then it becomes infeasible to build a spambot to enter > such sites. If it's arbitrary, it's generated by some algorithm. If it's generated by some algorithm, I just need to figure out the algorithm and I can always get it. > I'd pregenrate them, give them an arbitary name and store a dictionary > mapping email addresses to the image for page building purposes. > > > Once you've got that database, why not > > just have that database front a web form instead of displaying the > > address? > > I'm not sure what you mean by this. Can you explain? If you've got a database mapping arbitrary number/name/string to an email address, then why not just have a web form that sends mail to that address knowing only the arbitrary value (and never divulge the email address)? > I'd prefer a slashdot style per user 'display address' option. I don't believe any system like slashdot's is worth the time to implement, since it is just as easily broken, and now you've got more useless stuff for every single user to manage. --- Dale Newfield "To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." -T. Roosevelt From chuqui@plaidworks.com Thu Feb 21 05:41:01 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 20 Feb 2002 21:41:01 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: >> It's a test to find out if the agent that requested the page is human or some >> bot of some sort. > > Assuming you can build such a test. Good luck. That some other programmer can't cheat on. Even gooder luck. > If it's arbitrary, it's generated by some algorithm. If it's generated by > some algorithm, I just need to figure out the algorithm and I can always > get it. There is some validity to the "the club" mentality, of "we don't have to fix it, we only have ot make it difficult enough to convince them to annoy someone else". But if we assume we're building the New Defacto Standard Listserver for the Internet here with mailman, that strategy fails, because if we succeed, then it becomes worth their time to find the anti-Club. Security by obscurity only works if you're really obscure, which implies failure of the software to thrive. I'm not interested in that (and even then, you aren't guaranteed success by being obscure). Another way of looking at it is "I don't have to outrun the lion. I only have to outrun you" -- but that doesn't work if the lion is infinitely hungry and doesn't get tire.d Which defines a spambot. I'm more and more ocnvinced the answer is simply putting admins behind a web form, and telling site admins to publicize an emergency address (like postmaster), and putting up a watcher on the system to set off alarms when it breaks. > If you've got a database mapping arbitrary number/name/string to an email > address, then why not just have a web form that sends mail to that address > knowing only the arbitrary value (and never divulge the email address)? Basically, what I'm proposing. And I'm more and more convinced it's the right way to do this, for all that web forms are less personal than sending email directly. I think admins have to make themselves accessible. I don't think they have to make themselves accessible on the user's terms... Another of those tradeoffs. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From jwm@plain.co.nz Thu Feb 21 05:44:49 2002 From: jwm@plain.co.nz (John Morton) Date: Thu, 21 Feb 2002 18:44:49 +1300 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020221054450.A637813D78@registry.e-servicesltd.co.nz> On Thursday 21 February 2002 18:08, Dale Newfield wrote: > On Thu, 21 Feb 2002, John Morton wrote: > > It's a test to find out if the agent that requested the page is human or > > some bot of some sort. > > Assuming you can build such a test. Good luck. Building a good one is tricky. It depends on your model of the attacker, and while I've seen some wild speculation of the capabilities of email address harvesters, I don't have any hard facts about the cost/benifit equations they use. > > If the question and answer can be arbitary on a site by site, or better, > > hit by hit basis, then it becomes infeasible to build a spambot to enter > > such sites. > > If it's arbitrary, it's generated by some algorithm. If it's generated by > some algorithm, I just need to figure out the algorithm and I can always > get it. Arbitary as in 'doesn't have to be fixed'. Allowing the site admin the ability to build there own set wouldn't have to involve an algorithm (though I'm spliting hairs, really; I don't think this is a workable idea, either). > > I'd pregenrate them, give them an arbitary name and store a dictionary > > mapping email addresses to the image for page building purposes. > > > > > Once you've got that database, why not > > > just have that database front a web form instead of displaying the > > > address? > > > > I'm not sure what you mean by this. Can you explain? > > If you've got a database mapping arbitrary number/name/string to an email > address, then why not just have a web form that sends mail to that address > knowing only the arbitrary value (and never divulge the email address)? "What if the form breaks down?" :-) Actually, the reason not to use it is that it can be used to spam anyone who's id mapping you can grab from the archive! > > I'd prefer a slashdot style per user 'display address' option. > > I don't believe any system like slashdot's is worth the time to implement, > since it is just as easily broken, and now you've got more useless stuff > for every single user to manage. You've got three statements here, I'll address them one at a time: 1) 'I don't believe any system like slashdot's is worth the time to implement' How hard is it, really. All we're looking at is adding an extra field to the each member record, to the forms for managing user settings, a method to generate a default obfuscation and anther one to substitute addresses in the archive. 2) 'since it is just as easily broken' I never bothered to obfuscate my address, and while I seldom post, I hardly ever recieve spam either (and my address is attached to all sorts of things that are more likely to be harvested). The best we can do is come up with some 'good enough' solutions, and one that offers a user the opportunity to have their address displayed as 'no spam please' is about the best I can think of. Rather than have the whole list exhale great gouts of hot air about what obfuscation methods are broken or not, why don't we do an experiment? Someone should sign up for a couple of email addresses at a free mail service, subscribe to slashdot and post to several stories with each over the month. One account can use their raw email address in each posting, and the other can use some obfuscation method. Then, as the weeks tick by, we can actually see just how useless, or otherwise, obfuscation really is. 3) 'and now you've got more useless stuff for every single user to manage.' If 16 million people can operate the Hotmail UI, I think mailman list users can handle another text field. Especially if it's already filled out for them. John From jwblist@olympus.net Thu Feb 21 06:04:21 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 20 Feb 2002 22:04:21 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020220203652.42377@scfn.thpl.lib.fl.us> References: <20020220161829.34707@scfn.thpl.lib.fl.us> <20020220203652.42377@scfn.thpl.lib.fl.us> Message-ID: At 20:36 -0500 2/20/2002, Jay R. Ashworth wrote: [Quoting Chuq] >> See above. You don't get the analogy right. [Jay] > >No, I merely don't value the email address's privacy as highly as you >do. I get about 50 spam a day in 200 new messages including about 14 >mailing lists -- I'm entitled to hold that opinion if I want. > >You *can't* make addresses overly private; they cease to be usable. > >At least, given the supporting tools and infrastructure we have today. I have a domain, for no particularly good reason. (I saw the word in a book ad in Science News...I bought the book and the domain based on the ad. And since "you could look it up" it's scandaroon.com.) Once I had the domain, I started registering each product (or company's products) with a unique local part @scandaroon.com. Late last year, I had a sudden infusion of Spam addressed to jwbpalm@scandaroon.com. [Company shall remain nameless ;-)] Sending mail to that address now produces a 550 response whose text is "sold down the river by Palm" (Which might be wrong...they might have leaked it instead...which IMHO is worse.) Palm is probably following the privacy policy as it has evolved since I registered the (early production) Palm IIIx. For Usenet posting, I use an @spamcop.net address...the harvesters don't seem to bother with those...no obfuscation seems to be needed. (And yes, I get to deal with "our" SpamCop reports, but for THIS purpose the service works very well.) Scrambling quickly back on topic: some list admins could do well to try a SpamCop address--or the like elsewhere--for list admin purposes for Mailman lists. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jwm@plain.co.nz Thu Feb 21 06:10:29 2002 From: jwm@plain.co.nz (John Morton) Date: Thu, 21 Feb 2002 19:10:29 +1300 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020221061030.466D213D79@registry.e-servicesltd.co.nz> On Thursday 21 February 2002 18:41, Chuq Von Rospach wrote: > There is some validity to the "the club" mentality, of "we don't have to > fix it, we only have ot make it difficult enough to convince them to annoy > someone else". But if we assume we're building the New Defacto Standard > Listserver for the Internet here with mailman, that strategy fails, because > if we succeed, then it becomes worth their time to find the anti-Club. > Security by obscurity only works if you're really obscure, which implies > failure of the software to thrive. I'm not interested in that (and even > then, you aren't guaranteed success by being obscure). > > Another way of looking at it is "I don't have to outrun the lion. I only > have to outrun you" -- but that doesn't work if the lion is infinitely > hungry and doesn't get tire.d Which defines a spambot. Indeed. Email addresses aren't secrets - even more so than credit card numbers and biometric data - and the attackers have more than enough resources to seek them out. > I'm more and more ocnvinced the answer is simply putting admins behind a > web form, and telling site admins to publicize an emergency address (like > postmaster), and putting up a watcher on the system to set off alarms when > it breaks. For the admin addresses, I'd agree with you. Building up a document of pointers to good spam filtering tools couldn't hurt either. For archives that aren't behind a login, I think slashdot style obfuscation is the best we can do. The list admin can pick the default obfuscation scheme or none at all. Users who want there email address out there for whatever reason can do so, and rely on their 'War and Peace' spam filters to keep the noise down, while other folks can opt in even further and replace the obfuscated email address with some useless string. John From jwblist@olympus.net Thu Feb 21 06:14:43 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 20 Feb 2002 22:14:43 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: At 0:08 -0500 2/21/2002, Dale Newfield wrote: >> If the question and answer can be arbitary on a site by site, or better, >> hit by hit basis, then it becomes infeasible to build a spambot to enter >> such sites. > >If it's arbitrary, it's generated by some algorithm. If it's generated by >some algorithm, I just need to figure out the algorithm and I can always >get it. Not to mention that people surprisingly often mess up answers to questions as easy as "Who is buried in Grant's Tomb?" --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA Who is buried in Grant's Pass? Many people who lived there, and some who had moved away. From dale@newfield.org Thu Feb 21 06:15:20 2002 From: dale@newfield.org (Dale Newfield) Date: Thu, 21 Feb 2002 01:15:20 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: On Wed, 20 Feb 2002, Chuq Von Rospach wrote: > > If you've got a database mapping arbitrary number/name/string to an email > > address, then why not just have a web form that sends mail to that address > > knowing only the arbitrary value (and never divulge the email address)? > > Basically, what I'm proposing. And I'm more and more convinced it's the > right way to do this, for all that web forms are less personal than sending > email directly. I think admins have to make themselves accessible. I don't > think they have to make themselves accessible on the user's terms... Another > of those tradeoffs. I was meaning the archives. We have a database describing lists, so we can handle that. -Dale From dale@newfield.org Thu Feb 21 06:25:48 2002 From: dale@newfield.org (Dale Newfield) Date: Thu, 21 Feb 2002 01:25:48 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020221054450.A637813D78@registry.e-servicesltd.co.nz> Message-ID: On Thu, 21 Feb 2002, John Morton wrote: > Actually, the reason not to use it is that it can be used to spam anyone > who's id mapping you can grab from the archive! That's a separate issue and can have a separate solution. Make the form smart--for example, make it only accept 10 messages from a single IP address in a single day. If we want/expect Maimlan to succeed, then there will be enough incentive for someone to break the obfuscation mechanism. Are you suggesting we restrict access to part of Mailman's source code? Are you suggesting that with the source I can't reverse-engineer every obfuscation (as opposed to information removing) system you try? Why add more points of failure into a system if they don't gain you anything? Basically it looks to me like there ultimately can be no successful obfuscation technique. Why not instead simply remove the information and ONLY provide web-forms? (Again, I'm talking only about archives--I think at least some mailto: is required in case of systemic failures.) -Dale From jwblist@olympus.net Thu Feb 21 06:26:39 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 20 Feb 2002 22:26:39 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: At 23:15 -0500 2/20/2002, Dale Newfield wrote: >On Wed, 20 Feb 2002, Damien Morton wrote: >> I still think the email-address-as-jpeg solution is prohibitively >> expensive to reverse; effectively impossible for machines, entirely easy >> for people. > ... > >It can't be enlarged for people that have poor vision. Opera is a counter-example, but doesn't defeat your point. (Tidbits the cat enlarged the web page my Windows laptop was idling on to 200% earlier today in a walk across the keyboard: Opera has keystrokes for nearly everything.) --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From Dan Mick Thu Feb 21 06:27:05 2002 From: Dan Mick (Dan Mick) Date: Wed, 20 Feb 2002 22:27:05 -0800 (PST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... Message-ID: <200202210627.g1L6RncW022252@utopia.West.Sun.COM> > Have you seen what slashdot is doing? unobscured mailto: links? What am I missing? From marc_news@vasoftware.com Thu Feb 21 07:15:27 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 20 Feb 2002 23:15:27 -0800 Subject: [Mailman-Developers] mailman-cvs and email.Charset Message-ID: <20020221071527.GB10527@merlins.org> First, I got: Compiling /var/local/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/var/local/mailman/Mailman/MailList.py", line 49, in ? from Mailman.Archiver import Archiver File "/var/local/mailman/Mailman/Archiver/__init__.py", line 17, in ? from Archiver import * File "/var/local/mailman/Mailman/Archiver/Archiver.py", line 32, in ? from Mailman import Mailbox File "/var/local/mailman/Mailman/Mailbox.py", line 26, in ? from Mailman.Message import Message File "/var/local/mailman/Mailman/Message.py", line 26, in ? from email.Charset import Charset ImportError: No module named Charset make: *** [update] Error 1 Then I realized that there was an email-0.97 package in the tree, and it worked much better after that :-) The INSTALL doc still mention email-0.96, and say that python-2.2 is good enough, which isn't true anymore (actually even python-cvs doesn't seem to have this yet). It probably needs to be updated. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Thu Feb 21 08:38:04 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 21 Feb 2002 00:38:04 -0800 Subject: [Mailman-Developers] my top 3 wishlist for mailman cvs In-Reply-To: <15416.1029.173559.215312@anthem.wooz.org>; from barry@zope.com on Sun, Jan 06, 2002 at 03:00:05AM -0500 References: <20011210013348.H21219@magic.merlins.org> <15412.44419.399808.458250@geddy.wooz.org> <20020104084923.C2146@merlins.org> <15416.1029.173559.215312@anthem.wooz.org> Message-ID: <20020221003804.A16097@merlins.org> On Sun, Jan 06, 2002 at 03:00:05AM -0500, Barry A. Warsaw wrote: > I've added a new configuration variable to Defaults.py.in, called > ALLOW_SITE_ADMIN_COOKIES. Set this to true and authenticating to a > list admin login page with the site password, and Mailman will drop a > cookie representing the site authentication. Thus, authenticate once > and you can get into every list. The default value of this variable > is 0. > > -Barry I had to clear some of my cookies for the site in question, but after that it worked fine. Thanks. I also had to get back to you as to whether a mailman upgrade broke the exisiting crypted admin passwords. While the upgrade of one my of my sites to mm 2.1a3 seemed to have broken that, I just checked that the upgrade of another site I just completed didn't cause problems and the old passwords worked. Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Thu Feb 21 08:57:57 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 21 Feb 2002 00:57:57 -0800 Subject: [Mailman-Developers] exception for post from non list member In-Reply-To: <20020221071527.GB10527@merlins.org> References: <20020221071527.GB10527@merlins.org> Message-ID: <20020221085756.GG10527@merlins.org> I have mm 2.1a4cvs setup to refuse posts from non members and forward a copy to the list owner. This only happens if generic_nonmember_action is set to reject (accept, hold, and discard work) Feb 21 00:51:39 2002 (55) Uncaught runner exception: get_type Feb 21 00:51:39 2002 (55) Traceback (most recent call last): File "/var/local/mailman/Mailman/Queue/Runner.py", line 114, in __oneloop self.__onefile(msg, msgdata) File "/var/local/mailman/Mailman/Queue/Runner.py", line 162, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Queue/OutgoingRunner.py", line 59, in _dispos e func(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Handlers/SMTPDirect.py", line 79, in process msgtext = msg.as_string(unixfrom=0) File "/usr/lib/python2.1/site-packages/email/Message.py", line 85, in as_strin g g(self, unixfrom=unixfrom) File "/usr/lib/python2.1/site-packages/email/Generator.py", line 83, in __call __ self._write(msg) File "/usr/lib/python2.1/site-packages/email/Generator.py", line 104, in _writ e self._dispatch(msg) File "/usr/lib/python2.1/site-packages/email/Generator.py", line 134, in _disp atch meth(msg) File "/usr/lib/python2.1/site-packages/email/Generator.py", line 246, in _hand le_multipart g(part, unixfrom=0) File "/usr/lib/python2.1/site-packages/email/Generator.py", line 83, in __call __ self._write(msg) File "/usr/lib/python2.1/site-packages/email/Generator.py", line 104, in _writ e self._dispatch(msg) File "/usr/lib/python2.1/site-packages/email/Generator.py", line 121, in _disp atch ctype = msg.get_type() AttributeError: get_type -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Thu Feb 21 09:07:32 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 21 Feb 2002 01:07:32 -0800 Subject: [Mailman-Developers] auto discard doesn't seem to work as expected. Message-ID: <20020221090731.GH10527@merlins.org> I now tried to set non member posts to auto-discard. If I do not set forward_auto_discards, it works as intended. If I set it, it works as if the list were moderated (the poster gets a notice that the message needs moderation and the list owner gets a notice that there is something to moderate) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Thu Feb 21 09:15:52 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 21 Feb 2002 01:15:52 -0800 Subject: [Mailman-Developers] two small patches for mm 2.1a4cvs Message-ID: <20020221091552.GI10527@merlins.org> --- ../../src/mailman-cvs/build/contrib/check_perms_grsecurity.py Wed Feb 20 23:37:35 2002 +++ check_perms_grsecurity.py Wed Feb 20 23:42:57 2002 @@ -118,7 +118,7 @@ os.chmod(file, 06755) print "\nMaking mail wrapper setuid mailman" - file= paths.prefix + '/mail/wrapper' + file= paths.prefix + '/mail/mailman' os.chown(file, MAILMAN_UID, MAILMAN_GID) os.chmod(file, 06755) print file svlug:/var/local/mailman/bin# diff -u ../scripts/mailman /etc/init.d/mailman --- ../scripts/mailman Wed Feb 20 23:38:09 2002 +++ /etc/init.d/mailman Thu Feb 21 01:15:14 2002 @@ -18,6 +18,10 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # +# Copy this file in /etc/init.d/ and activate it as such: +# On Debian, just type "update-rc.d mailman defaults" +# On RedHat, and derivatives, install with chkconfig --add mailman +# # chkconfig: 2345 98 12 # description: Mailman is the GNU Mailing List Manager, a program that \ # manages electronic mail discussion groups. For more \ Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Thu Feb 21 09:25:44 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 21 Feb 2002 01:25:44 -0800 Subject: [Mailman-Developers] upgrading a private list from mm 2.0 to 2.1a4cvs Message-ID: <20020221092543.GK10527@merlins.org> Apparently, when I upgraded a list that had posting for members only, this setting didn't get translated into the new generic_nonmember_action / Hold I believe it defaulted to Accept. For migrating sites with many lists, having that convertion done automatically would be good. Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From che@debian.org Thu Feb 21 09:46:27 2002 From: che@debian.org (Ben Gertzfield) Date: Thu, 21 Feb 2002 18:46:27 +0900 Subject: [Mailman-Developers] mailman-cvs and email.Charset In-Reply-To: <20020221071527.GB10527@merlins.org> (Marc MERLIN's message of "Wed, 20 Feb 2002 23:15:27 -0800") References: <20020221071527.GB10527@merlins.org> Message-ID: <87d6yz5frg.fsf@nausicaa.interq.or.jp> >>>>> "Marc" == Marc MERLIN writes: Marc> The INSTALL doc still mention email-0.96, and say that Marc> python-2.2 is good enough, which isn't true anymore Marc> (actually even python-cvs doesn't seem to have this yet). It Marc> probably needs to be updated. Yeah, you need CVS email for now. Barry seems to be away for a bit, but hopefully I will eventually get access to the Mailman CVS tree so I can do tidying up like this. Also, the Japanese and Chinese Unicode codecs will be required if you want Mailman to send email in those languages. Ben -- Brought to you by the letters K and Q and the number 19. "Do you wish to see our *surprising toys*? No! Do not!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From marc_news@vasoftware.com Thu Feb 21 10:04:45 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 21 Feb 2002 02:04:45 -0800 Subject: [Mailman-Developers] Correct public archive URLs Message-ID: <20020221100444.GM10527@merlins.org> URLs were missing the trailing slash, which caused an extra http request and an http redirect. diff -urN mailman-cvs.orig/Mailman/Archiver/Archiver.py mailman-cvs/Mailman/Archiver/Archiver.py --- mailman-cvs.orig/Mailman/Archiver/Archiver.py Mon Feb 11 15:14:16 2002 +++ mailman-cvs/Mailman/Archiver/Archiver.py Thu Feb 21 02:01:06 2002 @@ -130,7 +130,7 @@ return mm_cfg.PUBLIC_ARCHIVE_URL % { 'listname': self.internal_name(), 'hostname': inv.get(self.host_name, mm_cfg.DEFAULT_URL_HOST), - } + } + '/' def __archive_file(self, afn): """Open (creating, if necessary) the named archive file.""" Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From dm-temp-310102@nyc.rr.com Thu Feb 21 13:28:13 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Thu, 21 Feb 2002 08:28:13 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: <000201c1badb$a0411af0$56296c42@damien> > From: Dale Newfield [mailto:dale@newfield.org] > > On Wed, 20 Feb 2002, Damien Morton wrote: > > I still think the email-address-as-jpeg solution is prohibitively > > expensive to reverse; effectively impossible for machines, entirely > > easy for people. > > But it does have drawbacks. > > It only works with graphical browsers. This is true. We are in the 21st century now. Expecting a graphical client isnt such a huge leap of faith, unless we allow ourselves to be guided by recidivist or luddite lynx users and their ilk. > It can't be enlarged for people that have poor vision. This is true, for the public archives. > It can be reverse-engineered -- all they have to do is decode > a single font, then they're all simple to snag. Assuming you use a single font. Assuming you don't add some noise to the resulting image. Assuming you don't do some geometric distortion to the resulting image. To reverse engineer, a harvester would have to examine pretty much every image it finds, OCR it with some fantastic military grade image recognition software, and see if theres an email address buried in there. As I said, "prohibitively expensive to reverse" > In fact, as someone with lots of computer graphics > experience, I'd say it would be almost no harder to write > code to decode them than it would be to write code to generate them. As someone with lots of computer graphics experience, you will probably know that OCR is hard. Its even harder with a non-cooperating document, hidden amongst many other documents. > > Web Forms for contacting the admin cold. If the admin > replies, you can > > continue the conversation via email. > > Right, assuming the web form doesn't break. In my experience, the mostly likely route to a web form breaking is if the email address it sends to breaks. > > Private and Public views of the archives. > > > > Private archives are restricted to list members and those that can > > pass a reverse turing test. > > People keep using this term, but I'm not sure what they mean, > or if I trust that they'd be so reliable... Some examples of reverse turing tests. (http://www.captcha.net/) http://www.captcha.net/cgi-bin/bongo http://www.captcha.net/cgi-bin/stumpy http://drive.to/research (this one uses audio) http://www.captcha.net/gimpy.html Any of those tests can be implemented in Python using PIL. Between an audio test and a visual test, you've got the blind and the deaf covered. > > Public archives render all email addresses as jpegs. > > If they're automatically generated, it'd be easier to create > pngs or gifs, or lots of other formats than jpgs. Think > about this, though--how do you actually generate the images > and serve them properly without either including the email > address in the html code anyway (so the img request specifies > what image to generate), or building a whole database mapping > arbitrary numbers to email addresses (so they can either be > generated on the fly or stored pre-generated). Once you've > got that database, why not just have that database front a > web form instead of displaying the address? I suggested JPEGs because they are computationally more expensive to decode than other formats. Also: compression is lossy and adds a certain amount of noise to an image. Generating and serving the images would be done as follows: filename = md5.new('list-specific-salt-string'+'email@server.com').hexdigest() + '.jpg' if not exists(filename): img = render_email('email@server.com') img.save(filename) Then you relace every occurrence of 'email@server.com' with '' % filename Replacing the email addresses with a link to a webform would be another, perfectly acceptable solution, assuming you can get over your own objections to web forms. From Nigel.Metheringham@dev.InTechnology.co.uk Thu Feb 21 14:37:36 2002 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 21 Feb 2002 14:37:36 +0000 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000201c1badb$a0411af0$56296c42@damien> References: <000201c1badb$a0411af0$56296c42@damien> Message-ID: <1014302256.20836.29.camel@gaspode.localnet> On Thu, 2002-02-21 at 13:28, Damien Morton wrote: > > From: Dale Newfield [mailto:dale@newfield.org] > > It only works with graphical browsers. > > This is true. We are in the 21st century now. Expecting a graphical > client isnt such a huge leap of faith, unless we allow ourselves to be > guided by recidivist or luddite lynx users and their ilk. You haven't been following this, have you... Chuq Vos Rospach wrote yesterday in response to Dale's point:- > This is a very good point. I mentioned ADA compliance yesterday. > To be ADA compliant, if you rendered the e-mail address as a graphic, > you'd also have to put the text into the ALT tag. Which would enable > it for lynx and sight-limited solutions -- and make putting into a > graphic kinda meaningless. So you can't use this approach unless you > want to ignore the ADA and lock out your blind users from those > functions. > I'm not willing to make that tradeoff. While I'm not going to live or > die on the ADA compliance issue, I think it's important to keep it in > mind because it forces us to focus on more than the "easy" case or the > "geek" case and worry about solutions that work across the spectrum of > users, from the AOL newbie to Jay. We can't solve problems just for > Jay, or just for Newbies, we have to find a solution that works as > well as possible for as many of those groups as possible. ADA > compliance is a useful strawman that keeps us focussed away from > "I want it this way, so that's the right way". plus enforcing a minimum browser standard (other than minimal text/html) is going to hit deep water with the various PDAs, phones, WAP and other stuff that almost has real browsers on. And insulting lynx users isn't a way to increase your expected life span. Go do something less controversial like arguing the advantages of vi in the emacs news groups. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From dm-temp-310102@nyc.rr.com Thu Feb 21 15:27:08 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Thu, 21 Feb 2002 10:27:08 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <1014302256.20836.29.camel@gaspode.localnet> Message-ID: <000301c1baec$3cd62580$56296c42@damien> > From: Nigel Metheringham > > > > From: Dale Newfield [mailto:dale@newfield.org] > > > It only works with graphical browsers. > > > > This is true. We are in the 21st century now. Expecting a graphical > > client isnt such a huge leap of faith, unless we allow > ourselves to be > > guided by recidivist or luddite lynx users and their ilk. > > You haven't been following this, have you... I have actually, although I do admit I probably stepped over the line there. > Chuq Vos Rospach wrote yesterday in response to Dale's point:- > > This is a very good point. I mentioned ADA compliance > yesterday. To be > > ADA compliant, if you rendered the e-mail address as a > graphic, you'd > > also have to put the text into the ALT tag. Which would > enable it for > > lynx and sight-limited solutions -- and make putting into a graphic > > kinda meaningless. So you can't use this approach unless > you want to > > ignore the ADA and lock out your blind users from those functions. Chuq, you wouldn't have to do this if it rendered the purpose of emails-as-jpegs invalid. email address obscured for security purposes, please log-in > > I'm not willing to make that tradeoff. While I'm not going > to live or > > die on the ADA compliance issue, I think it's important to > keep it in > > mind because it forces us to focus on more than the "easy" > case or the > > "geek" case and worry about solutions that work across the > spectrum of > > users, from the AOL newbie to Jay. We can't solve problems just for > > Jay, or just for Newbies, we have to find a solution that works as > > well as possible for as many of those groups as possible. ADA > > compliance is a useful strawman that keeps us focussed away from "I > > want it this way, so that's the right way". > > plus enforcing a minimum browser standard (other than minimal > text/html) is going to hit deep water with the various PDAs, > phones, WAP and other stuff that almost has real browsers on. I have been proposing the use of advanced browser standards for the 'public' archives, i.e. those archives that are accessible to the world, be it users, email harvesters, or the spiders of search engines. Making a private archive available to those who are list members or who are willing to authenticate themselves as human, and making the private archive plain unobfuscated text should mean that everyone is at least able to get what they need, if only after jumping through some hoops. Those hoops could be a visual test, an audio test, or a list membership test (which depends on having provided a valid email address). Further, the public archive would differ from the private archive only by the obfuscation of email addresses. That would be the only difference. I wonder if the ADA would accept the need to obscure email addresses, and I wonder if they would accept the extra authentication step required to get at the unobscured email address? Would they understand that it protects all mailman users, including the disabled? Would Lynx users and other browser-disadvantaged users accept the extra authentication/authorisation step to get at the unobscured email addresses? Would they understand that it protects _them_ as well? > And insulting lynx users isn't a way to increase your > expected life span. Go do something less controversial like > arguing the advantages of vi in the emacs news groups. Agreed, appologies to recidivists, luddites and lynx users :) From dale@newfield.org Thu Feb 21 16:20:14 2002 From: dale@newfield.org (Dale Newfield) Date: Thu, 21 Feb 2002 11:20:14 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000201c1badb$a0411af0$56296c42@damien> Message-ID: On Thu, 21 Feb 2002, Damien Morton wrote: > OCR is hard OCR is hard mostly because of the analog components (and the variety of fonts that exist). If you are generating the image digitally (and with a limited set of fonts), most of the OCR problems go away. > Some examples of reverse turing tests. (http://www.captcha.net/) It appears that each of those introduces non ADA compliant aspects. The first and third can be defeated with a database no larger than that needed to implement it, the third is unlikely to work on many platforms (audio dependancies kept it from working for me), and the fourth I couldn't even figure out as a human--not what we're looking for. > Between an audio test and a visual test, you've got the blind and the > deaf covered. And you've introduced lots of browser/platform dependancies that mean you can't use new low-bandwidth platforms, like WAP. -Dale From dale@newfield.org Thu Feb 21 16:28:17 2002 From: dale@newfield.org (Dale Newfield) Date: Thu, 21 Feb 2002 11:28:17 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000301c1baec$3cd62580$56296c42@damien> Message-ID: On Thu, 21 Feb 2002, Damien Morton wrote: > Making a private archive available to those who are list members I haven't commented on this before, but the reason I find this solution lacking is that most mailman lists (in my experience) don't require list admin permission to join. If this is the hurdle, as a spammer I'd just create a hotmail account that I can automatically subscribe to any mailman mailing list, and then gain access to the honeypot. -Dale From chuqui@plaidworks.com Thu Feb 21 17:01:10 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 21 Feb 2002 09:01:10 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000201c1badb$a0411af0$56296c42@damien> Message-ID: On 2/21/02 5:28 AM, "Damien Morton" wrote: >> It only works with graphical browsers. > > This is true. We are in the 21st century now. Expecting a graphical > client isnt such a huge leap of faith, unless we allow ourselves to be > guided by recidivist or luddite lynx users and their ilk. Or those who are sight-limited and using talker browsers, but the heck with the blind and aged, we don't need them anyway. Or those on wireless browsers, like cell phones, PDA's, blackberries and the like. And those can be ignored, they're merely the fastest growing segment of the industry. (grin) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! From dm-temp-310102@nyc.rr.com Thu Feb 21 17:05:53 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Thu, 21 Feb 2002 12:05:53 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: <001001c1bafa$08eb4030$56296c42@damien> > From: Dale Newfield > > On Thu, 21 Feb 2002, Damien Morton wrote: > > OCR is hard > > OCR is hard mostly because of the analog components (and the > variety of fonts that exist). If you are generating the > image digitally (and with a limited set of fonts), most of > the OCR problems go away. Youre assuming a simplistic implementation. The use of a single font, and the absence of noise or distortion. At any rate, its certainly much harder than writing a perl regex, both in terms of brainpower and in terms of computing power required. > > Some examples of reverse turing tests. (http://www.captcha.net/) > > It appears that each of those introduces non ADA compliant > aspects. The first and third can be defeated with a database > no larger than that needed to implement it, the third is > unlikely to work on many platforms (audio dependancies kept > it from working for me), and the fourth I couldn't even > figure out as a human--not what we're looking for. Youre assuming a simplistic implementation; a database of words and images. A sophisticated implementation would generate images from random words with random distortions added, sounds by overlaying random words with random backgrounds. You've also ignoring the third test, which is list membership. If youre not capable of passing the reverse turing tests offered, you can always join the list for unobscured access. > > Between an audio test and a visual test, you've got the > blind and the > > deaf covered. > > And you've introduced lots of browser/platform dependancies > that mean you can't use new low-bandwidth platforms, like WAP. You're ignoring the third test offered, which is list membership. 'enter your email address and password here'. Between the three kinds of tests, a person who desires at least the same functionality as is offered today, can do so, no matter what platform they are on. Let me reiterate that what is being proposed here is the obscuration of email addresses in the public archives; that is, the archives available to the world for casual inspection. Perhaps it might be fruitfull to look at omitting the email addresses in the public archives entirely. That would certainly be ADA compliant, and would be useable by anyone with any html 1.0 capable browser. As I see it, the questions are: Is it desireable to prevent the whole world seeing email addresses in mailman archives? If yes then should there be public and private archives, with the public archive obscuring addresses? if yes how should the access to the private archives be controlled? list membership? reverse truing tests? other? what should go into the public archives? obscured email? email as images? text based obfuscation? links to web form email? omit email addresses entirely? other? else if no should an obfuscation scheme be used at all? if yes what obfuscation scheme(s) should be used? obscured email? email as images? text based obfuscation? links to web form email? omit email addresses entirely? other? else if no talking in circles else if no end of conversation From dale@newfield.org Thu Feb 21 17:15:37 2002 From: dale@newfield.org (Dale Newfield) Date: Thu, 21 Feb 2002 12:15:37 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <001001c1bafa$08eb4030$56296c42@damien> Message-ID: On Thu, 21 Feb 2002, Damien Morton wrote: > should an obfuscation scheme be used at all? > if yes > what obfuscation scheme(s) should be used? > obscured email? > email as images? > text based obfuscation? >**** links to web form email? >**** omit email addresses entirely? > other? The two I marked with (****) above are not obfuscation schemes. They involve not the obfuscation of information, but rather it's removal. (While there are reasons webforms are evil, they still provide a way to contact people whose email addresses have been removed.) This is what I am advocating. -Dale From chuqui@plaidworks.com Thu Feb 21 17:23:51 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 21 Feb 2002 09:23:51 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: Message-ID: On 2/21/02 8:28 AM, "Dale Newfield" wrote: > On Thu, 21 Feb 2002, Damien Morton wrote: >> Making a private archive available to those who are list members > > I haven't commented on this before, but the reason I find this solution > lacking is that most mailman lists (in my experience) don't require list > admin permission to join. If this is the hurdle, as a spammer I'd just > create a hotmail account that I can automatically subscribe to any mailman > mailing list, and then gain access to the honeypot. This hits another aspect of my design philosophy. Don't sweat making one part of the system more secure than the other parts. In this case, you hit a nail on the head. If a spammer really, really wants your subscribers, we can't stop him. They can simply subscribe to a list and harvest it as it comes across. Unless you choose to anonymize every bloody message -- a spammer will win if they're motivated enough, and a smart spammer will do so in a way you'll never find. Like setting up a hotmail address for each list, so you can't see that all 30 lists have the same address in common, and simply reading messages as they come by. And since, inherently, you can't stop THAT, it makes no sense to make archives more secure than that. Any spammer smart enough to be willing to subscribe to a list to do their harvesting, you're going to have a very tough time stopping. Basically, you have to get lucky or hope they make a mistake or some sort. So since you can't make the subscription process more secure than that -- why try to make the archives more secure than the subscription process? It's extra work for no real gain, because any spammer will a clue will go through the patio door in the backyard instead of the front door with the three deadlocks and the security gate... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From dm-temp-310102@nyc.rr.com Thu Feb 21 18:32:44 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Thu, 21 Feb 2002 13:32:44 -0500 Subject: [Mailman-Developers] Interesting study -- spam onpostedaddresses... In-Reply-To: Message-ID: <001201c1bb06$2ab44660$56296c42@damien> Interestingly enough, the first place I ever saw the reverse turing test in use was in the signup for a yahoo account. "This step helps Yahoo! prevent automated registrations." http://edit.my.yahoo.com/config/eval_register?.partner=&.intl=us&.src=my &.last= The objective should be to raise the cost of harvesting. As you say, it cant be prevented, but forcing a human into the loop can raise the cost substantially. > -----Original Message----- > From: mailman-developers-admin@python.org > [mailto:mailman-developers-admin@python.org] On Behalf Of > Chuq Von Rospach > Sent: Thursday, 21 February 2002 12:24 > To: Dale Newfield; mailman-developers@python.org > Subject: Re: [Mailman-Developers] Interesting study -- spam > onpostedaddresses... > > > On 2/21/02 8:28 AM, "Dale Newfield" wrote: > > > On Thu, 21 Feb 2002, Damien Morton wrote: > >> Making a private archive available to those who are list members > > > > I haven't commented on this before, but the reason I find this > > solution lacking is that most mailman lists (in my > experience) don't > > require list admin permission to join. If this is the hurdle, as a > > spammer I'd just create a hotmail account that I can automatically > > subscribe to any mailman mailing list, and then gain access to the > > honeypot. > > This hits another aspect of my design philosophy. Don't sweat > making one part of the system more secure than the other parts. > > In this case, you hit a nail on the head. If a spammer > really, really wants your subscribers, we can't stop him. > They can simply subscribe to a list and harvest it as it > comes across. Unless you choose to anonymize every bloody > message -- a spammer will win if they're motivated enough, > and a smart spammer will do so in a way you'll never find. > Like setting up a hotmail address for each list, so you can't > see that all 30 lists have the same address in common, and > simply reading messages as they come by. > > And since, inherently, you can't stop THAT, it makes no sense > to make archives more secure than that. Any spammer smart > enough to be willing to subscribe to a list to do their > harvesting, you're going to have a very tough time stopping. > Basically, you have to get lucky or hope they make a mistake > or some sort. > > So since you can't make the subscription process more secure > than that -- why try to make the archives more secure than > the subscription process? It's extra work for no real gain, > because any spammer will a clue will go through the patio > door in the backyard instead of the front door with the three > deadlocks and the security gate... > > > -- > Chuq Von Rospach, Architech > chuqui@plaidworks.com -- http://www.chuqui.com/ > > Yes, I am an agent of Satan, but my duties > are largely ceremonial. > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailma> n-developers > From jra@baylink.com Thu Feb 21 21:57:00 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 21 Feb 2002 16:57:00 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000201c1badb$a0411af0$56296c42@damien>; from Damien Morton on Thu, Feb 21, 2002 at 08:28:13AM -0500 References: <000201c1badb$a0411af0$56296c42@damien> Message-ID: <20020221165700.05630@scfn.thpl.lib.fl.us> On Thu, Feb 21, 2002 at 08:28:13AM -0500, Damien Morton wrote: > > On Wed, 20 Feb 2002, Damien Morton wrote: > > > I still think the email-address-as-jpeg solution is prohibitively > > > expensive to reverse; effectively impossible for machines, entirely > > > easy for people. > > > > But it does have drawbacks. > > > > It only works with graphical browsers. > > This is true. We are in the 21st century now. Expecting a graphical > client isnt such a huge leap of faith, unless we allow ourselves to be > guided by recidivist or luddite lynx users and their ilk. And Chuq says *I'm* arrogant. There are lots of people who run their graphical browsers with J/Jscript off for security and images off for the same reason (much faster browsing) that I use Lynx. And see above about wireless browsers, and below about the blind. And get the phuque over yourself. > > It can't be enlarged for people that have poor vision. > > This is true, for the public archives. > > > It can be reverse-engineered -- all they have to do is decode > > a single font, then they're all simple to snag. > > Assuming you use a single font. > Assuming you don't add some noise to the resulting image. > Assuming you don't do some geometric distortion to the resulting image. > > To reverse engineer, a harvester would have to examine pretty much every > image it finds, OCR it with some fantastic military grade image > recognition software, and see if theres an email address buried in > there. It doesn't matter, really. > As I said, "prohibitively expensive to reverse" And just imaging -- yet another way to make 15 bytes into 15 kilobytes. Yeah, the network operators oughtta like that. You get a commission? > Replacing the email addresses with a link to a webform would be another, > perfectly acceptable solution, assuming you can get over your own > objections to web forms. We seem to keep conflating the "admin mailto problem" with the "list member mailto problem"; they have fairly widely diverging solutions. Could we please be a bit more cautious about that? Cheers, -- jra -- Jay R. Ashworth jra@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") From jwm@plain.co.nz Thu Feb 21 22:00:23 2002 From: jwm@plain.co.nz (John Morton) Date: Fri, 22 Feb 2002 11:00:23 +1300 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020221220024.692FE13D7F@registry.e-servicesltd.co.nz> On Friday 22 February 2002 05:28, Dale Newfield wrote: > On Thu, 21 Feb 2002, Damien Morton wrote: > > Making a private archive available to those who are list members > > I haven't commented on this before, but the reason I find this solution > lacking is that most mailman lists (in my experience) don't require list > admin permission to join. If this is the hurdle, as a spammer I'd just > create a hotmail account that I can automatically subscribe to any mailman > mailing list, and then gain access to the honeypot. I think we're really getting into wild speculation territory here. No one will bother hacking the code to automatically get new free mail accounts (this requires staying up to date with some range of mail service's cgi interface for their join function), automatically join any mailing list they find (same problem as before, coupled with having an automated way of finding lists to plunder), then going through the usual email confirmation step (ok, not hard if your mail service lets you pop mail from them). No one is going to bother implementing and maintaining this attack while they can grep addresses straight out of Usenet, off the web and out of DNS. If at some point in the future, those sources dry up, then it might be time to rearm. If there's compeling evidence that private archives and voluntary address obfuscation methods are failing, then it's time to rearm. But let's just keep in mind that this will always be an arms race, and that at the end of the day, it's only junk mail. John From jra@baylink.com Thu Feb 21 22:02:49 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 21 Feb 2002 17:02:49 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: ; from Chuq Von Rospach on Thu, Feb 21, 2002 at 09:23:51AM -0800 References: Message-ID: <20020221170249.40265@scfn.thpl.lib.fl.us> On Thu, Feb 21, 2002 at 09:23:51AM -0800, Chuq Von Rospach wrote: > This hits another aspect of my design philosophy. Don't sweat making one > part of the system more secure than the other parts. And very well phrased. > In this case, you hit a nail on the head. If a spammer really, really wants > your subscribers, we can't stop him. They can simply subscribe to a list and > harvest it as it comes across. Unless you choose to anonymize every bloody > message -- a spammer will win if they're motivated enough, and a smart > spammer will do so in a way you'll never find. Like setting up a hotmail > address for each list, so you can't see that all 30 lists have the same > address in common, and simply reading messages as they come by. > > And since, inherently, you can't stop THAT, it makes no sense to make > archives more secure than that. Any spammer smart enough to be willing to > subscribe to a list to do their harvesting, you're going to have a very > tough time stopping. Basically, you have to get lucky or hope they make a > mistake or some sort. My problem is with your characterization of that as "smart". I don't think that requires a whole helluva lot of brains, myself. > Yes, I am an agent of Satan, but my duties > are largely ceremonial. Are you the guy who goes in the convenience store to get him cigarettes? Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Thu Feb 21 22:01:09 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 21 Feb 2002 17:01:09 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000301c1baec$3cd62580$56296c42@damien>; from Damien Morton on Thu, Feb 21, 2002 at 10:27:08AM -0500 References: <1014302256.20836.29.camel@gaspode.localnet> <000301c1baec$3cd62580$56296c42@damien> Message-ID: <20020221170109.11482@scfn.thpl.lib.fl.us> On Thu, Feb 21, 2002 at 10:27:08AM -0500, Damien Morton wrote: > I wonder if the ADA would accept the need to obscure email addresses, > and I wonder if they would accept the extra authentication step required > to get at the unobscured email address? Would they understand that it > protects all mailman users, including the disabled? Stunningly unlikely... > Would Lynx users and other browser-disadvantaged users accept the extra > authentication/authorisation step to get at the unobscured email > addresses? Would they understand that it protects _them_ as well? If each page had a link to the version of that same page that required authentication, so that I wouldn't have to go do a whole-nother damned search, yeah... > > And insulting lynx users isn't a way to increase your > > expected life span. Go do something less controversial like > > arguing the advantages of vi in the emacs news groups. > > Agreed, appologies to recidivists, luddites and lynx users :) Nice to know that you understand now that those are three separate groups. :-) Cheers, -- jra -- Jay R. Ashworth jra@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") From dm-temp-310102@nyc.rr.com Thu Feb 21 22:21:47 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Thu, 21 Feb 2002 17:21:47 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020221170109.11482@scfn.thpl.lib.fl.us> Message-ID: <001f01c1bb26$2a28c1b0$56296c42@damien> > From: Jay R. Ashworth > > On Thu, Feb 21, 2002 at 10:27:08AM -0500, Damien Morton wrote: > > I wonder if the ADA would accept the need to obscure email > addresses, > > and I wonder if they would accept the extra authentication step > > required to get at the unobscured email address? Would they > understand > > that it protects all mailman users, including the disabled? > > Stunningly unlikely... Would they accept it if the email addresses were omitted in the public archives, and an extra authentication step required to get into the private archives. These might be a questions better answered by the ADA themselves. > > Would Lynx users and other browser-disadvantaged users accept the > > extra authentication/authorisation step to get at the > unobscured email > > addresses? Would they understand that it protects _them_ as well? > > If each page had a link to the version of that same page that > required authentication, so that I wouldn't have to go do a > whole-nother damned search, yeah... Cookies can be your friend. Remember, we arent talking about putting obstacles in the way of getting access to pages, but merely to pages that contain raw email addresses. From chuqui@plaidworks.com Thu Feb 21 22:20:47 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 21 Feb 2002 14:20:47 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020221220024.692FE13D7F@registry.e-servicesltd.co.nz> Message-ID: On 2/21/02 2:00 PM, "John Morton" wrote: > I think we're really getting into wild speculation territory here. No one > will bother hacking the code to automatically get new free mail accounts [...] Nobody has bothered to do this YET. That we know of. But the spamhacks are evolving rapidly. More rapidly than the anti-spam hacks in many ways. I sure wouldn't depend on them never doing this. I'm not sure what we'd do if they did, either, but some aspects of it have happened to me in small ways, just not from the major spamhacks. Fact is, if they want your subscribers, they can get them. Or more correctly, your subcribers that post -- but if everyone lurks in fear, why hav a mail list? The question is, what can we do to make it as tough as we can for the spammers, without screwing it up for us (as admins) or our list users. If only because the harder we make it for them to hack us, they more likely they'll go somewhere else that's easier to crack... On the other hand, if Mailman does become the de-factor mail list standard, or one of a couple of key list servers, you can bet the spam ahcks will focus on it, because if they can crack the code, they can crack a LOT of lists really fast. So we have the potential to become a target of our success, and we should be aware of that. > No one is going to bother implementing and maintaining this attack while they > can grep addresses straight out of Usenet, off the web and out of DNS. The "low hanging fruit" theory, or as I used yesterday, it's "the club" mentality. The Club (which, for those who don't catch my reference) is a big hunk o' steel you lock to your steering wheel. It's ability to slow down a car thief boils down to two things: how badly the thief wants YOUR car (vs. Any car), and how many other cars they can steal more easily. But what happens when other groups get smart too, and clean up the low hanging fruit? Depending on that to protect us is a false security, basically no better than the old security-by-obscurity issue. Given port scanners and the like, there IS no obscurity from the crackers any more. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From jwblist@olympus.net Thu Feb 21 23:56:04 2002 From: jwblist@olympus.net (John W Baxter) Date: Thu, 21 Feb 2002 15:56:04 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: At 12:15 -0500 2/21/2002, Dale Newfield wrote: >The two I marked with (****) above are not obfuscation schemes. >They involve not the obfuscation of information, but rather it's removal. Oh, good...another debating point. Is removal the limiting case of obfuscation, or something different in kind? ;-) --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From jwm@plain.co.nz Fri Feb 22 01:25:07 2002 From: jwm@plain.co.nz (John Morton) Date: Fri, 22 Feb 2002 14:25:07 +1300 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020222012508.BACF013D7F@registry.e-servicesltd.co.nz> On Friday 22 February 2002 11:20, Chuq Von Rospach wrote: > On 2/21/02 2:00 PM, "John Morton" wrote: > > I think we're really getting into wild speculation territory here. No one > > will bother hacking the code to automatically get new free mail accounts > > [...] > > Nobody has bothered to do this YET. That we know of. But the spamhacks are > evolving rapidly. Well, let's find out shall we? Set up a honeypot private list containing a collection of free mail accounts, then cycle through the account every week checking for spam and making some postings to keep the traffic up. Enough with the armchair anthropology, already! > More rapidly than the anti-spam hacks in many ways. I > sure wouldn't depend on them never doing this. I agree. That's because we're in an arms race here. Email harvesters are probably evolving faster than the countermeasures because of the tendency to deploy one countermeasure and forget about it. > I'm not sure what we'd do if > they did, either, but some aspects of it have happened to me in small ways, > just not from the major spamhacks. So basically you need to deploy a countermeasure, monitor it's effectiveness, and deploy another when it fails. Repeat for as long as you consider it important, or can tolerate not resorting to private archives, and establishing better trust relationships with the subscribers. > Fact is, if they want your subscribers, they can get them. Or more > correctly, your subscribers that post -- but if everyone lurks in fear, why > hav a mail list? I think we all need to take a deep breath and say 'It's only junkmail'. They're not spending up large on your credit card or pouring sugar into your gas tank. > The question is, what can we do to make it as tough as we > can for the spammers, without screwing it up for us (as admins) or our list > users. If only because the harder we make it for them to hack us, they more > likely they'll go somewhere else that's easier to crack... Right. So let's go with contact forms for list admins, and slashdot style, per user configurable address mangling for the archives. Let's do a little research into the ongoing effectiveness of these methods, too, so we know when it's time to implement something more expensive. > On the other hand, if Mailman does become the de-factor mail list standard, > or one of a couple of key list servers, you can bet the spam ahcks will > focus on it, because if they can crack the code, they can crack a LOT of > lists really fast. So we have the potential to become a target of our > success, and we should be aware of that. It's probably one of the top three or four already. Do listserv and majordomo admins have a major spam problem? The two above techniques will work fine. If I, as a list subscriber feel that the signal to noise ratio is dropping, I can change my address mangling scheme. Hiding the otherwise web published list admin address behind a form should just about protect it by that vector for all time as it will just never be worthwhile hitting a collection of forms when you can get vast lists of addresses elsewhere. (of course you have to publish the mailing list address, so you can deduce the admin address from that...:-) > But what happens when other groups get smart too, and clean up the low > hanging fruit? Depending on that to protect us is a false security, > basically no better than the old security-by-obscurity issue. Given port > scanners and the like, there IS no obscurity from the crackers any more. The problem with obscurity as a security tool is that it's not reliable. You may as well assume that one day your secret will be out, so the decision as to where and how to deploy it needs to be made based on the cost of obscuring, the cost of having the information revealed, the cost of reimplementing the system to replace the obscured part, and the size of the window of opportunity created before you can fix the problem. Passwords, passphrases, keys and so forth are all examples of security through obscurity. They work because it's very easy to replace them; they work most effectively in systems that are good at detecting that they've been compromised. Striping identity strings from network daemons is another security through obscurity technique. No one would rely on it to protect them, but it does make the job harder for attackers and easier for the defenders - they have to try a lot more things to detect what software is behind the port, or just brute force it with known attacks, greatly increasing the detection and response time available to defenders. Obscurity is useful. In our case, it's the only prevention tool we have. Email addresses are not secrets, but we still want to protect them from the bad guys while making them available to the good guys. We will never solve this problem. Even if you made all the subscribers sign a contract promising not reveal the addresses of the list membership to non-subscribers, and had reason to trust that they where not spammers. Someone could always go over to the dark side. An outlook virus could alway be used as the spam vector. And so on. The best we can do here is implement something simple now that gets the job done, and continuously test it to see if it's still good enough. When it's not, we build another countermeasure. John From spacey-mailman@lenin.nu Fri Feb 22 01:30:09 2002 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Thu, 21 Feb 2002 17:30:09 -0800 Subject: [Mailman-Developers] Can someone change the subject? In-Reply-To: <20020221220024.692FE13D7F@registry.e-servicesltd.co.nz> References: <20020221220024.692FE13D7F@registry.e-servicesltd.co.nz> Message-ID: <20020222013009.GA6734@lenin.nu> OK, the original article has long ago ceased to be an interesting one, and the conversation in general has veered towars raw flamage. Please, whoever wants to continue this please change the subject to read something like "overblown flamewar". -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From chuqui@plaidworks.com Fri Feb 22 01:36:34 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 21 Feb 2002 17:36:34 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020222012508.BACF013D7F@registry.e-servicesltd.co.nz> Message-ID: On 2/21/02 5:25 PM, "John Morton" wrote: >> Nobody has bothered to do this YET. That we know of. But the spamhacks are >> evolving rapidly. > > Well, let's find out shall we? Set up a honeypot private list containing a > collection of free mail accounts, then cycle through the account every week > checking for spam and making some postings to keep the traffic up. Enough > with the armchair anthropology, already! Um, John? I've been doing that for months. It's a standard tactic I use to test for archive harvests. No offense, but given I'd already thought of the "subscribe and harvest" attack, wouldn't you think I also would have looked for ways to detect it? I just don't like to talk about it. One has to think the harvesters are listening. I don't like giving away too many secrets -- but at the same time, it's something we have ot share ideas and concepts over... > So basically you need to deploy a countermeasure, monitor it's effectiveness, > and deploy another when it fails. Repeat for as long as you consider it > important, or can tolerate not resorting to private archives, and > establishing better trust relationships with the subscribers. Yup. Sounds familiar. >> Fact is, if they want your subscribers, they can get them. Or more >> correctly, your subscribers that post -- but if everyone lurks in fear, why >> hav a mail list? > > I think we all need to take a deep breath and say 'It's only junkmail'. > They're not spending up large on your credit card or pouring sugar into your > gas tank. I won't argue. I expect Jay will pop up shortly and do it for me. Which is, I think, the point. Just because you aren't too sensitive to the mail doesn't mean others aren't -- so we have to keep all of the views in mind. And this is a case where I actually side more on your view, but still understand the need to manage this for those that don't have my tolerance level. > It's probably one of the top three or four already. Do listserv and majordomo > admins have a major spam problem? Majordomo I did. Majordomo II? I dunno. Ditto listserv. I simply haven't looked. > (of course you have to publish the mailing list address, so you can deduce > the admin address from that...:-) Only if you don't change them. Making them standard might not be a good idea, once they're hidden behind contact forms. > The problem with obscurity as a security tool is that it's not reliable. It only works until it fails, and then you can't fix it. And I've found it invariably fails at 10PM on a Friday night, when you're about to leave for the weekend -- unless it's 2PM on a Thursday with a Friday deadline. > Obscurity is useful. In our case, it's the only prevention tool we have. I'm not sure obscurity is the right word. Most of what we're talking about is more of a cloaking effort. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From jwm@plain.co.nz Fri Feb 22 02:38:34 2002 From: jwm@plain.co.nz (John Morton) Date: Fri, 22 Feb 2002 15:38:34 +1300 Subject: [Mailman-Developers] Save the world from spam In-Reply-To: References: Message-ID: <20020222023836.0C00C13D7F@registry.e-servicesltd.co.nz> On Friday 22 February 2002 14:36, Chuq Von Rospach wrote: > On 2/21/02 5:25 PM, "John Morton" wrote: > >> Nobody has bothered to do this YET. That we know of. But the spamhacks > >> are evolving rapidly. > > > > Well, let's find out shall we? Set up a honeypot private list containing > > a collection of free mail accounts, then cycle through the account every > > week checking for spam and making some postings to keep the traffic up. > > Enough with the armchair anthropology, already! > > Um, John? I've been doing that for months. It's a standard tactic I use to > test for archive harvests. No offense, but given I'd already thought of the > "subscribe and harvest" attack, wouldn't you think I also would have looked > for ways to detect it? Excellent. Would you mind publishing an analysis so we can start making some informed decisions as to what methods are effective? > I just don't like to talk about it. One has to think the harvesters are > listening. I don't like giving away too many secrets -- but at the same > time, it's something we have ot share ideas and concepts over... Wah! Spammers aren't the NSA/Red Menace/Grey Aliens. I think we can and should be discussing what they're acutally up to if we want to find good methods of dealing with it. Don't get me started on full disclosure :-) > > I think we all need to take a deep breath and say 'It's only junkmail'. > > They're not spending up large on your credit card or pouring sugar into > > your gas tank. > > I won't argue. I expect Jay will pop up shortly and do it for me. Which is, > I think, the point. Just because you aren't too sensitive to the mail > doesn't mean others aren't -- so we have to keep all of the views in mind. > And this is a case where I actually side more on your view, but still > understand the need to manage this for those that don't have my tolerance > level. As a list admin, I'd like to inform my subscribers about their level of exposure, and empower them to decide whether there email address will appear in the archives, and how. I'd also like to keep the signal to noise ratio on the admin address in a tolerable state without running too great a risk of throwing the baby out with the bathwater by dropping too many legitimate crys for help along with the processed pig product. I'd like it if mailman would help me out with these things, but I don't want to _have_ to use ADA/text only browser busting jpeg addresses and reverse turing tests, and I don't want to have to use web form access to addresses in the archive as I won't trust that code until a lot of security geeks have looked it over. > Only if you don't change them. Making them standard might not be a good > idea, once they're hidden behind contact forms. Check. Add that to the admin form wishlist. > > The problem with obscurity as a security tool is that it's not reliable. > > It only works until it fails, and then you can't fix it. And I've found it > invariably fails at 10PM on a Friday night, when you're about to leave for > the weekend -- unless it's 2PM on a Thursday with a Friday deadline. As I said, obscurity works if you can replace one instance of compromised obscurity with another one fairly quickly. Works for passwords, and it can work well enough for this application, too. > > Obscurity is useful. In our case, it's the only prevention tool we have. > > I'm not sure obscurity is the right word. Most of what we're talking about > is more of a cloaking effort. That's because email addresses aren't secrets. If you can think of a better method than address mangling or hiding behind web forms, do tell. Personally, I'm willing to consider those good enough for the time being. John From chuqui@plaidworks.com Fri Feb 22 03:36:48 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 21 Feb 2002 19:36:48 -0800 Subject: [Mailman-Developers] Save the world from spam In-Reply-To: <20020222023836.0C00C13D7F@registry.e-servicesltd.co.nz> Message-ID: On 2/21/02 6:38 PM, "John Morton" wrote: >> Um, John? I've been doing that for months. It's a standard tactic I use to >> test for archive harvests. No offense, but given I'd already thought of the >> "subscribe and harvest" attack, wouldn't you think I also would have looked >> for ways to detect it? > > Excellent. Would you mind publishing an analysis so we can start making some > informed decisions as to what methods are effective? Oh, that's easy. I haven't found evidence of any harvesting. I've also been able to find evidence of harvesting from OTHER site's lists on at least three occcasions where people complained to me my lists were being harvested. > Wah! Spammers aren't the NSA/Red Menace/Grey Aliens. Whatever. You do what you think is best, I'll do what I think is best. > As a list admin, I'd like to inform my subscribers about their level of > exposure, and empower them to decide whether there email address will appear > in the archives, and how. I'd also like to keep the signal to noise ratio on > the admin address in a tolerable state without running too great a risk of > throwing the baby out with the bathwater by dropping too many legitimate crys > for help along with the processed pig product. > > I'd like it if mailman would help me out with these things, but I don't want > to _have_ to use ADA/text only browser busting jpeg addresses and reverse > turing tests, and I don't want to have to use web form access to addresses in > the archive as I won't trust that code until a lot of security geeks have > looked it over. Understood. But -- there are going to have to be some compromises and tradeoffs made. The whole discussion was intended to look for them, because I don't believe you can have all of that successfully. Something will have to give. >>> Obscurity is useful. In our case, it's the only prevention tool we have. >> >> I'm not sure obscurity is the right word. Most of what we're talking about >> is more of a cloaking effort. > > That's because email addresses aren't secrets. If you can think of a better > method than address mangling or hiding behind web forms, do tell. Personally, > I'm willing to consider those good enough for the time being. You know, now that I think of it, there's another approach: you don't get the admin's email address until you authenticate. Then you get it. If you're a list subscriber, you authenticate to the same level as the list is authenticated. If you're not, Mailman sends you an e-mail with the address in it (or FROM the address, so you can merely reply to it). No valid email address, no access to the admin. And if you do that, you can also set up a blackhole for known abusive addresses, shutting out the trolls.. Thoughts? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From jwm@plain.co.nz Fri Feb 22 05:18:27 2002 From: jwm@plain.co.nz (John Morton) Date: Fri, 22 Feb 2002 18:18:27 +1300 Subject: [Mailman-Developers] Save the world from spam In-Reply-To: References: Message-ID: <20020222051827.E79AE13D82@registry.e-servicesltd.co.nz> On Friday 22 February 2002 16:36, Chuq Von Rospach wrote: > > Excellent. Would you mind publishing an analysis so we can start making > > some informed decisions as to what methods are effective? > > Oh, that's easy. I haven't found evidence of any harvesting. I've also been > able to find evidence of harvesting from OTHER site's lists on at least > three occcasions where people complained to me my lists were being > harvested. And those lists had publicly accessable archives with no address mangling? > Understood. But -- there are going to have to be some compromises and > tradeoffs made. The whole discussion was intended to look for them, because > I don't believe you can have all of that successfully. Something will have > to give. Yep. Almost time to go back through the thread so far and summarize the options that have been discussed, I think. > > That's because email addresses aren't secrets. If you can think of a > > better method than address mangling or hiding behind web forms, do tell. > > Personally, I'm willing to consider those good enough for the time being. > > You know, now that I think of it, there's another approach: you don't get > the admin's email address until you authenticate. Then you get it. If > you're a list subscriber, you authenticate to the same level as the list is > authenticated. If you're not, Mailman sends you an e-mail with the address > in it (or FROM the address, so you can merely reply to it). No valid email > address, no access to the admin. And if you do that, you can also set up a > blackhole for known abusive addresses, shutting out the trolls.. > > Thoughts? I think the list admin address is exposed to subscribers in the welcome message and monthly reminders already; I presume you mean that to see a web page with it, you'd have to log in first. I think the problem with this is the most likely reason that someone would email the admin if they're subscribed is because they can't log into the site to change there settings, see the archive and so on, or they're trying to subscribe to the list but the email confirmation process is failing for some reason (this has happened to me on a couple of occasions due to MTA wierdness at the list end). Naturally, failures anywhere before the email confirmation process couldn't be reported, either. This one doesn't look to be any better than the web form, except that it might work in an email only environment. Perhaps both? John From dale@newfield.org Fri Feb 22 05:36:38 2002 From: dale@newfield.org (Dale Newfield) Date: Fri, 22 Feb 2002 00:36:38 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020222012508.BACF013D7F@registry.e-servicesltd.co.nz> Message-ID: On Fri, 22 Feb 2002, John Morton wrote: > The best we can do here is implement something simple now that gets the > job done, and continuously test it to see if it's still good enough. > When it's not, we build another countermeasure. I completely disagree. You argue for job security. I argue for better software. Temporary solutions are not solutions. -Dale From jwm@plain.co.nz Fri Feb 22 05:48:50 2002 From: jwm@plain.co.nz (John Morton) Date: Fri, 22 Feb 2002 18:48:50 +1300 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020222054851.C0DA213D89@registry.e-servicesltd.co.nz> On Friday 22 February 2002 18:36, Dale Newfield wrote: > On Fri, 22 Feb 2002, John Morton wrote: > > The best we can do here is implement something simple now that gets the > > job done, and continuously test it to see if it's still good enough. > > When it's not, we build another countermeasure. > > I completely disagree. You argue for job security. I argue for better > software. Temporary solutions are not solutions. Ok. Show me a solution that will protect list administrator addresses and publicly accessable list archives from email harvesting, while allowing list subscribers and members of the public the ability to contact the list admin in the event of a list related problem and allowing them to contact an individual personally in response to some message in the archive. The solution must not penalize text only web browser users, or the disabled, nor should it open up any other vectors for unsolicited mass emailing. I'd really like to see one. John From dale@newfield.org Fri Feb 22 05:58:12 2002 From: dale@newfield.org (Dale Newfield) Date: Fri, 22 Feb 2002 00:58:12 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020222054851.C0DA213D89@registry.e-servicesltd.co.nz> Message-ID: On Fri, 22 Feb 2002, John Morton wrote: > Ok. Show me a solution The point is that adding layer after layer of temporary solutions doesn't add up to an actual solution any more than not adding those layers. All it does add is more complexity to manage, more code to write and test, more annoyance to anyone trying to use the system, and more potential points of failure. Separate archives (public stripped of anything that looks like an email address, private unmodified), and an equivilant "give me archive access" path to the subscription path (through email) as has been suggested seems to be the best solution yet. -Dale From jwm@plain.co.nz Fri Feb 22 06:18:12 2002 From: jwm@plain.co.nz (John Morton) Date: Fri, 22 Feb 2002 19:18:12 +1300 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: References: Message-ID: <20020222061813.0F54413D89@registry.e-servicesltd.co.nz> On Friday 22 February 2002 18:58, Dale Newfield wrote: > On Fri, 22 Feb 2002, John Morton wrote: > > Ok. Show me a solution > > The point is that adding layer after layer of temporary solutions doesn't > add up to an actual solution any more than not adding those layers. All > it does add is more complexity to manage, more code to write and test, > more annoyance to anyone trying to use the system, and more potential > points of failure. This depends on just how temporary your 'solution' turns out to be, and it's level of complexity and usability. I don't think anyone has really advocate any really kludgy hacks so far. > Separate archives (public stripped of anything that > looks like an email address, private unmodified), and an equivilant "give > me archive access" path to the subscription path (through email) as has > been suggested seems to be the best solution yet. Not bad; it looks fairly easy to implement. I'd build the archive access to be just like regular list access, except delivery is turned off by default, to keep it simple. The problem is that if you accept that those nefarious agents of mass email will start auto-joining lists and plunder the private archive and message feed for addresses sometime in the future, then you have to implement another layer of hackery to detect and block that sort of thing. Does that make your suggestion any less of an actual solution? :-) I'd still go as far as adding per user configurability for address display so people can adjust the option to suit there own level of hysteria. John From dale@newfield.org Fri Feb 22 06:25:57 2002 From: dale@newfield.org (Dale Newfield) Date: Fri, 22 Feb 2002 01:25:57 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020222061813.0F54413D89@registry.e-servicesltd.co.nz> Message-ID: On Fri, 22 Feb 2002, John Morton wrote: > The problem is that if you accept that those nefarious agents of mass > email will start auto-joining lists and plunder the private archive and > message feed for addresses sometime in the future, then you have to > implement another layer of hackery to detect and block that sort of > thing. Does that make your suggestion any less of an actual solution? > :-) As was already pointed out, if the spambots get smart enough to subscribe, they don't need the archives--they just have to wait for the addresses to appear in their mailboxes. So once they've cleared that hurdle, nothing you do to the archives will help one bit. > I'd still go as far as adding per user configurability for address > display so people can adjust the option to suit there own level of > hysteria. That adds tremendous management headaches for both users and admins, as well as difficult coding problems (since whenever one subscriber quotes another you need to figure that out and do multiple "how should I obfuscate YOUR email adress?" lookups). Why not just ignore this non-solution and save everyone the headaches? -Dale From dale@newfield.org Fri Feb 22 06:27:59 2002 From: dale@newfield.org (Dale Newfield) Date: Fri, 22 Feb 2002 01:27:59 -0500 (EST) Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020222061813.0F54413D89@registry.e-servicesltd.co.nz> Message-ID: On Fri, 22 Feb 2002, John Morton wrote: > Not bad; it looks fairly easy to implement. I'd build the archive access > to be just like regular list access, except delivery is turned off by > default, to keep it simple. I thought about that, but do you really want to send monthly password reminders to people that just wanted to look at the archives? (Or do we not send those to people with "nomail" set?) -Dale From stephen@xemacs.org Fri Feb 22 08:18:26 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 22 Feb 2002 17:18:26 +0900 Subject: [Mailman-Developers] Save the world from spam In-Reply-To: References: Message-ID: <871yfeaq0d.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Chuq" == Chuq Von Rospach writes: Chuq> You know, now that I think of it, there's another approach: Chuq> you don't get the admin's email address until you Chuq> authenticate. Then you get it. [...] Chuq> Thoughts? You've just reinvented TMDA, basically, except for the initial contact protocol being HTTP instead of SMTP. TMDA would also protect admins of publically accessible lists (yes, I know that's basaqwards, Chuq, but it would keep them from aliasing the list admin address to /dev/null). I was going to suggest that a couple days ago, but assumed it was common knowledge here. http://sourceforge.net/projects/tmda Jason could probably be very helpful in tuning it to this specific application. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From stephen@xemacs.org Fri Feb 22 08:36:28 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 22 Feb 2002 17:36:28 +0900 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020222061813.0F54413D89@registry.e-servicesltd.co.nz> References: <20020222061813.0F54413D89@registry.e-servicesltd.co.nz> Message-ID: <87wux5ap6b.fsf@tleepslib.sk.tsukuba.ac.jp> I repeat myself, but only Chuq seems to have noticed the other post. >>>>> "John" == John Morton writes: John> This depends on just how temporary your 'solution' turns out John> to be, and it's level of complexity and usability. I don't John> think anyone has really advocate any really kludgy hacks so John> far. AFAICT both the trivial /. style obfuscation and the image style obfuscation are kludges because they ignore the statistical nature of harvesting. This works in two ways. First, since addresses are typically repeated but obfuscated in different ways, the probability that a given address gets harvested is much higher than the probability that any given obfuscated instance gets cracked. Second, you don't need to get 100% recognition, you don't even need to get 10% recognition, as long as you can process the bytes as fast as they come off the wire _and_ the number of harvested new addresses per megabyte is high enough. There is a third, "equilibrium" problem with obfuscation. Image obfuscation has the serious drawback that it looks "provably secure" if you don't think about it carefully. If this encourages lots more people to post real addresses, the value of the harvest rises proportionately and thus obfuscation decreases achieved security. I conclude that if obfuscated archives give a reasonable number of addresses per megabyte, and those addresses are drawn from a population that is not represented in other sources, spammers _will_ find cheap and dirty ways to achieve recognition, and then they will compete to improve it. People have seriously advocated obfuscation, especially images. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From dm-temp-310102@nyc.rr.com Fri Feb 22 14:16:20 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Fri, 22 Feb 2002 09:16:20 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <87wux5ap6b.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <000301c1bbab$89c6bf70$56296c42@damien> > From: Stephen J. Turnbull > > First, since addresses are typically repeated but obfuscated > in different ways, the probability that a given address gets > harvested is much higher than the probability that any given > obfuscated instance gets cracked. Second, you don't need to > get 100% recognition, you don't even need to get 10% > recognition, as long as you can process the bytes as fast as > they come off the wire _and_ the number of harvested new > addresses per megabyte is high enough. > > > > I conclude that if obfuscated archives give a reasonable > number of addresses per megabyte, and those addresses are > drawn from a population that is not represented in other > sources, spammers _will_ find cheap and dirty ways to achieve > recognition, and then they will compete to improve it. > > People have seriously advocated obfuscation, especially images. So obfuscation is imperfect, and the more effective it is, the more value there is in cracking it. Would you say, then, that youre advocating public and private list archives, with email addresses omitted from the public archives, and the private archives available to list members only? Im not clear on what your position is. A while ago, I laid out the decision/position tree, as I saw it. Only one person has clearly located their position in/on that tree, so I repeat it again. Im very interested to see where list members might locate their position in this decision tree. Please eel free to alter the tree, should your position not be included. Is it desireable to prevent the whole world seeing email addresses in mailman archives? If yes then should there be public and private archives, with the public archive protecting addresses? if yes how should the access to the private archives be controlled? list membership? (damien) reverse truing tests? (damien) other? what should go into the public archives? obfuscated email? email as images? (damien) text based obfuscation? links to web form email? (damien) omit email addresses entirely? other? else if no should an address protection scheme be used at all? if yes what protection scheme(s) should be used? obscured email? email as images? text based obfuscation? links to web form email? (dale) omit email addresses entirely? (dale) other? else if no talking in circles else if no end of conversation From stephen@xemacs.org Fri Feb 22 15:53:29 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 23 Feb 2002 00:53:29 +0900 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000301c1bbab$89c6bf70$56296c42@damien> References: <000301c1bbab$89c6bf70$56296c42@damien> Message-ID: <87adu18qdi.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Damien" == Damien Morton writes: Damien> So obfuscation is imperfect, and the more effective it is, Damien> the more value there is in cracking it. That's true, but that's not what I said. What I said is it is weak enough that a small amount of effort brings some payoff to harvesting, and the more effort, the higher the payoff. Furthermore, even though it is therefore not very effective, it's easy to convince yourself it is, and this _perception_ generates more value for spammers. Damien> Im not clear on what your position is. My position is that (1) obfuscation is unlikely to last 6 months after it becomes widespread, and (2) it is an unsatisfactory method for inclusion as a standard in Mailman, because it is costly to develop, and costly to all the legitimate users both in immediate inconvenience and in false sense of security, while probably not slowing down the spammers much. Beyond that, I don't have a position; I plan to ask my subscribers/ posters how they feel about it, and treat my own lists accordingly. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From jra@baylink.com Fri Feb 22 18:32:28 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 22 Feb 2002 13:32:28 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <000301c1bbab$89c6bf70$56296c42@damien>; from Damien Morton on Fri, Feb 22, 2002 at 09:16:20AM -0500 References: <87wux5ap6b.fsf@tleepslib.sk.tsukuba.ac.jp> <000301c1bbab$89c6bf70$56296c42@damien> Message-ID: <20020222133228.08994@scfn.thpl.lib.fl.us> On Fri, Feb 22, 2002 at 09:16:20AM -0500, Damien Morton wrote: > Is it desireable to prevent the whole world seeing email addresses in > mailman archives? > If yes then > should there be public and private archives, with the public > archive protecting addresses? > if yes > how should the access to the private archives be > controlled? > list membership? (damien) > reverse truing tests? (damien) > other? > what should go into the public archives? > obfuscated email? > email as images? (damien) > text based obfuscation? > links to web form email? (damien) > omit email addresses entirely? > other? > else if no > should an address protection scheme be used at all? > if yes > what protection scheme(s) should be used? > obscured email? > email as images? > text based obfuscation? > links to web form email? (dale) > omit email addresses entirely? (dale) > other? > else if no > talking in circles Well, this is where I sit -- and please note that I'm discussing *implementation of actual lists*, not *what facilities I think Mailman should provide*; if you feel this invalidates my opinion, so be it -- and I think that characterizing it as "talking in circle" is a bit digingenuous, at best. Please expand. > else if no > end of conversation Cheers, -- jra -- Jay R. Ashworth jra@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") From barry@zope.com Fri Feb 22 23:32:22 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 22 Feb 2002 18:32:22 -0500 Subject: [Mailman-Developers] Can someone change the subject? References: <20020221220024.692FE13D7F@registry.e-servicesltd.co.nz> <20020222013009.GA6734@lenin.nu> Message-ID: <15478.54534.51789.263094@anthem.wooz.org> >>>>> "PCN" == Peter C Norton writes: PCN> OK, the original article has long ago ceased to be an PCN> interesting one, and the conversation in general has veered PCN> towars raw flamage. Please, whoever wants to continue this PCN> please change the subject to read something like "overblown PCN> flamewar". I love it! I go away on vacation for a week and huge threads flame up and die out while I'm gone. I guess I can ignore the whole thing now right? . Oh, and sorry about my broken vacation program. At least it totally refused to send out any vacation messages rather than puke all over all my mailing lists with thousands of useless notices. I'm going to try to catch up this weekend, but I'll tell you, if we had gotten as much snow as I got email while I was away (even of the non-spam variety), I'd have stayed on the slopes another week. Watch for a bunch of checkins too. Yes, I was just sick enough to bring my laptop with me. Hey, you gotta do something after the champagne's gone. -Barry From barry@zope.com Wed Feb 20 04:47:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 19 Feb 2002 23:47:05 -0500 Subject: [Mailman-Developers] Future: Safe Auto-moderated Announce List References: Message-ID: <15475.10825.995066.738781@geddy.wooz.org> >>>>> "JWB" == John W Baxter writes: JWB> I see the basic "how do I let the right people post to this JWB> announce list automatically" question often enough to JWB> indicate that there is a perceived need. JWB> Let's put digital signature technology to work. With MM2.1, this will only be necessary if you don't trust the From: header. I'm not saying I do trust it -- we all know it's easily forged, but I am saying that the basic mechanisms you talk about are already in place. We'd simply need to add a way to manage and consult the PKI. I'd classify this as a useful feature for MM3.0, once we have a consolidated user database. Then the users could add public keys to their records and Mailman could consult them against the signatures for authentication of the From: address. JWB> Checkbox: Automatically and silently reject (with logging) JWB> any message not from a listed sender and properly signed. JWB> Variations (not silently rejected, etc, if desired...but JWB> sending a rejection message gives the would-be rogue poster JWB> information). This is turning into a common pattern, so it's likely something I'll refactor in future versions. You basically want to do something like this: - see if the message matches some criteria (e.g. from a known non-member, from a moderated member, etc.) - if so, then decide on an action: 1. approve the message right now; send on without further moderation steps 2. let pass to subsequent moderation steps; we haven't ruled this message out, but we haven't actively ruled it in either 3. hold the message for moderator approval - send a notification to the sender, or - don't send a notification to the sender 4. reject the message outright, bouncing it - this implies sending a notice to the sender 5. discard the message without further notification (but w/ logging probably). I've really only started to mull over in my mind the way to implement this. As usual, the sticky point is in designing a useable web gui for customization. >>>>> "DN" == Dale Newfield writes: >> Let's put digital signature technology to work. DN> I think we'd get quite a bit of bang for the effort just DN> adding a checkbox to the admindb page saying "and add this DN> sender to auto-approve list?" So it's easy to moderate a DN> person's messages as long as you want, and then also easy to DN> say "yeah--approve this and all future posts from this DN> person.") My time machine is working well then! Check out MM2.1's admindb summary page. You can by default turn on the moderation flag for all new members, and decide on an action for a moderated member (see above). If you decide to hold messages from moderated members, you'll see an extra checkbox on the disposition gui asking you if you want to turn off the member's moderation flag. This will be the way to quarantine new members until they can be trusted. You'll also be able to do things like ban somebody from subscribing from a list. -Barry From barry@zope.com Wed Feb 20 04:30:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 19 Feb 2002 23:30:05 -0500 Subject: [Mailman-Developers] VERP_DELIVERY_INTERVAL not yet functional ? References: <200202052336.PAA00948@utopia.West.Sun.COM> <20020211175901.A15319@monde-diplomatique.fr> <15464.27555.383406.744200@anthem.wooz.org> <20020212115301.A23803@monde-diplomatique.fr> Message-ID: <15475.9805.929291.215844@geddy.wooz.org> >>>>> "fil" == fil writes: >> The quick fix is to move the occasional VERP calculation into >> ToOutgoing.py, which is part of the munge-and-moderate >> pipeline, and thus will always have the up-to-date list data. fil> Is that really necessary? If it imposes some overhead, you fil> could use .... not (int(random() * fil> mm_cfg.VERP_DELIVERY_INTERVAL)): ... That's an interesting idea, but moving the calculation to ToOutgoing.py lets us do it a little more deterministically, with no extra cost. >> A related, longer term fix is to make sure that OutgoingRunner >> occasionally reloads the list data, but that's a bit tricky >> because we can't count on reference counting (maybe we could >> use Python2.1's weakrefs?) and we don't yet have an API to >> invalidate the MailList's state. I should mention that this change is really a "makes me feel better about it" kind of change. MM2.1 functionality shouldn't depend on this, but someday, something will and it's better to fix it now than to muddle over it all over again a year or so from now. :) If it's really a performance killer (and I think that it won't be bad given my currently implementation), then we can remove it fairly easily. -Barry From barry@zope.com Wed Feb 20 03:33:01 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 19 Feb 2002 22:33:01 -0500 Subject: [Mailman-Developers] Pipermail replacement? Zest! References: <15465.40265.533837.712733@anthem.wooz.org> Message-ID: <15475.6381.891758.575462@geddy.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: JRM> After looking at the Zest sample output, I'd have to say I JRM> still like pipermail's output better. The thing that's really cool about Zest is that you can follow the conversation almost completely by skimming the left frame. Although we won't know until it's in production, my gut tells me that it'll be /much/ easier with Zest to zero in on exactly the message that you care about. The unfortunate thing about Zest is the frame layout. Personally, I hate frames primarily because of the bookmarking problem. That might be alleviated with a "bookmark this message" link. JRM> I think pipermail is fine, it just lacks search capability JRM> which is the only reason I still use Wilma to archive my JRM> lists (see http://mla.libertine.org/tmda-users for a sample). Pipermail is basically a jumble of unmaintainable code. So far, no one's stepped up to the plate to fix the major glaring problems[*] and I'm not going to do it. If people get fired up about Zest aside from Mailman, I'll be happy to bundle it with Mailman, or at least make it really really easy to hook in. If someone wants to build a better Pipermail, I'm all for that too. -Barry [*] I think I've fixed the problem with the lack of MIME knowledge. Now we need to fix things like: - the huge memory consumption when rebuilding an archive from scratch - the lack of predictable unchanging url for a message (i.e. regenerate from scratch and it's possible all your bookmarked urls will break). - the ability to ask the archiver "what's the url for the message with this Message-ID:" - the ability to handle multiple charsets in a single message - performance problems for on-the-fly re-indexing when adding a message - searching - the ability for threads to span the artificial by-date index boundaries From barry@zope.com Wed Feb 20 04:48:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 19 Feb 2002 23:48:11 -0500 Subject: [Mailman-Developers] Problems with Cookie.py while upgrading References: <20020211211746.GO4569@ohnesorg.cz> Message-ID: <15475.10891.928404.666632@geddy.wooz.org> >>>>> "DO" == Dan Ohnesorg writes: DO> One beta tester of czech localization for mailman has me DO> reported this bug, which I am trying to translate into DO> English. DO> Mailman 2.0 uses its own modules Cookie.py and imports Cookie DO> class from it. DO> Mailman 2.1 uses this module from Python 2.2 and renames there DO> presented class from BasicCookie to Cookie. DO> And the problem is, that update script will try to remove the DO> unused Cookie.py, but it will first import it (indirectly) so DO> the whole update scrtipt fails to execute and has no DO> possibility to delete the unused file. DO> I hope, you will know what I mean. I do indeed, and I believe this problem is fixed in CVS. Do you know which version your tester was using? (I don't remember if it was fixed in alpha4). -Barry From barry@zope.com Wed Feb 20 02:13:43 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 19 Feb 2002 21:13:43 -0500 Subject: [Mailman-Developers] mylist-subscribe / mylist-unsubscribe References: Message-ID: <15475.1623.674782.645165@geddy.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: JRM> I noticed there are new "robot addresses" in MM 2.1 to ease JRM> subscribing and unsubscribing. JRM> mylist-join@mysite mylist-leave@mysite JRM> Great idea, but why not -subscribe and -unsubscribe as is JRM> already done in ezmlm? No (good) reason, really. I've added these two as aliases for -join and -leave respectively. -Barry From barry@zope.com Wed Feb 20 15:53:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 20 Feb 2002 10:53:48 -0500 Subject: [Mailman-Developers] User Database Wish List Feature Suggestion References: <3C35ED89.7C9358AB@perkel.com> Message-ID: <15475.50828.466289.373145@geddy.wooz.org> >>>>> "MP" == Marc Perkel writes: MP> Since you will be changing the user database - why not add MP> some date fields - like - date joined - maybe date the user MP> last modified their account - and the last date the sent an MP> email message. MP> It would also be nice if it stored some counters - like the MP> number of messages sent - maybe the number of messages sent in MP> the last month. All good ideas, but I think we'll wait until we've got the consolidated user database. MP> Master stats would also be nice - messages sent through the MP> list - number of megabytes of transfer - total and monthly. Aren't these available now by trolling through the existing log files? -Barry From barry@zope.com Wed Feb 20 03:49:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 19 Feb 2002 22:49:23 -0500 Subject: [Mailman-Developers] MM2.1 playground on python.org References: <15465.40691.159516.770726@anthem.wooz.org> <87lmdym6f4.fsf@nausicaa.interq.or.jp> <15466.1478.122250.652333@anthem.wooz.org> <878z9xlu2x.fsf@nausicaa.interq.or.jp> Message-ID: <15475.7363.545261.766291@geddy.wooz.org> >>>>> "BG" == Ben Gertzfield writes: >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BAW> Yup, there's a traceback in logs/error (attached below). BAW> Probably due to the lack of installed Japanese codecs. I'll BAW> have to make Mailman robust against this situation, and then BAW> install the codec on python.org. BG> I thought I had done that in my latest patch.. hrm. Well, I BG> guess the best thing to do in the case of Japanese is to just BG> send mails in English if the Japanese codecs are not BG> installed. BG> Sending mails in broken EUC-JP (long headers will not work) is BG> not really an option. So we should put in a hacklet for BG> Japanese and Chinese to send internally generated emails in BG> English if the codecs are not found. Does it have to be a special-cased hack? Can we just always fall back to English if the codec can't be found? Do you have any suggestions for where the patch ought to go? -Barry From jarrell@vt.edu Sat Feb 23 20:44:39 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sat, 23 Feb 2002 15:44:39 -0500 (EST) Subject: [Mailman-Developers] current snapshot install... Message-ID: <200202232044.g1NKid520871@babylon5.cc.vt.edu> Updated my snapshot, and was playing with install. Install *really* shouldn't depend on someone having installed a tar that understands the "z" option. And, given that the rest of the install stresses doing things are yourself, it really shouldn't be trying to install the email kit anyway - I've *never* installed mailman as something that *could* install a new python module... From che@debian.org Sun Feb 24 00:20:13 2002 From: che@debian.org (Ben Gertzfield) Date: Sun, 24 Feb 2002 09:20:13 +0900 Subject: [Mailman-Developers] MM2.1 playground on python.org In-Reply-To: <15475.7363.545261.766291@geddy.wooz.org> (barry@zope.com's message of "Tue, 19 Feb 2002 22:49:23 -0500") References: <15465.40691.159516.770726@anthem.wooz.org> <87lmdym6f4.fsf@nausicaa.interq.or.jp> <15466.1478.122250.652333@anthem.wooz.org> <878z9xlu2x.fsf@nausicaa.interq.or.jp> <15475.7363.545261.766291@geddy.wooz.org> Message-ID: <87pu2v3f42.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: BG> Sending mails in broken EUC-JP (long headers will not work) is BG> not really an option. So we should put in a hacklet for BG> Japanese and Chinese to send internally generated emails in BG> English if the codecs are not found. BAW> Does it have to be a special-cased hack? Can we just always BAW> fall back to English if the codec can't be found? BAW> Do you have any suggestions for where the patch ought to go? All we will have to do is make Message.py's UserNotification class somehow deal with when the codec is not found. It may require a modification to mimelib to return a unique error when the codec isn't found. Ben -- Brought to you by the letters J and W and the number 19. "You have my pills!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From barry@zope.com Sun Feb 24 05:24:58 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 24 Feb 2002 00:24:58 -0500 Subject: [Mailman-Developers] current snapshot install... References: <200202232044.g1NKid520871@babylon5.cc.vt.edu> Message-ID: <15480.31018.798785.873340@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Updated my snapshot, and was playing with install. Install RJ> *really* shouldn't depend on someone having installed a tar RJ> that understands the "z" option. Yeah, I know that. The command should be rewritten to use gunzip piping to tar. Can we count on that existing some place? If there are doubts, we can add a configure test w/ a warning if those progs are missing. RJ> And, given that the rest of the install stresses doing things RJ> are yourself, it really shouldn't be trying to install the RJ> email kit anyway - I've *never* installed mailman as something RJ> that *could* install a new python module... That's the point of the change, Mailman does not (now) install the email package into some place that will affect your normal Python environment. It installs it in a place that only Mailman will use. -Barry From spacey-mailman@lenin.nu Sun Feb 24 09:54:00 2002 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Sun, 24 Feb 2002 01:54:00 -0800 Subject: [Mailman-Developers] current snapshot install... In-Reply-To: <15480.31018.798785.873340@anthem.wooz.org> References: <200202232044.g1NKid520871@babylon5.cc.vt.edu> <15480.31018.798785.873340@anthem.wooz.org> Message-ID: <20020224095400.GA14548@lenin.nu> On Sun, Feb 24, 2002 at 12:24:58AM -0500, Barry A. Warsaw wrote: > Yeah, I know that. The command should be rewritten to use gunzip > piping to tar. Can we count on that existing some place? If there > are doubts, we can add a configure test w/ a warning if those progs > are missing. These days if someone doesn't have gzip installed they should be doing it ASAP. Even solaris users can get stuff like this from Sun now. Making gzip a requirement isn't an issue on any modern platform. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From barry@zope.com Sun Feb 24 18:18:46 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 24 Feb 2002 13:18:46 -0500 Subject: [Mailman-Developers] Interesting study -- spam on posted addresses... References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <20020218102139.30621@scfn.thpl.lib.fl.us> <20020218234209.9DCBA13D58@registry.e-servicesltd.co.nz> Message-ID: <15481.11910.925096.614284@anthem.wooz.org> >>>>> "JM" == John Morton writes: JM> No, it just involves squashing the two actions a user needs to JM> take into one, more obvious action - rather than subscribe a JM> new address, confirm it, then delete the old address and JM> confirm it, you change the address (keeping the settings), and JM> confirm both dropping the old address and sending to the new JM> one as a pair of emails. Iff both confirmations succeed, the JM> address changes, otherwise it stays as it was. Adding other JM> valid sending addresses will also require an email JM> confirmation action. I'm working on a longer response to this thread, but let me just point out that MM2.1 already allows users to change their email address (even globally for all lists at the site). It requires only a confirmation from the new address because the action is hidden behind a password screen. So we know the old address has been authenticated and we need only verify that the new address wants the change as well. Adding email addresses to the user's record requires a more radical change to the underlying schema so that's put off for MM3, but there are plans and (tentative) designs for it. -Barry From listmgr@perilpoint.com Sun Feb 24 20:17:18 2002 From: listmgr@perilpoint.com (Bradford Shaw) Date: Sun, 24 Feb 2002 14:17:18 -0600 Subject: [Mailman-Developers] moving list archives Message-ID: <4.2.0.58.20020224140827.00d1a420@perilpoint.com> Hello, I'm moving lists to a different server and would like to zip up their archives and unzip them on the new server. Is this possible without creating problems? I am concerned about making the lists inaccessible if I do this. Since I have created new lists that were not on the old server, it is not possible to zip up the directory and move that in total. Any assistance would be greatly appreciated. Best wishes, Bradford "Biff" Shaw List Administrator PerilPoint Communications Inc. http://www.perilpoint.com From jarrell@vt.edu Mon Feb 25 02:42:34 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sun, 24 Feb 2002 21:42:34 -0500 Subject: [Mailman-Developers] current snapshot install... In-Reply-To: <15480.31018.798785.873340@anthem.wooz.org> References: <200202232044.g1NKid520871@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020224213524.00a4aa40@lennier.cc.vt.edu> At 12:24 AM 2/24/02 -0500, you wrote: > >>>>> "RJ" == Ron Jarrell writes: > > RJ> Updated my snapshot, and was playing with install. Install > RJ> *really* shouldn't depend on someone having installed a tar > RJ> that understands the "z" option. > >Yeah, I know that. The command should be rewritten to use gunzip >piping to tar. Can we count on that existing some place? If there >are doubts, we can add a configure test w/ a warning if those progs >are missing. I'd imagine upwards of 90% of systems out there have gunzip. Or maybe just use gzip -d. It would, however, add another required component, and this one just for one itty bit of the install. Honestly, since you're distributing everything as a compressed tarball already, do really need to also compress email? Just ship it as a straight tar, or, better yet, ship it as an untarred tree... > > RJ> And, given that the rest of the install stresses doing things > RJ> are yourself, it really shouldn't be trying to install the > RJ> email kit anyway - I've *never* installed mailman as something > RJ> that *could* install a new python module... > >That's the point of the change, Mailman does not (now) install the >email package into some place that will affect your normal Python >environment. It installs it in a place that only Mailman will use. Ah. I didn't study the actual makefile commands far enough to notice that. I just the the "grumble grumble what in hell are you doing barry grumble grumble" comment out the offending part command... :-) From marc_news@vasoftware.com Mon Feb 25 08:01:21 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 25 Feb 2002 00:01:21 -0800 Subject: [Mailman-Developers] mailman wrapper chokes on unknown commands Message-ID: <20020225080121.GE12739@merlins.org> ----- Forwarded message from Mail Delivery System ----- So I was debugging this: test-bounces+merlin=gandalf.merlins.org@gandalf-lists.merlins.org Child process of mm21_transport transport returned 6 from command: /var/local/mailman/mail/mailman and found out that the mailman wrapper returns 6 with no error message if you send it an unexpected command, like: direct command after expansion: argv[0] = /var/local/mailman/mail/mailman argv[1] = bounces+merlin=gandalf.merlins.org argv[2] = test (argv[1] should have been just "bounces") Maybe a quick error message would be nice :-) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Mon Feb 25 08:36:39 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 25 Feb 2002 00:36:39 -0800 Subject: [Mailman-Developers] New uber exim transports/directors Message-ID: <20020225083638.GF12739@merlins.org> I've modified Nigel's exim transports (hopefully in good). Please review and tell me if this is fit for a patch to Barry: (I'll also submit an exim 4 version if those are good) The director now deals with VERP bounces and with lists that have -command in their name (like mailman-owner, which gets a mailman-owner-owner alias) The transport was improved to deal with local_part_suffix containing a VERP suffix # Mailman commands to run mm21_transport: driver = pipe # In case you wonder, substr_2 removes the leading '-' # and the regex removes optional +foo=hostname that can be after -bounce # (if you use VERP) -- Marc command = MAILMAN_WRAP "${if def:local_part_suffix{${substr_2:{${sg{${lc:$local_part_suffix}}{\\\\\+.*}{}}}}{post}}" ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID # Directors magic to support mailman lists without explicit aliases # We want this director first in case we have a list named something like # mailman-owner -- Marc mm21_main_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck transport = mm21_transport mm21_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.pck suffix = "-bounces:-bounces+*:-join:-leave:-owner:-request:-admin" transport = mm21_transport Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Mon Feb 25 08:51:03 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 25 Feb 2002 00:51:03 -0800 Subject: [Mailman-Developers] Can't get VERP to do much Message-ID: <20020225085103.GG12739@merlins.org> Ok, so I got VERP enabled, the envelope now looks good on outbound messages, and exim accepts messages back. I tried sending messages like this: echo -e "From: marc@merlins.org\nTo:test\n\ntest" | exim test-bounces+merlin=gandalf.merlins.org@gandalf-lists.merlins.org and they apparently didn't get picked up by bounce mechanism, but got sent to the list owner Then I tried to Email a list with a bouncing address, and triggered this; Feb 25 00:48:38 2002 (21519) Uncaught runner exception: no such group Feb 25 00:48:38 2002 (21519) Traceback (most recent call last): File "/var/local/mailman/Mailman/Queue/Runner.py", line 114, in __oneloop self.__onefile(msg, msgdata) File "/var/local/mailman/Mailman/Queue/Runner.py", line 162, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 74, in _dispose elif self.__verpbounce(mlist, msg): File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 112, in __verpbounce if bmailbox <> mo.group('bounces'): IndexError: no such group root@gandalf:/var/local/mailman/logs# cat ../qfiles/shunt/1014626917.416239+a9cf2c2ba9612bab36ead00ff58da9e5a9d40a06.pck (cMailman.Message Message qoq}q(preambleqN_charsetqN_payloadqTThis message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: sfsadfsadf@gandalf.merlins.org unknown local-part "sfsadfsadf" in domain "gandalf.merlins.org" ------ This is a copy of the message, including all the headers. ------ Return-path: Received: from localhost ([127.0.0.1] helo=gandalf.merlins.org ident=mailman) by gandalf.merlins.org with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 16fGoD-0006X6-00 for ; Mon, 25 Feb 2002 00:48:33 -0800 Received: from root by gandalf.merlins.org with local (Exim 3.31-VA-mm2 #1 (Debian)) id 16fGoC-0006Wy-00 for ; Mon, 25 Feb 2002 00:48:32 -0800 To: test@gandalf.merlins.org Message-Id: From: root Date: Mon, 25 Feb 2002 00:48:32 -0800 Subject: [Test] test 2 X-BeenThere: test@gandalf-lists.merlins.org X-Mailman-Version: 2.1a4+ Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://gandalf.merlins.org/lists/private/test/ test _______________________________________________ Test mailing list Test@gandalf-lists.merlins.org http://gandalf.merlins.org/lists/listinfo/test epilogueqNU _unixfromU+From MAILER-DAEMON Mon Feb 25 00:48:37 2002_headersq]q ((ReceivedUÍfrom mail by gandalf.merlins.org with local (Exim 3.31-VA-mm2 #1 (Debian)) id 16fGoH-0006XL-00 for ; Mon, 25 Feb 2002 00:48:37 -0800t(UX-Failed-RecipientsUsfsadfsadf@gandalf.merlins.orgt(UFromU0Mail Delivery System t(UToUEtest-bounces+sfsadfsadf=gandalf.merlins.org@gandalf-lists.merlins.orgq t(USubjectU1Mail delivery failed: returning message to sendert(U Message-IdU't(UDateUMon, 25 Feb 2002 00:48:37 -0800teub. Any ideas? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Mon Feb 25 15:09:35 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 10:09:35 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... References: Message-ID: <15482.21423.433540.541277@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> (Or a header that can be set to cause a message not to get >> archived?) CVR> That already exists -- X-No-Archive, which I believe CVR> pipermail understands. Mailman's interface to Pipermail is what does this check, currently defined as: X-No-Archive: yes X-Archive: no prevents the message from being archived in any way. I don't think there are standards for this particular header (else, why would it be an X- header?), so I'm wondering if I understand common practice well enough. I.e. should the presence of X-No-Archive: itself, regardless of value, prevent archiving of the message? -Barry From barry@zope.com Mon Feb 25 15:14:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 10:14:23 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... References: <000101c1ba6a$868027d0$56296c42@damien> <20020220204115.12175@scfn.thpl.lib.fl.us> Message-ID: <15482.21711.605378.886617@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Secondly, if Piper implements this the same way that Google JRA> does, you can put it in as the first line of the body, JRA> starting in column 1, followed by an (additional) blank line, JRA> and it will still take effect. It doesn't, currently. IIRC, only the new topics feature does a body scan for header-like directives. In the face of increasing html and multipart/alternative messages, it's a little tricky to code correctly. We should probably factor that out into a utility. -Barry From barry@zope.com Mon Feb 25 15:25:49 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 10:25:49 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... References: <20020220203652.42377@scfn.thpl.lib.fl.us> <20020220222641.04954@scfn.thpl.lib.fl.us> Message-ID: <15482.22397.497405.243991@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Spaminator. You picked precisely the example I had in mind. JRA> If the masses *demand* solutions, those solutions *will* JRA> happen. I tend to agree that the big ISPs will be forced by their users to put up their own spam prevention solutions. If the Earthlink ads are any indication, such tools will in fact be major marketing positions. I'd actually be surprised if any major ISP wasn't actively spam filtering for their customers. That doesn't help the little guy like me who runs my own domain and tools and spends a 1/2 hour (or more) every morning just deleting spam, even while on vacation. :) And no itch is as persistent and annoying as my own. Having said that, there's still no reason why Mailman can't and shouldn't do better, except perhaps for lack of resources . I'll follow up shortly with some other thoughts in this thread. -Barry From barry@zope.com Mon Feb 25 15:36:55 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 10:36:55 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... References: <20020220161829.34707@scfn.thpl.lib.fl.us> <20020220203652.42377@scfn.thpl.lib.fl.us> Message-ID: <15482.23063.87362.584917@anthem.wooz.org> >>>>> "JWB" == John W Baxter writes: JWB> Once I had the domain, I started registering each product (or JWB> company's products) with a unique local part @scandaroon.com. JWB> Late last year, I had a sudden infusion of Spam addressed to JWB> jwbpalm@scandaroon.com. [Company shall remain nameless ;-)] JWB> Sending mail to that address now produces a 550 response JWB> whose text is "sold down the river by Palm" (Which might be JWB> wrong...they might have leaked it instead...which IMHO is JWB> worse.) Palm is probably following the privacy policy as it JWB> has evolved since I registered the (early production) Palm JWB> IIIx. Neat! I do the same thing with my wooz.org domain. I get no spam on any of those product-derived addresses. -Barry From barry@zope.com Mon Feb 25 16:33:41 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 11:33:41 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... References: <20020222061813.0F54413D89@registry.e-servicesltd.co.nz> Message-ID: <15482.26469.928516.908897@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> I thought about that, but do you really want to send monthly DN> password reminders to people that just wanted to look at the DN> archives? (Or do we not send those to people with "nomail" DN> set?) We send password reminders to folks regardless of their delivery status. This actually makes sense in a VERP world because since password reminders are by nature personalized, we can piggyback the more accurate VERP bounce detection onto them. Note that in MM2.1, people can turn off password reminders altogether. -Barry From jra@baylink.com Mon Feb 25 16:54:00 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Feb 2002 11:54:00 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <15482.21423.433540.541277@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Feb 25, 2002 at 10:09:35AM -0500 References: <15482.21423.433540.541277@anthem.wooz.org> Message-ID: <20020225115400.33258@scfn.thpl.lib.fl.us> On Mon, Feb 25, 2002 at 10:09:35AM -0500, Barry A. Warsaw wrote: > Mailman's interface to Pipermail is what does this check, currently > defined as: > > X-No-Archive: yes > X-Archive: no > > prevents the message from being archived in any way. I don't think > there are standards for this particular header (else, why would it be > an X- header?), so I'm wondering if I understand common practice well > enough. I.e. should the presence of X-No-Archive: itself, regardless > of value, prevent archiving of the message? This depends on which side of the "enabler" argument, discussed ad nauseum last week, you come down on. :-) Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Mon Feb 25 16:56:49 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Feb 2002 11:56:49 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <15482.22397.497405.243991@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Feb 25, 2002 at 10:25:49AM -0500 References: <20020220203652.42377@scfn.thpl.lib.fl.us> <20020220222641.04954@scfn.thpl.lib.fl.us> <15482.22397.497405.243991@anthem.wooz.org> Message-ID: <20020225115649.34985@scfn.thpl.lib.fl.us> On Mon, Feb 25, 2002 at 10:25:49AM -0500, Barry A. Warsaw wrote: > That doesn't help the little guy like me who runs my own domain and > tools and spends a 1/2 hour (or more) every morning just deleting > spam, even while on vacation. :) And no itch is as persistent and > annoying as my own. "I'm here to talk to you about an itch *so* private..." Yeah. :-) That said, my normal daily mail load is almost 300 these days, including 9 mailing lists, and my spamcount is about 15; I deal with them in about 2 minutes; and that's with *no* automated de-spamming, and about 200 posts a week to Usenet in 12 different groups. I guess I'm just lucky. > Having said that, there's still no reason why Mailman can't and > shouldn't do better, except perhaps for lack of resources . > I'll follow up shortly with some other thoughts in this thread. Well, I think the argument was over what constituted 'better', on which topic I think Chuq and I disagree a bit. ;-) Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Mon Feb 25 17:23:59 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 25 Feb 2002 09:23:59 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020225115649.34985@scfn.thpl.lib.fl.us> Message-ID: On 2/25/02 8:56 AM, "Jay R. Ashworth" wrote: > That said, my normal daily mail load is almost 300 these days, > including 9 mailing lists, and my spamcount is about 15; I deal with > them in about 2 minutes; and that's with *no* automated de-spamming, > and about 200 posts a week to Usenet in 12 different groups. > > I guess I'm just lucky. Yes, you are. You don't want to know how much mail I get (but I'm subscribed to every list my sites manage plus most of the -admin addresses to same, but my assistant gets first crack at those now...). I have lists that get 15 spam attacks a day now. I woke up to 27 pieces of spam in my personal mailbox, and that's just one address, and since midnight. I also do almost not automated de-spamming at this point, other than basic sendmail relay checks and the like. I'll probably do more some day (at Apple, we use brightmail on the main mail systems, and I'd like to cloak the list servers on it as well; at home, once I upgrade the server to MacOS X, upgrade the MTA to Postfix and generally replace everything under the hood, I'm looking at spamassassin. But it makes no sense to do the work before the ugprade and move it...) I think you do have a light spam load for someone with a public presence, Jay. Especially on usenet. Do you obfuscate your usenet address? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From barry@zope.com Mon Feb 25 17:27:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 12:27:23 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> Message-ID: <15482.29691.492335.290682@anthem.wooz.org> I /think/ I've caught up on this thread, but I'm sure I've missed a bunch. As I see it there are really these issues to protecting email addresses in Mailman: 1) list admin addresses 2) public archives 3) private archives 4) raw archive 5) list rosters For #1, MM2.1 changes what gets included at the bottom of list pages. The admin's personal address is no longer included in the link's text or in mailto: href. In the mailto: you'll see something like mylist-owner@dom.ain and in the text you'll see something like "barry at zope.com". I see no point in trying to obscure the former -- or put it behind a web form -- because it's easily guessed given a probe of existing lists, as is every other list-related email address. More on protecting the -owner from spam below. I claim that the guessability is a feature, btw. You can argue that "barry at zope.com" isn't obfuscated enough, and you might be right. I'm against any image or JavaScript approach to protecting these because I really do want to keep Mailman's web interface as pedestrian as possible. In principle I don't mind if JavaScript or images are used, but they should never be the only way to navigate a Mailman site. Mailman must degrade gracefully for browsers that either don't support these features or have them disabled. I'd do the same with cookies if I could figure out how to do low-frustration-factor authentication without them. (Aside: I really really hate websites that are only viewable with JavaScript on, and I often send a friendly ADA-ish noodge to webmaster when I find such beasts, although it rarely does any good). MM3 will likely integrate admin addresses and list memberships into an object called a "roster" (essentially just a list of email addresses). This will let us define a pipeline for each roster, which could include a spam filter that performs an action based on some criteria (e.g. drop it, reject it, mark a header, etc.). So we can do more protection on the -owner address than we can do now (without hacking). Rosters and the improved user database will allow us to actually equate admin email addresses with Real Names, so you could conceivably see something like List run by Barry Warsaw at the bottom of the pages. You'd be within your rights to argue that end users never even need know who admins the list, but I think it helps to avoid the "faceless droid" syndrome. Mailman should avoid getting deeply into the spam detection and prevention business, except for some really really basic stuff (probably not much more or less than it does now). It should integrate well with external spam detection programs like SpamAssassin or commercial equivalents. E.g. if we always send the message through SA, and the message gets some score, we could decide to hold messages below say 5.0 on the Spamster Scale, discard anything about 5.0, etc. As for #2, I'd go for the low-tech approach of simply discarding the hostname part of the email address in all public archives. Certainly this is easy in the headers, and we'll have to decide whether we're going to expend the resources to do body searches for email addresses, and obfuscate those as well. If people want to make contacts based on some public archive message, they can email the list. Until we've got web-posting, I don't think it matters if they lose the full email address in the public archives. As for #3, I don't mind not obscuring the email addresses since a login will be required. If we think we don't trust the current private archive login procedures to be secure against bots, then we can fix that, but I don't see it as a high priority. #4 is interesting too. I'm not against putting the raw archive behind a turing-test, since I suspect that very few people will ever want it. It means that we won't be able to write an automated wget-ish script to do off-site backups, but so be it. Things to note for #'s 2-4: - The Pipermail implementation has lots of well-known problems. I'm personally not willing to spend a lot of time fixing them, and I still recommend Real Sites use a Real Archiver. I've just thrown the majority of the email obfuscation problems over the fence into someone else's back yard . - Adding public archive obfuscation is fine and dandy for new messages added to the archives but what about all the existing archived messages? Re-running Pipermail (i.e. bin/arch) to regenerate from scratch has two significant drawbacks. 1) Message url's can change, especially if you also fix broken From_ delimiters, and that in turn breaks bookmarks, 2) on large mboxes, you simply can't do bin/arch because of memory problems. - Someone needs to step up and "own" Pipermail if any of these problems are going to be fixed, or if the obfuscation is going to happen. - Remember that Pipermail itself is completely optional. An API is defined between Mailman and the archiver and that's all the interaction they have. Maybe the API needs to be more elaborate to support obfuscation. It definitely needs some changes if we ever want to add some of the features I'd like to add (but that's off-topic here). - I'll note that one of the early design decisions for Pipermail was that public archives should be vended directly from the file system for performance reasons. That decision may not be appropriate for today's operations. Certainly maintaining two static versions of the pages isn't feasible, so I think you have to vend one or the other (probably the obfuscated version) from a cgi. - Anybody who's really interested in archiving (I'm not) should take a look at Zest and think about contributing to it, so that it does stuff like this correctly from the start. I really like the Zest interface and think it ought to at least be a bundled alternative to Pipermail, some day. Nobody's even mentioned #5, which are available publically via the "Visit Subscriber List" button, or the email command "who" to the -request address. If I were a spam harvester, I wouldn't even bother with scanning the archives if either of these were publically enabled. When you turn them off, especially the former, just remember that you've now made it much harder for Joe User to unsubscribe themselves. Catch 22. -Barry From barry@zope.com Mon Feb 25 17:32:44 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 12:32:44 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... References: <15482.21423.433540.541277@anthem.wooz.org> <20020225115400.33258@scfn.thpl.lib.fl.us> Message-ID: <15482.30012.859431.640358@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> Mailman's interface to Pipermail is what does this check, >> currently defined as: X-No-Archive: yes X-Archive: no prevents >> the message from being archived in any way. I don't think >> there are standards for this particular header (else, why would >> it be an X- header?), so I'm wondering if I understand common >> practice well enough. I.e. should the presence of >> X-No-Archive: itself, regardless of value, prevent archiving of >> the message? JRA> This depends on which side of the "enabler" argument, JRA> discussed ad nauseum last week, you come down on. :-) For this particular issue, I'm happy to make it really easy for folks to make sure their article is not archived, even though I hope most people won't avail themselves of this (it harms public discourse). I can't imagine any other useful value for X-No-Archive: though, so I tend to think the value should be ignored. -Barry From jmeurer@gmx.de Mon Feb 25 17:39:32 2002 From: jmeurer@gmx.de (Jonas Meurer) Date: Mon, 25 Feb 2002 18:39:32 +0100 Subject: [Mailman-Developers] changing question-or-comment-addr Message-ID: <20020225173932.GA5129@jonas.server0.de> Hello, I posted this in mailman-user but there I got no answer so maybe this is a problem for developers ;): How can I change the 'send question or comments to'-Addr on the main- listinfo and admin-page? The domain isn't right. I've set DEFAULT_HOST_NAME, but this mail-addr is still another hostname. Bye Jonas -- "Men are born ignorant, not stupid; they are made stupid by education." -- Bertrand Russell, History of Western Philosophy. From jra@baylink.com Mon Feb 25 18:03:43 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Feb 2002 13:03:43 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: ; from Chuq Von Rospach on Mon, Feb 25, 2002 at 09:23:59AM -0800 References: <20020225115649.34985@scfn.thpl.lib.fl.us> Message-ID: <20020225130343.07017@scfn.thpl.lib.fl.us> On Mon, Feb 25, 2002 at 09:23:59AM -0800, Chuq Von Rospach wrote: > On 2/25/02 8:56 AM, "Jay R. Ashworth" wrote: > > That said, my normal daily mail load is almost 300 these days, > > including 9 mailing lists, and my spamcount is about 15; I deal with > > them in about 2 minutes; and that's with *no* automated de-spamming, > > and about 200 posts a week to Usenet in 12 different groups. > > > > I guess I'm just lucky. > > Yes, you are. You don't want to know how much mail I get (but I'm subscribed > to every list my sites manage plus most of the -admin addresses to same, but > my assistant gets first crack at those now...). I have lists that get 15 > spam attacks a day now. I woke up to 27 pieces of spam in my personal > mailbox, and that's just one address, and since midnight. Eek. > I think you do have a light spam load for someone with a public presence, > Jay. Especially on usenet. Do you obfuscate your usenet address? Nope. Same address for 5 years, too. And I'm a lightning rod on Usenet, just as much as I am here. ;-) It's all over my weblog, too; not obfucsated there, either. And my pain level *still* hasn't climbed high enough to merit automated methods (read: higher than the pain level of learning procmail. ;-) Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Mon Feb 25 18:05:11 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Feb 2002 13:05:11 -0500 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <15482.30012.859431.640358@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Feb 25, 2002 at 12:32:44PM -0500 References: <15482.21423.433540.541277@anthem.wooz.org> <20020225115400.33258@scfn.thpl.lib.fl.us> <15482.30012.859431.640358@anthem.wooz.org> Message-ID: <20020225130511.45631@scfn.thpl.lib.fl.us> On Mon, Feb 25, 2002 at 12:32:44PM -0500, Barry A. Warsaw wrote: > >> practice well enough. I.e. should the presence of > >> X-No-Archive: itself, regardless of value, prevent archiving of > >> the message? > > JRA> This depends on which side of the "enabler" argument, > JRA> discussed ad nauseum last week, you come down on. :-) > > For this particular issue, I'm happy to make it really easy for folks > to make sure their article is not archived, even though I hope most > people won't avail themselves of this (it harms public discourse). I > can't imagine any other useful value for X-No-Archive: though, so I > tend to think the value should be ignored. And worse, when people *quote* you, it doesn't track; I tend to think it's worse than useless (in the false sense of security sense) myself, but in for a penny, in for a pound, I guess... yeah, I'd ignore the argument. Cheers, -- jra -- Jay R. Ashworth jra@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") From marc_news@vasoftware.com Mon Feb 25 18:12:49 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 25 Feb 2002 10:12:49 -0800 Subject: [Mailman-Developers] Problems with Cookie.py while upgrading In-Reply-To: <15475.10891.928404.666632@geddy.wooz.org> References: <20020211211746.GO4569@ohnesorg.cz> <15475.10891.928404.666632@geddy.wooz.org> Message-ID: <20020225181248.GB11009@merlins.org> On Tue, Feb 19, 2002 at 11:48:11PM -0500, Barry A. Warsaw wrote: > DO> And the problem is, that update script will try to remove the > DO> unused Cookie.py, but it will first import it (indirectly) so > DO> the whole update scrtipt fails to execute and has no > DO> possibility to delete the unused file. > > DO> I hope, you will know what I mean. > > I do indeed, and I believe this problem is fixed in CVS. Do you know > which version your tester was using? (I don't remember if it was > fixed in alpha4). I'm fairly sure it was fixed in alpha4, and it is definitely fixed in CVS (this problem didn't appear when I upgraded another mm site of mine recently (from 2.0 to cvs that is)) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jra@baylink.com Mon Feb 25 18:14:56 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Feb 2002 13:14:56 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15482.29691.492335.290682@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Feb 25, 2002 at 12:27:23PM -0500 References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> Message-ID: <20020225131456.63400@scfn.thpl.lib.fl.us> On Mon, Feb 25, 2002 at 12:27:23PM -0500, Barry A. Warsaw wrote: > I /think/ I've caught up on this thread, but I'm sure I've missed a > bunch. As I see it there are really these issues to protecting email > addresses in Mailman: > > 1) list admin addresses > 2) public archives > 3) private archives > 4) raw archive > 5) list rosters I believe you've synopsized it correctly, yes. > For #1, MM2.1 changes what gets included at the bottom of list pages. > The admin's personal address is no longer included in the link's text > or in mailto: href. In the mailto: you'll see something like > mylist-owner@dom.ain and in the text you'll see something like "barry > at zope.com". I see no point in trying to obscure the former -- or > put it behind a web form -- because it's easily guessed given a probe > of existing lists, as is every other list-related email address. More > on protecting the -owner from spam below. I claim that the > guessability is a feature, btw. Concur. > You can argue that "barry at zope.com" isn't obfuscated enough, and > you might be right. I'm against any image or JavaScript approach to > protecting these because I really do want to keep Mailman's web > interface as pedestrian as possible. In principle I don't mind if > JavaScript or images are used, but they should never be the only way > to navigate a Mailman site. Mailman must degrade gracefully for > browsers that either don't support these features or have them > disabled. I'd do the same with cookies if I could figure out how to > do low-frustration-factor authentication without them. And, of course, if it *will* degrade, then address-snarfers will figure out how to *make* it degrade, so it's not worth doing in the first place, at least not for *that* reason. > (Aside: I really really hate websites that are only viewable with > JavaScript on, and I often send a friendly ADA-ish noodge to webmaster > when I find such beasts, although it rarely does any good). Hear hear! > MM3 will likely integrate admin addresses and list memberships into an > object called a "roster" (essentially just a list of email addresses). > This will let us define a pipeline for each roster, which could > include a spam filter that performs an action based on some criteria > (e.g. drop it, reject it, mark a header, etc.). So we can do more > protection on the -owner address than we can do now (without > hacking). I do see one problem here, and I don't know if you already address it below. [ looks ] You don't; it's this: if the list-owner addresses go through the MM machinery, as well, then they too can die if MM crashes the wrong way. This implies, as I believe has already been discussed, that the *server* admin address must be publicly accessible, not be piped into MailMan at all, and preferably, should actually not even be handled by the same machine... ("Single point of failure") > Rosters and the improved user database will allow us to > actually equate admin email addresses with Real Names, so you could > conceivably see something like > > List run by Barry Warsaw > > at the bottom of the pages. You'd be within your rights to argue that > end users never even need know who admins the list, but I think it > helps to avoid the "faceless droid" syndrome. Concur *strongly*. > Mailman should avoid getting deeply into the spam detection and > prevention business, except for some really really basic stuff > (probably not much more or less than it does now). It should > integrate well with external spam detection programs like SpamAssassin > or commercial equivalents. E.g. if we always send the message through > SA, and the message gets some score, we could decide to hold messages > below say 5.0 on the Spamster Scale, discard anything about 5.0, etc. That sounds good, and if there isn't already a "plugin" API for that, we ought to give some thought to that... > As for #2, I'd go for the low-tech approach of simply discarding the > hostname part of the email address in all public archives. Certainly > this is easy in the headers, and we'll have to decide whether we're > going to expend the resources to do body searches for email addresses, > and obfuscate those as well. If people want to make contacts based on > some public archive message, they can email the list. Until we've got > web-posting, I don't think it matters if they lose the full email > address in the public archives. Well, personally, I don't ever assume that someone who posted a message a year ago with 95% of the answer to my question is even *on* the list anymore -- a situation I don't think you thought of -- but... > As for #3, I don't mind not obscuring the email addresses since a > login will be required. If we think we don't trust the current > private archive login procedures to be secure against bots, then we > can fix that, but I don't see it as a high priority. Concur. > #4 is interesting too. I'm not against putting the raw archive behind > a turing-test, since I suspect that very few people will ever want > it. It means that we won't be able to write an automated wget-ish > script to do off-site backups, but so be it. Is there a difference between raw and private that I'm missing? Do you mean the mbox format files? > Things to note for #'s 2-4: > > - The Pipermail implementation has lots of well-known problems. I'm > personally not willing to spend a lot of time fixing them, and I > still recommend Real Sites use a Real Archiver. I've just thrown > the majority of the email obfuscation problems over the fence into > someone else's back yard . :-) > - Adding public archive obfuscation is fine and dandy for new messages > added to the archives but what about all the existing archived > messages? Re-running Pipermail (i.e. bin/arch) to regenerate from > scratch has two significant drawbacks. 1) Message url's can change, > especially if you also fix broken From_ delimiters, and that in turn > breaks bookmarks, 2) on large mboxes, you simply can't do bin/arch > because of memory problems. See above. :-) > - Someone needs to step up and "own" Pipermail if any of these > problems are going to be fixed, or if the obfuscation is going to > happen. Not much danger of that, is there? > - Remember that Pipermail itself is completely optional. An API is > defined between Mailman and the archiver and that's all the > interaction they have. Maybe the API needs to be more elaborate to > support obfuscation. It definitely needs some changes if we ever > want to add some of the features I'd like to add (but that's > off-topic here). Well, that's probably the best point yet: this isn't *MailMan's* problem, except to the extent that we "recommend" Piper as out archiver. > - I'll note that one of the early design decisions for Pipermail was > that public archives should be vended directly from the file system > for performance reasons. That decision may not be appropriate for > today's operations. Certainly maintaining two static versions of > the pages isn't feasible, so I think you have to vend one or the > other (probably the obfuscated version) from a cgi. No, but the performance reasons aren't as much of an issue now... > Nobody's even mentioned #5, which are available publically via the > "Visit Subscriber List" button, or the email command "who" to the > -request address. If I were a spam harvester, I wouldn't even bother > with scanning the archives if either of these were publically > enabled. When you turn them off, especially the former, just remember > that you've now made it much harder for Joe User to unsubscribe > themselves. Catch 22. Not enough experience in the field, or I'd probably have mentioned that already. Cheers, -- jra -- Jay R. Ashworth jra@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") From barry@zope.com Mon Feb 25 18:15:09 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 13:15:09 -0500 Subject: [Mailman-Developers] Problems with Cookie.py while upgrading References: <20020211211746.GO4569@ohnesorg.cz> <15475.10891.928404.666632@geddy.wooz.org> <20020225181248.GB11009@merlins.org> Message-ID: <15482.32557.579923.40312@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I'm fairly sure it was fixed in alpha4, and it is definitely MM> fixed in CVS (this problem didn't appear when I upgraded MM> another mm site of mine recently (from 2.0 to cvs that is)) Cool. -Barry From jarrell@vt.edu Mon Feb 25 18:23:40 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 25 Feb 2002 13:23:40 -0500 (EST) Subject: [Mailman-Developers] More building the snapshot.... Message-ID: <200202251823.g1PINe920393@babylon5.cc.vt.edu> Mailman/pythonlib/Makefile needs to get registered, so the cvs will realize it can delete it, and the pythonlib tree.. From chuqui@plaidworks.com Mon Feb 25 18:26:21 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 25 Feb 2002 10:26:21 -0800 Subject: [Mailman-Developers] Interesting study -- spam on postedaddresses... In-Reply-To: <20020225130343.07017@scfn.thpl.lib.fl.us> Message-ID: On 2/25/02 10:03 AM, "Jay R. Ashworth" wrote: >> spam attacks a day now. I woke up to 27 pieces of spam in my personal >> mailbox, and that's just one address, and since midnight. > > Eek. Yeah, but that's still a small percentage compared to legitimate mail. > It's all over my weblog, too; not obfucsated there, either. I don't obfuscate either. I decided long ago not to let the spammers get to my head. I'm just not that sensitive to it. I realize, though, that others feel differently -- I just don't see that the amount of time some folks put into dealing with spam is worth the investment. Part of the reason I get so much spam is that "chuqui" (I own chuqui.com) is the nickname of the largest open pit copper mine in the world, down in chile. So I get a lot of spanish language spam misdirected at that place... I'm of the opinion "when you start spending more time fighting spam than you do simply deleting it, the spammers are winning". Spam doesn't cost me money (please, let's not get into the bandwidth-wars -- I'm on a fixed-price network with spare capacity), it costs me time. And time, in my life, is my most precious commodity. I've also found you don't stop spam, you maybe slow it down for a while, so it's a war of attrition. I decided a while back it was less hassle to just blow through it, since most spam you can delete just from the subject line. But if you'll note, that's not the policy I propose for Mailman. I feel my approach works for me -- but is too laissez-faire for Mailman. A public tool like that needs to be more protective, even if I personally feel I can do with less. Barry's overview this morning of what he's doing seems fine to me. I might quibble with some details, but I think it's reasonable. I especially agree with him about list admins needing some public face, not an anonymous voice from behind the curtain. That's explicitly why I admin from my address, not a generic postmaster box. And even though I now have a 2nd helping out and we use a shared mailbox, I still respond as me, not as A Generic Apple Postmaster. Frankly, sometimes it causes problems, because some folks see you as a target. But I find humanizing it generally solves more problems than it causes. It's a lot easier to throw pitchforks at the abuse@ address, since you don't know who that is... > And my pain level *still* hasn't climbed high enough to merit automated > methods (read: higher than the pain level of learning procmail. ;-) Oh, heck. Procmail is the hard part, IMHO. What a bizarre, bogus syntax. I really, really like Barry's idea of an API for integrating into things like SpamAssassin and auto-adminning based on the returned score. That's the sort of thinking we ought to be looking at. Not implementing it all ourselves, but finding ways to take advantage of what others are doing as well. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! From barry@zope.com Mon Feb 25 19:45:45 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 14:45:45 -0500 Subject: [Mailman-Developers] New uber exim transports/directors References: <20020225083638.GF12739@merlins.org> Message-ID: <15482.37993.61816.296989@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> I've modified Nigel's exim transports (hopefully in good). MM> Please review and tell me if this is fit for a patch to Barry: MM> (I'll also submit an exim 4 version if those are good) MM> The director now deals with VERP bounces and with lists that MM> have -command in their name (like mailman-owner, which gets a MM> mailman-owner-owner alias) The transport was improved to deal MM> with local_part_suffix containing a VERP suffix Thanks Marc! We're in the process of upgrading the server on python.org and I'll give these new configs a shot when we're done with that. -Barry From jarrell@vt.edu Mon Feb 25 20:18:01 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 25 Feb 2002 15:18:01 -0500 (EST) Subject: [Mailman-Developers] more snapshot woes... Message-ID: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> I love playing catchup after a long hiatus :-)... Seems like somethings out of sync here... While doing the make install, update appears to blow chunks, because of PortableUnixMailbox.. Compiling /home/mailman/Mailman/aliases.py ... Compiling /home/mailman/Mailman/htmlformat.py ... Compiling /home/mailman/Mailman/i18n.py ... Listing /home/mailman/Mailman/pythonlib ... Compiling /home/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 49, in ? from Mailman.Archiver import Archiver File "/home/mailman/Mailman/Archiver/__init__.py", line 17, in ? from Archiver import * File "/home/mailman/Mailman/Archiver/Archiver.py", line 32, in ? from Mailman import Mailbox File "/home/mailman/Mailman/Mailbox.py", line 40, in ? class Mailbox(mailbox.PortableUnixMailbox): AttributeError: PortableUnixMailbox *** Error code 1 make: Fatal error: Command failed for target `update' 55.0u 111.0s 3:17 84% 0+0k 0+0io 0pf+0w From barry@zope.com Mon Feb 25 20:25:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 25 Feb 2002 15:25:05 -0500 Subject: [Mailman-Developers] more snapshot woes... References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> Message-ID: <15482.40353.473446.30798@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> I love playing catchup after a long hiatus :-)... Fun, ain't it? :) RJ> Seems like somethings out of sync here... While doing the make RJ> install, update appears to blow chunks, because of RJ> PortableUnixMailbox.. Shite. Be sure you're using at least Python 2.1. I think this will be a requirement. Py2.0 is getting pretty long in the teeth (yes, yet another reason to get MM2.1 out the freakin' door asap!). -Barry From jarrell@vt.edu Mon Feb 25 20:46:31 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 25 Feb 2002 15:46:31 -0500 Subject: [Mailman-Developers] more snapshot woes... In-Reply-To: <15482.40353.473446.30798@anthem.wooz.org> References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020225154018.08017ec0@lennier.cc.vt.edu> At 03:25 PM 2/25/02 -0500, you wrote: >>>>>> "RJ" == Ron Jarrell writes: > > RJ> I love playing catchup after a long hiatus :-)... > >Fun, ain't it? :) > > RJ> Seems like somethings out of sync here... While doing the make > RJ> install, update appears to blow chunks, because of > RJ> PortableUnixMailbox.. > >Shite. Be sure you're using at least Python 2.1. I think this will >be a requirement. Py2.0 is getting pretty long in the teeth (yes, yet >another reason to get MM2.1 out the freakin' door asap!). Ahhh. Yet another python upgrade just for mailman :-). Yup, still running 2.0... Ok, time to shelve mailman for a bit while we go hunt down python 2.1, and remember all the things we had to beat on to make it work the first time (since python has *never* compiled the way I want it the first time, not being on a linux box... Sigh.) Will 2.0* run fine on python 2.1? I'll probably upgrade my production machines python sooner, rather than later, if I'm going to need to be doing it. BTW, install or update probably should note that the user has a installed Mailman/pythonlib and delete the apps, before that bites someone on the ass. Or at least make a note in the upgrade instructions to go do it yourself. From jarrell@vt.edu Mon Feb 25 20:53:12 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 25 Feb 2002 15:53:12 -0500 Subject: [Mailman-Developers] more snapshot woes... In-Reply-To: <15482.40353.473446.30798@anthem.wooz.org> References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020225155232.07b8eea0@lennier.cc.vt.edu> At 03:25 PM 2/25/02 -0500, Barry A. Warsaw wrote: >Shite. Be sure you're using at least Python 2.1. I think this will >be a requirement. Py2.0 is getting pretty long in the teeth (yes, yet >another reason to get MM2.1 out the freakin' door asap!). Actually, come to think of it, will mm 2.1* work ok on python 2.2? Since it's out, I might just as well go straight there! From marc_news@vasoftware.com Mon Feb 25 22:19:28 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 25 Feb 2002 14:19:28 -0800 Subject: [Mailman-Developers] Can't get VERP to do much In-Reply-To: <200202251926.g1PJQXcW021335@utopia.West.Sun.COM> References: <200202251926.g1PJQXcW021335@utopia.West.Sun.COM> Message-ID: <20020225221927.GA4035@merlins.org> On Mon, Feb 25, 2002 at 11:25:45AM -0800, Dan Mick wrote: > 'cat' on the .pck isn't extremely useful; how about bin/dumpdb? Sorry, I thought cat was enough. Dumpdb doesn't seem to show anything else: root@gandalf:/var/local/mailman/bin# ./dumpdb ../qfiles/shunt/1014626917.416239+a9cf2c2ba9612bab36ead00ff58da9e5a9d40a06.pck >From MAILER-DAEMON Mon Feb 25 00:48:37 2002 Received: from mail by gandalf.merlins.org with local (Exim 3.31-VA-mm2 #1 (Debian)) id 16fGoH-0006XL-00 for ; Mon, 25 Feb 2002 00:48:37 -0800 X-Failed-Recipients: sfsadfsadf@gandalf.merlins.org From: Mail Delivery System To: test-bounces+sfsadfsadf=gandalf.merlins.org@gandalf-lists.merlins.org Subject: Mail delivery failed: returning message to sender Message-Id: Date: Mon, 25 Feb 2002 00:48:37 -0800 This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: sfsadfsadf@gandalf.merlins.org unknown local-part "sfsadfsadf" in domain "gandalf.merlins.org" ------ This is a copy of the message, including all the headers. ------ Return-path: Received: from localhost ([127.0.0.1] helo=gandalf.merlins.org ident=mailman) by gandalf.merlins.org with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 16fGoD-0006X6-00 for ; Mon, 25 Feb 2002 00:48:33 -0800 Received: from root by gandalf.merlins.org with local (Exim 3.31-VA-mm2 #1 (Debian)) id 16fGoC-0006Wy-00 for ; Mon, 25 Feb 2002 00:48:32 -0800 To: test@gandalf.merlins.org Message-Id: From: root Date: Mon, 25 Feb 2002 00:48:32 -0800 Subject: [Test] test 2 X-BeenThere: test@gandalf-lists.merlins.org X-Mailman-Version: 2.1a4+ Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://gandalf.merlins.org/lists/private/test/ test _______________________________________________ Test mailing list Test@gandalf-lists.merlins.org http://gandalf.merlins.org/lists/listinfo/test -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From Dan Mick Mon Feb 25 22:25:14 2002 From: Dan Mick (Dan Mick) Date: Mon, 25 Feb 2002 14:25:14 -0800 (PST) Subject: [Mailman-Developers] Can't get VERP to do much Message-ID: <200202252226.g1PMQ2cW001767@utopia.West.Sun.COM> > File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 112, in __verpbounce > if bmailbox <> mo.group('bounces'): > IndexError: no such group Are you sure Defaults.py is up-to-date? Specifically, VERP_FORMAT and VERP_REGEXP? From jarrell@vt.edu Mon Feb 25 22:29:38 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 25 Feb 2002 17:29:38 -0500 Subject: [Mailman-Developers] more snapshot woes... In-Reply-To: <15482.40353.473446.30798@anthem.wooz.org> References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> At 03:25 PM 2/25/02 -0500, you wrote: >Shite. Be sure you're using at least Python 2.1. I think this will >be a requirement. Py2.0 is getting pretty long in the teeth (yes, yet I hate installing python. All those 80 gazillion modules, each of which thinks it knows more about your system than you do, and wants to taunt you with it. I remembered that my big problems in the past have been the fact that I'm a Berkeley 3.N shop (soon to be 4.N) and pythin is still thinking 1.85... So I remembered to with the --without-libdb and compiled cleanly the first try. Now I discover that 2.2 is pissed at my libz, which I haven't changed since I started compiling python 1.whatever, and works fine with 2.0. Did I mention I hate installing python? From jmeurer@gmx.de Mon Feb 25 22:33:29 2002 From: jmeurer@gmx.de (Jonas Meurer) Date: Mon, 25 Feb 2002 23:33:29 +0100 Subject: [Mailman-Developers] following standards in signature-syntax Message-ID: <20020225223329.GA14246@jonas.server0.de> Hello, Wouldn't it be sencefull to follow the standards in signature-style and change the "___________....." line to "-- " like a signature has to be cuted as in standards declared? Bye Jonas --=20 Du willst einen Windows-PC als Gateway f=FCr ein NetBSD-System benutzen? Benutzt du auch N=E4gel, um einen Hammer in die Wand zu schlagen? -- Phillipp Schulte in doc From cheesefactory@yahoo.com Mon Feb 25 22:40:31 2002 From: cheesefactory@yahoo.com (Paul Schreiber) Date: Mon, 25 Feb 2002 14:40:31 -0800 (PST) Subject: [Mailman-Developers] error in Catchall.py Message-ID: <20020225224031.26385.qmail@web14806.mail.yahoo.com> Apologies if this is the wrong forum to post this; redirection appreciated. Here's the tail of my error log: Feb 25 17:24:02 2002 qrunner(29152): Traceback (most recent call last): Feb 25 17:24:02 2002 qrunner(29152): File "/home/mailman/cron/qrunner", line 282, in ? Feb 25 17:24:02 2002 qrunner(29152): kids = main(lock) Feb 25 17:24:02 2002 qrunner(29152): File "/home/mailman/cron/qrunner", line 252, in main Feb 25 17:24:02 2002 qrunner(29152): keepqueued = dispose_message(mlist, msg, msgdata) Feb 25 17:24:02 2002 qrunner(29152): File "/home/mailman/cron/qrunner", line 121, in dispose_message Feb 25 17:24:02 2002 qrunner(29152): if BouncerAPI.ScanMessages(mlist, mimemsg): Feb 25 17:24:02 2002 qrunner(29152): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 59, in ScanMessages Feb 25 17:24:02 2002 qrunner(29152): addrs = func(msg) Feb 25 17:24:02 2002 qrunner(29152): File "/home/mailman/Mailman/Bouncers/Catchall.py", line 102, in process Feb 25 17:24:02 2002 qrunner(29152): simple_bounce_pats = ( Feb 25 17:24:02 2002 qrunner(29152): AttributeError : 'module' object has no attribute 'compile' I'm running python 2.2, mailman 2.0.8. (i was running python 1.5.2 prior to today, but i was running into problems with qrunner and locks -- see my post to mailman-users.) what's going on here and how do i fix it? thanks. Paul __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From jra@baylink.com Mon Feb 25 22:41:46 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 25 Feb 2002 17:41:46 -0500 Subject: [Mailman-Developers] following standards in signature-syntax In-Reply-To: <20020225223329.GA14246@jonas.server0.de>; from Jonas Meurer on Mon, Feb 25, 2002 at 11:33:29PM +0100 References: <20020225223329.GA14246@jonas.server0.de> Message-ID: <20020225174146.29154@scfn.thpl.lib.fl.us> On Mon, Feb 25, 2002 at 11:33:29PM +0100, Jonas Meurer wrote: > Hello, >=20 > Wouldn't it be sencefull to follow the standards in signature-style and > change the "___________....." line to "-- " like a signature has to be > cuted as in standards declared? >=20 > Bye > Jonas >=20 > --=20 > Du willst einen Windows-PC als Gateway f=FCr ein NetBSD-System > benutzen? Benutzt du auch N=E4gel, um einen Hammer in die Wand zu > schlagen? -- Phillipp Schulte in doc >=20 > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers No, and I've quoted your posting to illustrate why: It's *part of* your signature, which already has sigdashes. Now, there's the "but what about people who don't *have* signatures" argument... but go back and read all the 'enabler' arguments from last week. ;-) Cheers, -- jra --=20 Jay R. Ashworth jra@baylin= k.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") From jarrell@vt.edu Mon Feb 25 22:48:30 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 25 Feb 2002 17:48:30 -0500 (EST) Subject: [Mailman-Developers] gate_news still broken in 2.1b.. Message-ID: <200202252248.g1PMmUh18292@babylon5.cc.vt.edu> Ok, mailman installs now, and large chunks of it are working, sans, apparently, any support for gzipping anymore since I got three pages of errors trying to link zlib. However, gate_news is still doing what I reported a month or two ago... If I email a messages to my gated test list, I get this i the errors file: Feb 25 17:44:21 2002 (17842) (NNTPDirect) NNTP error for list "rontest": 441 437 No colon-space in "From jarrell@lennier.cc.vt.edu Mon Feb 25 17:44:00 2002 " header For some reason gate_news is passing the unix mailbox "From " header to the news server, who, understandably, doesn't like it. From jason-list-mailman-developers@mastaler.com Mon Feb 25 23:24:40 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Mon, 25 Feb 2002 16:24:40 -0700 Subject: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: <15475.6381.891758.575462@geddy.wooz.org> (barry@zope.com's message of "Tue, 19 Feb 2002 22:33:01 -0500") References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > - searching This is the biggie IMHO. Interface differences matter little to me, but I find an unsearchable mailing list archive practically worthless. -- (http://tmda.sourceforge.net/) From jason-list-mailman-developers@mastaler.com Mon Feb 25 23:26:56 2002 From: jason-list-mailman-developers@mastaler.com (Jason R. Mastaler) Date: Mon, 25 Feb 2002 16:26:56 -0700 Subject: [Mailman-Developers] mylist-subscribe / mylist-unsubscribe In-Reply-To: <15475.1623.674782.645165@geddy.wooz.org> (barry@zope.com's message of "Tue, 19 Feb 2002 21:13:43 -0500") References: <15475.1623.674782.645165@geddy.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > No (good) reason, really. I've added these two as aliases for -join > and -leave respectively. Awesome, thanks. -- (http://tmda.sourceforge.net/) From marc_news@vasoftware.com Tue Feb 26 00:08:00 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Mon, 25 Feb 2002 16:08:00 -0800 Subject: [Mailman-Developers] Can't get VERP to do much In-Reply-To: <200202252226.g1PMQ2cW001767@utopia.West.Sun.COM> References: <200202252226.g1PMQ2cW001767@utopia.West.Sun.COM> Message-ID: <20020226000759.GB4035@merlins.org> On Mon, Feb 25, 2002 at 02:25:14PM -0800, Dan Mick wrote: > > > File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 112, in > __verpbounce > > if bmailbox <> mo.group('bounces'): > > IndexError: no such group > > Are you sure Defaults.py is up-to-date? Specifically, > VERP_FORMAT and VERP_REGEXP? root@gandalf:/var/local/mailman/Mailman# grep VERP_ mm_cfg.py VERP_FORMAT = '%(bounces)s+%(mailbox)s=%(host)s' VERP_REGEXP = r'^[^+]+?\+(?P[^=]+)=(?P[^@]+)@.*$' VERP_PASSWORD_REMINDERS = 1 VERP_PERSONALIZED_DELIVERIES = 1 VERP_DELIVERY_INTERVAL = 1 I left the defaults Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From cheesefactory@yahoo.com Tue Feb 26 00:18:47 2002 From: cheesefactory@yahoo.com (Paul Schreiber) Date: Mon, 25 Feb 2002 16:18:47 -0800 (PST) Subject: [Mailman-Developers] mylist-subscribe / mylist-unsubscribe In-Reply-To: Message-ID: <20020226001847.37771.qmail@web14810.mail.yahoo.com> --- "Jason R. Mastaler" wrote: > barry@zope.com (Barry A. Warsaw) writes: > > > No (good) reason, really. I've added these two as aliases for -join > > and -leave respectively. > > Awesome, thanks. Apologies if this has already been noted ... are -on and -off set up as aliases as well? I forgot who does this -- ListSTAR or LetterRip -- whatever TidBITS uses. Paul __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From stephen@xemacs.org Tue Feb 26 02:38:34 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 26 Feb 2002 11:38:34 +0900 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15482.29691.492335.290682@anthem.wooz.org> References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> Message-ID: <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "BAW" == Barry A Warsaw writes: BAW> I /think/ I've caught up on this thread, Like JRA I think your synopsis is accurate, with respect to the issues that can be addressed by code. BAW> I claim that the guessability [of list-related addresses] is BAW> a feature, btw. Yes. BAW> I'd do the same with cookies if I could figure out how to do BAW> low-frustration-factor authentication without them. Don't even think such things. You're just tempting the Lords of Chaos. Ie, in this case, if you can't support HTTP well enough to handle cookies, you aren't going to support anything powerful enough for any kind of authentication very well either. It's just not the same as supporting multimedia. BAW> 5) list rosters I don't know of any lists where these are available to the members, let alone the public. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From chuqui@plaidworks.com Tue Feb 26 02:47:43 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 25 Feb 2002 18:47:43 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: On 2/25/02 6:38 PM, "Stephen J. Turnbull" wrote: > BAW> 5) list rosters >=20 > I don't know of any lists where these are available to the members, > let alone the public. You know, now that I think about it. Wihle I think Mailman now has this turned off by default (does it? If not, it should...), perhaps it's time to just make the option dead and buried, so that na=EFve list admins don't have the ability to open it up any more... --=20 Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From jwm@plain.co.nz Tue Feb 26 03:01:47 2002 From: jwm@plain.co.nz (John Morton) Date: Tue, 26 Feb 2002 16:01:47 +1300 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: References: Message-ID: <20020226030148.79D0313DB6@registry.e-servicesltd.co.nz> On Tuesday 26 February 2002 15:47, Chuq Von Rospach wrote: > On 2/25/02 6:38 PM, "Stephen J. Turnbull" wrote: > > BAW> 5) list rosters > > > > I don't know of any lists where these are available to the members, > > let alone the public. > > You know, now that I think about it. Wihle I think Mailman now has this > turned off by default (does it? If not, it should...), perhaps it's time to > just make the option dead and buried, so that naďż˝e list admins don't have > the ability to open it up any more... I find this feature is handy for small, private lists. I'd rather it was still around and just disabled by default with warning stickers all over it than we dumb down mailman to Fisher Price levels just in case some twit exposes people to a greater likelihood of receiving junk mail. Perhaps it can be made to be disabled in a site-wide fashion? John From stephen@xemacs.org Tue Feb 26 03:52:09 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 26 Feb 2002 12:52:09 +0900 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <20020226030148.79D0313DB6@registry.e-servicesltd.co.nz> References: <20020226030148.79D0313DB6@registry.e-servicesltd.co.nz> Message-ID: <87r8n8vr12.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "John" == John Morton writes: John> I find this feature is handy for small, private lists. Sure. I have a couple that could be handled that way, but we just defaulted them all off. We post the names and addresses (they're basically lists of project staff) on the home page, with mailtos and fancy formatting, instead. When the staff forget who handles what, they use that interface, just like the clients do. (It's voluntary, they are warned about harvesting; nobody has refused yet.) John> I'd rather it was still around and just disabled by default John> with warning stickers all over it than we dumb down mailman To me, it's not really an issue of dumbing down. It would be easy enough to do this with a separate app, so the question is "should a deprecated feature continue to encruft MM?" -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From dan@ssc.com Tue Feb 26 05:30:19 2002 From: dan@ssc.com (Dan Wilder) Date: Mon, 25 Feb 2002 21:30:19 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: References: <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <20020225213019.A9716@ssc.com> On Mon, Feb 25, 2002 at 06:47:43PM -0800, Chuq Von Rospach wrote: > On 2/25/02 6:38 PM, "Stephen J. Turnbull" wrote: > > > BAW> 5) list rosters > > > > I don't know of any lists where these are available to the members, > > let alone the public. Waaaal, there's http://crackmonkey.org/mailman/roster/crackmonkey -- ----------------------------------------------------------------- Dan Wilder Technical Manager & Editor SSC, Inc. P.O. Box 55549 Phone: 206-782-8808 Seattle, WA 98155-0549 URL http://embedded.linuxjournal.com/ ----------------------------------------------------------------- From barry@zope.com Tue Feb 26 05:56:45 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 00:56:45 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <20020225131456.63400@scfn.thpl.lib.fl.us> Message-ID: <15483.9117.172305.565827@anthem.wooz.org> > You can argue that "barry at zope.com" isn't obfuscated enough, and > you might be right. I'm against any image or JavaScript approach to > protecting these because I really do want to keep Mailman's web > interface as pedestrian as possible. In principle I don't mind if > JavaScript or images are used, but they should never be the only way > to navigate a Mailman site. Mailman must degrade gracefully for > browsers that either don't support these features or have them > disabled. I'd do the same with cookies if I could figure out how to > do low-frustration-factor authentication without them. >>>>> "JRA" == Jay R Ashworth writes: JRA> And, of course, if it *will* degrade, then address-snarfers JRA> will figure out how to *make* it degrade, so it's not worth JRA> doing in the first place, at least not for *that* reason. Agreed. > MM3 will likely integrate admin addresses and list memberships into an > object called a "roster" (essentially just a list of email addresses). > This will let us define a pipeline for each roster, which could > include a spam filter that performs an action based on some criteria > (e.g. drop it, reject it, mark a header, etc.). So we can do more > protection on the -owner address than we can do now (without > hacking). JRA> I do see one problem here, and I don't know if you already JRA> address it below. [ looks ] You don't; it's this: if the JRA> list-owner addresses go through the MM machinery, as well, JRA> then they too can die if MM crashes the wrong way. JRA> This implies, as I believe has already been discussed, that JRA> the *server* admin address must be publicly accessible, not JRA> be piped into MailMan at all, and preferably, should actually JRA> not even be handled by the same machine... ("Single point of JRA> failure") Well, what machine it's handled by isn't Mailman's business, but you do have a point. Until recently, I recommended that you install aliases `mailman' and `mailman-owner', but now I recommend that `mailman' be an actual list, and it is from this list that things like password reminders look to come from. Also, if the site list gets a bounce, it'll check all the existing lists for a match against the bouncing address. You make the valid point that if the Mailman system were to break, you'd have no way to contact the site administrator, save for typical aliases like postmaster. It seems like you want: - A non-list, plain alias to contact the human in case of emergency - Some place that password reminders come from. Since this will be receiving bounces, it ought to be a real list. - A site-wide list of maintainers of the site who can take care of normal operations (i.e. panicky unsubscription requests). Perhaps #3 can be the same as #1 for those sites that have a collaborative management arrangement. So the question is, what do we call the alias and what do we call the list? I have definitely seen people try to send mail commands to `mailman@python.org' and from my Majordomo days, this seems like a reasonable thing to (eventually) implement. Is it sufficient to recommend that postmaster@ point to a real human, not a list, and leave mailman@dom.ain a normal list? If not, i'd still opt for `mailman' to be the site list, and add something like mailman-panic to be a human address. Or perhaps make mailman-owner pipe both to the wrapper and to postmaster. I dunno, I'm open to suggestions. > Mailman should avoid getting deeply into the spam detection and > prevention business, except for some really really basic stuff > (probably not much more or less than it does now). It should > integrate well with external spam detection programs like SpamAssassin > or commercial equivalents. E.g. if we always send the message through > SA, and the message gets some score, we could decide to hold messages > below say 5.0 on the Spamster Scale, discard anything about 5.0, etc. JRA> That sounds good, and if there isn't already a "plugin" API JRA> for that, we ought to give some thought to that... Agreed. I just have no idea what a reasonable API would be, although we're planning on doing some experiments with SA on {python,zope}.org to see what might make sense. > #4 is interesting too. I'm not against putting the raw archive behind > a turing-test, since I suspect that very few people will ever want > it. It means that we won't be able to write an automated wget-ish > script to do off-site backups, but so be it. JRA> Is there a difference between raw and private that I'm JRA> missing? Do you mean the mbox format files? Yup. raw == mbox. > - Someone needs to step up and "own" Pipermail if any of these > problems are going to be fixed, or if the obfuscation is going to > happen. JRA> Not much danger of that, is there? Not so far. :( > - Remember that Pipermail itself is completely optional. An API is > defined between Mailman and the archiver and that's all the > interaction they have. Maybe the API needs to be more elaborate to > support obfuscation. It definitely needs some changes if we ever > want to add some of the features I'd like to add (but that's > off-topic here). JRA> Well, that's probably the best point yet: this isn't JRA> *MailMan's* problem, except to the extent that we "recommend" JRA> Piper as out archiver. I don't know if I recommend it, in fact I try to dis-recommend it. Still, I think we do more good than harm in distributing an archiver that works out of the box. And the advantage of Pipermail is that for really really critical problems, we /can/ go in and hack on it. I'm torn, but still come down on the side of including Pipermail, even with all its worts. > - I'll note that one of the early design decisions for Pipermail was > that public archives should be vended directly from the file system > for performance reasons. That decision may not be appropriate for > today's operations. Certainly maintaining two static versions of > the pages isn't feasible, so I think you have to vend one or the > other (probably the obfuscated version) from a cgi. JRA> No, but the performance reasons aren't as much of an issue JRA> now... Nope. -Barry From barry@zope.com Tue Feb 26 05:58:30 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 00:58:30 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <15483.9222.222734.607004@anthem.wooz.org> >>>>> "SJT" == Stephen J Turnbull writes: BAW> I'd do the same with cookies if I could figure out how to do BAW> low-frustration-factor authentication without them. SJT> Don't even think such things. You're just tempting the Lords SJT> of Chaos. Ie, in this case, if you can't support HTTP well SJT> enough to handle cookies, you aren't going to support SJT> anything powerful enough for any kind of authentication very SJT> well either. It's just not the same as supporting SJT> multimedia. Yeah, it's just that I generally hate cookies too. But there's not much value in debating this. It is what it is. BAW> 5) list rosters SJT> I don't know of any lists where these are available to the SJT> members, let alone the public. If you only knew, you might be horrified (I know Chuq would be). -Barry From barry@zope.com Tue Feb 26 06:05:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:05:12 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <20020226030148.79D0313DB6@registry.e-servicesltd.co.nz> <87r8n8vr12.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <15483.9624.222115.340287@anthem.wooz.org> >>>>> "SJT" == Stephen J Turnbull writes: SJT> To me, it's not really an issue of dumbing down. It would be SJT> easy enough to do this with a separate app, so the question SJT> is "should a deprecated feature continue to encruft MM?" I'm not sure I'm ready to deprecate the roster until we can come up with a simple recipe for people to unsubscribe themselves unambiguously via the web. Right now I say: - Go to the listinfo page for this list - Click on "Visit Subscriber List" - Find your address, click on it. - Click on "Unsubscribe". Unless they know what address they're subscribed with, anything else involves a bunch of fumbling. -Barry From barry@zope.com Tue Feb 26 06:08:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:08:24 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <15483.9816.517954.815712@anthem.wooz.org> >>>>> "CVR" =3D=3D Chuq Von Rospach writes: >> BAW> 5) list rosters >> I don't know of any lists where these are available to the >> members, let alone the public. CVR> You know, now that I think about it. Wihle I think Mailman CVR> now has this turned off by default (does it? If not, it CVR> should...), perhaps it's time to just make the option dead CVR> and buried, so that na=EFve list admins don't have the ability= CVR> to open it up any more... The problem is that I suspect it makes it much harder for a person to find their user account and get themselves unsubscribed. Without the roster, they have to know the address they're subscribed with to get anywhere. And lots of people don't. -Barry From terri@thehole.zone12.com Fri Feb 1 07:32:30 2002 From: terri@thehole.zone12.com (Terri Oda) Date: Fri, 1 Feb 2002 02:32:30 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Announce] Once again, fame and fortune can be In-Reply-To: <15448.12471.191533.155893@anthem.wooz.org> from "Barry A. Warsaw" at Jan 30, 2002 12:43:19 PM Message-ID: <200202010732.g117WUn31666@thehole.zone12.com> > Two changes: I made the background grey since that looks a little > better on my Moz 0.9.6+ browser, and I converted it to PNG (GIFs are > taboo for GNU projects ;). I should have thought of that orginally! Actually, I thought about it after I put it up on my server, but I was too tired and lazy feeling to convert it, and then my mail bounced because I brilliantly signed up under this address and then sent mail from @zone12 instead of @hole.zone12 and... I guess it wasn't my night. :) It's actually an interesting quirk that I could authorize the subscription from @zone12 but couldn't post from there. I guess I've never tried that before. > Let me know what you all think. Terri, thanks, and would you be > willing to sign copyright assignment papers for the logo? No problem. Does anything actually need to be physically signed, or is just "I give all rights to this arrangement of 256 pixels to the FSF" by email good enough? (I know, it's necessary, but it seems a lot of fuss over such a tiny image!) Actually, I gather that since I'm in Canada, I retain moral rights even if I sign off everything. Not that it matters, (How the heck could you abuse moral right on such a tiny logo? Wait, don't answer that. :) ) but it's an interesting quirk of our system that artists have a right that can't be signed away in a legal sense. Moral right means that you can object legally if something you've created is used in a way which you deem inappropriate, like a picture being used on hate literature or, in the one case I've heard about, red bows tied around the necks of fake geese in a shopping centre. No, really! Terri From fbaroni@axoadi.it Tue Feb 5 13:52:25 2002 From: fbaroni@axoadi.it (Gian Franco Baroni) Date: Tue, 05 Feb 2002 14:52:25 +0100 Subject: [Mailman-Developers] Bug on web managed digest? Message-ID: Hi, I've got this error on my install of 2.1a4: Traceback: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 86, in run_main main() File "/home/mailman/Mailman/Cgi/admin.py", line 187, in main show_results(mlist, doc, category, subcat, cgidata) File "/home/mailman/Mailman/Cgi/admin.py", line 510, in show_results form.AddItem(show_variables(mlist, category, subcat, cgidata, doc)) File "/home/mailman/Mailman/Cgi/admin.py", line 562, in show_variables add_options_table_item(mlist, category, subcat, table, item) File "/home/mailman/Mailman/Cgi/admin.py", line 577, in add_options_table= _item val =3D get_item_gui_value(mlist, category, kind, varname, params) File "/home/mailman/Mailman/Cgi/admin.py", line 616, in get_item_gui_valu= e value =3D getattr(mlist, varname) File "/home/mailman/Mailman/MailList.py", line 135, in __getattr__ raise AttributeError, name AttributeError: _new_volume When trying to set the digest options of the list. All other admin tasks work fine. Thanks GFB From ggillen@MIT.EDU Mon Feb 11 18:27:33 2002 From: ggillen@MIT.EDU (Gerti Gillen) Date: Mon, 11 Feb 2002 13:27:33 -0500 Subject: [Mailman-Developers] Re: [Mailman-Announce] Verio VPS Solaris - Anyone use this service with MailMan? In-Reply-To: <15463.64550.771944.764236@anthem.wooz.org> References: <947853235donaven@scseaside.com> Message-ID: <5.0.2.1.2.20020211132713.019d5728@hesiod> --=====================_16306140==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed REMOVE me from this list, please. At 12:15 PM 2/11/2002 -0500, you wrote: > >>>>> "DS" == Donaven Staab writes: > > DS> Dear MailMan announce list members, > > DS> I'd appreciated any feedback here. > > DS> Does anyone currently use the MailMan Mailing List Utility > DS> with a Verio VPS Solaris account? > > DS> I'm interested in giving it a try and would like some feedback > DS> of current users. > > DS> Thank you for your time. > >My fault folks. I was modding this posting and hit the wrong button. >This should not have gone to mailman-announce. > >-Barry > >_______________________________________________ >Mailman-announce mailing list >Mailman-announce@python.org >http://mail.python.org/mailman/listinfo/mailman-announce __________________________________________________ Gerti Gillen Assistant Director for Administration MIT, CEHS 56-235 C 617-253-6282; fax 617-452-2066, ggillen@mit.edu --=====================_16306140==_.ALT Content-Type: text/html; charset="us-ascii" REMOVE me from this list, please.

At 12:15 PM 2/11/2002 -0500, you wrote:

>>>>> "DS" == Donaven Staab <donaven@scseaside.com> writes:

    DS> Dear MailMan announce list members,

    DS> I'd appreciated any feedback here.

    DS> Does anyone currently use the MailMan Mailing List Utility
    DS> with a Verio VPS Solaris account?

    DS> I'm interested in giving it a try and would like some feedback
    DS> of current users.

    DS> Thank you for your time.

My fault folks.  I was modding this posting and hit the wrong button.
This should not have gone to mailman-announce.

-Barry

_______________________________________________
Mailman-announce mailing list
Mailman-announce@python.org
http://mail.python.org/mailman/listinfo/mailman-announce

__________________________________________________
Gerti Gillen
Assistant Director for Administration
MIT, CEHS 56-235 C
617-253-6282; fax 617-452-2066,  ggillen@mit.edu --=====================_16306140==_.ALT-- From marc_news@vasoftware.com Sat Feb 16 06:05:08 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 15 Feb 2002 22:05:08 -0800 Subject: [Mailman-Developers] Potential risk of VERP? In-Reply-To: <15465.24008.930915.373871@anthem.wooz.org>; from barry@zope.com on Tue, Feb 12, 2002 at 01:24:08PM -0500 References: <15465.24008.930915.373871@anthem.wooz.org> Message-ID: <20020215220508.E16460@merlins.org> On Tue, Feb 12, 2002 at 01:24:08PM -0500, Barry A. Warsaw wrote: > - foo@yahoogroups.com gets disabled, thus shutting off a large list of > recipients. > > Or will/should yahoogroups rewrite the envelope sender for /its/ > downstream members? yahoogroups should rewrite the envelope sender to catch the bounces themselves. If they don't, they deserve to be unsubscribed. (in other words fan out lists setup without the approval and collaboration of the original list owner should be show up as one user, and handle whatever problems they may have on their side without having bounces go to you) Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jcmcm@speakeasy.net Mon Feb 25 18:25:28 2002 From: jcmcm@speakeasy.net (jcmcm@speakeasy.net) Date: Mon, 25 Feb 2002 10:25:28 -0800 Subject: [Mailman-Developers] cgi-bin src? Message-ID: <200202251825.g1PIPSh07830@spidey.speakeasy.net> I'm looking to modify the administration interface (and likely a handful of other things). Am I just looking in all the wrong places or is there no available source code for the cgi binaries? JM From Dan@ohnesorg.cz Mon Feb 25 20:28:16 2002 From: Dan@ohnesorg.cz (Dan Ohnesorg) Date: Mon, 25 Feb 2002 21:28:16 +0100 Subject: [Mailman-Developers] Problems with Cookie.py while upgrading In-Reply-To: <15482.32557.579923.40312@anthem.wooz.org> References: <20020211211746.GO4569@ohnesorg.cz> <15475.10891.928404.666632@geddy.wooz.org> <20020225181248.GB11009@merlins.org> <15482.32557.579923.40312@anthem.wooz.org> Message-ID: <20020225202815.GA1326@ohnesorg.cz> Dne Mon, Feb 25, 2002 at 01:15:09PM -0500, Barry A. Warsaw napsal: > > >>>>> "MM" == Marc MERLIN writes: > > MM> I'm fairly sure it was fixed in alpha4, and it is definitely > MM> fixed in CVS (this problem didn't appear when I upgraded > MM> another mm site of mine recently (from 2.0 to cvs that is)) > > Cool. Yes, I confirm, that CVS is OK. cheers dan -- ----------------------------------------------------------- / Dan Ohnesorg Dan@ohnesorg.cz \ < Jinočanská 7 252 19 Rudná u Prahy > \ tel: +420 311 679679 +420 311 679976 fax: +420 311 679311 / ----------------------------------------------------------- From barry@zope.com Tue Feb 26 06:14:34 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:14:34 -0500 Subject: [Mailman-Developers] mylist-subscribe / mylist-unsubscribe References: <20020226001847.37771.qmail@web14810.mail.yahoo.com> Message-ID: <15483.10186.672627.825333@anthem.wooz.org> >>>>> "PS" == Paul Schreiber writes: PS> Apologies if this has already been noted ... are -on and -off PS> set up as aliases as well? I forgot who does this -- ListSTAR PS> or LetterRip -- whatever TidBITS uses. No they aren't. I'm leary about adding a bunch of aliases, but if there's really a widely deployed established practice, then it might make sense to add them. -Barry From barry@zope.com Tue Feb 26 06:17:01 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:17:01 -0500 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> Message-ID: <15483.10333.392460.569578@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler >>>>> writes: JRM> barry@zope.com (Barry A. Warsaw) writes: >> - searching JRM> This is the biggie IMHO. Interface differences matter little JRM> to me, but I find an unsearchable mailing list archive JRM> practically worthless. I'd love it if Zest (or Pipermail, for that matter) had integrated searching. So would a lot of people. But nobody's cared enough to code it and own it. OTOH, Zest's interface is really neat in that search /seems/ like it'll be less necessary, because you can really follow the bulk of the conversation without having to pull up each and every message. -Barry From stephen@xemacs.org Tue Feb 26 06:17:39 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 26 Feb 2002 15:17:39 +0900 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.9222.222734.607004@anthem.wooz.org> References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> <15483.9222.222734.607004@anthem.wooz.org> Message-ID: <87wux0rcl8.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "BAW" == Barry A Warsaw writes: BAW> Yeah, it's just that I generally hate cookies too. So call them [Kerberos] "tickets". (Me like cookies, one, two, I put them away now. Tickets have no flavor and are hard to chew.) You aren't going to make cookies go away, because they really really do constitute a service to the browsing public. This is a generic problem on the 'net. Making the 'net work for you most effectively requires that you carry a persona with you, whether you call that "cookie", "ticket", "published email address", or "shopping cart". This necessarily conflicts with privacy. One may hope that Mailman's specific set of solutions can contribute to that broader set of issues. BAW> If you only knew, you might be horrified. Naw. I'm an economist in Japan. Beyond horror. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software. From barry@zope.com Tue Feb 26 06:20:23 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:20:23 -0500 Subject: [Mailman-Developers] gate_news still broken in 2.1b.. References: <200202252248.g1PMmUh18292@babylon5.cc.vt.edu> Message-ID: <15483.10535.697753.439510@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Ok, mailman installs now, and large chunks of it are working, RJ> sans, apparently, any support for gzipping anymore since I got RJ> three pages of errors trying to link zlib. However, gate_news RJ> is still doing what I reported a month or two ago... If I RJ> email a messages to my gated test list, I get this i the RJ> errors file: RJ> Feb 25 17:44:21 2002 (17842) (NNTPDirect) NNTP error for list RJ> "rontest": 441 437 No colon-space in "From RJ> jarrell@lennier.cc.vt.edu Mon Feb 25 17:44:00 2002 " header RJ> For some reason gate_news is passing the unix mailbox "From " RJ> header to the news server, who, understandably, doesn't like RJ> it. Ah, I've been confused. It's not gate_news that's broken (that's the NNTP->mail gateway), it's NewsRunner.py (the mail->NNTP) gateway. The fix seems simple. Can you try the attached please and let me know how it goes? -Barry -------------------- snip snip -------------------- Index: NewsRunner.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Queue/NewsRunner.py,v retrieving revision 2.8 diff -u -r2.8 NewsRunner.py --- NewsRunner.py 12 Oct 2001 05:16:18 -0000 2.8 +++ NewsRunner.py 26 Feb 2002 06:19:11 -0000 @@ -56,7 +56,7 @@ prepare_message(mlist, msg, msgdata) try: # Flatten the message object, sticking it in a StringIO object - fp = StringIO(str(msg)) + fp = StringIO(msg.as_string()) conn = None try: try: From barry@zope.com Tue Feb 26 06:23:17 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:23:17 -0500 Subject: [Mailman-Developers] More building the snapshot.... References: <200202251823.g1PINe920393@babylon5.cc.vt.edu> Message-ID: <15483.10709.859791.680998@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Mailman/pythonlib/Makefile needs to get registered, so the RJ> cvs will realize it can delete it, and the pythonlib tree.. Something's weird with the cvs repository, I suspect. I had this problem, and then I manually blew away the pythonlib directory, did a "cvs up -P -d" and couldn't reproduce the problem. :( -Barry From barry@zope.com Tue Feb 26 06:35:13 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:35:13 -0500 Subject: [Mailman-Developers] cgi-bin src? References: <200202251825.g1PIPSh07830@spidey.speakeasy.net> Message-ID: <15483.11425.574026.754192@anthem.wooz.org> >>>>> "jcmcm" == writes: jcmcm> I'm looking to modify the administration interface (and jcmcm> likely a handful of other things). Am I just looking in all jcmcm> the wrong places or is there no available source code for jcmcm> the cgi binaries? It's all in the Python source and in the templates. The cgi binaries are just tiny wrapper programs that do some assertions for security purposes. And of course, as Mailman is GPL'd, /all/ the source code is available! -Barry From barry@zope.com Tue Feb 26 06:40:20 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:40:20 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> <15483.9222.222734.607004@anthem.wooz.org> <87wux0rcl8.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <15483.11732.74459.428262@anthem.wooz.org> >>>>> "SJT" == Stephen J Turnbull writes: SJT> You aren't going to make cookies go away, because they really SJT> really do constitute a service to the browsing public. I've given up on the anti-cookie rants, for the most part. I still haven't given up my rage against JavaScript or Java, but I get derided daily by my Pythonlabs counterparts for it. :) BAW> If you only knew, you might be horrified. SJT> Naw. I'm an economist in Japan. Beyond horror. Try setting up a bona fide IRS approved not-for-profit in the USA. We humans have devised so many creative ways to reduce our brains to tasty grey jelly, it's almost funny. -Barry From barry@zope.com Tue Feb 26 06:48:43 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:48:43 -0500 Subject: [Mailman-Developers] current snapshot install... References: <200202232044.g1NKid520871@babylon5.cc.vt.edu> <15480.31018.798785.873340@anthem.wooz.org> <20020224095400.GA14548@lenin.nu> Message-ID: <15483.12235.109204.170506@anthem.wooz.org> >>>>> "PCN" == Peter C Norton writes: PCN> These days if someone doesn't have gzip installed they should PCN> be doing it ASAP. Even solaris users can get stuff like this PCN> from Sun now. Making gzip a requirement isn't an issue on PCN> any modern platform. Good, that's my intuition as well. Besides, if you didn't have some way to un-gzip, you wouldn't be able to unpack the orignal tarball. I don't distribute .Z files. :) -Barry From dm-temp-310102@nyc.rr.com Tue Feb 26 06:52:28 2002 From: dm-temp-310102@nyc.rr.com (Damien Morton) Date: Tue, 26 Feb 2002 01:52:28 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.11732.74459.428262@anthem.wooz.org> Message-ID: <002f01c1be92$2b339cf0$56296c42@damien> > From: Barry A. Warsaw > > >>>>> "SJT" == Stephen J Turnbull writes: > > SJT> You aren't going to make cookies go away, because they really > SJT> really do constitute a service to the browsing public. > > I've given up on the anti-cookie rants, for the most part. I > still haven't given up my rage against JavaScript or Java, > but I get derided daily by my Pythonlabs counterparts for it. :) You could always use Basic Authentication, with authentication being done by the cgi scripts against the membership list (emailaddress,password) rather than the webserver. As far as I can tell, this operates somewhat like a cookie in that identifying information is handed to the server on every request. From barry@zope.com Tue Feb 26 06:51:36 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:51:36 -0500 Subject: [Mailman-Developers] current snapshot install... References: <200202232044.g1NKid520871@babylon5.cc.vt.edu> <5.1.0.14.2.20020224213524.00a4aa40@lennier.cc.vt.edu> Message-ID: <15483.12408.141308.823871@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> I'd imagine upwards of 90% of systems out there have gunzip. RJ> Or maybe just use gzip -d. It would, however, add another RJ> required component, and this one just for one itty bit of the RJ> install. Honestly, since you're distributing everything as a RJ> compressed tarball already, do really need to also compress RJ> email? Just ship it as a straight tar, or, better yet, ship RJ> it as an untarred tree... It's handy because distutils creates the tarball for me. We don't /have/ to do it this way, but it's the easiest thing, so until it's proven broken... RJ> Ah. I didn't study the actual makefile commands far enough to RJ> notice that. I just the the "grumble grumble what in hell are RJ> you doing barry grumble grumble" comment out the offending RJ> part command... :-) Ah c'mon now, I'd never lead /you/ astray, Ron. At least not until I cash that $5000 check you sent me . -Barry From barry@zope.com Tue Feb 26 06:55:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:55:11 -0500 Subject: [Mailman-Developers] more snapshot woes... References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225154018.08017ec0@lennier.cc.vt.edu> Message-ID: <15483.12623.23112.305914@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Ahhh. Yet another python upgrade just for mailman :-). Yup, RJ> still running 2.0... Ok, time to shelve mailman for a bit RJ> while we go hunt down python 2.1, and remember all the things RJ> we had to beat on to make it work the first time (since python RJ> has *never* compiled the way I want it the first time, not RJ> being on a linux box... Sigh.) Python 2.1 /should/ be better than 2.0. For one thing, you shouldn't have to mess with the Setup file, since by default Python 2.1 will auto-detect and build all the shared libraries it can. It uses a new build machinery that 2.0 didn't have, so it should be much less error prone. Of course, it's been a /long/ time since I did an install on anything other than a Linux box (or the occasional *BSD box). RJ> Will 2.0* run fine on python 2.1? I'll probably upgrade my RJ> production machines python sooner, rather than later, if I'm RJ> going to need to be doing it. 2.0.8 should run fine on anything from Python 1.5.2 to Python 2.2. If you're going to use Python 2.1, I'd recommend 2.1.2 which is the latest patch release. RJ> BTW, install or update probably should note that the user has RJ> a installed Mailman/pythonlib and delete the apps, before that RJ> bites someone on the ass. Or at least make a note in the RJ> upgrade instructions to go do it yourself. bin/update should already zap an installed Mailman/pythonlib, but it won't get called by default until I bump the version numbers. For now (running from cvs), manually run "bin/update -f". You can't do any harm from running this multiple times. -Barry From barry@zope.com Tue Feb 26 06:56:13 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 01:56:13 -0500 Subject: [Mailman-Developers] more snapshot woes... References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225155232.07b8eea0@lennier.cc.vt.edu> Message-ID: <15483.12685.196368.147547@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Actually, come to think of it, will mm 2.1* work ok on python RJ> 2.2? Since it's out, I might just as well go straight there! I develop primarily using Python 2.2 these days, with occasional forays back into 2.1.2 land. -Barry From barry@zope.com Tue Feb 26 07:02:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 02:02:32 -0500 Subject: [Mailman-Developers] more snapshot woes... References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> Message-ID: <15483.13064.912061.276185@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> I hate installing python. All those 80 gazillion modules, RJ> each of which thinks it knows more about your system than you RJ> do, and wants to taunt you with it. I remembered that my big RJ> problems in the past have been the fact that I'm a Berkeley RJ> 3.N shop (soon to be 4.N) and pythin is still thinking 1.85... Berkeley db support is the sorest point for me, but BDB support on most Linuxes is a mess anyway. On my Linux box, with multiple BDB libraries installed, Python 2.1.x always worked just fine for me. It's completely broken in Python 2.2; won't even build. But unless you need BDB support for something other than Mailman, I wouldn't worry about it. I changed the Postfix MTA module to not depend on the bsddb module, so that fragile piece of brokenness is gone. (Aside: if you're doing serious work with Berkeley DB in Python, do yourself a favor and go to pybsddb.sf.net, download and install Robin Dunn's new wrapper. It's a little tricky getting to build correctly, but read the docs carefully and you should be okay.) RJ> So I remembered to with the --without-libdb and compiled RJ> cleanly the first try. Now I discover that 2.2 is pissed at RJ> my libz, which I haven't changed since I started compiling RJ> python 1.whatever, and works fine with 2.0. Did I mention I RJ> hate installing python? Sigh, I dimly remember something about zlib compatibility, it's got to be version 1.0.4 or better, right? I've got zlib 1.1.3 on my ancient RH6.1 Linux box, and Python 2.2 built against it no sweat. -Barry From barry@zope.com Tue Feb 26 07:05:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 02:05:03 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.11732.74459.428262@anthem.wooz.org> <002f01c1be92$2b339cf0$56296c42@damien> Message-ID: <15483.13215.652976.790788@anthem.wooz.org> >>>>> "DM" == Damien Morton writes: DM> You could always use Basic Authentication, with authentication DM> being done by the cgi scripts against the membership list DM> (emailaddress,password) rather than the webserver. As far as I DM> can tell, this operates somewhat like a cookie in that DM> identifying information is handed to the server on every DM> request. Yeah, except that AFAICT, basic auth is broken in that you can't re-authenticate yourself or un-authenticate yourself. I.e. you need to do `Logout', especially when you're debugging the admin interfaces. ;) I could be totally off base though. -Barry From chuqui@plaidworks.com Tue Feb 26 07:12:28 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 25 Feb 2002 23:12:28 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.9816.517954.815712@anthem.wooz.org> Message-ID: On 2/25/02 10:08 PM, "Barry A. Warsaw" wrote: > The problem is that I suspect it makes it much harder for a person to > find their user account and get themselves unsubscribed. Without the > roster, they have to know the address they're subscribed with to get > anywhere. And lots of people don't. Do users actually look themselves up? To be blunt about it, as far as I can tell, they simply email the admin and say "help me!". Is this a real issue any more? Not to me, it's not. The exposure risk is worth a couple of extra help requests to the admin -- and I doubt any significant group of users actually look themselves up any more. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From chuqui@plaidworks.com Tue Feb 26 07:14:55 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 25 Feb 2002 23:14:55 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.9624.222115.340287@anthem.wooz.org> Message-ID: On 2/25/02 10:05 PM, "Barry A. Warsaw" wrote: > > I'm not sure I'm ready to deprecate the roster until we can come up > with a simple recipe for people to unsubscribe themselves > unambiguously via the web. If you go to VERP (or more correctly, customized email), you can set up the footer of each message to include a URL to take them right ot the unsub page. Or then mimic lyris with a "you are subscribed as" in the footer. Much preferable to hoping they go and find themselves in the roster. I think the whole roster thing is obsolete technology, and few users today are on lists that actually disttribute them, so few know they exist, much less think to use them. I'd love to see data from sites that DO promote them to see how they're actually being used. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From cheesefactory@yahoo.com Tue Feb 26 07:23:34 2002 From: cheesefactory@yahoo.com (Paul Schreiber) Date: Mon, 25 Feb 2002 23:23:34 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.13215.652976.790788@anthem.wooz.org> Message-ID: <20020226072334.52118.qmail@web14807.mail.yahoo.com> --- "Barry A. Warsaw" wrote: > > >>>>> "DM" == Damien Morton writes: > > DM> You could always use Basic Authentication, with authentication > DM> being done by the cgi scripts against the membership list > DM> (emailaddress,password) rather than the webserver. As far as I > DM> can tell, this operates somewhat like a cookie in that > DM> identifying information is handed to the server on every > DM> request. > > Yeah, except that AFAICT, basic auth is broken in that you can't > re-authenticate yourself or un-authenticate yourself. I.e. you need > to do `Logout', especially when you're debugging the admin > interfaces. ;) I believe there is a way to to do logout; it involves sending another 401 header to the client, which causes the browser to think it now has the wrong password and forget it. apologies for being fuzzy on the details. While I'm on the topic.... http://www.apple.com/downloads/macosx/system_disk_utilities/spamstopper.html That utility translates all the characters in an email address to character entities, something spambots aren't likely to pick up on. for now, anyway. i.e. mailman could incorporate something like this. Paul __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From tkikuchi@is.kochi-u.ac.jp Tue Feb 26 07:28:50 2002 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 26 Feb 2002 16:28:50 +0900 Subject: [Mailman-Developers] A Bug in Hold.py Message-ID: <3C7B3932.407@is.kochi-u.ac.jp> Hi, I am playing with Mailman 2.1a i18n feature. When I set my test list as moderated, the rejection notice message in admindb/details doesn't show up with translation. Following short patch fixes this bug (I think). --- /home/mailman/src/mailman/Mailman/Handlers/Hold.py Fri Feb 15 19:17:45 2002 +++ Hold.py Tue Feb 26 16:16:44 2002 @@ -189,7 +189,7 @@ # We need to send both the reason and the rejection notice through the # translator again, because of the games we play above reason = Utils.wrap(exc.reason_notice()) - msgdata['rejection-notice'] = Utils.wrap(exc.rejection_notice(mlist)) + msgdata['rejection-notice'] = Utils.wrap(_(exc.rejection_notice(mlist))) id = mlist.HoldMessage(msg, reason, msgdata) # Now we need to craft and send a message to the list admin so they can # deal with the held message. Sorry, if the lines are wrapped. -- Tokio Kikuchi From chuqui@plaidworks.com Tue Feb 26 07:36:18 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 25 Feb 2002 23:36:18 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.9117.172305.565827@anthem.wooz.org> Message-ID: On 2/25/02 9:56 PM, "Barry A. Warsaw" wrote: > - Some place that password reminders come from. Since this will be > receiving bounces, it ought to be a real list. Cautionary tale here. A long time ago, in a galaxy far, far away, I decided to do my users a favor, and created an over-arching meta-list of all subscribers (effectively, an umbrella list of all lists on my site). I figured users would appreciate getting the monthly messages and admin notices once, instead of once-per-subscription. Silly me. All it did was start a continuing set of firefights with people who demanded the right to unsubscribe from the umbrella list. And they were quite unpleasant about it. I never did figure this out, either -- people that never complained about getting five copies of the monthly notice started screaming bloody murder when they started getting ONE, because they insisted on the right to get zero. It was such a nasty situation I blew the whole thing up after a few months, and went back to mailing admin and monthly notices to each list. And people stopped screaming. So just be aware -- if you create a server-wide "list", you may well be creating a point of conflict, based on my experience. And it wasn't a situation where, at least for those users, "if you subscribe to a list on this site, you have to get this" was an acceptable answer to these people. So instead of getting a message once, they get it four or five times, and since they come in the name of the list they subscribed to, evidently that's okay. Go figure. But be wary here, Barry. My experience doing something very similar was horrible. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! From chuqui@plaidworks.com Tue Feb 26 07:41:09 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 25 Feb 2002 23:41:09 -0800 Subject: [Mailman-Developers] mylist-subscribe / mylist-unsubscribe In-Reply-To: <15483.10186.672627.825333@anthem.wooz.org> Message-ID: On 2/25/02 10:14 PM, "Barry A. Warsaw" wrote: > No they aren't. I'm leary about adding a bunch of aliases, but if > there's really a widely deployed established practice, then it might > make sense to add them. Support the RFCs. If there are endemic options, support them (but, IMHO, add an RFC-only option.. Grin). Please, don't encourage too many NON RFC compliant options, it only encourages folks to roll their own and not moove to the RFCs. Just because others choose to not support the RFCs isn't an excuse for us to cooperate... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! From midnight@the-oasis.net Tue Feb 26 13:30:02 2002 From: midnight@the-oasis.net (Phil Barnett) Date: Tue, 26 Feb 2002 08:30:02 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: References: Message-ID: On Tuesday 26 February 2002 02:14 am, you wrote: > On 2/25/02 10:05 PM, "Barry A. Warsaw" wrote: > > I'm not sure I'm ready to deprecate the roster until we can come up > > with a simple recipe for people to unsubscribe themselves > > unambiguously via the web. > > If you go to VERP (or more correctly, customized email), you can set > up the footer of each message to include a URL to take them right ot > the unsub page. Or then mimic lyris with a "you are subscribed as" in > the footer. Actually, this 'you are subscribed as' is a good idea anyway. When people subscribe under one address and it goes through a couple of forwarding mailboxes that mung the headers and then dies, it's difficult to tell what the original subscriber name was sometime. This would alleviate that. I have a list right now that has this problem and I've yet to figure out which subscriber is causing the problem. From jra@baylink.com Tue Feb 26 17:17:28 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 26 Feb 2002 12:17:28 -0500 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: <15483.10333.392460.569578@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, Feb 26, 2002 at 01:17:01AM -0500 References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> Message-ID: <20020226121728.49429@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 01:17:01AM -0500, Barry A. Warsaw wrote: > >>>>> "JRM" == Jason R Mastaler > >>>>> writes: > > JRM> barry@zope.com (Barry A. Warsaw) writes: > > >> - searching > > JRM> This is the biggie IMHO. Interface differences matter little > JRM> to me, but I find an unsearchable mailing list archive > JRM> practically worthless. > > I'd love it if Zest (or Pipermail, for that matter) had integrated > searching. So would a lot of people. But nobody's cared enough to > code it and own it. Searching doesn't belong inside of a list archiver that has a web interface -- why do the same work twice? There are half a dozen or more web search engine packages which can be pointed at that interface, right? Not to mention Google, but we just finished that argument... Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Tue Feb 26 17:19:55 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 26 Feb 2002 12:19:55 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: ; from Phil Barnett on Tue, Feb 26, 2002 at 08:30:02AM -0500 References: Message-ID: <20020226121955.39567@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 08:30:02AM -0500, Phil Barnett wrote: > Actually, this 'you are subscribed as' is a good idea anyway. When > people subscribe under one address and it goes through a couple of > forwarding mailboxes that mung the headers and then dies, it's > difficult to tell what the original subscriber name was sometime. This > would alleviate that. *Whoa* yeah! Any error message that doesn't include the parameter of a bad call should cause it's writer to be shot. Cheers, -- jra -- Jay R. Ashworth jra@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") From dgc@uchicago.edu Tue Feb 26 17:26:11 2002 From: dgc@uchicago.edu (David Champion) Date: Tue, 26 Feb 2002 11:26:11 -0600 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! In-Reply-To: <20020226121728.49429@scfn.thpl.lib.fl.us> References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> Message-ID: <20020226172611.GB60@dust.uchicago.edu> On 2002.02.26, in <20020226121728.49429@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > Searching doesn't belong inside of a list archiver that has a web > interface -- why do the same work twice? There are half a dozen or > more web search engine packages which can be pointed at that interface, > right? Sure it does. No web search engines have access to my list server's private list archives, and none will. That's an implied promise to my list admins and their subscribers. Those lists are private, and having a search engine index them gives nonsubscribers a point of access, whether or not they can open up the original list server's presentation of the archive. But subscribers should still have the ability to search the lists they're subscribed to. -- -D. dgc@uchicago.edu NSIT University of Chicago From jra@baylink.com Tue Feb 26 17:36:49 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 26 Feb 2002 12:36:49 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.9117.172305.565827@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, Feb 26, 2002 at 12:56:45AM -0500 References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <20020225131456.63400@scfn.thpl.lib.fl.us> <15483.9117.172305.565827@anthem.wooz.org> Message-ID: <20020226123649.06945@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 12:56:45AM -0500, Barry A. Warsaw wrote: > JRA> I do see one problem here, and I don't know if you already > JRA> address it below. [ looks ] You don't; it's this: if the > JRA> list-owner addresses go through the MM machinery, as well, > JRA> then they too can die if MM crashes the wrong way. > > JRA> This implies, as I believe has already been discussed, that > JRA> the *server* admin address must be publicly accessible, not > JRA> be piped into MailMan at all, and preferably, should actually > JRA> not even be handled by the same machine... ("Single point of > JRA> failure") > > Well, what machine it's handled by isn't Mailman's business, but you > do have a point. Until recently, I recommended that you install > aliases `mailman' and `mailman-owner', but now I recommend that > `mailman' be an actual list, and it is from this list that things like > password reminders look to come from. Also, if the site list gets a > bounce, it'll check all the existing lists for a match against the > bouncing address. Hmmm... > You make the valid point that if the Mailman system were to break, > you'd have no way to contact the site administrator, save for typical > aliases like postmaster. It seems like you want: > > - A non-list, plain alias to contact the human in case of emergency Yep; and it's fine if this is an alias; I agree with Chuq's opinion about 'Real people", but I don't mind *sending* to a role account, as long as the *reply* comes from a human, with a .sig file. > - Some place that password reminders come from. Since this will be > receiving bounces, it ought to be a real list. Yeah, probably. > - A site-wide list of maintainers of the site who can take care of > normal operations (i.e. panicky unsubscription requests). > > Perhaps #3 can be the same as #1 for those sites that have a > collaborative management arrangement. So the question is, what do we > call the alias and what do we call the list? I have definitely seen > people try to send mail commands to `mailman@python.org' and from my > Majordomo days, this seems like a reasonable thing to (eventually) > implement. Is it sufficient to recommend that postmaster@ point to a > real human, not a list, and leave mailman@dom.ain a normal list? Hmmm... I see the problem: mailman is the obvious alias for the server admin, but I also see why you want to leave it a list. *I* think that postmaster@ the mailing list machine (or domain) is a good enough answer, but I think Chuq will accuse me of geeking out again, and on this one, I'm afraid I'd agree with him. The number of people on the net with *no* indoctrination at all is truly stunning. > If not, i'd still opt for `mailman' to be the site list, and add > something like mailman-panic to be a human address. Or perhaps make > mailman-owner pipe both to the wrapper and to postmaster. I dunno, > I'm open to suggestions. Well, here's the problem: it has to be predictable, because 1) you can't put in every mail footer cause you don't *want* people using it unless something goes Horribly Wrong, but 2) if something *does* go Horribly Wrong, they won't be *able* to get it from the website... > > Mailman should avoid getting deeply into the spam detection and > > prevention business, except for some really really basic stuff > > (probably not much more or less than it does now). It should > > integrate well with external spam detection programs like SpamAssassin > > or commercial equivalents. E.g. if we always send the message through > > SA, and the message gets some score, we could decide to hold messages > > below say 5.0 on the Spamster Scale, discard anything about 5.0, etc. > > JRA> That sounds good, and if there isn't already a "plugin" API > JRA> for that, we ought to give some thought to that... > > Agreed. I just have no idea what a reasonable API would be, although > we're planning on doing some experiments with SA on {python,zope}.org > to see what might make sense. I suspect that, at least for Unixy installs, a system call to the appropriate binary, with percentized arguments, will fill the bill nicely; you can catch the exit value -- and if your package doesn't do it that way, you can write a script to parse the output and send a return value. I, personally, would re-read the message from the file I put it in, in case someone's package (wants to) rewrite the MIME to remove and quarantine suspicious attachments. > > #4 is interesting too. I'm not against putting the raw archive behind > > a turing-test, since I suspect that very few people will ever want > > it. It means that we won't be able to write an automated wget-ish > > script to do off-site backups, but so be it. > > JRA> Is there a difference between raw and private that I'm > JRA> missing? Do you mean the mbox format files? > > Yup. raw == mbox. Ok. I've often found it quite useful to snarf those down for lists I'm not on (yet); I wouldn't mind having to prove I was human, though. My real problem was just that the obfuscation breaks Google, and since "Get the glue right" is one of my loudest systems-design mantras... > JRA> Well, that's probably the best point yet: this isn't > JRA> *MailMan's* problem, except to the extent that we "recommend" > JRA> Piper as out archiver. > > I don't know if I recommend it, in fact I try to dis-recommend it. Sounds like a good call to me... > Still, I think we do more good than harm in distributing an archiver > that works out of the box. And the advantage of Pipermail is that for > really really critical problems, we /can/ go in and hack on it. I'm > torn, but still come down on the side of including Pipermail, even > with all its worts. Until Zest is a solution... > > - I'll note that one of the early design decisions for Pipermail was > > that public archives should be vended directly from the file system > > for performance reasons. That decision may not be appropriate for > > today's operations. Certainly maintaining two static versions of > > the pages isn't feasible, so I think you have to vend one or the > > other (probably the obfuscated version) from a cgi. > > JRA> No, but the performance reasons aren't as much of an issue > JRA> now... > > Nope. Optimizing for performance in the core design of a system is nearly always a bad idea, at least on this end of the performance curve. If you're redesigning Amadeus, or SABRE; perhaps not. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Tue Feb 26 17:37:58 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 26 Feb 2002 12:37:58 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.11732.74459.428262@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, Feb 26, 2002 at 01:40:20AM -0500 References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <878z9hvufp.fsf@tleepslib.sk.tsukuba.ac.jp> <15483.9222.222734.607004@anthem.wooz.org> <87wux0rcl8.fsf@tleepslib.sk.tsukuba.ac.jp> <15483.11732.74459.428262@anthem.wooz.org> Message-ID: <20020226123758.46383@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 01:40:20AM -0500, Barry A. Warsaw wrote: > Try setting up a bona fide IRS approved not-for-profit in the USA. > We humans have devised so many creative ways to reduce our brains to > tasty grey jelly, it's almost funny. I'm a director of one; secretary, in fact; that stack of paper lives in a box in my van. Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Tue Feb 26 17:59:39 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 26 Feb 2002 09:59:39 -0800 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: <20020226121728.49429@scfn.thpl.lib.fl.us> Message-ID: On 2/26/02 9:17 AM, "Jay R. Ashworth" wrote: > Searching doesn't belong inside of a list archiver that has a web > interface -- why do the same work twice? There are half a dozen or > more web search engine packages which can be pointed at that interface, > right? This is a discussion we had early on at apple. You'll notice if you look closely that apple's list archives are not available through apple's corporate search engine, and lists has its own search engine. Why? Because of focus. People going to www.apple.com don't want to be sidetracked having to wade through hits in the archives looking for what they want on the main site. Loading in the archives really hurts being able to find stuff in BOTH data sets. My opinion is that archives should not be generically lumped in with the rest of the web site in a single browser, because our tests and studies have shown it reduces the efficiency in finding stuff in both. They're really disjoint data sets. So my feeling is a list server archive ought to be an independent search engine, and our tests back that up. If someone goes to www.apple.com and wants to find the latest java updater for MacOS X, they don't really want 100 postings from Java-dev to pop up and annoy them. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From jra@baylink.com Tue Feb 26 18:26:34 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 26 Feb 2002 13:26:34 -0500 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! In-Reply-To: <20020226172611.GB60@dust.uchicago.edu>; from David Champion on Tue, Feb 26, 2002 at 11:26:11AM -0600 References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> Message-ID: <20020226132634.43759@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 11:26:11AM -0600, David Champion wrote: > On 2002.02.26, in <20020226121728.49429@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > > > Searching doesn't belong inside of a list archiver that has a web > > interface -- why do the same work twice? There are half a dozen or > > more web search engine packages which can be pointed at that interface, > > right? > > Sure it does. No web search engines have access to my list server's > private list archives, and none will. That's an implied promise to my > list admins and their subscribers. Those lists are private, and having a > search engine index them gives nonsubscribers a point of access, whether > or not they can open up the original list server's presentation of the > archive. But subscribers should still have the ability to search the > lists they're subscribed to. ... and a generic web search engine, running locally on that machine, with access to the messages, will serve that purpose fine, and can still be hidden behind whatever authentication you like. My point that this particular wheel need not be reinvented still stands. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Tue Feb 26 18:27:50 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 26 Feb 2002 13:27:50 -0500 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: ; from Chuq Von Rospach on Tue, Feb 26, 2002 at 09:59:39AM -0800 References: <20020226121728.49429@scfn.thpl.lib.fl.us> Message-ID: <20020226132750.19020@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 09:59:39AM -0800, Chuq Von Rospach wrote: > On 2/26/02 9:17 AM, "Jay R. Ashworth" wrote: > > Searching doesn't belong inside of a list archiver that has a web > > interface -- why do the same work twice? There are half a dozen or > > more web search engine packages which can be pointed at that interface, > > right? > > This is a discussion we had early on at apple. You'll notice if you look > closely that apple's list archives are not available through apple's > corporate search engine, and lists has its own search engine. > > Why? Because of focus. People going to www.apple.com don't want to be > sidetracked having to wade through hits in the archives looking for what > they want on the main site. Loading in the archives really hurts being able > to find stuff in BOTH data sets. My opinion is that archives should not be > generically lumped in with the rest of the web site in a single browser, > because our tests and studies have shown it reduces the efficiency in > finding stuff in both. They're really disjoint data sets. > > So my feeling is a list server archive ought to be an independent search > engine, and our tests back that up. If someone goes to www.apple.com and > wants to find the latest java updater for MacOS X, they don't really want > 100 postings from Java-dev to pop up and annoy them. No argument there, though *my* personal preferred approach is to have the same search engine do all the work, and have a set of checkboxes for domain selection, with a properly chosen default... Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Tue Feb 26 18:40:46 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 26 Feb 2002 10:40:46 -0800 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: <20020226132750.19020@scfn.thpl.lib.fl.us> Message-ID: On 2/26/02 10:27 AM, "Jay R. Ashworth" wrote: > No argument there, though *my* personal preferred approach is to have > the same search engine do all the work, and have a set of checkboxes > for domain selection, with a properly chosen default... Our user testing doesn't agree with your personal preference. Sorry. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From barry@zope.com Tue Feb 26 18:53:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 13:53:50 -0500 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! References: <20020226121728.49429@scfn.thpl.lib.fl.us> Message-ID: <15483.55742.667977.241043@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> So my feeling is a list server archive ought to be an CVR> independent search engine, and our tests back that up. If CVR> someone goes to www.apple.com and wants to find the latest CVR> java updater for MacOS X, they don't really want 100 postings CVR> from Java-dev to pop up and annoy them. When we were actually indexing the python.org archives with our donated Ultraseek server (donated because they used Python), we could set up different search sets. The default set (I believe) did the same thing -- it separated the web hits from the archive hits. Advanced searches had the ability to pick and choose which search sets would be included, so you /could/ search both the web and archives, just one, or the other, etc. -Barry From barry@zope.com Tue Feb 26 19:43:17 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 14:43:17 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.9816.517954.815712@anthem.wooz.org> Message-ID: <15483.58709.756971.33324@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> The problem is that I suspect it makes it much harder for a >> person to find their user account and get themselves >> unsubscribed. Without the roster, they have to know the >> address they're subscribed with to get anywhere. And lots of >> people don't. CVR> Do users actually look themselves up? To be blunt about it, CVR> as far as I can tell, they simply email the admin and say CVR> "help me!". Is this a real issue any more? Not to me, it's CVR> not. The exposure risk is worth a couple of extra help CVR> requests to the admin -- and I doubt any significant group of CVR> users actually look themselves up any more. I'm willing to change the default roster view to list-members-only. -Barry From jarrell@vt.edu Tue Feb 26 19:54:05 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Feb 2002 14:54:05 -0500 Subject: [Mailman-Developers] More building the snapshot.... In-Reply-To: <15483.10709.859791.680998@anthem.wooz.org> References: <200202251823.g1PINe920393@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20020226145220.04123840@lennier.cc.vt.edu> At 01:23 AM 2/26/02 -0500, Barry A. Warsaw wrote: >>>>>> "RJ" == Ron Jarrell writes: > > RJ> Mailman/pythonlib/Makefile needs to get registered, so the > RJ> cvs will realize it can delete it, and the pythonlib tree.. > >Something's weird with the cvs repository, I suspect. I had this >problem, and then I manually blew away the pythonlib directory, did a >"cvs up -P -d" and couldn't reproduce the problem. :( Well, it properly deleted everything else. But Makefile isn't technically in the registry, it's made by configure. So cvs didn't know about it, and couldn't delete it. I deleted just it, once I realized what was up, and the next cvs up -P -d deleted the rest of the tree - so I was suggesting making sure that cvs new about Makefile. Maybe add it to the registry, and then delete it :-). From jarrell@vt.edu Tue Feb 26 20:07:55 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Feb 2002 15:07:55 -0500 Subject: [Mailman-Developers] more snapshot woes... In-Reply-To: <15483.13064.912061.276185@anthem.wooz.org> References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020226145743.04120820@lennier.cc.vt.edu> At 02:02 AM 2/26/02 -0500, Barry A. Warsaw wrote: > RJ> So I remembered to with the --without-libdb and compiled > RJ> cleanly the first try. Now I discover that 2.2 is pissed at > RJ> my libz, which I haven't changed since I started compiling > RJ> python 1.whatever, and works fine with 2.0. Did I mention I > RJ> hate installing python? > >Sigh, I dimly remember something about zlib compatibility, it's got to >be version 1.0.4 or better, right? I've got zlib 1.1.3 on my ancient >RH6.1 Linux box, and Python 2.2 built against it no sweat. Turns out, the autodetect worked fine on berkeleydb, but picked up the wrong libraries (ones it couldnt' understand, being too new), so I had to override that, to get it to work. However the autodetect stuff apparently did *not* work on zlib (which was 1.1.3, and has been for a while on my machine). It then proceeded to give me three pages of library errors on linking. I'm thinking it didn't build the interface module, but tried to link in the library anyway. Eventually I figured out that I had to manually enable it in Setup (btw, the docs have a certain "tail chasing" quality to them, with various files point you at files that have comments that say "Well, nothing *really* uses this file anymore, you should go look at X." I found my self wandering from Setup to Setup.config to setup.py following the bread crumbs... Eventually my 2.2 passed all its tests. Which leads to an entirely different issue of me wanting a word or two with the person who developed the sunaudiodev test... Which had never properly built before, but 2.2 figured out I had one and auto-enabled it. I was building and testing on the workstation, and doing some abuse tracking on my laptop. Suddenly, after visiting a spam site my laptop yelled "Noooo one expects the spanish inquisition." Regular python builders on sun boxes will already know the resolution to this story. I freaked, figuring I'd let some applet through my security software and into my laptop. After searching for a while, and revisiting websites, looking at (bad) html code, (and starting another test run on python going, after trying another library fix), my laptop suddenly did it again. I dragged out ever ip and file descriptor tracking program I had, and was watching the machine like a hawk. Did another python test on the sun workstation. Which, by the way, is in a tower, under my desk, coincidentally right under my laptop. Laptop does the monty python bit again, and now I'm confused, because not a single blip registered on the monitors - how in hell did the sound get to the speakers, when I can see none of the audio devices were touched? Suddenly I have an epiphany... And start cursing. And type "python Lib/blahblahblah/test_sunaudiodev" and hear "Nooo one expects the spanish inquisition" coming from, I know realize, under my table... ARRGH! Two hours later, it was really funny... From jarrell@vt.edu Tue Feb 26 20:10:15 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Feb 2002 15:10:15 -0500 Subject: [Mailman-Developers] more snapshot woes... In-Reply-To: <15483.13064.912061.276185@anthem.wooz.org> References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020226150822.04120b80@lennier.cc.vt.edu> BTW, either update needs to do something, or issue a warning, or install needs to refer to it, or something, but even knowing exactly what caused it, I got bit by the "en" was installed in my list directory. Took me a while to realize it was happening, because, screwing around, I selected Russian as my language of choice. Which, BTW, displayed everything in English. Does that mean I'm missing something in the install? When I switched to English for real, I got the *old* web pages... And immediately realized what was going on... From dgc@uchicago.edu Tue Feb 26 21:04:06 2002 From: dgc@uchicago.edu (David Champion) Date: Tue, 26 Feb 2002 15:04:06 -0600 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! In-Reply-To: <20020226132634.43759@scfn.thpl.lib.fl.us> References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> <20020226132634.43759@scfn.thpl.lib.fl.us> Message-ID: <20020226210406.GE60@dust.uchicago.edu> On 2002.02.26, in <20020226132634.43759@scfn.thpl.lib.fl.us>, "Jay R. Ashworth" wrote: > > ... and a generic web search engine, running locally on that machine, > with access to the messages, will serve that purpose fine, and can > still be hidden behind whatever authentication you like. Maybe I'm simply unaware of the generic web search engines that will run on my web server and subscribe to whatever authentication mechanism I like, including checking Mailman mailing list passwords for the particular mailing list a user is trying to search. My point is that if the specific authentication I'm looking must be devised, there's no functional difference to me between placing it in the archiver and placing it in a separate search product that knows how my MLM and archiver work, and can talk to them. But the former seems like a better software design to me, since the archiver is already part of my MLM. I'm in search of the ability to index list archives in a way that does not violate privacy and that my users will understand. It matters more to me that I can achieve that (without developing the glue myself each time Mailman changes its authentication interface) than whether my solution is Righteous. -- -D. dgc@uchicago.edu NSIT University of Chicago From jarrell@vt.edu Tue Feb 26 21:07:53 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 26 Feb 2002 16:07:53 -0500 Subject: [Mailman-Developers] gate_news still broken in 2.1b.. In-Reply-To: <15483.59947.556683.678903@anthem.wooz.org> References: <200202252248.g1PMmUh18292@babylon5.cc.vt.edu> <5.1.0.14.2.20020226132320.03db2920@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20020226160356.045700c0@lennier.cc.vt.edu> At 03:03 PM 2/26/02 -0500, Barry A. Warsaw wrote: >>>>>> "RJ" == Ron Jarrell writes: > > RJ> Yea, you know, I sat down last night when I got home and > RJ> looked at the code, and slapped myself on the forehead with > RJ> the same realization, that I was blaming the wrong piece of > RJ> code... > > RJ> As for the patch - BING! We have a winner. > >Awesome. Thanks, I'm going to commit this change. Cool.. How much more you going to do before the formal beta release? Enough seems to be working (and I have enough of a handle on things I might have to handwave) that I'm tempted to start putting it up on my production box... But if there's going to be a last minute flurry of features and fixes before then, I probably won't bother. Oh, BTW, simple typo in the admin pages. In the VARHELP=topics/topics_enabled, the sentence: "The body of the message can also be optionally scanned for Subject: and Keyword: headers" Keyword: should be "Keywords:", which bit me for a while, because, of course, *that* was the occurrence of the word (which is right two other places in the paragraph) that I focused on. Although, I'm thinking, either Keyword: or Keywords: out to to work. Especically since it'll usually be one keyword... From Dan Mick Tue Feb 26 21:27:49 2002 From: Dan Mick (Dan Mick) Date: Tue, 26 Feb 2002 13:27:49 -0800 (PST) Subject: [Mailman-Developers] Can't get VERP to do much Message-ID: <200202262128.g1QLSdcW028207@utopia.West.Sun.COM> > On Mon, Feb 25, 2002 at 02:25:14PM -0800, Dan Mick wrote: > > > > > File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 112, in > > __verpbounce > > > if bmailbox <> mo.group('bounces'): > > > IndexError: no such group > > > > Are you sure Defaults.py is up-to-date? Specifically, > > VERP_FORMAT and VERP_REGEXP? > > root@gandalf:/var/local/mailman/Mailman# grep VERP_ mm_cfg.py > VERP_FORMAT = '%(bounces)s+%(mailbox)s=%(host)s' > VERP_REGEXP = r'^[^+]+?\+(?P[^=]+)=(?P[^@]+)@.*$' > VERP_PASSWORD_REMINDERS = 1 > VERP_PERSONALIZED_DELIVERIES = 1 > VERP_DELIVERY_INTERVAL = 1 > > I left the defaults Those aren't current. # Note that your MTA /must/ be configured to deliver such an addressed message # to mylist-bounces! VERP_FORMAT = '%(bounces)s+%(mailbox)s=%(host)s' # The second describes a regular expression to unambiguously decode such an # address, which will be placed in the To: header of the bounce message by the # bouncing MTA. Getting this right is critical -- and tricky. Learn your # Python regular expressions. It must define exactly three named groups, # bounces, mailbox and host, with the same definition as above. It will be # compiled case-insensitively. VERP_REGEXP = r'^(?P[^+]+?)\+(?P[^=]+)=(?P[^@]+)@.*$' From jwm@plain.co.nz Tue Feb 26 22:22:11 2002 From: jwm@plain.co.nz (John Morton) Date: Wed, 27 Feb 2002 11:22:11 +1300 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <87r8n8vr12.fsf@tleepslib.sk.tsukuba.ac.jp> References: <20020226030148.79D0313DB6@registry.e-servicesltd.co.nz> <87r8n8vr12.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <20020226222212.7698313DC6@registry.e-servicesltd.co.nz> On Tuesday 26 February 2002 16:52, Stephen J. Turnbull wrote: > >>>>> "John" == John Morton writes: > > John> I find this feature is handy for small, private lists. > > Sure. I have a couple that could be handled that way, but we just > defaulted them all off. We post the names and addresses (they're > basically lists of project staff) on the home page, with mailtos and > fancy formatting, instead. When the staff forget who handles what, > they use that interface, just like the clients do. (It's voluntary, > they are warned about harvesting; nobody has refused yet.) Unless the membership data that mailman stores has suddenly got a lot better documented since I last looked, I assume you're basically maintaining a separate list for your roster. I'd rather have one source of member data. > John> I'd rather it was still around and just disabled by default > John> with warning stickers all over it than we dumb down mailman > > To me, it's not really an issue of dumbing down. It would be easy > enough to do this with a separate app, so the question is "should a > deprecated feature continue to encruft MM?" I agree that when Mailman has a nice, well documented data schema and a datastore that accepts concurrent client access, then this sort of feature ought to be deprecated from the MM core. John From marc_news@vasoftware.com Tue Feb 26 22:36:48 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 26 Feb 2002 14:36:48 -0800 Subject: [Mailman-Developers] Can't get VERP to do much In-Reply-To: <200202262128.g1QLSdcW028207@utopia.West.Sun.COM> References: <200202262128.g1QLSdcW028207@utopia.West.Sun.COM> Message-ID: <20020226223647.GF5066@merlins.org> On Tue, Feb 26, 2002 at 01:27:49PM -0800, Dan Mick wrote: > > root@gandalf:/var/local/mailman/Mailman# grep VERP_ mm_cfg.py > > VERP_FORMAT = '%(bounces)s+%(mailbox)s=%(host)s' > > VERP_REGEXP = r'^[^+]+?\+(?P[^=]+)=(?P[^@]+)@.*$' > > VERP_PASSWORD_REMINDERS = 1 > > VERP_PERSONALIZED_DELIVERIES = 1 > > VERP_DELIVERY_INTERVAL = 1 > > > > I left the defaults > > Those aren't current. Indeed. > VERP_REGEXP = r'^(?P[^+]+?)\+(?P[^=]+)=(?P[^@]+)@.*$' Thanks for pointing that out. I probably missed that at my last CVS update. Works much better now: Feb 26 14:33:41 2002 (30145) test: sfsadfsadf@gandalf.merlins.org bounce score: 1.0 Note to Barry: some "can't parse string" or "unhappy with VERP string" instead of a traceback and a non obvious "IndexError: no such group" would be nice :-) Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jwblist@olympus.net Tue Feb 26 23:16:10 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 26 Feb 2002 15:16:10 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <20020226123649.06945@scfn.thpl.lib.fl.us> References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <20020225131456.63400@scfn.thpl.lib.fl.us> <15483.9117.172305.565827@anthem.wooz.org> <20020226123649.06945@scfn.thpl.lib.fl.us> Message-ID: At 12:36 -0500 2/26/2002, Jay R. Ashworth wrote: >*I* think that postmaster@ the mailing list machine (or domain) is a >good enough answer, but I think Chuq will accuse me of geeking out >again, and on this one, I'm afraid I'd agree with him. > >The number of people on the net with *no* indoctrination at all is >truly stunning. Earthlink seems to think that postmaster@ should be a synonym for abuse@, and that a robot should scan the incoming message and say "nothing here seems like abuse of an Earthlink account...go away". And all I was trying to do was tell them "hey, in the odd moments when I can actually use the POP server, I've gotten a dozen Welcome messages for other users, 4 invoices for other users, two responses from support robots destined for other users which about said other users having similar problems." The robot is right...no abuse there. ;-( With that kind of training, no one will find the postmaster@ address. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From barry@zope.com Wed Feb 27 00:33:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 19:33:39 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: Message-ID: <15484.10595.122174.30830@anthem.wooz.org> >>>>> "PB" == Phil Barnett writes: PB> Actually, this 'you are subscribed as' is a good idea PB> anyway. When people subscribe under one address and it goes PB> through a couple of forwarding mailboxes that mung the headers PB> and then dies, it's difficult to tell what the original PB> subscriber name was sometime. This would alleviate that. PB> I have a list right now that has this problem and I've yet to PB> figure out which subscriber is causing the problem. Again, another of the wonderful things you can do if you turn on personalized email and don't mind the extra resources that consumes. The additional substitution variable is `user_address'. time-machine-again-ly y'rs, -Barry From barry@zope.com Wed Feb 27 00:38:08 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 19:38:08 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <20020225131456.63400@scfn.thpl.lib.fl.us> <15483.9117.172305.565827@anthem.wooz.org> <20020226123649.06945@scfn.thpl.lib.fl.us> Message-ID: <15484.10864.654930.810183@anthem.wooz.org> >>>>> "JWB" == John W Baxter writes: JWB> With that kind of training, no one will find the postmaster@ JWB> address. I find it very rare that anybody actually responds to postmaster@ addressed email. I suspect that for most sites, nobody reads them. I think I'm coming down on the side that mailman@ should be a tee, one to the list machinery and another to a Real Human. -barry From barry@zope.com Wed Feb 27 00:40:20 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 19:40:20 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.9117.172305.565827@anthem.wooz.org> Message-ID: <15484.10996.354231.393205@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> So just be aware -- if you create a server-wide "list", you CVR> may well be creating a point of conflict, based on my CVR> experience. And it wasn't a situation where, at least for CVR> those users, "if you subscribe to a list on this site, you CVR> have to get this" was an acceptable answer to these people. CVR> So instead of getting a message once, they get it four or CVR> five times, and since they come in the name of the list they CVR> subscribed to, evidently that's okay. CVR> Go figure. But be wary here, Barry. My experience doing CVR> something very similar was horrible. Actually, we're no worse off than we were before, in fact, it should now be better. How many messages have /you/ gotten from people receiving the password reminder from a list they never heard of? Remember that 2.0.x just picked the first public list at random (well, lexically sorted) and used /that/ for the origin of the reminder. That's so obviously broken that it had to be fixed. -Barry From barry@zope.com Wed Feb 27 00:41:13 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 19:41:13 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.13215.652976.790788@anthem.wooz.org> <20020226072334.52118.qmail@web14807.mail.yahoo.com> Message-ID: <15484.11049.568205.119009@anthem.wooz.org> >>>>> "PS" == Paul Schreiber writes: PS> While I'm on the topic.... PS> http://www.apple.com/downloads/macosx/system_disk_utilities/spamstopper.html PS> That utility translates all the characters in an email address PS> to character entities, something spambots aren't likely to PS> pick up on. for now, anyway. PS> i.e. mailman could incorporate something like this. Interesting, except that I suspect the mailto: is a dead giveaway. Seems like something the harvesters could easily adjust for and detect, so I don't see the value in spending time implementing it. -Barry From marc_news@vasoftware.com Wed Feb 27 00:50:26 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 26 Feb 2002 16:50:26 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15484.10996.354231.393205@anthem.wooz.org> References: <15483.9117.172305.565827@anthem.wooz.org> <15484.10996.354231.393205@anthem.wooz.org> Message-ID: <20020227005026.GH5066@merlins.org> On Tue, Feb 26, 2002 at 07:40:20PM -0500, Barry A. Warsaw wrote: > Actually, we're no worse off than we were before, in fact, it should > now be better. How many messages have /you/ gotten from people > receiving the password reminder from a list they never heard of? The funny thing is that I've gotten lots of hate mail saying "how do you dare sending my my mailman password in cleartext. STOP THIS NOW!!!", but not one "why did this come from test-admin@lists.sf.net" :-) That said, I very much welcome the new option in 2.1. Am I to understand however that the sitewide list doesn't have to be a list and can be a mail alias instead? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From barry@zope.com Wed Feb 27 01:03:14 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 26 Feb 2002 20:03:14 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.9117.172305.565827@anthem.wooz.org> <15484.10996.354231.393205@anthem.wooz.org> <20020227005026.GH5066@merlins.org> Message-ID: <15484.12370.505278.852077@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> The funny thing is that I've gotten lots of hate mail saying MM> "how do you dare sending my my mailman password in MM> cleartext. STOP THIS NOW!!!", but not one "why did this come MM> from test-admin@lists.sf.net" :-) MM> That said, I very much welcome the new option in 2.1. And of course, in MM2.1 they can turn their password reminders off entirely. MM> Am I to understand however that the sitewide list doesn't have MM> to be a list and can be a mail alias instead? No, as it stands in cvs, it has to be a list. -Barry From marc_news@vasoftware.com Wed Feb 27 01:07:41 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Tue, 26 Feb 2002 17:07:41 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15484.12370.505278.852077@anthem.wooz.org> References: <15483.9117.172305.565827@anthem.wooz.org> <15484.10996.354231.393205@anthem.wooz.org> <20020227005026.GH5066@merlins.org> <15484.12370.505278.852077@anthem.wooz.org> Message-ID: <20020227010741.GJ5066@merlins.org> On Tue, Feb 26, 2002 at 08:03:14PM -0500, Barry A. Warsaw wrote: > MM> The funny thing is that I've gotten lots of hate mail saying > MM> "how do you dare sending my my mailman password in > MM> cleartext. STOP THIS NOW!!!", but not one "why did this come > MM> from test-admin@lists.sf.net" :-) > > MM> That said, I very much welcome the new option in 2.1. > > And of course, in MM2.1 they can turn their password reminders off > entirely. Yes, I was very relieved when that feature appeared :-) > MM> Am I to understand however that the sitewide list doesn't have > MM> to be a list and can be a mail alias instead? > > No, as it stands in cvs, it has to be a list. Not that it is a big deal to me, but out of curiosity: what part of mailman cares that it's a list and not a mail alias? Does mailman act on the bounces sent back to the envelope from when it sends password reminders? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From stephen@xemacs.org Wed Feb 27 01:57:51 2002 From: stephen@xemacs.org (Stephen J. Turnbull) Date: 27 Feb 2002 10:57:51 +0900 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! In-Reply-To: <20020226210406.GE60@dust.uchicago.edu> References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> <20020226132634.43759@scfn.thpl.lib.fl.us> <20020226210406.GE60@dust.uchicago.edu> Message-ID: <87sn7npty8.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "David" == David Champion writes: David> On 2002.02.26, in David> <20020226132634.43759@scfn.thpl.lib.fl.us>, David> "Jay R. Ashworth" wrote: >> ... and a generic web search engine, running locally on that >> machine, with access to the messages, will serve that purpose >> fine, and can still be hidden behind whatever authentication >> you like. David> Maybe I'm simply unaware of the generic web search engines David> that will run on my web server Er, all of them? Search engines don't do authentication, webservers do. Or at the very least, webservers can do enough kinds of authentication that you should be able to find one you like. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Think orthogonal. Think freedom from .OCTOPUS. Not as hard as you think. From brett@twobikes.ottawa.on.ca Wed Feb 27 02:00:12 2002 From: brett@twobikes.ottawa.on.ca (Brett Delmage) Date: Tue, 26 Feb 2002 21:00:12 -0500 (EST) Subject: [Mailman-Developers] Can't approve/discard/reject subscriptions in 2.1a4 Message-ID: Problem: I can't clear pending subscription requests by processing them. I applied the patch to 2.1a4 below but it doesn't work for me. The steps to duplicate the problem are listed below and are very simple. I created a new list. I subscribed to the list using email, not the web form, using the list defaults. The subscription was activated without incident. Using Konquerer (2.2.1) as my browser, I modified the subcribe_policy to "Require approval" then subscribed to it using a different email address. I received the "Your subscription request has been forwarded to the list administrator" message as expected, as well as the list-owner notification. I went to the Administrative requests for mailing list: form and confirmed that the pending subscribe request was shown. I selected the Discard radio button end entered a reason, then the submit button. I confirmed that the rejection notice was mailed to the subscriber. However the subscriber was still shown as a subscription request. I tried resubmitting the form with the Approve radio button selected. The subscriber was sent a welcome message, but still appeared on the form as a pending subscription request. I selected the Reject radio button end entered a reason, then the submit button. The subscriber (supposedly already subscribed!) was mailed a rejection notice. And still appeared on the form as a pending request. Some users just won't go away ;-) If left in this state, the daily oustanding moderations nag is mailed to the list owner. I've looked at the code but am just learning python (part of my reason for using mailman, I figured it was a great 'real world' project to help me learn python.) But I couldn't see the problem. Maybe in a month or two... I hope the steps to reproduce the problem are helpful. Really, you can't help but encounter it. Thanks to all those working on Mailman. It's a really impressive list manager despite this bug, which doesn't affect the actual list operation in any way. Brett ------------------------------------------------------ On Thu, 24 Jan 2002, Les Niles wrote: > (Apologies if this has already been reported. I don't remember > it.) Approval of pending subscriptions via the admindb web page is > ignored in 2.1a4. Here's a patch that fixes this. > > ------------------------------------------------------------- > *** Mailman/Cgi/admindb.py.~1~ Sun Jan 6 23:04:02 2002 > --- Mailman/Cgi/admindb.py Thu Jan 24 21:56:59 2002 > *************** > *** 630,635 **** > --- 630,636 ---- > except ValueError: > continue > if v not in (mm_cfg.DEFER, mm_cfg.APPROVE, > + mm_cfg.SUBSCRIBE, mm_cfg.UNSUBSCRIBE, > mm_cfg.REJECT, mm_cfg.DISCARD): > continue > # Get the action comment and reasons if present. > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > From chuqui@plaidworks.com Wed Feb 27 02:41:12 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 26 Feb 2002 18:41:12 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <20020227005026.GH5066@merlins.org> Message-ID: On 2/26/02 4:50 PM, "Marc MERLIN" wrote: > The funny thing is that I've gotten lots of hate mail saying "how do you > dare sending my my mailman password in cleartext. STOP THIS NOW!!!", but not > one "why did this come from test-admin@lists.sf.net" :-) That's our experience, exactly. And it's mostly the same people, every month, making accusations about my mother's morals. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From dgc@uchicago.edu Wed Feb 27 02:57:38 2002 From: dgc@uchicago.edu (David Champion) Date: Tue, 26 Feb 2002 20:57:38 -0600 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! In-Reply-To: <87sn7npty8.fsf@tleepslib.sk.tsukuba.ac.jp> References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> <20020226132634.43759@scfn.thpl.lib.fl.us> <20020226210406.GE60@dust.uchicago.edu> <87sn7npty8.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <20020227025738.GL60@dust.uchicago.edu> On 2002.02.26, in <87sn7npty8.fsf@tleepslib.sk.tsukuba.ac.jp>, "Stephen J. Turnbull" wrote: > > Er, all of them? Search engines don't do authentication, webservers > do. Or at the very least, webservers can do enough kinds of > authentication that you should be able to find one you like. It's not a matter of finding an authentication method I like. It has to be authentication against the Mailman list roster and its passwords, whether or not I like it. :) I have that now, and actually, it's provided by Mailman and its integrated archiver, not by the HTTP server. If I add in a search engine, it needs to link into the same authentication system, and work in the same way. The HTTP server can't do that. I've slipped a semantic boundary by speaking of the MLM and the archiver as a unit (they are, to some extent, but the roles are separate and they don't have to be integrated). Maybe it's been a little unclear what I'm getting at. The current situation (archiving with no indexing, authenticated against the MM rosters) is possible because the archival documents on disk are accessible only to the Mailman CGI modules, and those authenticate access by being a core part of Mailman. So when I throw in an indexer/search engine, how will I make it authenticate against Mailman, too? I can achieve that by hacking onto an existing search engine knowledge of Mailman, which sounds to me like a PITA and difficult to support for any length of time (since the search engine isn't really bound to Mailman in any significant way). Or I can achieve it by using a search engine whose search parameters are taken as a GET request in the URL, so that it's visible to the web server, and munge into the web server recognition of the GET string so that it can authenticate to Mailman's roster using a substring of the URL passed through some arcana that I'd have to code up as an independent authentication module, I guess. But that sounds even worse. Or, since the archiver is an integrated part of Mailman already -- this is presupposed in the context of this thread -- I can have the archiver perform some basic searching. That's easy on the user, because it's a single authentication transaction to get into the archive and to perform a search. (With the other approaches, it's two transactions, unless the new code knows not only how to talk to Mailman's roster, but also how to insert an authentication token into the HTTP client in a forward- compatible way.) That's also a bit of work, but it doesn't need to be high-powered searching. Just basic "find this text" will do for most purposes. And it has the advantage of being more integrated with the MLM, requiring less off-sync third-party maintenance. I'm interested in a 95% solution. And it's there and useful with environments besides Mailman, too, even if they also use odd built-in authentication systems that aren't a part of the local web server. Maybe I'm still missing something, but if so, I still don't see it. That's how it seems to me. Anyway, I'm only trying to show that there's a case for having the search capability in the archiver, not to say that things should or shouldn't be some particular way. -- -D. dgc@uchicago.edu NSIT University of Chicago From Dan Mick Wed Feb 27 03:21:40 2002 From: Dan Mick (Dan Mick) Date: Tue, 26 Feb 2002 19:21:40 -0800 (PST) Subject: [Mailman-Developers] At least some of my problems... Message-ID: <200202270322.g1R3MTcW022209@utopia.West.Sun.COM> ....with messages that get corrupted in an I18N-ish way, are due to the fact that I'd written a Handler module to reject messages held for ImplicitDestination reasons (because I was tired of them). Um...but I didn't I18N-ize it. Oops. Sorry Ben, and thanks for the help. :) From jwblist@olympus.net Wed Feb 27 03:55:57 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 26 Feb 2002 19:55:57 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15484.10864.654930.810183@anthem.wooz.org> References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <20020225131456.63400@scfn.thpl.lib.fl.us> <15483.9117.172305.565827@anthem.wooz.org> <20020226123649.06945@scfn.thpl.lib.fl.us> <15484.10864.654930.810183@anthem.wooz.org> Message-ID: >I find it very rare that anybody actually responds to postmaster@ >addressed email. I suspect that for most sites, nobody reads them. Hmmm...could that be why other admins seem surprised when I answer? ;-) --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From Dan Mick Wed Feb 27 04:14:01 2002 From: Dan Mick (Dan Mick) Date: Tue, 26 Feb 2002 20:14:01 -0800 (PST) Subject: [Mailman-Developers] Bug in Bouncer.py (was: At least some of my problems...) Message-ID: <200202270414.g1R4EocW023249@utopia.West.Sun.COM> Or not. That was the proverbial pickled scarlet fish. Here's a fix to Bouncer.py. I'm divided about the wisdom of including some keywords and not all. I suppose I should at least be consistent, but I know Barry will fix it right anyway. Index: Bouncer.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Bouncer.py,v retrieving revision 2.23 diff -u -r2.23 Bouncer.py --- Bouncer.py 11 Feb 2002 21:05:10 -0000 2.23 +++ Bouncer.py 27 Feb 2002 04:05:51 -0000 @@ -165,8 +165,8 @@ }, mlist=self) subject = _('Bounce action notification') umsg = Message.UserNotification(self.GetOwnerEmail(), - siteowner, subject, - self.preferred_language) + siteowner, subject, text=None, + lang=self.preferred_language) umsg.attach(MIMEText(text)) if isinstance(msg, StringType): umsg.attach(MIMEText(msg)) @@ -222,8 +222,8 @@ notice = _(e.notice()) # Currently we always craft bounces as MIME messages. bmsg = Message.UserNotification(msg.get_sender(), - self.GetOwnerEmail(), - subject, self.preferred_language) + self.GetOwnerEmail(), subject, + text=None, lang=self.preferred_language) bmsg['Content-Type'] = 'multipart/mixed' bmsg['MIME-Version'] = '1.0' txt = MIMEText(notice, All Rejected messages and "bounce-disable" messages were getting corrupted. > ....with messages that get corrupted in an I18N-ish way, are due > to the fact that I'd written a Handler module to reject messages > held for ImplicitDestination reasons (because I was tired of them). > > Um...but I didn't I18N-ize it. > > Oops. > > Sorry Ben, and thanks for the help. :) > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From mac@wooz.org Wed Feb 27 00:23:31 2002 From: mac@wooz.org (mac@wooz.org) Date: Tue, 26 Feb 2002 19:23:31 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.9624.222115.340287@anthem.wooz.org> Message-ID: <15484.9987.866320.684830@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> I'm not sure I'm ready to deprecate the roster until we can >> come up with a simple recipe for people to unsubscribe >> themselves unambiguously via the web. CVR> If you go to VERP (or more correctly, customized email), you CVR> can set up the footer of each message to include a URL to CVR> take them right ot the unsub page. Or then mimic lyris with a CVR> "you are subscribed as" in the footer. In fact, when email personalization is enabled, there's a new substitution variable `user_optionsurl' which gets replaced with the url for the user's login page (which itself contains a big prominent Unsubscribe button). CVR> Much preferable to hoping they go and find themselves in the CVR> roster. CVR> I think the whole roster thing is obsolete technology, and CVR> few users today are on lists that actually disttribute them, CVR> so few know they exist, much less think to use them. I'd love CVR> to see data from sites that DO promote them to see how CVR> they're actually being used. Me too. Until then, I'm making the default for new mailing lists be private rosters. -Barry From brett@cfsc.ottawa.on.ca Wed Feb 27 01:55:26 2002 From: brett@cfsc.ottawa.on.ca (Brett Delmage) Date: Tue, 26 Feb 2002 20:55:26 -0500 (EST) Subject: [Mailman-Developers] Can't approve/discard/reject subscriptions in 2.1a4 In-Reply-To: <200201250600.WAA08022@mutiny.2pi.org> Message-ID: Problem: I can't clear pending subscription requests by processing them. I applied the patch to 2.1a4 below but it doesn't work for me. The steps to duplicate the problem are listed below and are very simple. I created a new list. I subscribed to the list using email, not the web form, using the list defaults. The subscription was activated without incident. Using Konquerer (2.2.1) as my browser, I modified the subcribe_policy to "Require approval" then subscribed to it using a different email address. I received the "Your subscription request has been forwarded to the list administrator" message as expected, as well as the list-owner notification. I went to the Administrative requests for mailing list: form and confirmed that the pending subscribe request was shown. I selected the Discard radio button end entered a reason, then the submit button. I confirmed that the rejection notice was mailed to the subscriber. However the subscriber was still shown as a subscription request. I tried resubmitting the form with the Approve radio button selected. The subscriber was sent a welcome message, but still appeared on the form as a pending subscription request. I selected the Reject radio button end entered a reason, then the submit button. The subscriber (supposedly already subscribed!) was mailed a rejection notice. And still appeared on the form as a pending request. Some users just won't go away ;-) If left in this state, the daily oustanding moderations nag is mailed to the list owner. I've looked at the code but am just learning python (part of my reason for using mailman, I figured it was a great 'real world' project to help me learn python.) But I couldn't see the problem. Maybe in a month or two... I hope the steps to reproduce the problem are helpful. Really, you can't help but encounter it. Thanks to all those working on Mailman. It's a really impressive list manager despite this bug, which doesn't affect the actual list operation in any way. Brett ------------------------------------------------------ On Thu, 24 Jan 2002, Les Niles wrote: > (Apologies if this has already been reported. I don't remember > it.) Approval of pending subscriptions via the admindb web page is > ignored in 2.1a4. Here's a patch that fixes this. > > ------------------------------------------------------------- > *** Mailman/Cgi/admindb.py.~1~ Sun Jan 6 23:04:02 2002 > --- Mailman/Cgi/admindb.py Thu Jan 24 21:56:59 2002 > *************** > *** 630,635 **** > --- 630,636 ---- > except ValueError: > continue > if v not in (mm_cfg.DEFER, mm_cfg.APPROVE, > + mm_cfg.SUBSCRIBE, mm_cfg.UNSUBSCRIBE, > mm_cfg.REJECT, mm_cfg.DISCARD): > continue > # Get the action comment and reasons if present. > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > --- Brett Delmage brett@cfsc.ottawa.on.ca --- o --- \\_/\ (*) `(*) From che@debian.org Wed Feb 27 05:07:29 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 27 Feb 2002 14:07:29 +0900 Subject: [Mailman-Developers] more snapshot woes... In-Reply-To: <5.1.0.14.2.20020226150822.04120b80@lennier.cc.vt.edu> (Ron Jarrell's message of "Tue, 26 Feb 2002 15:10:15 -0500") References: <200202252018.g1PKI1Y13227@babylon5.cc.vt.edu> <5.1.0.14.2.20020225172719.04b901c0@lennier.cc.vt.edu> <5.1.0.14.2.20020226150822.04120b80@lennier.cc.vt.edu> Message-ID: <87it8j4ini.fsf@nausicaa.interq.or.jp> >>>>> "Ron" == Ron Jarrell writes: Ron> Took me a while to realize it was happening, because, Ron> screwing around, I selected Russian as my language of choice. Ron> Which, BTW, displayed everything in English. Does that mean Ron> I'm missing something in the install? When I switched to Ron> English for real, I got the *old* web pages... And Ron> immediately realized what was going on... You'll notice that some of the messages, not many, are actually in Russian. (Like the language pull-down box). That means that the Russian translation has been started, but is missing a lot of translated strings, so Mailman uses the English defaults for those. Ben -- Brought to you by the letters C and H and the number 5. "Elate means having wings." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From che@debian.org Wed Feb 27 05:26:49 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 27 Feb 2002 14:26:49 +0900 Subject: [Mailman-Developers] System to tie Hypermail archiving to Mailman Message-ID: <87elj74hra.fsf@nausicaa.interq.or.jp> Here's a simple system I whipped up to automatically generate Hypermail configuration files based on each Mailman list's preferences and a few template files. The default template files I supply are for Japanese, but you can just remove the iso-2022-jp related lines and the Japanese comments from the html templates if you don't need that. http://nausicaa.interq.or.jp/mailman/hypermail-conf/ The meat is in hypermail-conf, a script to be run occasionally from cron to generate the per-list config files and create or rename hypermail archives for lists that do/don't want archiving. The do-hypermail script simply loops over all config files in /etc/hypermail/ created by hypermail-conf and runs hypermail on them. hypermail-conf.cron is an example crontab to run these. Comments, complaints, etc. are all appreciated. Ben -- Brought to you by the letters W and H and the number 12. "What's green and sits in the corner? ... A naughty frog!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From che@debian.org Wed Feb 27 06:03:39 2002 From: che@debian.org (Ben Gertzfield) Date: Wed, 27 Feb 2002 15:03:39 +0900 Subject: [Mailman-Developers] Error: Invalid value for variable: ban_list Message-ID: <878z9f4g1w.fsf@nausicaa.interq.or.jp> Using Mailman CVS, I get the following error whenever trying to change any privacy options for a newly-created list via the admin interface: Error: Invalid value for variable: ban_list But I don't have anything in my ban_list, it's completely empty. If I put a value into the ban_list (foo@bar.com) then I can set my preferences correctly. Ben -- Brought to you by the letters L and B and the number 17. "I choose YOU! Pikachu!" Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/ From Nigel.Metheringham@dev.InTechnology.co.uk Wed Feb 27 09:40:20 2002 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 27 Feb 2002 09:40:20 +0000 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15483.58709.756971.33324@anthem.wooz.org> References: <15483.9816.517954.815712@anthem.wooz.org> <15483.58709.756971.33324@anthem.wooz.org> Message-ID: <1014802820.9860.10.camel@gaspode.localnet> On Tue, 2002-02-26 at 19:43, Barry A. Warsaw wrote: > I'm willing to change the default roster view to list-members-only. For those within the EU*, the only correct setting is for the list admin only to be able to see the roster. You may be able to make a case for not even them to be able to see the roster :-) * ie those with EU data protection legislation affecting them. I have a vague idea that there are EU attempts to make this legislation stick worldwide where EU citizens are involved, and US attempt to be able to rape the data whoever its on. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] From jra@baylink.com Wed Feb 27 14:59:25 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 09:59:25 -0500 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: ; from Chuq Von Rospach on Tue, Feb 26, 2002 at 10:40:46AM -0800 References: <20020226132750.19020@scfn.thpl.lib.fl.us> Message-ID: <20020227095925.07438@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 10:40:46AM -0800, Chuq Von Rospach wrote: > On 2/26/02 10:27 AM, "Jay R. Ashworth" wrote: > > No argument there, though *my* personal preferred approach is to have > > the same search engine do all the work, and have a set of checkboxes > > for domain selection, with a properly chosen default... > > Our user testing doesn't agree with your personal preference. Sorry. Given the number of the HIG's that Apple violates these days, I didn't even know that y'all *did* user testing anymore. But Apple users aren't the whole world either, even though they think they are. Sorry. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 27 15:00:25 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 10:00:25 -0500 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! In-Reply-To: <15483.55742.667977.241043@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, Feb 26, 2002 at 01:53:50PM -0500 References: <20020226121728.49429@scfn.thpl.lib.fl.us> <15483.55742.667977.241043@anthem.wooz.org> Message-ID: <20020227100025.01308@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 01:53:50PM -0500, Barry A. Warsaw wrote: > >>>>> "CVR" == Chuq Von Rospach writes: > > CVR> So my feeling is a list server archive ought to be an > CVR> independent search engine, and our tests back that up. If > CVR> someone goes to www.apple.com and wants to find the latest > CVR> java updater for MacOS X, they don't really want 100 postings > CVR> from Java-dev to pop up and annoy them. > > When we were actually indexing the python.org archives with our > donated Ultraseek server (donated because they used Python), we could > set up different search sets. The default set (I believe) did the > same thing -- it separated the web hits from the archive hits. > Advanced searches had the ability to pick and choose which search sets > would be included, so you /could/ search both the web and archives, > just one, or the other, etc. Gee, that sounds familiar. I guess I'm not the only one who thinks it's a good idea, eh what? :-) Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 27 15:02:55 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 10:02:55 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15484.10864.654930.810183@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, Feb 26, 2002 at 07:38:08PM -0500 References: <20020218052510.A687013D4D@registry.e-servicesltd.co.nz> <15482.29691.492335.290682@anthem.wooz.org> <20020225131456.63400@scfn.thpl.lib.fl.us> <15483.9117.172305.565827@anthem.wooz.org> <20020226123649.06945@scfn.thpl.lib.fl.us> <15484.10864.654930.810183@anthem.wooz.org> Message-ID: <20020227100255.43308@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 07:38:08PM -0500, Barry A. Warsaw wrote: > >>>>> "JWB" == John W Baxter writes: > > JWB> With that kind of training, no one will find the postmaster@ > JWB> address. > > I find it very rare that anybody actually responds to postmaster@ > addressed email. I suspect that for most sites, nobody reads them. Well, *my* domains comply with the RFC. I don't actually *get* a lot of postmaster mail, though. > I think I'm coming down on the side that mailman@ should be a tee, one > to the list machinery and another to a Real Human. Yeah, that would work, too. Cheers, - jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 27 15:05:00 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 10:05:00 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <1014802820.9860.10.camel@gaspode.localnet>; from Nigel Metheringham on Wed, Feb 27, 2002 at 09:40:20AM +0000 References: <15483.9816.517954.815712@anthem.wooz.org> <15483.58709.756971.33324@anthem.wooz.org> <1014802820.9860.10.camel@gaspode.localnet> Message-ID: <20020227100500.02639@scfn.thpl.lib.fl.us> On Wed, Feb 27, 2002 at 09:40:20AM +0000, Nigel Metheringham wrote: > On Tue, 2002-02-26 at 19:43, Barry A. Warsaw wrote: > > I'm willing to change the default roster view to list-members-only. > > For those within the EU*, the only correct setting is for the list admin > only to be able to see the roster. You may be able to make a case for > not even them to be able to see the roster :-) > > * ie those with EU data protection legislation affecting them. > I have a vague idea that there are EU attempts to make this > legislation stick worldwide where EU citizens are involved, > and US attempt to be able to rape the data whoever its on. Well, presumably, if you *tell the users before hand that it's a condition*, then could make the information available, right? Lawyers will be happy to make it impossible for you to actually conduct business, if you let them; after all, *everything* is a legal exposure. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 27 15:11:50 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 10:11:50 -0500 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! In-Reply-To: <20020226210406.GE60@dust.uchicago.edu>; from David Champion on Tue, Feb 26, 2002 at 03:04:06PM -0600 References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> <20020226132634.43759@scfn.thpl.lib.fl.us> <20020226210406.GE60@dust.uchicago.edu> Message-ID: <20020227101150.05657@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 03:04:06PM -0600, David Champion wrote: > On 2002.02.26, in <20020226132634.43759@scfn.thpl.lib.fl.us>, > "Jay R. Ashworth" wrote: > > ... and a generic web search engine, running locally on that machine, > > with access to the messages, will serve that purpose fine, and can > > still be hidden behind whatever authentication you like. > > Maybe I'm simply unaware of the generic web search engines that will > run on my web server and subscribe to whatever authentication mechanism > I like, including checking Mailman mailing list passwords for the > particular mailing list a user is trying to search. I believe you've misunderstood me, here. If you run ht://dig, or something akin to it, *on a machine local to the mailing-list-archive machine, globally authenticated and authorized to retrieve messages from the archiver web server*, and then place *access to that search engine* behind whatever authentication you require for access to the messages themselves*, you've solved your problem, no? > My point is that if the specific authentication I'm looking must be > devised, there's no functional difference to me between placing it in > the archiver and placing it in a separate search product that knows how > my MLM and archiver work, and can talk to them. But the former seems > like a better software design to me, since the archiver is already part > of my MLM. And I disagree, precisely on point: if you have a clean interface to which the search engine can attach (and you do: HTTP), and there's no impedance mismatch (there isn't; the search engine needs to be returning *website* addresses, anyway), then why bundle it inside -- *especially* when there are packaged solutions... and there are. > I'm in search of the ability to index list archives in a way that does > not violate privacy and that my users will understand. It matters more > to me that I can achieve that (without developing the glue myself each > time Mailman changes its authentication interface) than whether my > solution is Righteous. Mailman isn't the issue, so far as I can see; the *archiver* is. Using a packaged websearch engine relieves you of the tie to Piper (which sucks) or Zest (which, I gather, sucks less), or whatever... I can't imagine that hooking the Mailman auth code could be *that* difficult... Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 27 15:14:06 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 10:14:06 -0500 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! In-Reply-To: <20020227025738.GL60@dust.uchicago.edu>; from David Champion on Tue, Feb 26, 2002 at 08:57:38PM -0600 References: <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> <20020226132634.43759@scfn.thpl.lib.fl.us> <20020226210406.GE60@dust.uchicago.edu> <87sn7npty8.fsf@tleepslib.sk.tsukuba.ac.jp> <20020227025738.GL60@dust.uchicago.edu> Message-ID: <20020227101406.49341@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 08:57:38PM -0600, David Champion wrote: > Or, since the archiver is an integrated part of Mailman already -- this > is presupposed in the context of this thread -- I can have the archiver > perform some basic searching. That's easy on the user, because it's a > single authentication transaction to get into the archive and to perform > a search. (With the other approaches, it's two transactions, unless the > new code knows not only how to talk to Mailman's roster, but also how > to insert an authentication token into the HTTP client in a forward- > compatible way.) That's also a bit of work, but it doesn't need to be > high-powered searching. Just basic "find this text" will do for most > purposes. And it has the advantage of being more integrated with the > MLM, requiring less off-sync third-party maintenance. I'm interested > in a 95% solution. And it's there and useful with environments besides > Mailman, too, even if they also use odd built-in authentication systems > that aren't a part of the local web server. > > Maybe I'm still missing something, but if so, I still don't see it. I believe that what you're missing is up in the top of the message -- unless *I'm* missing something. Pipermail is *not*, so far as I've been able to tell, "an integrated part of Mailman". Is it, Barry? For the purposes of David's assertion above, I mean. Cheers, - jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Wed Feb 27 15:28:43 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 27 Feb 2002 07:28:43 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <1014802820.9860.10.camel@gaspode.localnet> Message-ID: On 2/27/02 1:40 AM, "Nigel Metheringham" wrote: > On Tue, 2002-02-26 at 19:43, Barry A. Warsaw wrote: > >> I'm willing to change the default roster view to list-members-only. > > For those within the EU*, the only correct setting is for the list admin > only to be able to see the roster. Oh, good point. I'd forgotten that. > * ie those with EU data protection legislation affecting them. FWIW, at Apple, our corporate policy is to manage to the EU standards globally, because of the nature of the internet. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From jra@baylink.com Wed Feb 27 17:48:18 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 12:48:18 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <20020227010741.GJ5066@merlins.org>; from Marc MERLIN on Tue, Feb 26, 2002 at 05:07:41PM -0800 References: <15483.9117.172305.565827@anthem.wooz.org> <15484.10996.354231.393205@anthem.wooz.org> <20020227005026.GH5066@merlins.org> <15484.12370.505278.852077@anthem.wooz.org> <20020227010741.GJ5066@merlins.org> Message-ID: <20020227124818.52026@scfn.thpl.lib.fl.us> On Tue, Feb 26, 2002 at 05:07:41PM -0800, Marc MERLIN wrote: > Not that it is a big deal to me, but out of curiosity: what part of mailman > cares that it's a list and not a mail alias? The *user*, when the list machinery breaks completely, and there's no obvious target address to complain to. Cheers, -- jra -- Jay R. Ashworth jra@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") From Dan Mick Wed Feb 27 18:42:36 2002 From: Dan Mick (Dan Mick) Date: Wed, 27 Feb 2002 10:42:36 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters Message-ID: <200202271843.g1RIhQcW015040@utopia.West.Sun.COM> > On Tue, Feb 26, 2002 at 05:07:41PM -0800, Marc MERLIN wrote: > > Not that it is a big deal to me, but out of curiosity: what part of mailman > > cares that it's a list and not a mail alias? > > The *user*, when the list machinery breaks completely, and there's no > obvious target address to complain to. While this might be a good point, it's wrong and unhelpful to Marc's question. IIRC, Marc, there's a bunch of stuff that does things like "get the Owner address for the list named mm_cfg.". Not that that couldn't be found and changed, but...that's how it works currently. Also, that way bounce handling happens for those sorts of notification messages in the "normal" way. From Dan Mick Wed Feb 27 18:55:17 2002 From: Dan Mick (Dan Mick) Date: Wed, 27 Feb 2002 10:55:17 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters Message-ID: <200202271856.g1RIu7cW016023@utopia.West.Sun.COM> > > > Not that it is a big deal to me, but out of curiosity: what part of mailman > > > cares that it's a list and not a mail alias? > > > > The *user*, when the list machinery breaks completely, and there's no > > obvious target address to complain to. > > While this might be a good point, it's wrong and unhelpful to Marc's > question. "wrong" was misstated; what I meant to say was "the user is not part of Mailman". From jwblist@olympus.net Wed Feb 27 19:43:26 2002 From: jwblist@olympus.net (John W Baxter) Date: Wed, 27 Feb 2002 11:43:26 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <200202271856.g1RIu7cW016023@utopia.West.Sun.COM> References: <200202271856.g1RIu7cW016023@utopia.West.Sun.COM> Message-ID: At 10:55 -0800 2/27/2002, Dan Mick wrote: >"wrong" was misstated; what I meant to say was "the user is not >part of Mailman". But the user is part of the mailing list system. Usually the most troublesome part. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From Dan Mick Wed Feb 27 19:47:35 2002 From: Dan Mick (Dan Mick) Date: Wed, 27 Feb 2002 11:47:35 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters Message-ID: <200202271948.g1RJmPcW019136@utopia.West.Sun.COM> > At 10:55 -0800 2/27/2002, Dan Mick wrote: > >"wrong" was misstated; what I meant to say was "the user is not > >part of Mailman". > > But the user is part of the mailing list system. Usually the most > troublesome part. That's as may be, but Marc asked a specific question that had nothing at all to do with the user part of the holistic system. The weather is part of everything, but discussing it doesn't really solve specific software problems. From jra@baylink.com Wed Feb 27 19:49:32 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 14:49:32 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <200202271843.g1RIhQcW015040@utopia.West.Sun.COM>; from Dan Mick on Wed, Feb 27, 2002 at 10:42:36AM -0800 References: <200202271843.g1RIhQcW015040@utopia.West.Sun.COM> Message-ID: <20020227144932.13381@scfn.thpl.lib.fl.us> On Wed, Feb 27, 2002 at 10:42:36AM -0800, Dan Mick wrote: > > On Tue, Feb 26, 2002 at 05:07:41PM -0800, Marc MERLIN wrote: > > > Not that it is a big deal to me, but out of curiosity: what part > > > of mailman cares that it's a list and not a mail alias? > > > > The *user*, when the list machinery breaks completely, and there's > > no obvious target address to complain to. > > While this might be a good point, it's wrong and unhelpful to Marc's > question. Well, either I have misunderstood Barry these last 48 hours, or you have. We're talking about the *server* admin address. > IIRC, Marc, there's a bunch of stuff that does things like "get > the Owner address for the list named mm_cfg.". Not > that that couldn't be found and changed, but...that's how it works > currently. Also, that way bounce handling happens for those sorts of > notification messages in the "normal" way. Yup, we're talking about different things. Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 27 20:06:39 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 15:06:39 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <200202271856.g1RIu7cW016023@utopia.West.Sun.COM>; from Dan Mick on Wed, Feb 27, 2002 at 10:55:17AM -0800 References: <200202271856.g1RIu7cW016023@utopia.West.Sun.COM> Message-ID: <20020227150639.14871@scfn.thpl.lib.fl.us> On Wed, Feb 27, 2002 at 10:55:17AM -0800, Dan Mick wrote: > > > > Not that it is a big deal to me, but out of curiosity: what part of > > > > mailman > > > > cares that it's a list and not a mail alias? > > > > > > The *user*, when the list machinery breaks completely, and there's no > > > obvious target address to complain to. > > > > While this might be a good point, it's wrong and unhelpful to Marc's > > question. > > "wrong" was misstated; what I meant to say was "the user is not > part of Mailman". I guess we'll have to agree to disagree, here. The user is the most important part of any system (or we wouldn't go so far out of our way to coddle them), and they are the only part affected by this. Does the fact that you don't consider the user "part of mailman" mean that you don't think it's important that they have a way to contact the server admin when everything breaks? Cheers, -- jra -- Jay R. Ashworth jra@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") From jra@baylink.com Wed Feb 27 20:07:35 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 15:07:35 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <200202271948.g1RJmPcW019136@utopia.West.Sun.COM>; from Dan Mick on Wed, Feb 27, 2002 at 11:47:35AM -0800 References: <200202271948.g1RJmPcW019136@utopia.West.Sun.COM> Message-ID: <20020227150735.26179@scfn.thpl.lib.fl.us> On Wed, Feb 27, 2002 at 11:47:35AM -0800, Dan Mick wrote: > > At 10:55 -0800 2/27/2002, Dan Mick wrote: > > >"wrong" was misstated; what I meant to say was "the user is not > > >part of Mailman". > > > > But the user is part of the mailing list system. Usually the most > > troublesome part. > > That's as may be, but Marc asked a specific question that had > nothing at all to do with the user part of the holistic system. > > The weather is part of everything, but discussing it doesn't really > solve specific software problems. Aw, c'mon; this is horseshit, y'all. If you're planning an outdoor event, I assure you, the weather is the *top* thing on your mind*. Cheers, -- jra -- Jay R. Ashworth jra@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") From chuqui@plaidworks.com Wed Feb 27 20:12:34 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 27 Feb 2002 12:12:34 -0800 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <200202271948.g1RJmPcW019136@utopia.West.Sun.COM> Message-ID: On 2/27/02 11:47 AM, "Dan Mick" wrote: > The weather is part of everything, but discussing it doesn't really > solve specific software problems. Can someone please make an oblique nazi referenc,e so I can declare Godwin's law and we move on? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From jra@baylink.com Wed Feb 27 20:17:58 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 27 Feb 2002 15:17:58 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: ; from Chuq Von Rospach on Wed, Feb 27, 2002 at 12:12:34PM -0800 References: <200202271948.g1RJmPcW019136@utopia.West.Sun.COM> Message-ID: <20020227151758.37363@scfn.thpl.lib.fl.us> On Wed, Feb 27, 2002 at 12:12:34PM -0800, Chuq Von Rospach wrote: > On 2/27/02 11:47 AM, "Dan Mick" wrote: > > The weather is part of everything, but discussing it doesn't really > > solve specific software problems. > > Can someone please make an oblique nazi referenc,e so I can declare Godwin's > law and we move on? Nope, sorry, the war march drawing in the Tufte book is the wrong war. Cheers, -- jra -- Jay R. Ashworth jra@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") From Dan Mick Wed Feb 27 20:24:26 2002 From: Dan Mick (Dan Mick) Date: Wed, 27 Feb 2002 12:24:26 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters Message-ID: <200202272025.g1RKPGcW021330@utopia.West.Sun.COM> > On Wed, Feb 27, 2002 at 10:42:36AM -0800, Dan Mick wrote: > > > On Tue, Feb 26, 2002 at 05:07:41PM -0800, Marc MERLIN wrote: > > > > Not that it is a big deal to me, but out of curiosity: what part > > > > of mailman cares that it's a list and not a mail alias? > > > > > > The *user*, when the list machinery breaks completely, and there's > > > no obvious target address to complain to. > > > > While this might be a good point, it's wrong and unhelpful to Marc's > > question. > > Well, either I have misunderstood Barry these last 48 hours, or you > have. We're talking about the *server* admin address. Right. And currently that admin address is "mailman-admin" or "mailman-owner", and both are tied to a list. Marc asked what about the Mailman **SOFTWARE** cares that it's a list. I answered him, correctly. > > IIRC, Marc, there's a bunch of stuff that does things like "get > > the Owner address for the list named mm_cfg.". Not > > that that couldn't be found and changed, but...that's how it works > > currently. Also, that way bounce handling happens for those sorts of > > notification messages in the "normal" way. > > Yup, we're talking about different things. Only when you bring up the user, which has no bearing on the question *at all*. From Dan Mick Wed Feb 27 20:25:13 2002 From: Dan Mick (Dan Mick) Date: Wed, 27 Feb 2002 12:25:13 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters Message-ID: <200202272026.g1RKQ3cW021343@utopia.West.Sun.COM> > I guess we'll have to agree to disagree, here. The user is the most > important part of any system (or we wouldn't go so far out of our way > to coddle them), and they are the only part affected by this. > > Does the fact that you don't consider the user "part of mailman" mean > that you don't think it's important that they have a way to contact the > server admin when everything breaks? Oh, get off your hobby horse. My comments were completely limited to Marc's specific question. I'm not interested in the other head-of-a-pin conversations you're having, and god be with you on those. From marc_news@vasoftware.com Wed Feb 27 21:36:50 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Wed, 27 Feb 2002 13:36:50 -0800 Subject: [Mailman-Developers] Error: Invalid value '' for variable: accept_these_nonmembers Message-ID: <20020227213649.GQ5066@merlins.org> This is in mailman CVS I've changed GUI/GUIBase.py with the hopes to output a better error: try: val = self._getValidValue(mlist, property, wtype, val) except ValueError: doc.addError(_("Invalid value '"+val+"' for variable: %(property)s"), tag=_('Error: ')) I get the error (without my patch too obviously) only one install. I can't seem to reproduce it on the list install I have on my laptop. Any ideas what's going on? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jmeurer@gmx.de Thu Feb 28 00:07:04 2002 From: jmeurer@gmx.de (Jonas Meurer) Date: Thu, 28 Feb 2002 01:07:04 +0100 Subject: [Mailman-Developers] wildcards in poster-without-approval Message-ID: <20020228000703.GA9317@jonas.server0.de> Hello, Is it possible to set wildcards in the field 'Addresses of members accepted for postings to this list without implicit approval requirement' in Privacy Options? That every addr from domain xyz.com is allowed to post without approval requirement. If yes, how? *@xyz.com or xyz.com or .*@xyz.com Thanks Jonas -- We'll try to make different mistakes this time -- Larry Wall From barry@zope.com Thu Feb 28 01:15:03 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 20:15:03 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.9117.172305.565827@anthem.wooz.org> <15484.10996.354231.393205@anthem.wooz.org> <20020227005026.GH5066@merlins.org> <15484.12370.505278.852077@anthem.wooz.org> <20020227010741.GJ5066@merlins.org> Message-ID: <15485.33943.69624.78456@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> Not that it is a big deal to me, but out of curiosity: what MM> part of mailman cares that it's a list and not a mail alias? MM> Does mailman act on the bounces sent back to the envelope from MM> when it sends password reminders? Yup, and it'll try to register the bounce for every list at the site, if the bounce comes back to the site list. -Barry From barry@zope.com Thu Feb 28 01:16:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 20:16:19 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <200202271843.g1RIhQcW015040@utopia.West.Sun.COM> <20020227144932.13381@scfn.thpl.lib.fl.us> Message-ID: <15485.34019.143502.346792@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> Not that it is a big deal to me, but out of curiosity: what >> part of mailman cares that it's a list and not a mail alias? >> The *user*, when the list machinery breaks completely, and >> there's no obvious target address to complain to. >> While this might be a good point, it's wrong and unhelpful to >> Marc's question. JRA> Well, either I have misunderstood Barry these last 48 hours, JRA> or you have. We're talking about the *server* admin address. Now I think I'm confused. What actually is being asked? -Barry From barry@zope.com Thu Feb 28 01:25:16 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 20:25:16 -0500 Subject: [Mailman-Developers] Protecting email addresses from spam harvesters References: <15483.9816.517954.815712@anthem.wooz.org> <15483.58709.756971.33324@anthem.wooz.org> <1014802820.9860.10.camel@gaspode.localnet> Message-ID: <15485.34556.229284.889442@anthem.wooz.org> >>>>> "NM" == Nigel Metheringham >>>>> writes: NM> * ie those with EU data protection legislation affecting them. NM> I have a vague idea that there are EU attempts to make this NM> legislation stick worldwide where EU citizens are involved, NM> and US attempt to be able to rape the data whoever its on. Lovely. There's probably some stupid-ass DMCA, SSSCA, or other idiocy that'll get passed in the US that will prohibit you from disabling the roster because then you'll be circumventing some digital security device. Then we're in a catch-22 where Mailman will only be legal in Togo, but only there until the Dizz Knee Police need a boondoggle enforcement expedition. can-i-be-a-rock-star-yet?-ly y'rs, -Barry From Dan Mick Thu Feb 28 01:26:25 2002 From: Dan Mick (Dan Mick) Date: Wed, 27 Feb 2002 17:26:25 -0800 (PST) Subject: [Mailman-Developers] Bug in current authentication Message-ID: <200202280127.g1S1RHcW013303@utopia.West.Sun.COM> A non-member can visit the listinfo page, enter an email address, and get sent to a "member options" page...but there are no options, really, for him to deal with. He can also hit the "Password reminder" button once he gets there, and get a response that a password is being mailed...but of course that can't happen, since he's not a member. options.py has this code: # Sanity check the user, but be careful about leaking membership # information when we're using private rosters. if not mlist.isMember(user) and mlist.private_roster == 0: # Avoid cross-site scripting attacks safeuser = cgi.escape(user) add_error_message(doc, _('No such member: %(safeuser)s.')) loginpage(mlist, doc, None, cgidata) print doc.Format() return but that misses the case of if not mlist.isMember(user) and mlist.private_roster == 1: which is my case. Why is that second check there? From barry@wooz.org Thu Feb 28 02:35:47 2002 From: barry@wooz.org (Barry A. Warsaw) Date: Wed, 27 Feb 2002 21:35:47 -0500 Subject: [Mailman-Developers] Re: Bug in current authentication References: <200202280127.g1S1RHcW013303@utopia.West.Sun.COM> Message-ID: <15485.38787.494274.775548@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> but that misses the case of DM> if not mlist.isMember(user) and mlist.private_roster == 1: DM> which is my case. Why is that second check there? To avoid leaking member information when the roster is private. The intent is that when rosters are private, you don't want a "no such member" error message when a non-member address is entered (because the lack of such a message reveals positive hits when you've actually entered a member address). The bug is that when rosters are public, and you've entered a non-member address, you should not see the unsubscribe or remind buttons. I'll fix that. -Barry From jlord@infomg.com Wed Feb 27 14:49:31 2002 From: jlord@infomg.com (Joel Lord) Date: Wed, 27 Feb 2002 09:49:31 -0500 Subject: [Mailman-Developers] Can't approve/discard/reject subscriptions in 2.1a4 References: Message-ID: <3C7CF1FB.943CE878@infomg.com> My experience is that this is more than just subscribtion requests - any moderator request at all will maintain like this. I now have three domains worth of the daily nags hitting me - two of them were subscription requests, two moderated posts (the posts went through, but the daily nag doesn't get cleared). I posted a bug report on sourceforge for this one... Brett Delmage wrote: > > Problem: I can't clear pending subscription requests by processing them. > I applied the patch to 2.1a4 below but it doesn't work for me. > > The steps to duplicate the problem are listed below and are very simple. > > I created a new list. > > I subscribed to the list using email, not the web form, using the list > defaults. The subscription was activated without incident. > > Using Konquerer (2.2.1) as my browser, I modified the subcribe_policy to > "Require approval" then subscribed to it using a different email address. > > I received the "Your subscription request has been forwarded to the list > administrator" message as expected, as well as the list-owner > notification. > > I went to the Administrative requests for mailing list: form > and confirmed that the pending subscribe request was shown. > > I selected the Discard radio button end entered a reason, then the submit > button. > > I confirmed that the rejection notice was mailed to the subscriber. > > However the subscriber was still shown as a subscription request. > > I tried resubmitting the form with the Approve radio button selected. The > subscriber was sent a welcome message, but still appeared on the form as a > pending subscription request. > > I selected the Reject radio button end entered a reason, then the submit > button. The subscriber (supposedly already subscribed!) was mailed a > rejection notice. And still appeared on the form as a pending request. > Some users just won't go away ;-) > > If left in this state, the daily oustanding moderations nag is mailed to > the list owner. > > I've looked at the code but am just learning python (part of my reason for > using mailman, I figured it was a great 'real world' project to help me > learn python.) But I couldn't see the problem. Maybe in a month or two... > > I hope the steps to reproduce the problem are helpful. Really, you can't > help but encounter it. > > Thanks to all those working on Mailman. It's a really impressive list > manager despite this bug, which doesn't affect the actual list operation > in any way. > -- Joel Lord Systems Architect Information Management Group From barry@zope.com Thu Feb 28 04:00:54 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 23:00:54 -0500 Subject: [Mailman-Developers] Error: Invalid value '' for variable: accept_these_nonmembers References: <20020227213649.GQ5066@merlins.org> Message-ID: <15485.43894.935399.774981@anthem.wooz.org> >>>>> "MM" == Marc MERLIN writes: MM> This is in mailman CVS MM> I've changed GUI/GUIBase.py with the hopes to output a better MM> error: try: val = self._getValidValue(mlist, property, wtype, MM> val) except ValueError: doc.addError(_("Invalid value MM> '"+val+"' for variable: %(property)s"), tag=_('Error: ')) MM> I get the error (without my patch too obviously) only one MM> install. I can't seem to reproduce it on the list install I MM> have on my laptop. MM> Any ideas what's going on? Yup, it's a bug. Fixed in CVS. -Barry From barry@zope.com Thu Feb 28 04:02:18 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 23:02:18 -0500 Subject: [Mailman-Developers] wildcards in poster-without-approval References: <20020228000703.GA9317@jonas.server0.de> Message-ID: <15485.43978.621556.875458@anthem.wooz.org> >>>>> "JM" == Jonas Meurer writes: JM> Is it possible to set wildcards in the field 'Addresses of JM> members accepted for postings to this list without implicit JM> approval requirement' in Privacy Options? That every addr JM> from domain xyz.com is allowed to post without approval JM> requirement. If yes, how? *@xyz.com or xyz.com or .*@xyz.com Not in MM2.0.x. That specific field is gone in MM2.1, but in the equivalent ones you will be able to specify Python regular expressions. -Barry From barry@zope.com Thu Feb 28 04:12:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 23:12:27 -0500 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! References: <15465.40265.533837.712733@anthem.wooz.org> <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> <20020226132634.43759@scfn.thpl.lib.fl.us> <20020226210406.GE60@dust.uchicago.edu> <20020227101150.05657@scfn.thpl.lib.fl.us> Message-ID: <15485.44587.21445.344151@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> I can't imagine that hooking the Mailman auth code could be JRA> *that* difficult... It's not, if you can hack a little Python. Here's a bit of untested code to get you started. Note: you must have the Mailman package's parent directory on your PYTHONPATH (aka sys.path). -Barry -------------------- snip snip -------------------- from Mailman import Errors from Mailman.MailList import MailList def authenticate(listname, address, response): """Return true if the response authenticates the address as a member of the named mailing list (i.e. response == the correct password). """ # Might raise MMListError if listname doesn't exist mlist = MailList(listname, lock=0) # Might raise NotAMember if address isn't a member secret = mlist.authenticateMember(address, response) if secret: return 1 return 0 From barry@zope.com Thu Feb 28 04:19:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 23:19:31 -0500 Subject: [Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest! References: <15475.6381.891758.575462@geddy.wooz.org> <15483.10333.392460.569578@anthem.wooz.org> <20020226121728.49429@scfn.thpl.lib.fl.us> <20020226172611.GB60@dust.uchicago.edu> <20020226132634.43759@scfn.thpl.lib.fl.us> <20020226210406.GE60@dust.uchicago.edu> <87sn7npty8.fsf@tleepslib.sk.tsukuba.ac.jp> <20020227025738.GL60@dust.uchicago.edu> <20020227101406.49341@scfn.thpl.lib.fl.us> Message-ID: <15485.45011.838861.869101@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Pipermail is *not*, so far as I've been able to tell, "an JRA> integrated part of Mailman". JRA> Is it, Barry? For the purposes of David's assertion above, I JRA> mean. The way I see it, Pipermail is bundled and integrated (in the sense that you have to do no extra work to hook the two together), but it is by no means integral. I sketched out a function in a previous email for how you would hook into Mailman's member authentication mechanism (MM2.1 of course). If you don't want to glue things together with Python, simply turn that function into a command line script with a couple of extra lines of code. -Barry From barry@zope.com Thu Feb 28 04:22:34 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 23:22:34 -0500 Subject: [Zest-devel] Re: [Mailman-Developers] Pipermail replacement? Zest! References: <20020226121728.49429@scfn.thpl.lib.fl.us> <15483.55742.667977.241043@anthem.wooz.org> <20020227100025.01308@scfn.thpl.lib.fl.us> Message-ID: <15485.45194.276850.512905@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Gee, that sounds familiar. JRA> I guess I'm not the only one who thinks it's a good idea, eh JRA> what? :-) Except that I'm the first to admit that my user base is, er, unique. Everything we do is aimed at geeks looking for technical information. And besides, we can't index the archives any more. We exhausted the indexing limit on our donated server, so we just let Google do it now. -Barry From barry@zope.com Thu Feb 28 04:30:47 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 27 Feb 2002 23:30:47 -0500 Subject: [Mailman-Developers] Error: Invalid value for variable: ban_list References: <878z9f4g1w.fsf@nausicaa.interq.or.jp> Message-ID: <15485.45687.801235.802514@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> Using Mailman CVS, I get the following error whenever trying BG> to change any privacy options for a newly-created list via BG> the admin interface: BG> Error: Invalid value for variable: ban_list BG> But I don't have anything in my ban_list, it's completely BG> empty. BG> If I put a value into the ban_list (foo@bar.com) then I can BG> set my preferences correctly. I think this one is the same as the bug Marc reported. Should be fixed now in CVS. -Barry From barry@zope.com Thu Feb 28 05:13:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 28 Feb 2002 00:13:11 -0500 Subject: [Mailman-Developers] Bug in Bouncer.py (was: At least some of my problems...) References: <200202270414.g1R4EocW023249@utopia.West.Sun.COM> Message-ID: <15485.48231.366912.800800@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Or not. That was the proverbial pickled scarlet fish. DM> Here's a fix to Bouncer.py. I'm divided about the wisdom of DM> including some keywords and not all. I suppose I should at DM> least be consistent, but I know Barry will fix it right DM> anyway. I just did an audit of all the calls on the UserNotification() constructor. I noticed there were quite a few that weren't being passed the language keyword. I'm going to attempt to fix (and test ;) them all, but would appreciate Ben especially giving the checkins a once over. As for consistency, hobgoblins, shmobgoblins. -Barry From cheesefactory@yahoo.com Thu Feb 28 07:52:59 2002 From: cheesefactory@yahoo.com (Paul Schreiber) Date: Wed, 27 Feb 2002 23:52:59 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <15484.11049.568205.119009@anthem.wooz.org> Message-ID: <20020228075259.70301.qmail@web14806.mail.yahoo.com> --- "Barry A. Warsaw" wrote: > > >>>>> "PS" == Paul Schreiber writes: > > PS> While I'm on the topic.... > PS> > http://www.apple.com/downloads/macosx/system_disk_utilities/spamstopper.html > > PS> That utility translates all the characters in an email address > PS> to character entities, something spambots aren't likely to > PS> pick up on. for now, anyway. > > PS> i.e. mailman could incorporate something like this. > > Interesting, except that I suspect the mailto: is a dead giveaway. > Seems like something the harvesters could easily adjust for and > detect, so I don't see the value in spending time implementing it. Yes,, but you can encode the "mailto:" as well, like so: me I would guess most spambots are pretty dumb, probably using a silly regex like . Paul __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com From cheesefactory@yahoo.com Thu Feb 28 08:02:12 2002 From: cheesefactory@yahoo.com (Paul Schreiber) Date: Thu, 28 Feb 2002 00:02:12 -0800 (PST) Subject: [Mailman-Developers] Protecting email addresses from spam harvesters In-Reply-To: <20020228075259.70301.qmail@web14806.mail.yahoo.com> Message-ID: <20020228080212.45438.qmail@web14805.mail.yahoo.com> --- Paul Schreiber wrote: > Yes,, but you can encode the "mailto:" as well, like so: > me > > I would guess most spambots are pretty dumb, probably using a silly regex > like . Be careful if you read my last message via a web browser; it may have shown up as a plain text mailto instead of being encoded as entities. here, i've purposely broken the entities by adding spaces: me Paul __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com From Kirez Korgan" greetings, My mailman archives are configged, by default, in chronological order. I need to change them to reverse chronological order. I've gone through many of the source files, all the documentation, and I've inquired a few times on the mailman-users list (one respondent, who has been very helpful and knowledgeable, said his 2.0.8 archives were by default in reverse-chronological order). Nobody can point me to where I can change this setting. I was surprised that there was no toggle switch in the admindb to switch between chrono- or reverse-chronological order for the archives. Could somebody please help me with this? To clarify: I need my archives arranged so that the newest (most recent) messages are accumulating at the top of the archive page, not at the bottom; this is what I mean by reverse-chronological order. Many thanks! Kirez From jmeurer@gmx.de Thu Feb 28 11:47:45 2002 From: jmeurer@gmx.de (Jonas Meurer) Date: Thu, 28 Feb 2002 12:47:45 +0100 Subject: [Mailman-Developers] wildcards in poster-without-approval In-Reply-To: <15485.43978.621556.875458@anthem.wooz.org> References: <20020228000703.GA9317@jonas.server0.de> <15485.43978.621556.875458@anthem.wooz.org> Message-ID: <20020228114745.GA1204@jonas.server0.de> On Wed, Feb 27, 2002 at 11:02:18PM -0500, Barry A. Warsaw wrote: > >>>>> "JM" == Jonas Meurer writes: > JM> Is it possible to set wildcards in the field 'Addresses of > JM> members accepted for postings to this list without implicit > JM> approval requirement' in Privacy Options? That every addr > JM> from domain xyz.com is allowed to post without approval > JM> requirement. If yes, how? *@xyz.com or xyz.com or .*@xyz.com > > Not in MM2.0.x. That specific field is gone in MM2.1, but in the > equivalent ones you will be able to specify Python regular > expressions. Mh, but I need it ;( Can I just fix the code of 2.0.8? A diff-file would be fine. Or just: What files would I have to modify? Could you post the code I have to delete and I have to add? Thanks Jonas -- Calculating in binary code is as easy as 01,10,11. From marc_news@vasoftware.com Thu Feb 28 21:26:44 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 28 Feb 2002 13:26:44 -0800 Subject: [Mailman-Developers] wildcards in poster-without-approval In-Reply-To: <20020228114745.GA1204@jonas.server0.de> References: <20020228000703.GA9317@jonas.server0.de> <15485.43978.621556.875458@anthem.wooz.org> <20020228114745.GA1204@jonas.server0.de> Message-ID: <20020228212643.GS5066@merlins.org> On Thu, Feb 28, 2002 at 12:47:45PM +0100, Jonas Meurer wrote: > > JM> Is it possible to set wildcards in the field 'Addresses of > > JM> members accepted for postings to this list without implicit > > JM> approval requirement' in Privacy Options? That every addr > > JM> from domain xyz.com is allowed to post without approval > > JM> requirement. If yes, how? *@xyz.com or xyz.com or .*@xyz.com > > > > Not in MM2.0.x. That specific field is gone in MM2.1, but in the > > equivalent ones you will be able to specify Python regular > > expressions. > > Mh, but I need it ;( Can I just fix the code of 2.0.8? That's why it's in 2.1. If you want the feature, you can try to backport it, or just upgrade. Quite frankly, mm 2.1a4+ (cvs) is quite useable already. > A diff-file would be fine. Or just: What files would I have to modify? > Could you post the code I have to delete and I have to add? I'd rather Barry concentrate his time on 2.1. Feel free to upgrade and help us find any remaining problems if there are any. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From chuqui@plaidworks.com Thu Feb 28 21:50:16 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 28 Feb 2002 13:50:16 -0800 Subject: [Mailman-Developers] wildcards in poster-without-approval In-Reply-To: <20020228212643.GS5066@merlins.org> Message-ID: On 2/28/02 1:26 PM, "Marc MERLIN" wrote: > I'd rather Barry concentrate his time on 2.1. Feel free to upgrade and help > us find any remaining problems if there are any. Agreed. Features go into new releases. They have to be very persuasively important to the universe to sidetrack 2.1 development. Security flaws? Patch. Serious bugs? Probably patch. New features? That's why we have new releases... With 2.1 well down the road, stopping and doing 2.0.9 is the wrong decision. All IMHO, of course. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From marc_news@vasoftware.com Thu Feb 28 22:02:54 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu, 28 Feb 2002 14:02:54 -0800 Subject: [Mailman-Developers] Error: Invalid value '' for variable: accept_these_nonmembers In-Reply-To: <15485.43894.935399.774981@anthem.wooz.org> References: <20020227213649.GQ5066@merlins.org> <15485.43894.935399.774981@anthem.wooz.org> Message-ID: <20020228220254.GU5066@merlins.org> On Wed, Feb 27, 2002 at 11:00:54PM -0500, Barry A. Warsaw wrote: > MM> I've changed GUI/GUIBase.py with the hopes to output a better > MM> error: try: val = self._getValidValue(mlist, property, wtype, > MM> val) except ValueError: doc.addError(_("Invalid value > MM> '"+val+"' for variable: %(property)s"), tag=_('Error: ')) > > MM> Any ideas what's going on? > > Yup, it's a bug. Fixed in CVS. Sure enough, works much better now :-) In the meantime, I have more info on auto discard and auto reject auto discard / don't mail admin => works auto discard / mail admin => doesn't work reject / mail admin => doesn't work reject / don't mail admin => doesn't work Basically, anything that triggers an Email, bombs with: ==> ../logs/error <== Feb 28 13:40:21 2002 (18025) Uncaught runner exception: get_type Feb 28 13:40:21 2002 (18025) Traceback (most recent call last): File "/var/local/mailman/Mailman/Queue/Runner.py", line 114, in __oneloop self.__onefile(msg, msgdata) File "/var/local/mailman/Mailman/Queue/Runner.py", line 162, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Queue/OutgoingRunner.py", line 59, in _dispose func(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Handlers/SMTPDirect.py", line 79, in process msgtext = msg.as_string(unixfrom=0) File "/var/local/mailman/pythonlib/email/Message.py", line 85, in as_string g(self, unixfrom=unixfrom) File "/var/local/mailman/pythonlib/email/Generator.py", line 83, in __call__ self._write(msg) File "/var/local/mailman/pythonlib/email/Generator.py", line 104, in _write self._dispatch(msg) File "/var/local/mailman/pythonlib/email/Generator.py", line 134, in _dispatch meth(msg) File "/var/local/mailman/pythonlib/email/Generator.py", line 246, in _handle_multipart g(part, unixfrom=0) File "/var/local/mailman/pythonlib/email/Generator.py", line 83, in __call__ self._write(msg) File "/var/local/mailman/pythonlib/email/Generator.py", line 104, in _write self._dispatch(msg) File "/var/local/mailman/pythonlib/email/Generator.py", line 121, in _dispatch ctype = msg.get_type() AttributeError: get_type Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From marc_news@vasoftware.com Thu Feb 28 17:35:02 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Thu Feb 28 17:35:01 2002 Subject: [Mailman-Developers] problem with VERP stuffing all the messages in one connection I was hoping to have a crack at a patch today, but I've been too busy converting my whole exim configs to exim 4. When VERP is enabled, mailman apparently sends all the Emails over one SMTP connection. When exim receives more than smtp_accept_queue_per_connection messages in one connection, it spools everything without trying to resend it. That's actually very bad, because list messages then get delayed by 30mn or more (waiting on a queue runner to pick them up, one per one, and you can imagine that it's a lot of queue entries to clean up (# of subscribers x # of messages sent in the last 30mn) I've currently set that to 1000 on one of my test servers, but that's not very scalable. Mailman needs a MAX_RCPT_PER_SMTP setting and close the SMTP connection after sending that many messages, and open up a new one. Or did I miss something obvious? Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key