From iane at sussex.ac.uk Tue Nov 1 13:25:14 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 1 Nov 2011 12:25:14 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111029043922.GC2272@state-of-mind.de> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> Message-ID: On 29 Oct 2011, at 05:39, Patrick Ben Koetter wrote: >> Hmm, adopting a hash-tags format here would be kind of interesting for interop >> with social networking sites. It wouldn't have to be reflected in the name of > > ACK with the notion that hashtag seems to closely realted with twitter and a > more general 'tag' would stay away from that. > > Is there or should there be a distinction between 'tag' and http 'keywords' > ? Should we > use 'keywords' instead? Well, both are just ways of sorting messages into sets, rather than categories. By definition (using the usual mathematical definition), categories don't overlap but sets may, so objects may be in only one category, but may be in several sets. So, yes, keywords, tags and hashtags are pretty much the same thing. And, it turns out that the Keywords: header is already defined in RFC5322: 3.6.5. Informational Fields keywords = "Keywords:" phrase *("," phrase) CRLF The "Keywords:" field contains a comma- separated list of important words and phrases that might be useful for the recipient. There's also a "Comments:" field defined, apparently. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From iane at sussex.ac.uk Tue Nov 1 13:28:43 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 1 Nov 2011 12:28:43 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111029043922.GC2272@state-of-mind.de> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> Message-ID: <018A32A8-0365-44A8-8DFF-4A0F5ACC9FDB@sussex.ac.uk> On 29 Oct 2011, at 05:39, Patrick Ben Koetter wrote: > List-Archive-Send-Date > 'List-Archive-Send-Date' sounds pretty clumsy and overly long. OTOH we > needn't care, as it will only be added to messages that go to the > archive, right? > > Archive-Transmit-Date, Archive-Transfer-Date, Archiv-Transfer > Marks the beginning in opposition to Archive-Received-Date or > Archive-Received. But then again an archiver could simply add a > Received:-header! Good point. I'd argue that the list manager, and the archiver should simply do that: put a received header into the message at the appropriate point. That would make it much easier to track the message progress. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From iane at sussex.ac.uk Tue Nov 1 13:29:15 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 1 Nov 2011 12:29:15 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111029043922.GC2272@state-of-mind.de> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> Message-ID: On 29 Oct 2011, at 05:39, Patrick Ben Koetter wrote: > > I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 > instead: > > A Mediator attempts to preserve the original Author's information in > the message it reformulates but is permitted to make meaningful > changes to the message content or envelope. > > A Mediator's role is complex and contingent, for example, modifying > and adding content or regulating which Users are allowed to > participate and when. The common example of this role is a group > Mailing List. > > (see section "2.1.4. Mediator" and also section "5. Mediators") > > > A 'Mediator' would leave the original User-Agent intact AND tell the message > had been processed by another mail handling service AND it would allow for > other Mediators to be added in case more mail processing was done after an > MLM's (here: Mailman) job. That seems sensible to me. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From iane at sussex.ac.uk Tue Nov 1 14:07:15 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 1 Nov 2011 13:07:15 +0000 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111030233732.GA20250@state-of-mind.de> References: <20111030190403.GG6534@state-of-mind.de> <20111030233732.GA20250@state-of-mind.de> Message-ID: On 30 Oct 2011, at 23:37, Patrick Ben Koetter wrote: > * Murray S. Kucherawy : >>> -----Original Message----- >>> From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Patrick Ben Koetter >>> Sent: Sunday, October 30, 2011 12:04 PM >>> To: Mailman Developers >>> Subject: [Mailman-Developers] Mailman headers roundup >>> >>> I've created a list to sum up the current discussion/threads on the mailman >>> header work. >>> [...] >> >> Nice! > > Thanks. > >> For the ones that are at "Create RFC", does someone have a specific syntax >> they should follow, especially something like ABNF? That plus a description >> makes crafting the RFC easy. > > My impression is we need to settle User-Agent, List-Agent and/or Mediator first. > > Then, at least that's my plan, I would start to collect/write descriptions, > syntax, ABNF etc. > > p at rick I favour User-Agent and Mediator, though I'd settle for just multiple instances of User-Agent. Either way, I think that both should have the same syntax, and that it should follow the syntax in rfc2616 section 14.43, and 3.8. That's because Thunderbird already uses User-Agent in this way (as does Mutt and MS Entourage), and it adds enough structure for automated log processing to be feasible, for example. Some MUAs use X-Mailer with similar syntax, e.g. Mulberry, but others like Exchange use a more free form approach. Below, I've listed all the User-Agent and X-Mailer strings in a couple of my mailboxes. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 User-Agent: SquirrelMail/1.4.16 User-Agent: Alpine 1.00 (DEB 882 2007-12-20) User-Agent: Alpine 1.00 (LRH 882 2007-12-20) User-Agent: Alpine 1.10 (OSX 962 2008-03-14) User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) User-Agent: Alpine 2.01 (DEB 1266 2009-07-14) User-Agent: Asnet.am WebMail User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) User-Agent: Growl/1.2.1 simple-mailer/1.0 python-smtplib/2.6.1 User-Agent: Internet Messaging Program (IMP) 0.9.4 User-Agent: Internet Messaging Program (IMP) 3.2.5 User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) User-Agent: Internet Messaging Program (IMP) H3 (4.2) User-Agent: Internet Messaging Program (IMP) H3 (4.2-RC2) / FreeBSD-6.3 User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs) User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) User-Agent: Internet Messaging Program (IMP) H3 (4.3.7-cvs) User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) User-Agent: KMail/1.12.0 (Linux/2.6.30-5.slh.1-sidux-686; KDE/4.3.0; i686; ; ) User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686-bigmem; KDE/4.4.5; i686; ; ) User-Agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; ) User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r1; KDE/4.4.5; i686; ; ) User-Agent: Microsoft-Entourage/12.26.0.100708 User-Agent: Microsoft-Entourage/12.28.0.101117 User-Agent: Microsoft-MacOutlook/14.0.0.100825 User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.2.13) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100515 Shredder/3.0.6pre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100118 Shredder/3.2a1pre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.13) User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.8) User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.23) Gecko/20090823 SeaMonkey/1.1.18 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ca; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.8) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110114 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-1.1.1 Thunderbird/3.0.4 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090908 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090908 Fedora/1.1.18-1.fc11 pango-text SeaMonkey/1.1.18 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100421 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100720 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101103 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110303 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.11pre) Gecko/20100918 Shredder/3.1.5pre User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) User-Agent: Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.9.1.15) Gecko/20101111 SeaMonkey/2.0.10 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100610 User-Agent: Mozilla/5.001 (X11; U; FreeBSD i386; U; NT4.0; en-us) Gecko/25250101 User-Agent: Mutt/1.4.2.1i User-Agent: Mutt/1.4.2.2i User-Agent: Mutt/1.5.16 (2007-06-09) User-Agent: Mutt/1.5.17 (2007-11-01) User-Agent: Mutt/1.5.18 (2008-05-17) User-Agent: Mutt/1.5.20 (2009-06-14) User-Agent: Mutt/1.5.20 (2009-12-10) User-Agent: Mutt/1.5.6i User-Agent: Neotonic Trakken/inject_actuator_server-2.67.1 User-Agent: Opera Mail/9.25 (SunOS) User-Agent: RoundCube Webmail/0.2.1 User-Agent: RoundCube Webmail/0.3.1 User-Agent: Roundcube Webmail/0.4.2 User-Agent: SMAHU.COM Webmail/0.21 User-Agent: SingNet WebMail User-Agent: SquirrelMail/1.4.10a User-Agent: SquirrelMail/1.4.12 User-Agent: SquirrelMail/1.4.13 User-Agent: SquirrelMail/1.4.13-1.fc9 User-Agent: SquirrelMail/1.4.15 User-Agent: SquirrelMail/1.4.16 User-Agent: SquirrelMail/1.4.19 User-Agent: SquirrelMail/1.4.20 User-Agent: SquirrelMail/1.4.21 User-Agent: SquirrelMail/1.4.3a User-Agent: SquirrelMail/1.4.4-2 User-Agent: SquirrelMail/1.4.5 User-Agent: SquirrelMail/1.4.6 User-Agent: SquirrelMail/1.4.6-7.el4 User-Agent: SquirrelMail/1.4.8 User-Agent: SquirrelMail/1.4.9a User-Agent: SquirrelMail/1.5.0 User-Agent: Thunderbird 1.5.0.14 (X11/20060911) User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) User-Agent: Thunderbird 2.0.0.23 (X11/20090812) User-Agent: Thunderbird 2.0.0.23 (X11/20090817) User-Agent: Thunderbird 2.0.0.23 (X11/20090825) User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) User-Agent: Thunderbird 2.0.0.24 (X11/20100317) User-Agent: Thunderbird 2.0.0.24 (X11/20100411) User-Agent: Thunderbird 2.0.0.24 (X11/20100702) User-Agent: Thunderbird 2.0.0.24 (X11/20100721) User-Agent: Thunderbird 2.0.0.24 (X11/20101027) User-Agent: Thunderbird 2.0.0.24 (X11/20101213) User-Agent: WEB-Mail Hotmail.kg X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mailer: StreamSend2 - 333673 X-Mailer: 1.0.0.34025 X-Mailer: 6, 5, 0, 3 X-Mailer: AC Mailer X-Mailer: AOL Webmail 31650-STANDARD X-Mailer: Advanced e-mail client v2.1 X-Mailer: AfterLogic WebMail Pro PHP X-Mailer: Apple Mail (2.1075.2) X-Mailer: Apple Mail (2.1077) X-Mailer: Apple Mail (2.1078) X-Mailer: Apple Mail (2.1081) X-Mailer: Apple Mail (2.1082) X-Mailer: Apple Mail (2.1084) X-Mailer: Apple Mail (2.753.1) X-Mailer: Apple Mail (2.936) X-Mailer: AtMail 4.11 X-Mailer: AtMail PHP 5.1 X-Mailer: AutoBahn Webmail X-Mailer: BritecastMailer 2.0 alfa (ISO-8859-1) X-Mailer: COMPESA WebMail 2.53 20080123 X-Mailer: Cabestan DMS X-Mailer: CampusM Password Service X-Mailer: Centrum Mail 5.0 X-Mailer: Claws Mail 3.7.4 (GTK+ 2.20.1; x86_64-pc-linux-gnu) X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu) X-Mailer: CommuniGate Pro WebUser v5.2.19 X-Mailer: CommuniGate Pro WebUser v5.3.2 X-Mailer: Default X-Mailer: Drupal X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) X-Mailer: Eloop Mailer X-Mailer: Enabler - http://www.enablermail.com X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.2) X-Mailer: Evolution 2.22.1.1 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) X-Mailer: Evolution 2.28.1 X-Mailer: Evolution 2.28.1 X-Mailer: Evolution 2.28.2 (2.28.2-1.fc12) X-Mailer: Evolution 2.28.3 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) X-Mailer: Evolution 2.30.2 X-Mailer: Evolution 2.30.2 (2.30.2-1.fc13) X-Mailer: Evolution 2.30.2 (2.30.2-3.fc13.dwmw2.1) X-Mailer: Evolution 2.30.3 X-Mailer: Evolution 2.30.3 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) X-Mailer: F2F Mail X-Mailer: Fishbowl 6.3.3772 X-Mailer: IceWarp Web Mail 5.6.7 X-Mailer: KANA Response 7.0.1.142.15 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 X-Mailer: Lotus Notes Release 8.5FP1 SHF164 August 28, 2009 X-Mailer: MBM 7.7-NL X-Mailer: MIME::Lite 3.01 (F2.73; B3.01; Q3.01) X-Mailer: MIME::Lite 3.01 (F2.73; T1.13; A1.62; B3.03; Q3.03) X-Mailer: MIME::Lite 3.01 (F2.74; A1.77; B3.07; Q3.07) X-Mailer: MIME::Lite 3.025 (F2.74; A2.04; B3.07; Q3.07) X-Mailer: MIME::Lite 3.025 (F2.74; A2.06; B3.07; Q3.07) X-Mailer: MIME::Lite 3.025 (F2.74; A2.07; B3.07; Q3.07) X-Mailer: MIME::Lite 3.027 (F2.74; T1.29; A2.06; B3.07; Q3.07) X-Mailer: MXM-v5-MailEngine X-Mailer: MailBee.NET 5.6.2.146 X-Mailer: MailChimp Mailer - **CID01f024c8ba0f472bfb9f** X-Mailer: MailChimp Mailer - **CID06dd11b6e10f472bfb9f** X-Mailer: MailChimp Mailer - **CID0d7e52368c67cf65591e** X-Mailer: MailChimp Mailer - **CID23078f0f2d0f472bfb9f** X-Mailer: MailChimp Mailer - **CID2a5c9c31fd0f472bfb9f** X-Mailer: MailChimp Mailer - **CID5f020b58af0f472bfb9f** X-Mailer: MailChimp Mailer - **CID653d883fb30f472bfb9f** X-Mailer: MailChimp Mailer - **CID6b277c24c30f472bfb9f** X-Mailer: MailChimp Mailer - **CID6e39c4ca9b0f472bfb9f** X-Mailer: MailChimp Mailer - **CID83c477b1616d29add736** X-Mailer: MailChimp Mailer - **CIDb23a8ad6c00f472bfb9f** X-Mailer: MailChimp Mailer - **CIDc5bf7294e30f472bfb9f** X-Mailer: MailChimp Mailer - **CIDc789f185c80f472bfb9f** X-Mailer: MailChimp Mailer - **CIDf32043f3ee0f472bfb9f** X-Mailer: MailChimp Mailer - **CIDfa642aadc10f472bfb9f** X-Mailer: MessageFocus Launcher (2.0-dev) X-Mailer: MessagingEngine.com Webmail Interface X-Mailer: Microsoft Avondale Mailer X-Mailer: Microsoft CDO for Windows 2000 X-Mailer: Microsoft Office Outlook 11 X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-Mailer: Microsoft Outlook 14.0 X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2800.1081 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mailer: Microsoft Outlook Web Access 6.5.7651.60 X-Mailer: Microsoft Outlook, Build 10.0.3416 X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-Mailer: Mike Cardwell's email_privacy_tester Mailer X-Mailer: Mirapoint Webmail Direct 4.1.8-GA X-Mailer: MobileMe Mail (1C262605) X-Mailer: MobileMe Mail (1C262606) X-Mailer: MobileMe Mail (1C3224) X-Mailer: Mulberry/2.2.0 (Win32) X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Mailer: Mulberry/3.1.6 (Win32) X-Mailer: Mulberry/4.0.4 (Win32) X-Mailer: Mulberry/4.0.7 (Mac OS X) X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Mailer: Mulberry/4.0.8 (Win32) X-Mailer: MyBB X-Mailer: NetMail ModWeb Module X-Mailer: Novell GroupWise Internet Agent 7.0.3 X-Mailer: Novell GroupWise Internet Agent 8.0.1 X-Mailer: OPEN-XCHANGE 5607 - WebMail X-Mailer: Oempro4 X-Mailer: Open WebMail 2.40 20040816 X-Mailer: Open WebMail 2.51 - BRMA 20050522 X-Mailer: OpenEMM V6.0.1 X-Mailer: OpenWebMail 2.52 20060502 X-Mailer: OpenWebMail 2.53 X-Mailer: OpenWebMail 2.53-B2D X-Mailer: Openwave WebEngine, version 2.8.10.2 X-Mailer: Oracle Communications Messenger Express 7u4-19.01 64bit (built Sep 7 X-Mailer: PHP X-Mailer: PHP/5.2.14 X-Mailer: PHPMailer (phpmailer.codeworxtech.com) [version 2.2] X-Mailer: PHPMailer (phpmailer.codeworxtech.com) [version 2.3] X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.2] X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.3] X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4] X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version ] X-Mailer: PHPMailer 5.0.0 (phpmailer.codeworxtech.com) X-Mailer: PHPMailer 5.0.2 (phpmailer.codeworxtech.com) X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) X-Mailer: PHPMailer [version 1.73] X-Mailer: PHPMailer [version 1.W_RND_INT[5].W_RND_INT[3]] X-Mailer: Precedence Webmail 2.34 (7/10/2009) X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 X-Mailer: Roving Constant Contact 2009 (http://www.constantcontact.com) X-Mailer: SAP Web Application Server 7.01 X-Mailer: SendBlaster.1.4.13 X-Mailer: Siebel EMS 80 [EMS 2011] main/200807172104 X-Mailer: SquirrelMail (version 1.2.6) X-Mailer: SquirrelMail (version 1.2.8) X-Mailer: SquirrelMail/1.4.3a X-Mailer: StrongMail Enterprise 4.1.2(4.1.2-51177) X-Mailer: Sun Java(tm) System Messenger Express 7u3-16.01 64bit (built Apr 6 X-Mailer: TKMS Webmail Server 2.52 20061019 X-Mailer: The Bat! (v2.00.2) Business X-Mailer: The Bat! (v2.00.2) Personal X-Mailer: The Bat! (v2.00.3) Educational X-Mailer: The Bat! (v2.00.5) Business X-Mailer: The Bat! (v2.00.6) Business X-Mailer: The Bat! (v2.00.6) Personal X-Mailer: The Bat! (v2.00.9) Business X-Mailer: The Bat! (v2.00.9) Educational X-Mailer: The Bat! (v2.01) Educational X-Mailer: The Bat! (v2.04.7) Educational X-Mailer: The Bat! (v2.10.01) Personal X-Mailer: The Bat! (v2.11) Educational X-Mailer: The Bat! (v3.0.1.33) Educational X-Mailer: The Bat! (v3.0.1.33) Professional X-Mailer: The Bat! (v3.5) Educational X-Mailer: The Bat! (v3.5.25) Educational X-Mailer: The Bat! (v3.5.30) Educational X-Mailer: The Bat! (v3.5.30) Home X-Mailer: The Bat! (v3.51) Professional X-Mailer: The Bat! (v3.51.10) Educational X-Mailer: The Bat! (v3.62.03) Educational X-Mailer: The Bat! (v3.62.03) Home X-Mailer: The Bat! (v3.62.14) Home X-Mailer: The Bat! (v3.71.01) Educational X-Mailer: The Bat! (v3.71.01) Professional X-Mailer: The Bat! (v3.71.04) Professional X-Mailer: The Bat! (v3.80.06) Professional X-Mailer: The Bat! (v3.95.6) Professional X-Mailer: ThinData EMS v30 X-Mailer: Ubersmith X-Mailer: Ultrafunk Popcorn 1.95 (31-August-2009) X-Mailer: VM under Emacs 23.1.1 (i386-pc-solaris2.8) X-Mailer: VM 7.19 under Emacs 21.2.1 X-Mailer: WhatCounts X-Mailer: WorldClient 11.0.3 X-Mailer: XMail 3.7.0 X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.102.267879 X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.100.260964 X-Mailer: YahooMailClassic/11.0.8 YahooMailWebService/0.8.103.269680 X-Mailer: YahooMailClassic/11.1.4 YahooMailWebService/0.8.103.269680 X-Mailer: YahooMailClassic/11.1.4 YahooMailWebService/0.8.104.274457 X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.104.274457 X-Mailer: YahooMailClassic/11.3.2 YahooMailWebService/0.8.105.279950 X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.108.291010 X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.295617 X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.107.284920 X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.1 X-Mailer: YahooMailClassic/9.0.20 YahooMailWebService/0.8.100.260964 X-Mailer: YahooMailClassic/9.2.12 YahooMailWebService/0.8.100.260964 X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.8.107.285259 X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.8.109.292656 X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.109.292656 X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.292656 X-Mailer: ZeMailer 4.1 (www.sc-zemail.fr) X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - SAF3 (Win)/5.0.18_GA_3011.RHEL4_64) X-Mailer: Zimbra 5.0.20_GA_3127.RHEL5_64 (ZimbraWebClient - FF3.0 X-Mailer: Zimbra 5.0.21_GA_3150.RHEL5 (zclient/5.0.21_GA_3150.RHEL5) X-Mailer: Zimbra 6.0.4_GA_2038.RHEL5 (zclient/6.0.4_GA_2038.RHEL5) X-Mailer: Zimbra 6.0.5_GA_2213.RHEL5 (zclient/6.0.5_GA_2213.RHEL5) X-Mailer: Zimbra 6.0.6_GA_2332.RHEL4 (ZimbraWebClient - FF3.0 X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - FF3.0 X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) X-Mailer: Zimbra 6.0.8_GA_2661 (zclient/6.0.8_GA_2661) X-Mailer: ZuckMail [version 1.00] X-Mailer: aspNetEmail ver 3.5.2.0 X-Mailer: class SMTPMail X-Mailer: cmail3.com X-Mailer: cmail4.com X-Mailer: createsend2.com X-Mailer: createsend5.com X-Mailer: cwidb.15 X-Mailer: eC-Messenger Build 5.31.92 X-Mailer: eC-Messenger Build 5.41.71 X-Mailer: eC-Messenger Build 5.41.89 X-Mailer: eC-Messenger Build 5.41.90 X-Mailer: eC-Messenger Build 6.00.115 X-Mailer: eC-Messenger Build 6.30.7 X-Mailer: email2market X-Mailer: fdfntsal.21 X-Mailer: hotmel.eu X-Mailer: iPad Mail (7B367) X-Mailer: iPad Mail (7B500) X-Mailer: iPhone Mail (7C144) X-Mailer: iPhone Mail (7D11) X-Mailer: iPhone Mail (7E18) X-Mailer: iPhone Mail (8A293) X-Mailer: iPhone Mail (8A306) X-Mailer: iPhone Mail (8B117) X-Mailer: iPhone Mail (8C148) X-Mailer: iPhone Mail (8F190) X-Mailer: iPhone Mail (8G4) X-Mailer: iPod Mail (7D11) X-Mailer: jfsg 06 X-Mailer: kydymtam_89 X-Mailer: oemPro - www.octeth.com X-Mailer: osTicket v 1.6 X-Mailer: phplist v2.10.10 X-Mailer: phplist v2.10.12 X-Mailer: phplist v2.10.13 X-Mailer: qxdan_38 X-Mailer: rnwyek.24 X-Mailer: vBulletin Mail via PHP X-Mailer: venomous [1-3 X-Mailer: www.guzelliksalonum.com From stephen at xemacs.org Tue Nov 1 14:23:37 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 01 Nov 2011 22:23:37 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <018A32A8-0365-44A8-8DFF-4A0F5ACC9FDB@sussex.ac.uk> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> <018A32A8-0365-44A8-8DFF-4A0F5ACC9FDB@sussex.ac.uk> Message-ID: <87fwi8ou1y.fsf@uwakimon.sk.tsukuba.ac.jp> Ian Eiloart writes: > Good point. I'd argue that the list manager, and the archiver > should simply do that: put a received header into the message at > the appropriate point. That would make it much easier to track the > message progress. I don't have a strong opinion on whether or not that's the best way to handle this, but I'd like to point out that RFC 5321 has quite a bit to say about the format of such lines. It also seems to imply that these are added by "gateway, relay, and forwarding systems". I would guess that Mailman qualifies as a forwarding system in which case it whould probably try to conform to the RFC 5321 syntax. From William at alt-config.net Wed Nov 2 14:26:45 2011 From: William at alt-config.net (William Bagwell) Date: Wed, 2 Nov 2011 09:26:45 -0400 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <87zkghok69.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111030190403.GG6534@state-of-mind.de> <87zkghok69.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <201111020926.46039.William@alt-config.net> On Monday 31 October 2011, Stephen J. Turnbull wrote: > Patrick Ben Koetter writes: > > X-Topics > > This contains a list of all the topic names that matched the > > message. Are there any other MLMs that support topics in a way that > > would make that header generally useful? > > "Topics" is way too general a word, and easily confused with Summary > (an existing standard header) or perhaps a digest table of contents. Has been a few days and no one else has commented on this. My thoughts are strictly from an end user and list owners point of view. I happen to like Topics and find them quite usefull. You are correct however in that they are confusing. The few lists I have been on through the years that enabled Topics were all social lists with non-technical users. BTW, these lists started on ListServe and later migrated to Mailman to save money. I'm presuming that the name and function "Topics" originated with ListServe? Many people (including more than a few list owners) have problems with Topics and using them correctly and efficiently. Can proved examples / statistics if anyone wants? Oddly, I personally have never seen a technical list that uses Topics. Have been greeted by crickets the few times I have suggested tuning them on in responce to a political flame fest. Only word I can think of that more accurately describes the way Topics are used in real life is "Sub-list". Unfortunately it is also confusing and I think not strictly accurate in what they really are. Perhaps "mini-sublists" to distinguish them from true sublists? > > X-Archive > > X-No-Archive > > deprecated > > Next Step: Remove from code > > These are originator headers, and I don't see any harm in respecting > them (or providing the option to list owners), even if many other > agents do not. Yes, please keep. If and when Mailman gets a user friendly archive, then the need for this header might grow. Both KMail (Linux) and Forte Agent (Windows) support custom headers, so options exist for end users to use it. -- William From barry at list.org Wed Nov 2 16:06:57 2011 From: barry at list.org (Barry Warsaw) Date: Wed, 2 Nov 2011 11:06:57 -0400 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111030190403.GG6534@state-of-mind.de> References: <20111030190403.GG6534@state-of-mind.de> Message-ID: <20111102110657.00ca7ddf@resist> Thanks for coordinating this Patrick. On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: >X-List-Received-Date > This only gets added when the message is sent to the archive. > Modify to: List-Archive-Sent > Next Step: Discuss List-Archive-Sent (maybe with -Date) makes sense to me. This really is different than Received headers IMO since it's not recording any "receiving" event in Mailman. To the extent that it's useful to know when an MLM sends the message to its archivers, getting the direction right seems important. The question in my mind is what to do about the case where, as in MM3, we have multiple archivers. Multiple L-A-S headers should be allowed, but then I wonder whether the headers need to record which archiver the header applies to. TBH, in MM3 when we send to one archiver, we send to them all so I'm not sure the extra complexity is worth it. I also don't know whether any other MLM supports multiple archivers. >X-Message-ID-Hash > propose an RFC as an extension of RFC 5064 > Modify to: unclear > Next Step: Discuss As an RFC, obviously we'd drop the X- prefix, but also "Hash" might be too vague. Personally I think Message-ID-Hash is fine and the theoretical RFC shouldn't allow much leeway in implementations (i.e. only one hash algorithm is allowed). This will probably be bikeshedded to death. Still, since Message-ID must be unique (and generally is, as backed up by The Mail Archive's data), I think base-32 of SHA-1 will in practice be just fine. >X-Mailman-Version > The version of Mailman that sent the message. It can lose the X- > prefix. > Modify to: List-Agent, Mediator > Next Step: Discuss I like List-Agent much more than User-Agent, since Mailman is only tenuously under any control of the user. I like having this header under the List- prefix, so I Mediator doesn't appeal to me. >X-Mailman-Approved-At > lose the X-prefix > Modify to: List-Approved-Date > Next Step: Create RFC or Extend RFC 2369? To generalize, it might be useful to have List-Moderation-Action and List-Moderation-Date headers. The former would have values like Approved, Held, Rejected, or Discarded, while the latter would have the date of the disposition. Seemingly useless actions like Discarded and Held would still be useful because even a discarded message may end up in some email graveyard for future data mining. >II. MODIFY >X-Mailer > Only used when Mailman originates messages such as autoresponses. > Modify to: User-Agent > Next Step: Change code Similar to the above, I don't like User-Agent much here. I think this could be simply folded into List-Agent since there are probably plenty of other header clues to know that a message was originated by Mailman. >X-Topics > This contains a list of all the topic names that matched the message. > Are there any other MLMs that support topics in a way that would make that > header generally useful? > Modify to: Tag > Next Step: Create RFC I think someone suggested Keywords, and as much as I'd like to use that one, I don't think it's feasible. Existing Keywords headers are used as input to the topic tagger so it can't be re-used. List-Topics seems fine to me, but other possibilities include List-Tags, List-HashTags, or List-Keywords. >X-Mailman-Rule-Hits > They could certainly lose the X- prefix. > Modify to: Mailman-Rule-Hits > Next Step: Create RFC > >X-Mailman-Rule-Misses > They could certainly lose the X- prefix. > Modify to: Mailman-Rule-Misses > Next Step: Create RFC These are all pretty specific to the Mailman implementation so dropping the X- should be enough. No RFC needed. >X-Content-Filtered-By > I think this should be renamed to (X-)Mailman-Content-Filter. > Modify to: Mailman-Content-Filter > Next Step: Create RFC The only utility of this header is to notify the recipients that the original message has been altered by removing MIME parts. OTOH, I think it's pretty much understood that messages flowing to mailing lists are subject to considerable modification. Certainly the content of this header as it currently stands is useless. It's akin to "This film has been modified from its original version. It has been formatted to fit this screen." I don't know whether we can come up with a List-* header that actually carries some meaningful content, so maybe it should just be dropped? Cheers, -Barry From CNulk at scu.edu Wed Nov 2 19:14:28 2011 From: CNulk at scu.edu (C Nulk) Date: Wed, 02 Nov 2011 11:14:28 -0700 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111102110657.00ca7ddf@resist> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> Message-ID: <4EB18884.4020301@scu.edu> On 11/2/2011 8:06 AM, Barry Warsaw wrote: > Thanks for coordinating this Patrick. > > On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: > >> X-List-Received-Date >> This only gets added when the message is sent to the archive. >> Modify to: List-Archive-Sent >> Next Step: Discuss > List-Archive-Sent (maybe with -Date) makes sense to me. This really is > different than Received headers IMO since it's not recording any "receiving" > event in Mailman. To the extent that it's useful to know when an MLM sends > the message to its archivers, getting the direction right seems important. I agree with having a List-Archive-Sent header for when the message is sent to one (or more archivers). However, I still think there is a need for the date and time when the List actually receives the message. Let's say Mailman is running on the same system as a spam/anti-virus software package. The message comes into the systems MTA which then routes the message to the spam/anti-virus software where it is held for approval. Two days later, someone approves the message which is returned to the MTA for delivery. The MTA passes the message to Mailman. Mailman adds the List-Received-Date header since that is when Mailman received it. A similar argument can be made about the List-Archive-Sent header. The header should not be added until the last moment, basically right before calling the archiving module. If a list is moderated or a message is held, that will affect the List-Archive-Sent header because the message can't be sent unless a disposition is known about the message. > > The question in my mind is what to do about the case where, as in MM3, we have > multiple archivers. Multiple L-A-S headers should be allowed, but then I > wonder whether the headers need to record which archiver the header applies > to. TBH, in MM3 when we send to one archiver, we send to them all so I'm not > sure the extra complexity is worth it. I also don't know whether any other > MLM supports multiple archivers. >> X-Message-ID-Hash >> propose an RFC as an extension of RFC 5064 >> Modify to: unclear >> Next Step: Discuss > As an RFC, obviously we'd drop the X- prefix, but also "Hash" might be too > vague. Personally I think Message-ID-Hash is fine and the theoretical RFC > shouldn't allow much leeway in implementations (i.e. only one hash algorithm > is allowed). This will probably be bikeshedded to death. Still, since > Message-ID must be unique (and generally is, as backed up by The Mail > Archive's data), I think base-32 of SHA-1 will in practice be just fine. > >> X-Mailman-Version >> The version of Mailman that sent the message. It can lose the X- >> prefix. >> Modify to: List-Agent, Mediator >> Next Step: Discuss > I like List-Agent much more than User-Agent, since Mailman is only tenuously > under any control of the user. I like having this header under the List- > prefix, so I Mediator doesn't appeal to me. I would much more prefer List-Agent over User-Agent. I agree Barry about Mailman tenuously under any control of the user. My experience is that users generally exercise no control over Mailman. Mediator also doesn't make much sense to me. Mailman settle any disputes for me. Nor, do I see it as an intermediate "agency". I see lists in general and Mailman in particular as a collecting point or aggregator for messages for a common "topic" which then distributes the received messages to interested parties. So, instead of a Mediator header, I can see a Collector header, or Aggregator header, or a Distributor header, and even then none of them really make sense. To me, List-Agent makes the most sense. >> X-Mailman-Approved-At >> lose the X-prefix >> Modify to: List-Approved-Date >> Next Step: Create RFC or Extend RFC 2369? > To generalize, it might be useful to have List-Moderation-Action and > List-Moderation-Date headers. The former would have values like Approved, > Held, Rejected, or Discarded, while the latter would have the date of the > disposition. Seemingly useless actions like Discarded and Held would still be > useful because even a discarded message may end up in some email graveyard for > future data mining. > >> II. MODIFY >> X-Mailer >> Only used when Mailman originates messages such as autoresponses. >> Modify to: User-Agent >> Next Step: Change code > Similar to the above, I don't like User-Agent much here. I think this could > be simply folded into List-Agent since there are probably plenty of other > header clues to know that a message was originated by Mailman. I can see this one both ways. Since Mailman is the "List-Agent" doing the work, add to the message the List-Agent header. And because Mailman is generating the content, add to the message the User-Agent header and make it the same information from the List-Agent header. Then when you are reading the headers, you can see the MTAs Received headers, List-Agent tells you the list the message came from and User-Agent tells you who generated and put together the content of the message. > Cheers, -Barry Thanks, Chris From Chris.Clark at actian.com Wed Nov 2 20:00:14 2011 From: Chris.Clark at actian.com (Chris Clark) Date: Wed, 02 Nov 2011 12:00:14 -0700 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111102110657.00ca7ddf@resist> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> Message-ID: <4EB1933E.9080707@actian.com> Barry Warsaw wrote: > On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: > >> X-Message-ID-Hash >> propose an RFC as an extension of RFC 5064 >> Modify to: unclear >> Next Step: Discuss >> > > As an RFC, obviously we'd drop the X- prefix, but also "Hash" might be too > vague. Personally I think Message-ID-Hash is fine and the theoretical RFC > shouldn't allow much leeway in implementations (i.e. only one hash algorithm > is allowed). This will probably be bikeshedded to death. Still, since > Message-ID must be unique (and generally is, as backed up by The Mail > Archive's data), I think base-32 of SHA-1 will in practice be just fine. > I love painting bikesheds... or rather offering paint color/colour suggestions to painters doing the work ;-) If a header is going to contain data that is generated from non-trivial processing I think it would be good form to include the algorithm name in the header. The DKIM-Signature (RFC 4871, and was included in the email I'm replying to) itself includes the name, example extract: DKIM-Signature: a=rsa-sha256; ......... DKIM is using a secure hash which is arguable more processing than a simple digest hash but the same principle of self documenting seems reasonable. Admittedly there will be a need in the future for new secure algorithms to be deployed for DKIM, it is less certain if there is a need to ever change the algorithm used for X-Message-ID-Hash. Is there a clear advantage limiting the algorithm used? Chris From p at state-of-mind.de Wed Nov 2 21:31:13 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Wed, 2 Nov 2011 21:31:13 +0100 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111102110657.00ca7ddf@resist> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> Message-ID: <20111102203112.GG3084@state-of-mind.de> * Barry Warsaw : > Thanks for coordinating this Patrick. > > On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: > > >X-List-Received-Date > > This only gets added when the message is sent to the archive. > > Modify to: List-Archive-Sent > > Next Step: Discuss > > List-Archive-Sent (maybe with -Date) makes sense to me. This really is > different than Received headers IMO since it's not recording any "receiving" > event in Mailman. To the extent that it's useful to know when an MLM sends > the message to its archivers, getting the direction right seems important. > > The question in my mind is what to do about the case where, as in MM3, we have > multiple archivers. Multiple L-A-S headers should be allowed, but then I > wonder whether the headers need to record which archiver the header applies > to. TBH, in MM3 when we send to one archiver, we send to them all so I'm not > sure the extra complexity is worth it. I also don't know whether any other > MLM supports multiple archivers. > > >X-Message-ID-Hash > > propose an RFC as an extension of RFC 5064 > > Modify to: unclear > > Next Step: Discuss > > As an RFC, obviously we'd drop the X- prefix, but also "Hash" might be too > vague. Personally I think Message-ID-Hash is fine and the theoretical RFC > shouldn't allow much leeway in implementations (i.e. only one hash algorithm > is allowed). This will probably be bikeshedded to death. Still, since > Message-ID must be unique (and generally is, as backed up by The Mail > Archive's data), I think base-32 of SHA-1 will in practice be just fine. As a sidenote: Postfix 2.9 will introduce longer Message-IDs because a Message-ID is only stable while the message is in the server (queue), but it may be reused immediately after the first message had been delivered - that's RFC compliant. This has caused problems with long time log analysis software and archival and that's why Postfix 2.9 will offer longer Message-IDs (read also: Queue-IDs). > >X-Mailman-Version > > The version of Mailman that sent the message. It can lose the X- > > prefix. > > Modify to: List-Agent, Mediator > > Next Step: Discuss > > I like List-Agent much more than User-Agent, since Mailman is only tenuously > under any control of the user. I like having this header under the List- > prefix, so I Mediator doesn't appeal to me. One last attempt: Using List-Agent only creates an agent instance that can be used by MLM software. Using Mediator will creat an Agent that can be used by any software that processes mail. > >X-Mailman-Approved-At > > lose the X-prefix > > Modify to: List-Approved-Date > > Next Step: Create RFC or Extend RFC 2369? > > To generalize, it might be useful to have List-Moderation-Action and > List-Moderation-Date headers. The former would have values like Approved, +1 > Held, Rejected, or Discarded, while the latter would have the date of the > disposition. Seemingly useless actions like Discarded and Held would still be > useful because even a discarded message may end up in some email graveyard for > future data mining. > > >II. MODIFY > >X-Mailer > > Only used when Mailman originates messages such as autoresponses. > > Modify to: User-Agent > > Next Step: Change code > > Similar to the above, I don't like User-Agent much here. I think this could > be simply folded into List-Agent since there are probably plenty of other > header clues to know that a message was originated by Mailman. > > >X-Topics > > This contains a list of all the topic names that matched the message. > > Are there any other MLMs that support topics in a way that would make that > > header generally useful? > > Modify to: Tag > > Next Step: Create RFC > > I think someone suggested Keywords, and as much as I'd like to use that one, I > don't think it's feasible. Existing Keywords headers are used as input to the > topic tagger so it can't be re-used. List-Topics seems fine to me, but other > possibilities include List-Tags, List-HashTags, or List-Keywords. Lets settle for List-Topics. If someone wants to compare e.g. with their social network, forum ... they will have to create a mapping. This will work too. > > >X-Mailman-Rule-Hits > > They could certainly lose the X- prefix. > > Modify to: Mailman-Rule-Hits > > Next Step: Create RFC > > > >X-Mailman-Rule-Misses > > They could certainly lose the X- prefix. > > Modify to: Mailman-Rule-Misses > > Next Step: Create RFC > > These are all pretty specific to the Mailman implementation so dropping the X- > should be enough. No RFC needed. Okay. > >X-Content-Filtered-By > > I think this should be renamed to (X-)Mailman-Content-Filter. > > Modify to: Mailman-Content-Filter > > Next Step: Create RFC > > The only utility of this header is to notify the recipients that the original > message has been altered by removing MIME parts. OTOH, I think it's pretty > much understood that messages flowing to mailing lists are subject to > considerable modification. Certainly the content of this header as it To a postmaster debugging a problem knowing instead of assuming the message had been altered can make all the difference. I expect an MLM to add some headers and add a footer, but I don't expect it to rip out MIME parts - allthough I know it can do. I personally think MM should add a notice if it removes or replaces MIME parts. > currently stands is useless. It's akin to "This film has been modified from > its original version. It has been formatted to fit this screen." I don't know > whether we can come up with a List-* header that actually carries some > meaningful content, so maybe it should just be dropped? Maybe saying what the MLM did would be more meaningful? It could give a hint what was done: List-Message-Modified: Removed|Replaced ... p at rick -- state of mind () http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From terri at zone12.com Wed Nov 2 21:38:26 2011 From: terri at zone12.com (Terri Oda) Date: Wed, 02 Nov 2011 14:38:26 -0600 Subject: [Mailman-Developers] Topics/sublists (was Re: Mailman headers roundup) In-Reply-To: <201111020926.46039.William@alt-config.net> References: <20111030190403.GG6534@state-of-mind.de> <87zkghok69.fsf@uwakimon.sk.tsukuba.ac.jp> <201111020926.46039.William@alt-config.net> Message-ID: <4EB1AA42.3090505@zone12.com> On 11-11-02 7:26 AM, William Bagwell wrote: > Many people (including more than a few list owners) have problems with > Topics and using them correctly and efficiently. Can proved examples / > statistics if anyone wants? Oddly, I personally have never seen a > technical list that uses Topics. Have been greeted by crickets the few > times I have suggested tuning them on in responce to a political flame > fest. For the record, I have seen them used on a smaller technical list (which was running courses for different mostly tech topics), but the most extensive use of a topic system I've ever seen is actually the Systers "dynamic sublists" system: http://wiki.list.org/display/DEV/Dynamic+Sublists In short, it uses listname+topicname at example.com style email addresses to create sublists (listname+new at example.com to start a new one) and allows people to subscribe/unsubscribe from those individually. Overall, it means admins don't have to go around manually setting up topics, it means subscribers don't have to try to read regexes to figure out what subject tags they need to get grouped with the right topic, and it seems to run a lot more smoothly in practice than Mailman's default topic system, having used both. One of the goals with Systers' summer of code work has been to get some of this stuff integrated with Mailman, so if we're talking about fixing the topic system, I highly recommend we take advantage of the lovely code already prepared for us. :) We may even already have copyright releases on file for this. Terri From mark at msapiro.net Wed Nov 2 22:57:28 2011 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 02 Nov 2011 14:57:28 -0700 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111102203112.GG3084@state-of-mind.de> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <20111102203112.GG3084@state-of-mind.de> Message-ID: <4EB1BCC8.9060409@msapiro.net> On 11/2/2011 1:31 PM, Patrick Ben Koetter wrote: > * Barry Warsaw : >> Thanks for coordinating this Patrick. >> >> On Oct 30, 2011, at 08:04 PM, Patrick Ben Koetter wrote: >> >>> X-Message-ID-Hash >>> propose an RFC as an extension of RFC 5064 >>> Modify to: unclear >>> Next Step: Discuss >> >> As an RFC, obviously we'd drop the X- prefix, but also "Hash" might be too >> vague. Personally I think Message-ID-Hash is fine and the theoretical RFC >> shouldn't allow much leeway in implementations (i.e. only one hash algorithm >> is allowed). This will probably be bikeshedded to death. Still, since >> Message-ID must be unique (and generally is, as backed up by The Mail >> Archive's data), I think base-32 of SHA-1 will in practice be just fine. > > As a sidenote: Postfix 2.9 will introduce longer Message-IDs because a > Message-ID is only stable while the message is in the server (queue), but it > may be reused immediately after the first message had been delivered - that's > RFC compliant. This has caused problems with long time log analysis software > and archival and that's why Postfix 2.9 will offer longer Message-IDs (read > also: Queue-IDs). I think the Message-ID to which you refer in the above paragraph is the Postfix queue ID and has nothing whatsoever to do with the Message-ID: header or (X-)Message-ID-Hash which is a hash of that header. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at list.org Thu Nov 3 15:35:59 2011 From: barry at list.org (Barry Warsaw) Date: Thu, 3 Nov 2011 10:35:59 -0400 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <4EB1933E.9080707@actian.com> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <4EB1933E.9080707@actian.com> Message-ID: <20111103103559.39bcc4f1@resist> On Nov 02, 2011, at 12:00 PM, Chris Clark wrote: >If a header is going to contain data that is generated from non-trivial >processing I think it would be good form to include the algorithm name in the >header. The idea behind the header is to enhance RFC 5064 so that the MLM can pre-calculate Archived-At for the destination archive, without any interaction from that archiver. It also enables users to do the same. Message-ID-Hash is primarily a convenience value which provides the last component in Archived-At. Thus Archived-At is calculated as / where is typically the List-Archive header value and is Message-ID-Hash. The choice of Base 32 was deliberate. It's seen as a trade-off between uniqueness and (potentially ) human readable. http://wiki.list.org/display/DEV/Stable+URLs The reason you do not want variability in the algorithm is because you want to be able to calculate the Archived-At value given only the Message-ID and the archiver base url. Having to also exchange knowledge of the algorithm used would make this less usable IMO. Let's say I know that messages to mailman-developers are archived at mail.python.org, gmane.org and www.mail-archive.com, and I somehow know that your original message has Message-ID: <4EB1933E.9080707 at actian.com>, I don't need anything else to find your message: >>> from hashlib import sha1 >>> from base64 import b32encode >>> mid_hash = b32encode(sha1('<4EB1933E.9080707 at actian.com>').digest()) >>> mid_hash 'ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6' >>> for base in ('gmane.org', 'mail-archive.com', 'mail.python.org'): ... print 'http://{0}/{1}'.format(base, mid_hash) ... http://gmane.org/ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6 http://mail-archive.com/ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6 http://mail.python.org/ANDJGXNCTPGVTF5F2WROKOOKXGKZDBC6 That's the compelling argument behind the *concept* of Message-ID-Hash, but as you can see, it's easy to calculate with just two pieces of information, one of which is static and the other which is fairly easy to convey. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Thu Nov 3 15:46:41 2011 From: barry at list.org (Barry Warsaw) Date: Thu, 3 Nov 2011 10:46:41 -0400 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <4EB18884.4020301@scu.edu> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <4EB18884.4020301@scu.edu> Message-ID: <20111103104641.5b28720f@resist> On Nov 02, 2011, at 11:14 AM, C Nulk wrote: >I agree with having a List-Archive-Sent header for when the message is >sent to one (or more archivers). However, I still think there is a need >for the date and time when the List actually receives the message. I agree, but I think Mailman should be adding a Received header for that. https://bugs.launchpad.net/mailman/+bug/885715 >A similar argument can be made about the List-Archive-Sent header. The >header should not be added until the last moment, basically right before >calling the archiving module. Agreed, and this is how MM3 currently works. Cheers, -Barry From msk at cloudmark.com Thu Nov 3 19:22:07 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Thu, 3 Nov 2011 11:22:07 -0700 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <4EB1BCC8.9060409@msapiro.net> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <20111102203112.GG3084@state-of-mind.de> <4EB1BCC8.9060409@msapiro.net> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Mark Sapiro > Sent: Wednesday, November 02, 2011 2:57 PM > To: mailman-developers at python.org > Subject: Re: [Mailman-Developers] Mailman headers roundup > > I think the Message-ID to which you refer in the above paragraph is the > Postfix queue ID and has nothing whatsoever to do with the Message-ID: > header or (X-)Message-ID-Hash which is a hash of that header. Sometimes Message-ID includes the queue ID. That's the case with sendmail, as I recall. The queue ID is also typically part of the Received: field already. From iane at sussex.ac.uk Fri Nov 4 13:06:07 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 4 Nov 2011 12:06:07 +0000 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111102110657.00ca7ddf@resist> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> Message-ID: <5F2FEE0B-3C59-4076-AB17-B5EA6F51F2C2@sussex.ac.uk> On 2 Nov 2011, at 15:06, Barry Warsaw wrote: >> >> X-Topics >> This contains a list of all the topic names that matched the message. >> Are there any other MLMs that support topics in a way that would make that >> header generally useful? >> Modify to: Tag >> Next Step: Create RFC > > I think someone suggested Keywords, and as much as I'd like to use that one, I > don't think it's feasible. Existing Keywords headers are used as input to the > topic tagger so it can't be re-used. List-Topics seems fine to me, but other > possibilities include List-Tags, List-HashTags, or List-Keywords. Fine, but not hashtag, since there will, presumably, be no requirement to use the hash character. Hashtags were invented for inline use in Twitter. These aren't hashtags. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From p at state-of-mind.de Thu Nov 10 21:33:18 2011 From: p at state-of-mind.de (Patrick Ben Koetter) Date: Thu, 10 Nov 2011 21:33:18 +0100 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111102110657.00ca7ddf@resist> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> Message-ID: <20111110203318.GA6587@state-of-mind.de> * Barry Warsaw : > >X-Mailman-Version > > The version of Mailman that sent the message. It can lose the X- > > prefix. > > Modify to: List-Agent, Mediator > > Next Step: Discuss > > I like List-Agent much more than User-Agent, since Mailman is only tenuously > under any control of the user. I like having this header under the List- > prefix, so I Mediator doesn't appeal to me. Here's why I would prefer "Mediator": What we want is a header field name that indicates the message has been accepted, modified and forwared by a program. The header field name 'List-Agent' does that, but it is specific to mailing lists. The term 'Mediator' describes the same, but it is general in meaning. Any instance modifying and forwarding a message can use it. If we use List-Agent others will have to register another header field name - 'Mediator' would fit for all. p at rick -- state of mind () http://www.state-of-mind.de Franziskanerstra?e 15 Telefon +49 89 3090 4664 81669 M?nchen Telefax +49 89 3090 4666 Amtsgericht M?nchen Partnerschaftsregister PR 563 From CNulk at scu.edu Thu Nov 10 23:17:05 2011 From: CNulk at scu.edu (C Nulk) Date: Thu, 10 Nov 2011 14:17:05 -0800 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111110203318.GA6587@state-of-mind.de> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <20111110203318.GA6587@state-of-mind.de> Message-ID: <4EBC4D61.3060404@scu.edu> On 11/10/2011 12:33 PM, Patrick Ben Koetter wrote: > * Barry Warsaw : >>> X-Mailman-Version >>> The version of Mailman that sent the message. It can lose the X- >>> prefix. >>> Modify to: List-Agent, Mediator >>> Next Step: Discuss >> I like List-Agent much more than User-Agent, since Mailman is only tenuously >> under any control of the user. I like having this header under the List- >> prefix, so I Mediator doesn't appeal to me. > Here's why I would prefer "Mediator": > > What we want is a header field name that indicates the message has been > accepted, modified and forwared by a program. > > The header field name 'List-Agent' does that, but it is specific to mailing > lists. The term 'Mediator' describes the same, but it is general in meaning. > Any instance modifying and forwarding a message can use it. > > If we use List-Agent others will have to register another header field name - > 'Mediator' would fit for all. > > p at rick > > I understand what you are saying. To me "Mediator" doesn't describe the same information specifically because it is too general in meaning. "List-Agent" as the header makes sense to me. Mailman manages whatever email distribution lists I create or manage, dealing with "lists" and the message traffic back and forth to it and subscribers. To me, it acts as a agent, thus "List-Agent" makes more sense. In addition, when I am or have to look through a messages headers to see what is happening, I want to be able to group common headers together. All the "Received" headers, all the "List-" headers so I can get a sense of things faster. The "Mediator" header doesn't lend itself to doing so. It is out on its own. This header discussion, to me, is about identifying and registering common headers useful for Mailman in particular and Mailing List Managers in general. The "List-Agent" header works best and working with other MLMs to register the common headers is for the best. I don't think we are trying to solve all the issues associated with email processing, only a little piece. If other software packages that may have some small interaction with email need a header, then let them build a consensus around their header and then register it. If, later in time, it turns out there is a need for a super-set of headers that includes MLMs, then maybe the "Mediator" header is appropriate which wouldn't conflict with "List-Agent". For now, I think "List-Agent" is the best solution to provide a descriptive header for Mailman and other MLMs which when used with other proposed "List-" headers allows one to easily identify a MLM and its interactions with a message. Sorry for the long post. Thanks, Chris From barry at list.org Sun Nov 13 00:31:29 2011 From: barry at list.org (Barry Warsaw) Date: Sat, 12 Nov 2011 18:31:29 -0500 Subject: [Mailman-Developers] Mailman lists now available on Gmane Message-ID: <20111112183129.0f23c183@resist.wooz.org> I'm very happy to announce that at long last, the main GNU Mailman mailing lists hosted at python.org are now available on Gmane. This includes: mailman-announce mailman-developers mailman-users mailman-i18n All of the archives for these lists have been imported as well. If you're not familiar with Gmane, I strongly encourage you to take a look. It's an amazing service for the free software and open source community. http://gmane.org/ While web archives are available, for me, the NNTP access is the really cool thing. If your mail reader can speak NNTP (the good and still useful part of Usenet :), then you just need to subscribe to the newsgroups and you can read entire threads of discussion from the past. After the first email verification dance, you can even post to the newsgroup and it will show up on the mailing list. I'm on a personal mission to stop archiving any publicly available mailing lists, and what this means to me is that I can just about halve my inbox! Here are some links: http://gmane.org/find.php?list=mailman-announce http://gmane.org/find.php?list=mailman-developers http://gmane.org/find.php?list=mailman-users http://gmane.org/find.php?list=mailman-i18n The NNTP interface is also a model of what I'd love to see Mailman 3 eventually provide by default (not to steal any thunder from Gmane). My thanks to Lars Magne Ingebrigtsen who runs Gmame, and to the python.org postmasters for all their help in getting this set up. Enjoy, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From terri at zone12.com Mon Nov 14 09:57:13 2011 From: terri at zone12.com (Terri Oda) Date: Mon, 14 Nov 2011 01:57:13 -0700 Subject: [Mailman-Developers] GHC11 open source day Message-ID: <4EC0D7E9.5010201@zone12.com> GHC11 included an open source hackathon on Saturday, and I was lucky enough to find some great people who spent the day helping with usability testing and interface mockups for Mailman. We focused a bunch on the admin interfaces, which (unlike the archives and the member options pages) haven't been particularly usability tested before, and poked through using the first roughs for Mailman 3.0 (Thanks again for letting us abuse your server, Florian!). I've got a huge pile of notes and a suitcase filled with big paper prototypes, like the one Mel's working on in this photo: https://photos-2.dropbox.com/i/l/tGZOpFHyUZYWdP8qQIWC3bCtfwQ7vqHMrwqhz8tGWC4/9183906/1321347600/f75f406/DSC_6385.JPG#20 Over the next week or so I'll be digitizing what we produced in the form of photos, ui mockups and notes on the wiki. If anyone's interested in helping with the UI work, I could use some help! This is a great place to start if you've always wanted to help but weren't sure what to do or were worried your python skills weren't up to snuff. I should have the photos of the paper prototypes up Monday evening (I'm on US Mountain time) and I'd love some help translating the photos into UI mockups (either on the wiki or semi-functional HTML/JavaScript prototypes) to start. Terri From drew at afccommercial.co.uk Mon Nov 14 11:19:48 2011 From: drew at afccommercial.co.uk (Drew Ferguson) Date: Mon, 14 Nov 2011 10:19:48 +0000 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <4EC0D7E9.5010201@zone12.com> References: <4EC0D7E9.5010201@zone12.com> Message-ID: <20111114101948.52274e5b@blacktav.fergiesontour.org> Hi I have been thinking of getting involved in helping the mailman team especially regarding the web interface where I am most at home. Perhaps assisting you with this might be a good introduction What would you suggest as a next step? On Mon, 14 Nov 2011 01:57:13 -0700 Terri Oda wrote: > GHC11 included an open source hackathon on Saturday, and I was lucky > enough to find some great people who spent the day helping with > usability testing and interface mockups for Mailman. > > We focused a bunch on the admin interfaces, which (unlike the archives > and the member options pages) haven't been particularly usability tested > before, and poked through using the first roughs for Mailman 3.0 (Thanks > again for letting us abuse your server, Florian!). I've got a huge pile > of notes and a suitcase filled with big paper prototypes, like the one > Mel's working on in this photo: > > https://photos-2.dropbox.com/i/l/tGZOpFHyUZYWdP8qQIWC3bCtfwQ7vqHMrwqhz8tGWC4/9183906/1321347600/f75f406/DSC_6385.JPG#20 > > Over the next week or so I'll be digitizing what we produced in the form > of photos, ui mockups and notes on the wiki. > > If anyone's interested in helping with the UI work, I could use some > help! This is a great place to start if you've always wanted to help > but weren't sure what to do or were worried your python skills weren't > up to snuff. I should have the photos of the paper prototypes up > Monday evening (I'm on US Mountain time) and I'd love some help > translating the photos into UI mockups (either on the wiki or > semi-functional HTML/JavaScript prototypes) to start. > > Terri > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/drew%40fergiesontour.org > > Security Policy: http://wiki.list.org/x/QIA9 -- Drew Ferguson AFC Commercial http://www.afccommercial.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From f at state-of-mind.de Mon Nov 14 15:36:47 2011 From: f at state-of-mind.de (Florian Fuchs) Date: Mon, 14 Nov 2011 15:36:47 +0100 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <4EC0D7E9.5010201@zone12.com> Message-ID: <2ac0-4ec12780-1-3e296e00@110130761> Hi, > (Thanks > again for letting us abuse your server, Florian!). You're very welcome! BTW: Thanks to Patrick Koetter for providing us with a virtual machine to play around with. > I've got a huge pile of notes and a suitcase filled with big paper prototypes, like the one > Mel's working on in this photo: > https://photos-2.dropbox.com/i/l/tGZOpFHyUZYWdP8qQIWC3bCtfwQ7vqHMrwqhz8tGWC4/9183906/1321347600/f75f406/DSC_6385.JPG#20 > > Over the next week or so I'll be digitizing what we produced in the form > of photos, ui mockups and notes on the wiki. That sounds (and looks) fantastic! I am SO looking forward to see the results. > If anyone's interested in helping with the UI work, I could use some > help! This is a great place to start if you've always wanted to help > but weren't sure what to do or were worried your python skills weren't > up to snuff. I should have the photos of the paper prototypes up > Monday evening (I'm on US Mountain time) and I'd love some help > translating the photos into UI mockups (either on the wiki or > semi-functional HTML/JavaScript prototypes) to start. I have streamlined the installation process for the web ui a bit and am in the process of setting up something like a "5 Minute Guide to Getting the Web UI Running" page in the wiki. I hope to post the link here within the next hour or so... Cheers Florian > > Terri > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/f%40state-of-mind.de > > Security Policy: http://wiki.list.org/x/QIA9 From barry at list.org Mon Nov 14 16:30:20 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 14 Nov 2011 10:30:20 -0500 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <4EC0D7E9.5010201@zone12.com> References: <4EC0D7E9.5010201@zone12.com> Message-ID: <20111114103020.328e91a1@limelight.wooz.org> On Nov 14, 2011, at 01:57 AM, Terri Oda wrote: >If anyone's interested in helping with the UI work, I could use some help! >This is a great place to start if you've always wanted to help but weren't >sure what to do or were worried your python skills weren't up to snuff. I >should have the photos of the paper prototypes up Monday evening (I'm on US >Mountain time) and I'd love some help translating the photos into UI mockups >(either on the wiki or semi-functional HTML/JavaScript prototypes) to start. Thanks Terri, this is fantastic. I'll take this opportunity to announce something that we've been chatting about in private for a little while. I want to officially announce that Terri and Florian are leading the new Mailman 3 web-ui sub-project. While I will continue to lead the core work, I am totally confident that Terri and Florian are not only talented and able to drive the web-ui work, they can also do a *much* better job at it than I can. We'll use the Launchpad bug tracker as the primary way to have the web-ui inform the core about API work that they need to best implement the web-ui. As other contributors have done, this is in some ways no different than anyone else doing integration work with the Mailman 3 core, and I will try to add any identified missing APIs as soon as possible. (Don't forget to tag such bugs with the 'mailman3' official tag). While we didn't hit my goal of a release on 11/11/11, I do think we've made a significant amount of progress recently. The next core release will be a beta, just as soon as I crack the authentication/authorization nut (if you have ideas for that, let's hear it!). Please join me in congratulating - and more importantly, helping! - Terri and Florian. Cheers, -Barry From barry at list.org Mon Nov 14 16:33:41 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 14 Nov 2011 10:33:41 -0500 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <20111114101948.52274e5b@blacktav.fergiesontour.org> References: <4EC0D7E9.5010201@zone12.com> <20111114101948.52274e5b@blacktav.fergiesontour.org> Message-ID: <20111114103341.7de10893@limelight.wooz.org> On Nov 14, 2011, at 10:19 AM, Drew Ferguson wrote: >I have been thinking of getting involved in helping the mailman team >especially regarding the web interface where I am most at home. > >Perhaps assisting you with this might be a good introduction > >What would you suggest as a next step? Drew, that's great, we'd love to have you help us out. The first step is to join the mailman-developers mailing list (I had to approve your post). Use this list to discuss any issues or work you do with Mailman, and the bug tracker to report any issues. If you're looking for things to do, perhaps you can describe your interests, and then Florian and Terri can look for interesting tasks that align with your interests. Also, if you are going to contribute code to the project, we should get you to sign an FSF copyright assignment for sooner rather than later. Would you be willing to do that? If so, I can get things started with the FSF. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From f at state-of-mind.de Mon Nov 14 18:14:28 2011 From: f at state-of-mind.de (Florian Fuchs) Date: Mon, 14 Nov 2011 18:14:28 +0100 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <20111114103341.7de10893@limelight.wooz.org> Message-ID: <2ac4-4ec14c80-b-75d41380@94036160> Hi, for those who are thinking about contributing to the new web UI (welcome, Drew!) and want to mess around with what's already there, here's a quick guide to installing the necessary components: http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running This guide will be subject to change (especially the branch locations on launchpad), but I wanted to send this out quickly to provide a starting point. Please bear in mind that it only covers a development installation of the web ui, so no mails will be sent nor received. Also: Installing it as described on a publicly accessible server would pose a security risk. So don't! ;-) The web UI basically consists of three components: GNU Mailman 3 (obviously), mailman-django (a pluggable Django application) and mailman.client (a ReST API client library). Many thanks go out to Anna Granudd and Benedict Stein who did almost all the work on mailman_django as part of their Google Summer of Code projects in 2010 and 2011! Please tell me if something doesn't work or if you need help setting this up. Cheers Florian On Monday, November 14, 2011 16:33 CET, Barry Warsaw wrote: > On Nov 14, 2011, at 10:19 AM, Drew Ferguson wrote: > > >I have been thinking of getting involved in helping the mailman team > >especially regarding the web interface where I am most at home. > > > >Perhaps assisting you with this might be a good introduction > > > >What would you suggest as a next step? > > Drew, that's great, we'd love to have you help us out. The first step is to > join the mailman-developers mailing list (I had to approve your post). Use > this list to discuss any issues or work you do with Mailman, and the bug > tracker to report any issues. > > If you're looking for things to do, perhaps you can describe your interests, > and then Florian and Terri can look for interesting tasks that align with your > interests. > > Also, if you are going to contribute code to the project, we should get you to > sign an FSF copyright assignment for sooner rather than later. Would you be > willing to do that? If so, I can get things started with the FSF. > > -Barry From drew at fergiesontour.org Mon Nov 14 18:25:42 2011 From: drew at fergiesontour.org (Drew Ferguson) Date: Mon, 14 Nov 2011 17:25:42 +0000 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <20111114103341.7de10893@limelight.wooz.org> References: <4EC0D7E9.5010201@zone12.com> <20111114101948.52274e5b@blacktav.fergiesontour.org> <20111114103341.7de10893@limelight.wooz.org> Message-ID: <20111114172542.2de7b258@blacktav.fergiesontour.org> On Mon, 14 Nov 2011 10:33:41 -0500 Barry Warsaw wrote: > On Nov 14, 2011, at 10:19 AM, Drew Ferguson wrote: > > >I have been thinking of getting involved in helping the mailman team > >especially regarding the web interface where I am most at home. > > > >Perhaps assisting you with this might be a good introduction > > > >What would you suggest as a next step? > > Drew, that's great, we'd love to have you help us out. The first step > is to join the mailman-developers mailing list (I had to approve your > post). Use this list to discuss any issues or work you do with Mailman, Sorry, my mistake - posting from wrong address > If you're looking for things to do, perhaps you can describe your > interests, and then Florian and Terri can look for interesting tasks > that align with your interests. Long time hacker on Plone/Zope projects and standalone python projects Was originally interested in working on CSS part of Web UI for skinning purposes but comfortable and interested in most aspects of this. Was a victim of sendmail in my youth acquiring a "mild" aversion to SMTP in general -- Drew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From drew at fergiesontour.org Mon Nov 14 18:46:21 2011 From: drew at fergiesontour.org (Drew Ferguson) Date: Mon, 14 Nov 2011 17:46:21 +0000 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <2ac4-4ec14c80-b-75d41380@94036160> References: <20111114103341.7de10893@limelight.wooz.org> <2ac4-4ec14c80-b-75d41380@94036160> Message-ID: <20111114174621.1707cd64@blacktav.fergiesontour.org> On Mon, 14 Nov 2011 18:14:28 +0100 "Florian Fuchs" wrote: > for those who are thinking about contributing to the new web UI > (welcome, Drew!) and want to mess around with what's already there, > here's a quick guide to installing the necessary components: > > http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running > Thanks, checking it now... -- Drew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From f at state-of-mind.de Mon Nov 14 22:50:41 2011 From: f at state-of-mind.de (Florian Fuchs) Date: Mon, 14 Nov 2011 22:50:41 +0100 Subject: [Mailman-Developers] GHC11 open source day Message-ID: <2ac1-4ec18d00-9-2c35bb00@150427780> Hi, > I'll take this opportunity to announce something that we've been chatting > about in private for a little while. I want to officially announce that Terri > and Florian are leading the new Mailman 3 web-ui sub-project. Thanks so much for the confidence, Barry! I hope I can live up to it and I'm really looking forward to work with Terri (and hopefully many more contributers). I'm sure it will be as much fun as it has been up until now. Happy to be part of this great project! Cheers Florian From f at state-of-mind.de Mon Nov 14 22:59:04 2011 From: f at state-of-mind.de (Florian Fuchs) Date: Mon, 14 Nov 2011 22:59:04 +0100 Subject: [Mailman-Developers] GHC11 open source day In-Reply-To: <2ac4-4ec14c80-b-75d41380@94036160> Message-ID: <2ac1-4ec18f00-11-2c35bb00@150427784> Hi, > http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running There was a typo in the second code block - where it said "$ bin/mailman" it should've said "$ bin/buildout" (thanks for correcting it, Tiago!). Also, confluence seems to display code blocks only with JavaScript activated. So if all you see is empty dashed borders between the paragraphs, try to activate JS... Florian From barry at list.org Wed Nov 16 03:24:49 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 15 Nov 2011 21:24:49 -0500 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <201111020926.46039.William@alt-config.net> References: <20111030190403.GG6534@state-of-mind.de> <87zkghok69.fsf@uwakimon.sk.tsukuba.ac.jp> <201111020926.46039.William@alt-config.net> Message-ID: <20111115212449.1124ebc3@resist.wooz.org> On Nov 02, 2011, at 09:26 AM, William Bagwell wrote: >I happen to like Topics and find them quite usefull. You are correct >however in that they are confusing. The few lists I have been on through >the years that enabled Topics were all social lists with non-technical >users. BTW, these lists started on ListServe and later migrated to >Mailman to save money. I'm presuming that the name and function "Topics" >originated with ListServe? The topics feature was funded and promoted by Control.com way back in the 2.1 alpha days (the NEWS file says it was released in 2.1a3 on 22-Oct-2001). IIRC we had quite a few discussions both internally and publicly about what Control.com needed, and how best to generalize the feature for the Mailman community. -Barry From barry at list.org Wed Nov 16 03:25:17 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 15 Nov 2011 21:25:17 -0500 Subject: [Mailman-Developers] Topics/sublists (was Re: Mailman headers roundup) In-Reply-To: <4EB1AA42.3090505@zone12.com> References: <20111030190403.GG6534@state-of-mind.de> <87zkghok69.fsf@uwakimon.sk.tsukuba.ac.jp> <201111020926.46039.William@alt-config.net> <4EB1AA42.3090505@zone12.com> Message-ID: <20111115212517.4a77c45d@resist.wooz.org> On Nov 02, 2011, at 02:38 PM, Terri Oda wrote: >One of the goals with Systers' summer of code work has been to get some of >this stuff integrated with Mailman, so if we're talking about fixing the >topic system, I highly recommend we take advantage of the lovely code already >prepared for us. :) We may even already have copyright releases on file for >this. Yes, please! :) -Barry From barry at list.org Wed Nov 16 03:38:19 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 15 Nov 2011 21:38:19 -0500 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <4EBC4D61.3060404@scu.edu> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <20111110203318.GA6587@state-of-mind.de> <4EBC4D61.3060404@scu.edu> Message-ID: <20111115213819.69a885c0@resist.wooz.org> On Nov 10, 2011, at 02:17 PM, C Nulk wrote: >I understand what you are saying. To me "Mediator" doesn't describe the >same information specifically because it is too general in meaning. >"List-Agent" as the header makes sense to me. I'm torn. I see where Patrick is coming from, but I also wonder as Chris does, whether Mediator is too generic. So I guess I'll punt for now. This bug tracks updating the headers: https://bugs.launchpad.net/mailman/+bug/883193 and it would be pretty easy to change X-Mailman-Version to List-Agent, Mediator, something else, or any of the above. -Barry From barry at list.org Wed Nov 16 03:45:23 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 15 Nov 2011 21:45:23 -0500 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> Message-ID: <20111115214523.299f2cb0@resist.wooz.org> On Oct 28, 2011, at 11:45 PM, Murray S. Kucherawy wrote: >I've got a separate draft that adds to Received: fields a tag that indicates >transitions of messages into administrative hold states (quarantining, timed >delivery and list moderation are included in the initial list of reasons) >ready to go. I just missed the -00 submission deadline prior to the next >IETF meeting in November, so it's not in the IETF datatracker but it is here: >http://www.blackops.org/~msk/draft-kucherawy-received-state.txt. Comments >welcome. > >The idea: When the MLM selects a message for moderation it would a Received: >field with such a tag, and then on release the next MTA in the chain adds >another Received: as per normal which, presumably, completes the handling >chain in a way that the end user can see what happened (i.e., when it entered >the hold and when it came out). > >This doesn't include a mechanism for tracking who did the approval, but >you've got that separately on your list anyway. That's pretty interesting. Currently MM3 doesn't add any Received headers, but this bug tracks that: https://bugs.launchpad.net/mailman/+bug/885715 -Barry From barry at list.org Wed Nov 16 03:52:31 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 15 Nov 2011 21:52:31 -0500 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111029043922.GC2272@state-of-mind.de> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> Message-ID: <20111115215231.17d1fb42@resist.wooz.org> On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote: >I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 > instead: > > A Mediator attempts to preserve the original Author's information in > the message it reformulates but is permitted to make meaningful > changes to the message content or envelope. > > A Mediator's role is complex and contingent, for example, modifying > and adding content or regulating which Users are allowed to > participate and when. The common example of this role is a group > Mailing List. > > (see section "2.1.4. Mediator" and also section "5. Mediators") That makes a good case for Mediator. >Hmm, if there are no intermediate processes between receiving a message and >approving it a List-Approved-Date seems fine. But if there are we run into the >same problem as described below with List-Archived-Date - you can't tell when >it was queued and when processing took place. > >Adding a second header might make the useful distinction: > >List-Received-Date > RFC 2822 date timestamp when message was received by MLM > >List-Approved-Date > RFC 2822 date timestamp when message was approved by moderator What if the message is automatically approved? Does it get a List-Approved-Date header? Merging with Murray's concept of Received states, it might just make more sense to put all that information into Received headers. >> Another header that might be useful here would be List-Approved-By which >> could be the name or email address of the moderator who approved it. Right >> now, MM3 doesn't fill that in, and it could of course be filled in by say >> list-owner at example.com, but in MM3 it could be potentially filled in with >> the preferred address for the moderator that approved it. > >I see the benefit because it helps if you moderate in a team. But I fear the >anger of people whose postings we decline. They search for moderator >identities and then start molesting them e.g. by subscribing them to mailing >lists that don't require opt-in. (Happend to me python.org postmaster. The >angry person subscribed my address to various pr0n mailing lists and it took >me weeks to get unsubscribed.) Good point. I do want to provide the opportunity to "anonymize" ownership roles via generic owner email addresses. E.g. on the listinfo page. >ACK with the notion that hashtag seems to closely realted with twitter and a >more general 'tag' would stay away from that. > >Is there or should there be a distinction between 'tag' and http 'keywords' >? Should we >use 'keywords' instead? We can't use Keywords, because that header is already used as input to various functions such as the topic tagger. We have to use a different header for "output". I can't think of anything better than List-Tags though. >List-Archive-Send-Date > 'List-Archive-Send-Date' sounds pretty clumsy and overly long. OTOH we > needn't care, as it will only be added to messages that go to the > archive, right? > >Archive-Transmit-Date, Archive-Transfer-Date, Archiv-Transfer > Marks the beginning in opposition to Archive-Received-Date or > Archive-Received. But then again an archiver could simply add a > Received:-header! > >Not an easy one. Agreed. :/ -Barry From stephen at xemacs.org Wed Nov 16 04:26:59 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 16 Nov 2011 12:26:59 +0900 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <20111115213819.69a885c0@resist.wooz.org> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <20111110203318.GA6587@state-of-mind.de> <4EBC4D61.3060404@scu.edu> <20111115213819.69a885c0@resist.wooz.org> Message-ID: <874ny4karg.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > On Nov 10, 2011, at 02:17 PM, C Nulk wrote: > > >I understand what you are saying. To me "Mediator" doesn't describe the > >same information specifically because it is too general in meaning. > >"List-Agent" as the header makes sense to me. Mediator generalizes across decision-makers (human, program) and applications (news, web forum). But it's more specialized in the context of list management, IMHO applicable only when the list agent changes the content (other than prepending/appending brief "This is the XXX list" notices). I think the two headers have different roles. > and it would be pretty easy to change X-Mailman-Version to List-Agent, > Mediator, something else, or any of the above. The replacement for X-Mailman-Version and X-Mailer and User-Agent (in Mailman usage) should be replaced by List-Agent (or folded into User-Agent, but I prefer List-Agent for this purpose). > So I guess I'll punt for now. This bug tracks updating the headers: > > https://bugs.launchpad.net/mailman/+bug/883193 Should this post have gone to the bug instead? (I might not have bothered if so, but usually I'd be willing to update a bug if either a policy is in place or explicitly requested.) From stephen at xemacs.org Wed Nov 16 05:02:10 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 16 Nov 2011 13:02:10 +0900 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111115215231.17d1fb42@resist.wooz.org> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> <20111115215231.17d1fb42@resist.wooz.org> Message-ID: <8739dok94t.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote: > > >I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 > > instead: [...] > > That makes a good case for Mediator. +1, but only for the case of modification IMO. >Adding a second header might make the useful distinction: > > > >List-Received-Date > > RFC 2822 date timestamp when message was received by MLM I think this is best done with an RFC 5321 Received header as Murray suggests, even though I don't really think of MLMs as MTAs (or MUAs for that matter). OTOH, RFC 5321 requires that MTAs be pretty lenient about the presence of non-standardized trace headers, and specifically forbids altering them IIRC. > >List-Approved-Date > > RFC 2822 date timestamp when message was approved by moderator > > What if the message is automatically approved? Does it get a > List-Approved-Date header? Merging with Murray's concept of Received states, > it might just make more sense to put all that information into Received > headers. -1 on using "Received" for approvals. The approval Also (per site or list policy) I would suggest that instead of a family of List-Approved-* headers, there should be a single List-Approved header with variable format. If present, it MUST contain an action ("Approved", "Denied", "Rejected", "Held"), MUST contain "at" and a timestamp, MAY contain "because" and a rule ("list member", "moderator", "spam score exceeded threshold"), and MAY contain "by" and a moderator ID (arbitrary token, could be a name, a numerial ID, or generic tokens like "mailman" (the name of the MLM in general), "list-owner", "moderator"). (I'm not wedded to the field tags, of course.) The actions other than "Approved" would be used in cases where non-approvals are sent to the list or site owner for debugging purposes etc. Maybe "List-Action" or "List-Approval" or some such would be a better field tag. I would suggest that it be inserted into the trace stream "as if" it were a "Received" header (or maybe before the Resent-* cluster?) > >I see the benefit because it helps if you moderate in a team. But > >I fear the anger of people whose postings we decline. They search > >for moderator identities Secret moderator IDs would serve to anonymize. > We can't use Keywords, because that header is already used as input > to various functions such as the topic tagger. Worse, it's already standardized by RFC 5322. In general, I take a dim view of a MLM hijacking any headers standardized by RFC 5322; those headers are basically for use of *authors*, though the common practice of adding various tags to Subject doesn't bother me *too* much, and exceptions might need to be made for Date and (especially) Message-ID, although maybe the MLM can just add those as Resent-* fields and abdicate responsibility if the user did. > We have to use a different header for "output". I can't think of > anything better than List-Tags though. What's wrong with List-Topics or List-Keywords? List-Tags is OK, I guess, but I think of tags as user-provided information for other users (not necessarily provided by the author, and not necessarily usable for automatic association of different posts). > >List-Archive-Send-Date How about just List-Archived, make it a formatted field "in[to] $ARCHIVE at $TIMESTAMP", and let the sent/received distinction be made by using the standard trace header of "Received" (as already suggested)? The "in" version is used when ARCHIVE contains a user-accessible URL (either generic for the list or post-specific), and "to" is for cases where the user URL is not necessarily known but the message is sent "to" an archiver and information about user access is given out-of-band. From msk at cloudmark.com Wed Nov 16 07:02:31 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 15 Nov 2011 22:02:31 -0800 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111115214523.299f2cb0@resist.wooz.org> References: <20111013113012.35438eee@limelight.wooz.org> <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111115214523.299f2cb0@resist.wooz.org> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Barry Warsaw > Sent: Tuesday, November 15, 2011 6:45 PM > To: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > That's pretty interesting. Currently MM3 doesn't add any Received > headers, but this bug tracks that: > > https://bugs.launchpad.net/mailman/+bug/885715 Excellent. The draft is now posted: http://datatracker.ietf.org/doc/draft-kucherawy-received-state/ Comments welcome, ideally to the ietf-smtp mailing list. -MSK From msk at cloudmark.com Wed Nov 16 07:06:25 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Tue, 15 Nov 2011 22:06:25 -0800 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: <874ny4karg.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <20111110203318.GA6587@state-of-mind.de> <4EBC4D61.3060404@scu.edu> <20111115213819.69a885c0@resist.wooz.org> <874ny4karg.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Whatever you folks decide about List-Agent vs. Mediator, I'd be happy to help write up an RFC draft that registers the various header field names and descriptions and start it on its path to standardization. However, the IETF might want to change it to the opposite name from the one you pick, or even something else. So you're quite possibly going to repeat this debate in their forum, so save (some of) your strength. "Just saying." :-) -MSK From stephen at xemacs.org Wed Nov 16 08:29:11 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 16 Nov 2011 16:29:11 +0900 Subject: [Mailman-Developers] Mailman headers roundup In-Reply-To: References: <20111030190403.GG6534@state-of-mind.de> <20111102110657.00ca7ddf@resist> <20111110203318.GA6587@state-of-mind.de> <4EBC4D61.3060404@scu.edu> <20111115213819.69a885c0@resist.wooz.org> <874ny4karg.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87y5vgikzc.fsf@uwakimon.sk.tsukuba.ac.jp> Murray S. Kucherawy writes: > However, the IETF might want to change it to the opposite name from > the one you pick, or even something else. So you're quite possibly > going to repeat this debate in their forum, so save (some of) your > strength. Or the posts. ;-) From CNulk at scu.edu Wed Nov 16 17:10:03 2011 From: CNulk at scu.edu (C Nulk) Date: Wed, 16 Nov 2011 08:10:03 -0800 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <20111115215231.17d1fb42@resist.wooz.org> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> <20111115215231.17d1fb42@resist.wooz.org> Message-ID: <4EC3E05B.9050809@scu.edu> On 11/15/2011 6:52 PM, Barry Warsaw wrote: > On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote: > >> I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 >> instead: >> >> A Mediator attempts to preserve the original Author's information in >> the message it reformulates but is permitted to make meaningful >> changes to the message content or envelope. >> >> A Mediator's role is complex and contingent, for example, modifying >> and adding content or regulating which Users are allowed to >> participate and when. The common example of this role is a group >> Mailing List. >> >> (see section "2.1.4. Mediator" and also section "5. Mediators") > That makes a good case for Mediator. Hmmm. To me, the above definition for Mediator is reason enough to abandon it (for the time at least) because it is not well thought out regarding everything that may touch, modify, add content, regulate user, etc. Together with the above and a line from a previous message Patrick sent to the list: "The term 'Mediator' describes the same, but it is general in meaning. Any instance modifying and forwarding a message can use it. " I can't help but consider the rash of useless Mediator headers. Consider the following example: Person 1 sends a message to a list which is then sent to Person 2. Person 1's site has separate appliances for the MTA, Spam checking, Anti-Virus, and Spy-ware, likewise for the receiver's site and the site the MLM is for the list. My reading of the above definitions tells me: 1. Person 1's MUA adds a Mediator header (creating a message is a simple special case of modifying/adding a message, 2. Person 1's site adds 4 additional Mediator headers (one each for the MTA, Spam, Anti-Virus, Spy-ware since each modify/forward/add to the message, 3. The MLM's site adds 9 additional Mediator headers (4 inbound [item 2], 1 for the MLM [maybe more], and 4 outbound), 4. Person 2's site adds 4 additional Mediator headers (4 inbound [item 2]), 5. Person 2's MUA may or may not add a Mediator header depending on any rules/filters Person 2 has in place. So, at the end of this simple posting of a message to a list, we have 18+ Mediator headers, one for each time an instance adds content, modifies a message, or regulates a user. Granted, I may be making this a worst case scenario, but also consider any sites the message is relayed through - adding even more Mediator headers. Looking at a worst case scenario helps see where the problems occur and cracks in specifications happen. I am not opposed to a Mediator header. I just think since our discussion is focused on MLMs that List-Agent is the best choice that all MLM developers can come to an agreement on. As for other applications (news, web forum, etc), a discussion with those developers should (and needs to) take place to come up with a more generic header - be it Mediator or not. In any case, let's focus on MLM related headers, like List-Agent :), and then work on a more generic, non-conflicting header for others at a later time. I just see including non-MLM information into a MLM header discussion as feature-creep. >> Hmm, if there are no intermediate processes between receiving a message and >> approving it a List-Approved-Date seems fine. But if there are we run into the >> same problem as described below with List-Archived-Date - you can't tell when >> it was queued and when processing took place. >> >> Adding a second header might make the useful distinction: >> >> List-Received-Date >> RFC 2822 date timestamp when message was received by MLM >> >> List-Approved-Date >> RFC 2822 date timestamp when message was approved by moderator > What if the message is automatically approved? Does it get a > List-Approved-Date header? Merging with Murray's concept of Received states, > it might just make more sense to put all that information into Received > headers. The only issue I can see is if the Received headers are removed as part of processing, whether in an appliance, an MTA, or an MUA. I know it shouldn't happen but I received messages with missing Received headers. Having the information in a List-* header wouldn't hurt. > >>> Another header that might be useful here would be List-Approved-By which >>> could be the name or email address of the moderator who approved it. Right >>> now, MM3 doesn't fill that in, and it could of course be filled in by say >>> list-owner at example.com, but in MM3 it could be potentially filled in with >>> the preferred address for the moderator that approved it. >> I see the benefit because it helps if you moderate in a team. But I fear the >> anger of people whose postings we decline. They search for moderator >> identities and then start molesting them e.g. by subscribing them to mailing >> lists that don't require opt-in. (Happend to me python.org postmaster. The >> angry person subscribed my address to various pr0n mailing lists and it took >> me weeks to get unsubscribed.) > Good point. I do want to provide the opportunity to "anonymize" ownership > roles via generic owner email addresses. E.g. on the listinfo page. :) So far, I haven't had anyone that grumpy at me to add me to various "other" lists. But they do occasionally go over my head to get authorization so they can post without being moderated (at least until they send a message that exceeds the size limit). > >> ACK with the notion that hashtag seems to closely realted with twitter and a >> more general 'tag' would stay away from that. >> >> Is there or should there be a distinction between 'tag' and http 'keywords' >> ? Should we >> use 'keywords' instead? > We can't use Keywords, because that header is already used as input to various > functions such as the topic tagger. We have to use a different header for > "output". I can't think of anything better than List-Tags though. > >> List-Archive-Send-Date >> 'List-Archive-Send-Date' sounds pretty clumsy and overly long. OTOH we >> needn't care, as it will only be added to messages that go to the >> archive, right? >> >> Archive-Transmit-Date, Archive-Transfer-Date, Archiv-Transfer >> Marks the beginning in opposition to Archive-Received-Date or >> Archive-Received. But then again an archiver could simply add a >> Received:-header! >> >> Not an easy one. > Agreed. :/ > > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/cnulk%40scu.edu > > Security Policy: http://wiki.list.org/x/QIA9 Thanks for bearing with me, Chris From iane at sussex.ac.uk Wed Nov 23 14:16:13 2011 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 23 Nov 2011 13:16:13 +0000 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <4EC3E05B.9050809@scu.edu> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> <20111115215231.17d1fb42@resist.wooz.org> <4EC3E05B.9050809@scu.edu> Message-ID: <9C724CB9-C8A6-4D81-83FF-73EFAD9E7BDE@sussex.ac.uk> On 16 Nov 2011, at 16:10, C Nulk wrote: > > I can't help but consider the rash of useless Mediator headers. > Consider the following example: > > Person 1 sends a message to a list which is then sent to Person 2. > Person 1's site has separate appliances for the MTA, Spam checking, > Anti-Virus, and Spy-ware, likewise for the receiver's site and the site > the MLM is for the list. My reading of the above definitions tells me: > 1. Person 1's MUA adds a Mediator header (creating a message is a simple > special case of modifying/adding a message, But, there are already headers to identify the creator. There's no need to use a mediator header to duplicate other information. > 2. Person 1's site adds 4 additional Mediator headers (one each for the > MTA, Spam, Anti-Virus, Spy-ware since each modify/forward/add to the > message, The MTA would use a "received" header, not a mediator header. If the message is routed through the other systems, then they should already add received headers. If the message isn't routed through those systems (e.g., the systems are plugged in to the MTA, then there's no need to add mediator headers). > 3. The MLM's site adds 9 additional Mediator headers (4 inbound [item > 2], 1 for the MLM [maybe more], and 4 outbound), > 4. Person 2's site adds 4 additional Mediator headers (4 inbound [item 2]), > 5. Person 2's MUA may or may not add a Mediator header depending on any > rules/filters Person 2 has in place. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From felipe at felipegasper.com Sat Nov 26 02:15:00 2011 From: felipe at felipegasper.com (Felipe Gasper) Date: Fri, 25 Nov 2011 19:15:00 -0600 Subject: [Mailman-Developers] building/running alpha 8 on MacOS Message-ID: <4ED03D94.3070709@felipegasper.com> Is this possible? I?m trying: python bootstrap.py -d ?and that works. (It seems to need the -d; otherwise it won?t find the setuptools that MacPorts installs.) But when I do bin/buildout, I get this mess: -------------------------------------- Traceback (most recent call last): File "/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmp3WxCTH", line 11, in execfile('/Users/felipe/code/mailman/./setup.py') File "/Users/felipe/code/mailman/./setup.py", line 110, in 'zope.testing<4', File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/core.py", line 113, in setup _setup_distribution = dist = klass(attrs) File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/dist.py", line 223, in __init__ _Distribution.__init__(self,attrs) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/dist.py", line 270, in __init__ self.finalize_options() File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/dist.py", line 256, in finalize_options ep.load()(self, ep.name, value) File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/pkg_resources.py", line 1912, in load raise ImportError("%r has no %r attribute" % (entry,attr)) ImportError: has no 'check_packages' attribute While: Installing. Processing develop directory '/Users/felipe/code/mailman/.'. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py", line 1805, in main File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py", line 446, in install File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py", line 686, in _develop File "/private/var/folders/K+/K+C9J9XbFpa8wjRCkcMl1U+++TI/-Tmp-/tmpQ_QZXK/zc.buildout-1.5.2-py2.6.egg/zc/buildout/easy_install.py", line 1189, in develop AssertionError --------------------------------- Does buildout not work on MacOS? -FG From barry at list.org Sun Nov 27 02:02:05 2011 From: barry at list.org (Barry Warsaw) Date: Sat, 26 Nov 2011 20:02:05 -0500 Subject: [Mailman-Developers] building/running alpha 8 on MacOS In-Reply-To: <4ED03D94.3070709@felipegasper.com> References: <4ED03D94.3070709@felipegasper.com> Message-ID: <20111126200205.4a5489eb@limelight.wooz.org> On Nov 25, 2011, at 07:15 PM, Felipe Gasper wrote: >I?m trying: > >python bootstrap.py -d > >?and that works. (It seems to need the -d; otherwise it won?t find the >setuptools that MacPorts installs.) Hmm, the distribute_setup.py should pick up the right version of distribute instead of setuptools. I don't know what version MacPorts has, but I do know that on Debian/Ubuntu, setuptools is really distribute. These days, buildout is only needed for the test suite, so you could try creating a virtualenv and running `python setup.py install` from there. You might have to provide --no-site-packages to virtualenv if the MacPorts packages get in the way. -Barry From stephen at xemacs.org Sun Nov 27 13:43:06 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 27 Nov 2011 21:43:06 +0900 Subject: [Mailman-Developers] building/running alpha 8 on MacOS In-Reply-To: <4ED03D94.3070709@felipegasper.com> References: <4ED03D94.3070709@felipegasper.com> Message-ID: <87ehwtpwh1.fsf@uwakimon.sk.tsukuba.ac.jp> Felipe Gasper writes: > Does buildout not work on MacOS? It worked for me in the past, so if it doesn't work for you there's a bug somewhere that needs fixing. From CNulk at scu.edu Mon Nov 28 20:01:58 2011 From: CNulk at scu.edu (C Nulk) Date: Mon, 28 Nov 2011 11:01:58 -0800 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <9C724CB9-C8A6-4D81-83FF-73EFAD9E7BDE@sussex.ac.uk> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> <20111115215231.17d1fb42@resist.wooz.org> <4EC3E05B.9050809@scu.edu> <9C724CB9-C8A6-4D81-83FF-73EFAD9E7BDE@sussex.ac.uk> Message-ID: <4ED3DAA6.9010307@scu.edu> Hello Ian, Sorry I am a bit late in responding but with our Thanksgiving holiday and me taking a few days of vacation I was away from email. I understand what you are saying in your message but I think you possibly missed my point. Given the definitions previously proposed for the "Mediator" header, I believe it is far too generic to be useful. To paraphrase the previous definitions for the "Mediator" header, "any program/instance/etc. that modifies, adds content, regulates Users, etc. can use it [the 'Mediator' header]". To me, a reasonable reading and understanding of the definition[s] tells me the MUA, the MTA, any appliances, any other program/instance [including devices]/etc. can add the "Mediator" header REGARDLESS of whether or not that appliance/program/instance/device has added a "Received" header, a "User-Agent" header, or any other pertinent header(s). Since I think the "Mediator" header is, at this time, poorly defined and the initial point of the discussion was about having a "List-Agent" header for MLMs, I say "List-Agent". As for my example you pulled apart :), I deliberately made it a worst case scenario just to highlight how the "Mediator" header was poorly defined. In fact, given the "Mediator" header definitions and your comments, you also highlight how poor the definition is since not only will the "Mediator" headers be added but also all the additional "Received" headers. I may be wrong in that you assume that if "Received" headers are used then the "Mediator" headers won't be used. However, the definition does not precluded having both, thus doubling (or more) on the number of headers. Again, I say stick with the "List-Agent" header for MLMs. It is narrowly defined and limited in scope, precisely what a header should be to be effective. Thanks for listening/reading :), Chris On 11/23/2011 5:16 AM, Ian Eiloart wrote: > On 16 Nov 2011, at 16:10, C Nulk wrote: > >> I can't help but consider the rash of useless Mediator headers. >> Consider the following example: >> >> Person 1 sends a message to a list which is then sent to Person 2. >> Person 1's site has separate appliances for the MTA, Spam checking, >> Anti-Virus, and Spy-ware, likewise for the receiver's site and the site >> the MLM is for the list. My reading of the above definitions tells me: >> 1. Person 1's MUA adds a Mediator header (creating a message is a simple >> special case of modifying/adding a message, > But, there are already headers to identify the creator. There's no need to use a mediator header to duplicate other information. > >> 2. Person 1's site adds 4 additional Mediator headers (one each for the >> MTA, Spam, Anti-Virus, Spy-ware since each modify/forward/add to the >> message, > The MTA would use a "received" header, not a mediator header. If the message is routed through the other systems, then they should already add received headers. If the message isn't routed through those systems (e.g., the systems are plugged in to the MTA, then there's no need to add mediator headers). > >> 3. The MLM's site adds 9 additional Mediator headers (4 inbound [item >> 2], 1 for the MLM [maybe more], and 4 outbound), >> 4. Person 2's site adds 4 additional Mediator headers (4 inbound [item 2]), >> 5. Person 2's MUA may or may not add a Mediator header depending on any >> rules/filters Person 2 has in place. From CNulk at scu.edu Mon Nov 28 20:18:47 2011 From: CNulk at scu.edu (C Nulk) Date: Mon, 28 Nov 2011 11:18:47 -0800 Subject: [Mailman-Developers] Mailman v3 and ban-list Message-ID: <4ED3DE97.8020500@scu.edu> Hello, I thought I would ask a quick question on the development of Mailman 3. Over in the Mailman-Users list, Mark Sapiro mentions that he adds a regex into the ban_list of all of his lists. Is there any consideration being given to having a global ban_list which applied across all lists for a mailman instance? It would be nice to have both a global and a list-specific ban_list mechanism. The global version would allow one to put in one ban entry in for all lists. An example would be Mark's regex for answerpot (a list message harvester). Just a thought, Chris From Tim.VanDyne at valleyair.org Mon Nov 28 21:39:14 2011 From: Tim.VanDyne at valleyair.org (Tim Van Dyne) Date: Mon, 28 Nov 2011 12:39:14 -0800 Subject: [Mailman-Developers] Mailman v3 and ban-list In-Reply-To: <4ED3DE97.8020500@scu.edu> References: <4ED3DE97.8020500@scu.edu> Message-ID: <0743ACC63489E8418A38B6F78DCB1DDC0355FD21@mailfre.SJVAPCD.LOCAL> I know the usual answer I've seen for this particular feature in the past has been essentially been "use your MTA" when blocking globally, because it is quite easy to do. But I want to second Chris' thought because those who don't have access to the MTA's config are unable to do anything about it. And those who administer mailman services but simply do not know how to configure the MTA to do this (like staff that cover me when I'm off of work) would find this sort of feature to be a lifesaver when they're directed to block a certain address on the server but are faced with over 100 lists to insert the address into. Personally I'd just write a script to do it or configure the MTA, but I do see a clear need for something like this if it's possible at this stage in development to consider if it hasn't been already. -----Original Message----- Subject: [Mailman-Developers] Mailman v3 and ban-list Hello, I thought I would ask a quick question on the development of Mailman 3. Over in the Mailman-Users list, Mark Sapiro mentions that he adds a regex into the ban_list of all of his lists. Is there any consideration being given to having a global ban_list which applied across all lists for a mailman instance? It would be nice to have both a global and a list-specific ban_list mechanism. The global version would allow one to put in one ban entry in for all lists. An example would be Mark's regex for answerpot (a list message harvester). Just a thought, Chris From barry at list.org Tue Nov 29 01:18:55 2011 From: barry at list.org (Barry Warsaw) Date: Mon, 28 Nov 2011 19:18:55 -0500 Subject: [Mailman-Developers] Mailman v3 and ban-list In-Reply-To: <4ED3DE97.8020500@scu.edu> References: <4ED3DE97.8020500@scu.edu> Message-ID: <20111128191855.16f283e2@resist.wooz.org> On Nov 28, 2011, at 11:18 AM, C Nulk wrote: >Is there any consideration being given to having a global ban_list which >applied across all lists for a mailman instance? MM3 already supports global bans. :) -Barry From msk at cloudmark.com Tue Nov 29 01:33:37 2011 From: msk at cloudmark.com (Murray S. Kucherawy) Date: Mon, 28 Nov 2011 16:33:37 -0800 Subject: [Mailman-Developers] New RFC on using DKIM with MLMs In-Reply-To: <8739dok94t.fsf@uwakimon.sk.tsukuba.ac.jp> References: <871uugpclf.fsf@uwakimon.sk.tsukuba.ac.jp> <20111024210403.1395d359@resist.wooz.org> <7AF6F01C-BF79-4B8C-9D60-36EEABD6EFF1@sussex.ac.uk> <20111026153344.GD18712@state-of-mind.de> <20111028132713.23d2a395@limelight.wooz.org> <20111028203601.GA2311@state-of-mind.de> <20111028184328.68379aa6@limelight.wooz.org> <20111029043922.GC2272@state-of-mind.de> <20111115215231.17d1fb42@resist.wooz.org> <8739dok94t.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > -----Original Message----- > From: mailman-developers-bounces+msk=cloudmark.com at python.org [mailto:mailman-developers-bounces+msk=cloudmark.com at python.org] On Behalf Of Stephen J. Turnbull > Sent: Tuesday, November 15, 2011 8:02 PM > To: Barry Warsaw > Cc: mailman-developers at python.org > Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs > > Barry Warsaw writes: > > On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote: > > > > >I suggest we use the term 'Mediator' as introduced by D. Crocker in > RFC 5598 > > instead: > [...] > > > > That makes a good case for Mediator. > > +1, but only for the case of modification IMO. Works for me. If it includes the hostname where the mediator is running, it can go a long way toward debugging things like DKIM validation problems or other "What the hell happened to this message?" things. But then again, if we go with the received-state idea, mailman could do what other MTAs do and write its name and version information in a comment in a Received field. > > >List-Approved-Date > > > RFC 2822 date timestamp when message was approved by > moderator > > > > What if the message is automatically approved? Does it get a > > List-Approved-Date header? Merging with Murray's concept of Received > states, > it might just make more sense to put all that information > into Received > headers. > > -1 on using "Received" for approvals. The approval Incomplete thought here? If the received-state idea is adopted, a second Received: is the perfect way to show when something entered an approval hold and when it came out, without registering a new header field dedicated for this purpose. > Also (per site or list policy) I would suggest that instead of a family > of List-Approved-* headers, there should be a single List-Approved > header with variable format. If present, it MUST contain an action > ("Approved", "Denied", "Rejected", "Held"), MUST contain "at" and a > timestamp, MAY contain "because" and a rule ("list member", > "moderator", "spam score exceeded threshold"), and MAY contain "by" and > a moderator ID (arbitrary token, could be a name, a numerial ID, or > generic tokens like "mailman" (the name of the MLM in general), "list- > owner", "moderator"). (I'm not wedded to the field tags, of course.) > [...] If this is meant to be machine-parsable versus user-parsable, it'll need to be more rigid than that. But I see where you're going. Phrases in particular are a pain unless they're meant to be quoted strings that machines don't care about using. So I guess we need to be clear on how these various new fields are expected to be used. > Secret moderator IDs would serve to anonymize. As long as the MLM keeps track of who they are so administrators can track actions, sure. > > We can't use Keywords, because that header is already used as input > > to various functions such as the topic tagger. > > Worse, it's already standardized by RFC 5322. In general, I take a dim > view of a MLM hijacking any headers standardized by RFC 5322; those > headers are basically for use of *authors*, though the common practice > of adding various tags to Subject doesn't bother me *too* much, and > exceptions might need to be made for Date and (especially) Message-ID, > although maybe the MLM can just add those as Resent-* fields and > abdicate responsibility if the user did. I think RFC5598 suggests that the MLM re-mailing should generate a new Message-ID and a new Date, and observes the common Subject: tagging practice, but I don't think anyone expects the other stuff to be renamed to Resent-* first. > What's wrong with List-Topics or List-Keywords? List-Tags is OK, I > guess, but I think of tags as user-provided information for other users > (not necessarily provided by the author, and not necessarily usable for > automatic association of different posts). As above, how are they typically consumed? That might help to answer these questions. -MSK From barry at list.org Tue Nov 29 13:18:45 2011 From: barry at list.org (Barry Warsaw) Date: Tue, 29 Nov 2011 07:18:45 -0500 Subject: [Mailman-Developers] [Bug 860159] Re: Mailman 3.0 support for Postgres In-Reply-To: <20111129101817.23025.16195.malone@wampee.canonical.com> References: <20110927001849.9391.31768.malonedeb@gac.canonical.com> <20111129101817.23025.16195.malone@wampee.canonical.com> Message-ID: <20111129071845.284587b9@limelight.wooz.org> On Nov 29, 2011, at 10:18 AM, Stephane Wirtel \(OpenERP\) wrote: >I'm interested by the support of PostgreSQL by Mailman, is there some >news for a future release with this feature ? PostgreSQL support is in Mailman 3 bzr. It will be available in beta 1, but I have no eta on that at the moment. -Barry