Mailman 3 November 2003 - Mailman-Developers

Re: [Mailman-Developers] bugtraq submission warning: email address harvesting exploit
by J C Lawrence 29 Nov '03

29 Nov '03

On Fri, 28 Nov 2003 16:32:09 +0000 Richard Barrett <r.barrett(a)openinfo.co.uk> wrote: > Prompted by this thread and taking on board some of the ideas > expressed in the discussion I have posted the following patch for MM > 2.1.3 on sourceforge: > [ 850805 ] Aggressive anti email address harvesting measure This patch appears to fail to distinguish between email addresses and Message IDs. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

2 1

AW: [Mailman-Developers] Secure Mailing Lists
by Dietmar Maurer 28 Nov '03

28 Nov '03

>> >> Actually, you can encrypt the message once, to each of the keys >> >> of each of the people on the list. You don't have to do multiple >> >> encryptions. That would save a hell of a lot of >processing overhead. Another problem I see is that PGP/MIME format. If I implement such secure lists I need to decode mails in that format. Is that staright forward or a complex task? Are there tools/libraries available? - Dietmar

2 1

Re: [Mailman-Developers] bugtraq submission warning: email address harvesting exploit
by Richard Barrett 28 Nov '03

28 Nov '03

Prompted by this thread and taking on board some of the ideas expressed in the discussion I have posted the following patch for MM 2.1.3 on sourceforge: [ 850805 ] Aggressive anti email address harvesting measure https://sourceforge.net/tracker/? func=detail&aid=850805&group_id=103&atid=300103 Basics of the patch are: For those with deep concerns about email address harvesting this patch offers a more aggressive masking of email addresses in Mailman mail archive files. The patch modifes two files in the standard Mailman distribution: Mailman/Defaults.py and Mailman/Cgi/private.py and can be applied using the following command from within the Mailman build directory: path -p1 < path-to-patch-file It would be fairly trivial to make enabling this feature per-list configurable rather than it being a site admin decision and I will enhance this patch for that purpose if people show an interest in it being done. The following notes about the patch can be found in Defaults.py. Rather idiosyncratically most of the operational elements of this patch are in that file. My reasoning behind this decision is that if people want to fool with the regexes that are at the heart of this patch they can see what will be affected by the changes more readily if the related bits are in the same place. ##### # Anti-spam email address harvesting prevention measures. # # These measures are to limit the ability of spam generators to acquire # email address from archived material in Mailman's list archives. # Implementation is via a dynamic search and replace for email # addresses, appearing in files of MIME type text/html or text/plain, as # those files are requested. The underlying archive file content as # generated by the archiving software remains unchanged. # # The implementation requires that archive files are all delivered by a # modified private.py CGI script which only requires user authentication # if the list whose archive material is being requested is set up as a private # list. In order to get public archives served by private.py a RewriteRule # like this: # # RewriteRule ^/pipermail/(.*) /mailman/private/$1 [PT] # # needs to be used in the Apache httpd.conf to transparently redirect # public archive file requests. # # When email addresses are found, the domain part of the addressed is replaced # with a string of 'x' characters. If the local part of the address appears to # have been VERP'ed then the VERP information is similarly obscured. This is # a fairly brutal set of irreversible modifications to any email addresses in # the returned text and will break any mailto: links in the text. # # Th eamil address regex looks for either an '@' character or its HTML escaped # version '%40' as the local-part/domain separator. You should set # ARCHIVER_OBSCURES_EMAILADDRS = 0 and run bin/arch to rebuild existing archives # to prevent that feature interfering with the operation of these harvesting # prevention measures. # # If you decide to change the regexes then copy all of this stuff into # mm_cfg.py and make the changes there. # ##### Any thoughts or comments, let me know. ----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk

1 0

AW: [Mailman-Developers] Secure Mailing Lists
by Dietmar Maurer 28 Nov '03

28 Nov '03

>On Thu, 2003-11-27 at 17:07, Brad Knowles wrote: >> At 1:12 PM -0500 2003/11/27, Barry Warsaw wrote: >> >> > - Obviously you're going to do personalized deliveries, >so for any such >> > list you'll probably want to disable digests. >> >> Actually, you can encrypt the message once, to each of the keys >> of each of the people on the list. You don't have to do multiple >> encryptions. That would save a hell of a lot of processing overhead. >> >> You could easily handle a digest the same way. Sorry, I dont underdstand that suggestion. You want to put several encrypted messages into one mail? (I dont know much about public key systems). That would increase the size of the message? Or is it possible to encrypt a message once so that several people can decrypt it? - Dietmar

3 2

Secure Mailing Lists
by Dietmar Maurer 27 Nov '03

27 Nov '03

Hi all, we are looking for a solution to implement secure mailing lists. We need the following behaviour: 1.) A secure mailing list has an assiciated PGP Key. 2.) postings to the list are encrypted with the public key of the list. 3.) The list server decrypts the message, and then, for each list member, encrypts the message with the public key of the list member and sends that mail. That way the whole traffic is encrypted. Does somebody know a solution for that problem? Is there already such extension for mailman? If not, how long would it take to implement such thing? - Dietmar --------------------------------------------------- Dietmar Maurer Maurer IT Systemlösungen KEG Technischer Leiter Kohlgasse 51/9 Tel: +43 1 545 449 712 A - 1050 WIEN Fax: +43 1 545 449 722 Mobil: +43 699 105 88 032 dietmar(a)maurer-it.com http://www.maurer-it.com ---------------------------------------------------

3 3

Re: [Mailman-Developers] bugtraq submission warning: email address harvesting exploit
by J C Lawrence 27 Nov '03

27 Nov '03

On Thu, 27 Nov 2003 09:17:33 -0800 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > On Nov 27, 2003, at 9:08 AM, Terri Oda wrote: >> On Tue, Nov 25, 2003 at 11:07:39AM -0800, Chuq Von Rospach wrote: > Remember challenge/response? When everyone thought it was the solution > to all of our problems? Took the spammers under six weeks to crack it > once they decided to try. (answer: send spam as being "From:" you, > "To:" you. Most C/R systems have the user's email address > whitelisted. end of story. Hehn, the first thing I did was to blacklist myself and every role address I had. > Or leave pipermail alone, and write a CGI that all archives exit > through that does the filtering, which is IMHO, how you ought to do > it. +1 > That way, you can authenticate via that CGI to a level of access, > change the filtering on the fly, and leave the archives unedited (as I > think they ought to be). +1 -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] bugtraq submission warning: email address harvesting exploit
by J C Lawrence 27 Nov '03

27 Nov '03

On Thu, 27 Nov 2003 12:08:24 -0500 Terri Oda <terri(a)zone12.com> wrote: > On Tue, Nov 25, 2003 at 11:07:39AM -0800, Chuq Von Rospach wrote: > I know there are great alternative archivers out there, but Mailman > still winds up with a bad reputation if the default isn't very secure. Disagreed. > Maybe for 2.2 we could have a "completely obscure archived email > addresses" option which changed them all to user@xxxxxx. Another option, and the one I advocate, is to replace all email addresses with TMDA-style dated addresses, much in the manner GMane does. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] Secure Mailing Lists
by J C Lawrence 27 Nov '03

27 Nov '03

On Thu, 27 Nov 2003 16:49:58 +0100 Dietmar Maurer <dietmar(a)maurer-it.com> wrote: > Hi all, we are looking for a solution to implement secure mailing > lists. We need the following behaviour: Architecturally it can be accomplished at either the MLM or MTA level without enourmous difficulty. The problems arise when you start confronting the PKI issues, the human usability issues, and the server-side performance issues. There are no "right" answers to any of them. This is explored and surprisingly non-trivial territory. http://www.raphinou.com/smailman/smailman.html http://sourceforge.net/projects/mmreencrypt/ http://www.synacklabs.net/projects/crypt-ml/ http://www.atnf.csiro.au/people/rgooch/PGPsendmail.html http://shibboleth.sourceforge.net/ -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Any other NNTP gatewayers out there? SMTP reject bounce processing is broken?
by Barry Warsaw 26 Nov '03

26 Nov '03

Does anybody else gateway messages from NNTP, and specifically Usenet using Mailman 2.1.x? We've been seeing a very weird behavior where python-list (which is gated to and from comp.lang.python) suddenly mass bounce disables every regular delivery member. The triggering bounce messages always come from NNTP, never from email. The problem doesn't appear to affect digest members. There are other clues <wink>. Here's what I believe happens: Mailman pulls a message pulled from NNTP, and tries to post it to the list. The message however triggers and Exim acl check such as the one on message header syntax or one of our homegrown virus checks. Exim then rejects the message at SMTP hand-off time. Mailman see that rejection and scores a bounce message for every SMTP recipient. Now, I VERP that list so everybody gets a separate SMTP session, but I see about the number of rejects as the number of non-already-disabled regular delivery members. Exim never rejects a digest containing one of the trigger messages. Any message posted via mail that would hit one of our Exim acls would never even make it to the list, but NNTP pulled messages bypass that front-door check. I think part of the problem is our Exim config, and I'm working with the other python.org postmasters to address that. The other problem is in Mailman's handling of rejections at SMTP time. Currently, it always scores a bounce for any recipients of such a rejected message, and this scoring bypasses the bounce_processing flag. I think this behavior is at least partially broken. One fix would be to never score a bounce if the message was rejected at SMTP time. We could move the message to qfiles/bad and log the rejection but otherwise ignore the scoring. This might be bad because then Mailman wouldn't score bounces for non-existent local users, and because on a VERP'd list, we might get tons of qfiles/bad messages for every gated message. This latter might be manageable. We could just ignore rejections only for messages pulled from NNTP, which should reduce the missing of legitimate scoring for bogus local users, since they'll still get scored for regular email posts. Anybody have any thoughts or comments? I'm probably going to implement the latter to fix the immediate problem. -Barry

2 2

RE: Fwd: RE: [Mailman-Developers] RE: [Mailman-Users] Mailman &CPanel?
by Barry Warsaw 26 Nov '03

26 Nov '03

On Wed, 2003-11-26 at 01:15, Martin(a)Cleaver.org wrote: > All, has anyone taken up Nick's kind offer of using these details to get the > modification scripts? I honestly don't know when I'm going to have time to follow through on this. I'm chasing a few other critical issues right now. If anyone else can lend a hand, it would be appreciated! -Barry

1 0