Re: [Mailman-Developers] dkim-signature headers
On 2/8/07 10:27 AM, Barry Warsaw [EMAIL PROTECTED] wrote: Me too. Here's my discussion on the topic, including a concrete proposal for Mailman 2.1.10 and 2.2/3.0. Feel free to comment on the wiki on in this thread. http://wiki.list.org/x/OgM Looks good to me. IOW, a valid signed List-ID header should be indication enough that all other signatures were subject to breakage because of mailing list garbling Probably should be ...all prior signatures... not ...other --- Since the public key for a DKIM signature comes from DNS (as I understand it), an administrative detail is that a mailing list operator has to provide for the key's existence in order for Mailman's attempt to sign to be effective. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] dkim-signature headers
On 2/6/07 5:51 PM, Bob Puff [EMAIL PROTECTED] wrote: If a bad DK isn't bad, then how is this supposed to help spam? I mean, if the mere presence of some signature in the headers will increase the likelihood of an email being delivered (or at least help it NOT be tagged as spam), surely the spammers will pick up on this, and the whole benefit lost. They have. Much of the spam I see from the new breed legitimate spammers* contains DKIM signatures. (I have to assume those verify OK, else why put them in.) * new breed legitimate spammers: That is, in the US, those who carefully conform to CAN-SPAM as far as one can tell--one can't really tell whether they share unsubscribed addresses with other spammers as likely new victims without probing. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] dkim-signature headers
On 2/7/07 7:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote: Either they have a milter that refuses to resign or they have a working milter. If their milter doesn't resign, then less harm is done by stripping the header. If their milter does resign, then less harm is done by allowing it to resign, even if Mailman has broken the original signature. Or they have an MTA that doesn't care at all about DKIM, in which case less harm is done by not stripping. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] dkim-signature headers
On 2/7/07 8:46 AM, Barry Warsaw [EMAIL PROTECTED] wrote: Should we strip DKIM by default or not? Not strip by default. Even though that changes the default vs the most recent Mailman, it leaves the default alone for everyone who jumps to 2.1.10 from earlier versions. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] dkim-signature headers
On 2/7/07 9:19 AM, Barry Warsaw [EMAIL PROTECTED] wrote: OTOH, how many people would smell something fishy if this message had this header: From: Barry Warsaw [EMAIL PROTECTED] With many MUAs (including the vast majority of different MUA programs and versions) that would pass totally unnoticed, as the user only sees From: Barry Warsaw without taking some action. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] dkim-signature headers
On 2/1/07 5:46 PM, Bob Puff [EMAIL PROTECTED] wrote: I have demime in front of most of my larger lists, and I can tell you from casual peeks at the incoming copy that I keep, there are far too many people who send html email. Anyone using Windows machine, or a Mac starting with Tiger who hasn't made a change to the defaults out of the box sends HTML mail. Before Tiger, Mac users were sending text/rich. And there is little incentive to change the defaults unless one is an Internet veteran. Plus AOL. There is some self-selection away from HTML in the mailing list population, since many folks using lists know what's wrong with HMTL mail, and others get chided for sending it. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Pickles begone
On 12/29/06 2:17 PM, Barry Warsaw [EMAIL PROTECTED] wrote: I'm about to merge my SQLAlchemy branch to the trunk. I'm happy enough with where this is going to commit to this approach going forward. [Loud cheering from the sidelines!!] (An upcoming rewrite of our mail handling system will also be eliminating (at least most) pickles. At present, these are cleverly stored in MySQL, and getting the data out in ad hoc queries is remarkably difficult.) --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Crypto-sign to post
On 11/9/06 2:54 AM, Stefan Schlott [EMAIL PROTECTED] wrote: Another possible problem: And yet another problem: the proliferation of different ways to create signed messages, and recognizing them successfully. I could sign messages at least three ways just using Apple's Mail.app: GPG with a suitable plug-in (what I do) in SMIME form BEGIN SIGNED MESSAGE form Whatever is native to Mail.app (involves getting a [free] personal certificate from Thawte, and putting it into the keychain. Signing is automatic at that point). I don't know what format that produces--I've been meaning to find out. (No, you won't find me on the public key servers--we use this inhouse only.) I think all traces of the signature need to be stripped after it is used for verification (but I could be wrong). All that (and the other problems cited in this thread) aside, I advocated this idea about 5 years ago, and still favor it. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] OS X Mailman Python
On 9/28/06 7:16 PM, Barry Warsaw [EMAIL PROTECTED] wrote: If you look at the source, you'll see that the #! line is actually @PYTHON@ which gets substituted by configure at build time. I forget exactly why, but the standard #! /usr/bin/env python invocation caused problems for people, so now we hardcode it via configure. #! /usr/bin/env python in an old-enough RedHat would have launched Python 1.5.2 when that version was long dead (deceased, etc). That's probably not the only example of the reason for configure to select the Python to be used--essentially any installation with multiple Pythons is subject to env picking the wrong one. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8041] trunk/mailman/Mailman
On 9/28/06 1:11 AM, Nigel Metheringham [EMAIL PROTECTED] wrote: On Wed, 2006-09-27 at 23:25 -0500, Brad Knowles wrote: LMTP is probably the best and most native method for both sendmail and postfix. I can't speak for other MTAs. Exim can do LMTP, over a pipe (ie fork/exec program), a socket or TCP/IP. Exim can, indeed. But for some cases only if built with a special build flag. From the (4.6.1) spec: The lmtp transport runs the LMTP protocol (RFC 2033) over a pipe to a specified command or by interacting with a Unix domain socket. This transport is something of a cross between the pipe and smtp transports. Exim also has support for using LMTP over TCP/IP; this is implemented as an option for the smtp transport. Because LMTP is expected to be of minority interest, the default build-time configure in src/EDITME has it commented out. You need to ensure that TRANSPORT_LMTP=yes is present in your Local/Makefile in order to have the lmtp transport included in the Exim binary. However, we seem to be interested in LMTP over TCP (to localhost), and I *think* that is available without the TRANSPORT_LMTP=yes build. As one data point, the Exim (4.54) shipped with CentOS-4.4 is built without the TRANSPORT_LMTP flag: # exim -bV ... Transports: appendfile/maildir autoreply pipe smtp ... A quick test with exim -bV -C testConfig suggests that the protocol = lmtp option in an smtp transport is at least not a syntax error (and I believe it will work). --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] OS X Mailman Python
On 9/27/06 6:29 PM, Carson Gaspar [EMAIL PROTECTED] wrote: --On Wednesday, September 27, 2006 11:54 AM -0400 Barry Warsaw [EMAIL PROTECTED] wrote: Then there is the question of what versions we support for Mailman 2.2, which is currently under development. Previously we've said we'll support Python 2.3 but I think we should revisit that decision. If you drop python 2.3, you drop RHEL4. It doesn't effect me personally, as I don't run mailman on my RHEL4 servers, but I suspect it would make many folks unhappy. Well, to run Mailman later than 2.1.5 (with backports) (I think it is) in RHEL 4 (or, therefore, CentOS-4), one is looking at building Mailman from source rather than using official packages. If one is capable of doing that, one is also capable of doing an alternative install of a newer Python, and telling one's Mailman to use that. Unofficial packages would have to take the Python version problem into account. So while the requirement is a nuisance, it's not a show stopper IMHO. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Patches in mandriva package
On 9/17/06 8:01 PM, Barry Warsaw [EMAIL PROTECTED] wrote: BTW, what do you think about changing the way we hold messages for digests? E.g. instead of putting them in an mbox file, where it's more difficult to skip bad messages, stick them in a queue-like directory and pull them from there. Any messages that can't be read and scrubbed would just be removed. Might be too big a change for the 2.1 series, but perhaps we should look at that for 2.2. Sounds like a good change (with 2.2 being the earliest reasonable time to do it). --John (cheering from the sidelines) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Fwd: suggested improvement for Mailman's bounce processing
On 8/14/06 5:42 AM, Barry Warsaw [EMAIL PROTECTED] wrote: Today, held messages still have to be approved by the moderator. What I propose is to allow posters to self-moderate, simply by verifying that their address is real. This probably means a clickable link and (maybe) a header cookie for replying. Think Gmane's auto-moderation approach. Unfortunately, the would-be posters then have to be notified of the message status. Thus, while you're reducing moderator workload, the backscatter problem isn't solved. Unfortunately, we know MTAs are hard to write (Exim is still evolving; Postfix took much longer to write than the author expected; sendmail will never be finished). Mailing list managers are hard to write (Mailman is still evolving). So an integrated MTA/MLM would be hard to write (it wouldn't need all the bells and whistles of a full MTA, and would simplify some of the MUA's problems, so the difficulty is probably less than the sum of the difficulties, but still probably more than either alone). (And a newly-written thing doing SMTP would be insecure.) So aside from ruining email, the spammers have ruined email mailing lists. Perhaps irretrievably (at my age of 67, certainly irretrievably in my working lifetime). None of which means it shouldn't be tried, although perhaps it should be tried in the world of whatever comes along to provide a working replacement for SMTP. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
Thank you for the correction, David. --John On 7/5/06 5:07 PM, David Andrews [EMAIL PROTECTED] wrote: That assertion is not true, to my knowledge -- and I am a screen reader user. Because it does work with a lot of things, and does offer improved functionality, it is rare to turn Javascript off. David Andrews At 01:54 PM 7/5/2006, John W. Baxter wrote: On 7/5/06 11:26 AM, emf [EMAIL PROTECTED] wrote: The problem I face is not when JavaScript is not active, the problem is when JavaScript *is* active *and* behaves correctly - i.e. performs the dom modification I've told it to - but the browser/screen reader doesn't bother to tell the user. ~ethan fremen Does the industry (I almost wrote do we) know how big a problem this is in practice? That is, what fraction of users of screen readers and other assistive stuff routinely run with JavaScript active? Since the assertion here is screenreaders have trouble with JavaScript I would expect most screenreader users to have JavaScript turned off. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Turning off dynamic JavaScript
On 7/5/06 11:26 AM, emf [EMAIL PROTECTED] wrote: The problem I face is not when JavaScript is not active, the problem is when JavaScript *is* active *and* behaves correctly - i.e. performs the dom modification I've told it to - but the browser/screen reader doesn't bother to tell the user. ~ethan fremen Does the industry (I almost wrote do we) know how big a problem this is in practice? That is, what fraction of users of screen readers and other assistive stuff routinely run with JavaScript active? Since the assertion here is screenreaders have trouble with JavaScript I would expect most screenreader users to have JavaScript turned off. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Parsing and Rendering rfc8222
On 7/5/06 4:30 PM, Barry Warsaw [EMAIL PROTECTED] wrote: I'm thinking something along the lines of sha1 hashing Message-ID and perhaps Date. RFC 2822 $3.6 says that the only required headers are the origination date (Date:) and originator address fields (From: and possibly Sender: and Reply-To:). One does see messages with no Date: header. In the past, one also saw messages with multiple Date: headers. (Neither condition complies with RFCs.) I suspect in that case the hash would include some convenient constant. (I can't remember where I saw the multiple Date: header form--it might have been from Western Union (or not)). I was examining Date: headers because of the bug in old Exchange + Outlook combinations in which a crafted overlength Date: header could cause viral infections if the message were simply present in a mailbox list display created by Outlook. (Around 1966 or so, but of course those versions have to be in use together somewhere still--it's only a decade.) --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2.1.8 documentation mismatch
On 6/6/06 9:23 AM, David Lee [EMAIL PROTECTED] wrote: This mixture of terminology seems to occur in other places also. You might want to consider rationalising these to the same thing for the sake of moderators who might be (say) secretarial staff. Secretarial staff should have no problem with the example given. The CEO, on the other hand... And yes, terminology should be consistent. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Topic regexps
On 5/25/06 8:29 PM, Mark Sapiro [EMAIL PROTECTED] wrote: I've thought about this some more and what I'm currently thinking is if the topic regexp is multiline, leave it as is in topics, but before compiling it for use, split the lines and then rejoin them with |, and compile not in VERBOSE mode. I think you need to strip any trailing | characters from the strings in the resulting list before joining with |. Otherwise, you might build one||two||three Which clearly isn't what is wanted. Hmmm...I guess I mean up to one trailing | character...in case someone really wanted one||two for some really strange reason. I think this would be the natural interpretation from the existing explanation. I agree. When we first installed a Mailman version with topic support, I messed around with it, and it didn't work. Since I didn't care much, I ignored the problem rather than figuring out what I was doing wrong. (This thread has made that obvious, of course.) --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Sender field
On 4/29/06 8:00 AM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the only thing that a RFC 2821-conforming MTA looks at is the Return-Path header, and it's supposed to remove that. There is no Return-Path: header during transmission of a message. The Return-Path header is added in the process of delivery. There is a return path, stated in the MAIL FROM:[EMAIL PROTECTED] SMTP command. (That command *can* have more stuff related to authentication.) The return path is what should be used as the address of a bounce if a mail system foolishly accepts a message and then creates a bounce. Notice that if an MTA rejects a message (or one or more of the recipients of the message), it is not bouncing or creating a bounce. It is issuing an error response...the MTA (or MUA in the case of message submission) that was trying to send creates a bounce message if appropriate (for message submission, the MUA notifies the user--or pretends to: Microsoft by default hides the notification remarkably well). While multi-line text associated with the rejection code is provided for, MUAs are very poor about showing it if a submission is rejected--some show only the first line; some only the last line. Even some MTAs improve the text of the rejection. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Users] Sender field
On 4/28/06 6:06 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote: If the previous value of the Sender: field is being lost, then that should be corrected. At the very least, the value should be saved in an Old-Sender: or Previous-Sender: or some other suitable renamed sender field. Probably Original-Sender: Probably, indeed. But what happens if that header was already taken in the process that brought the message to mailman for distribution to the list? (As usual, I have only questions, not answers.) --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Advice wanted on option to not include original post in notices
On 3/27/06 3:48 PM, Mark Sapiro [EMAIL PROTECTED] wrote: First, should these be site wide mm_cfg.py options or should they be per-list options with a default from mm_cfg.py? In either case, the Defaults.py setting would match current behavior. [Other good thoughts deleted, as Mark knows what he said] Hi, Mark It is the site's reputation which (increasingly with more aggressive anti-spam in the world) suffers from bounces containing the content. So messages heading out of the site to the world should be controlled by the site as to whether the content is included. It should be up to the list administrator what (non-bounce) message bodies reach the administrator/moderator in email. (Personally, I don't much care as long as the whole thing remains visible in the web interface. I get ideas about servers to block.) I agree that bounces without content are pretty useless...so they should go to list administrators. Sorry I didn't answer last week...I was busy. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Inactivity deletion of maillist users ?
On 1/12/06 5:51 PM, Mark Sapiro [EMAIL PROTECTED] wrote: Joshua Ginsberg wrote: Perhaps an interesting compromise might be to add to config.pck a key last_post whose value is a dictionary of email:time 9-tuple pairs. That way, folks like Erling could write a script to go ahead and do this fu, and it might be an interesting metric for other purposes as well. This could prove to be a real burden to sites that have LARGE lists. Adding yet another dictionary with 100,000 keys to the list object could have significant impact. Aimed primarily at original poster, whose name I don't remember. What is so hard about parsing the lines like the following in the post log for the information? Jan 11 14:31:59 2006 (8997) post to list-name from [EMAIL PROTECTED], size=3320, message-id=insignificant for this purpose, success Run a script before the log is rotated away which maintains a database keyed by posting address and containing a last_post_date field. Now and then query the database for posters who have posted more recently than xxx days ago, gets a list of all members, and reports the set difference of all-members - recent-posters. Action taken could be any of the ones discussed. This really doesn't seem like it should be part of Mailman, although it might have standing as a contributed extra goodie. I would expect it to have a low download count. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] RELEASED Mailman 2.1.7
On 1/1/06 1:22 AM, Tokio Kikuchi [EMAIL PROTECTED] wrote: John W. Baxter wrote: Shouldn't Mark Shapiro be recognized in the ACKNOWLEDGEMENTS file now? Yes. Mark Sapiro _is_ in the ACKNOWLEDEMENTS. I've just added his name in top page of the http://mailman.sourceforge.net/ It'll appear in list.org and gnu mirror sites later. YIKES. I have been reading Mark's name for a long time now, and my mind has continuously inserted an h after the S. So I did a search for the incorrect name I expected so find. Sorry, Mark! --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] RELEASED Mailman 2.1.7
On 12/31/05 5:02 AM, Tokio Kikuchi [EMAIL PROTECTED] wrote: I'm pleased to announce the release of GNU Mailman 2.1.7. This is a significant release, which includes security enhancement fixes, a new language (ia: Interlingua) support, a couple of new features, and many bug fixes. Well done! Thank you, all involved. Shouldn't Mark Shapiro be recognized in the ACKNOWLEDGEMENTS file now? --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Spam/Scam button
On 12/14/05 3:32 PM, Barry Warsaw [EMAIL PROTECTED] wrote: I do think mailman-developers is a reasonable place to discuss this. We can talk about whether it's even reasonable to have anti-spam defenses in Mailman, and if so whether we want to pick one such product to support, or have a pluggable architecture (possibly shipping one by default). I also think there are interesting usability/user interface questions to ask, as well as whether spam filters should be per-list, site-wide, or domain-wide. We're happy with spam and virus defenses in the MTA which receives from the world and does the spam and virus work before handing off the messages to the MTA on the Mailman machine. The Mailman machine can't be reached on port 25 (or 587 or 465) from the world. If anything is shipped with Mailman (beyond tuneups to what is there now, which we mostly don't have to use), we'd likely want it able to be turned off. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Make web_page_url visible in the admin GUI?
On 11/26/05 1:25 AM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Max == Max Bowsher [EMAIL PROTECTED] writes: Max Is there any reason not to add web_page_url to the Max configurable options in the admin GUI? Right below host_name Max in the general category would be a good place. Yes, please! Yes, there is a reason. It is the same reason that the ability was taken out many Mailman versions ago. Thought experiment: 1. Make a typo which cripples the URL such that you can't reach the admin web page. 2. Now fix it from the browser. The sort of thing in #1 (sometimes not a typo but a more fundamental mistake) happened often enough to make removing the ability seem quite desirable. One thing which has changed since the decision is that a much higher proportion of list operators don't have command line access than was the case then. So *perhaps* it would make sense to revisit the decision (making it a site option, please). --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] MysqlMemberships.py
On 11/23/05 3:38 AM, Fil [EMAIL PROTECTED] wrote: Unfortunately this still doesn't succeed reconnecting to the server: I get this traceback: File /var/local/mailman/Mailman/MysqlMemberships.py, line 141, in _prodServerConnection if self.connection.ping() == 0: OperationalError: (2006, 'MySQL server has gone away') A little bit of hacking makes this problem less painful, but I'm sure I got it wrong, or it is that my MySQL server goes away quite a lot. I don't know for sure, anyway, but if you're currently trying my version of MysqlMemberships.py you might want to update the patch is @ http://trac.rezo.net/trac/rezo/changeset/59 -- Fil What sort of setting does the MySQL server you are running have for timing out idle connections? Could it be that you aren't hitting it often enough? In which case, going away a lot is normal. (I have that problem regularly with a desktop query client (CocoaMySQL for Mac OS X). It responds to a vanished connection by hanging unresponsively until killed...your code is clearly better than that. ;-)) --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Mysql MemberAdaptor 1.61 and Mailman 2.1.6
On 10/26/05 6:06 PM, Mark Sapiro [EMAIL PROTECTED] wrote:
Actually, it is not really doing the right thing because it is not
supposed to be aware of what's in the _BounceInfo class. The info that
is passed to it is a string representation of the _BounceInfo
instance, and it should really just be saving and retrieving that.
IMO, there should be just one column in the MySQL table for this
string representation. The only possible snag I see is that the string
contains new-lines, and I don't know MySQL so I don't know if
new-lines are allowed in a string field/column.
Based on these tests dashed off using one of Exim's debugging capabilities
$ exim -be
${quote_mysql: A\x0atest}
A\ntest
${quote_mysql: A\x0dtest}
A\rtest
the newlines are OK but have to be quoted (as do CR characters, and others).
This, of course, assumes that Exim's quote_mysql operator is doing the right
thing.
The best thing would be to check the MySQL documentation (which I'm too lazy
to do this evening).
--John
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Issues with archiving directory and OS limitations
On 10/24/05 5:28 PM, Brad Knowles [EMAIL PROTECTED] wrote: Base-64 would let you get two characters creating no more than 4096 hash subdirectories, and you can see the numbers above for the likely reduction in the number of grandchild subdirectories/files. Base 64 isn't a good idea for code which might run on case-insensitive file systems (eg Cygwin or Mac OS X). Base 36 would seem safer if this code is going to go into the official Mailman release sometime (which is probably a good idea). --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Mailman 2.X CVS MAIN is back
On 8/31/05 8:11 AM, Barry Warsaw [EMAIL PROTECTED] wrote: At the very least, we must drop Python 2.1 and 2.2. Neither of those versions are being supported any longer and I will definitely not claim to have tested the current code base on either version in a very long time. If we must continue to support Python 2.3, so be it, but I'd like to leapfrog even that version. There are several Python 2.4 constructs and modules that I'd dearly love to be able to take advantage of. It seems to me that the improved email module is enough reason to require Python 2.4. (We moved our email processing to 2.4 for that reason.) Yes, one can--as I understand it--use the new email module under Python 2.3, but if one has institutional issues that prevent using Python 2.4 they probably prevent messing about with 2.3 in that sort of way, as well. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] EOL handling in Mailman
On 3/19/2005 23:43, Sylvain Beucler [EMAIL PROTECTED] wrote: Savane uses the PHP mail() function, that executes the local sendmail-compatible command. At both GNU Savannah (savannah.gnu.org) and Gna! (gna.org), we use the Exim version packaged by Debian. In both cases, the mail we receive via mailing lists (and in the Mailman archives) have the newlines doubled. The mails we receive at our personnal mail addresses is correct (no doubling). As far as I'm concerned, line doubling _does_ look ugly and unprofessional ;) As a result, I was under the impression that Mailman is the one that doubles the newlines. Now maybe Exim as an SMTP server (not as a sendmail-compatible command) is doubling lines. But are you completely sure Mailman (or a Python library used by Mailman) is not converting \r\n to \n\n? Ever since Philip Hazel tried to accommodate some broken email producers by messing with incoming line endings, there have been problems with products broken in different ways. As I recall, Philip has done various tuneups over the last many Exim versions. You didn't say what version of Exim is running in your Debian installation...there are backports of newish Exim versions available which would likely fix your problem. Note that switching from the Exim 3.x series to Exim 4.x involves a significant reconfiguration of Exim...it's likely best done by running debconfig and answering the Exim configuration questions as if you were starting from scratch. This will not be something to tackle the day before a vacations on your production server. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Mailman 2.1.6b4
On 3/4/2005 9:37, Nigel Metheringham [EMAIL PROTECTED] wrote: On Fri, 2005-03-04 at 12:11 -0500, Bryan Fullerton wrote: Is there an updated timeline for the final 2.1.6 release? It won't be in February... :) Is there a booking form for Guido's time machine? Of course it will be in February. Perhaps February 35th, perhaps 48th... --John (this comes from growing up in California, where the legislature had a ritual of the presiding person ordering the Sergeant at Arms to stop the clock a few minutes before midnight on budget deadline night. Then it entailed climbing a ladder to stop the clock) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] High Availability
On 2/27/2005 17:46, Preston Wade [EMAIL PROTECTED] wrote: Hello, I read some old post back in 2002 on this list about Load balancing. In my scenario I don't have near the volume to warrant load balancing but I am interested in fail over capabilities. Would it cause Mailman any heartburn if I simply wrote an rsync script to keep the trees in sync? We do this. It seems to be successful. And then use the heartbeat package to do automatic fail over. I realize depending on my sync cycle I will potentially loose some data. Is there a better alternative to this? We stopped trying to use heartbeat long ago, when of the first 10 auto-triggered switches, all proved to be false alarms by the heartbeat code. (Not just for this purpose.) Also I saw there are plans to move to a user store were users would have one password for all list. Have there been any considerations for LDAP as that user store? There have...I hope LDAP isn't the only choice when the change happens (we're moving away from LDAP, having become tired of repairing broken LDAP databases). --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Hashing member passwords in config.pck
On 2/12/2005 6:02, Barry Warsaw [EMAIL PROTECTED] wrote: On Sat, 2005-02-12 at 02:07, Bob Puff wrote: So let me ask this: if we drop passwords for everything but the private archives, do we really need to do anything differently than the format currently in place? Do they really need to be one-way encrypted? Being able to email a forgotten password has its benefits. It's still worthwhile (in the long run) to hash the passwords. Some people tend to re-use them, so stealing Mailman passwords can potentially lead to cascading attacks. Password resets are fine. I don't see how users remote from their normal email can make use of password resets. Without the old password, how do they prove they should be able to reset a subscriber's password? Thus they can't designate the new password, nor learn the generated one, remotely. I don't think the above kills the idea (I've changed my mind, with respect to the private archives, from what I said earler). --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org As a general rule, if you have questions regarding sensitive security issues, you can post them to [EMAIL PROTECTED], which is a closed distribution list. Please do not otherwise discuss sensitive security issues on any public mailing list, until such time as an official announcement has been made, including availability of a patch, etc Even if the issue has been publicly discussed in other forums, you should wait for the official announcements before discussing them publicly, whether on mailman-users, mailman-developers, or elsewhere.
Re: [Mailman-Developers] Hashing member passwords in config.pck
I used to be careful about saving my passwords for all the lists [Mailman*] I am subscribed to. I no longer bother...I request the mail out of the password if I need it (very rare). If the situation becomes a choice of 1. mail out the password becomes generate a new time-limited password and mail that Or 2. do away with passwords and have everything validated via a mailed-out URL I think I as a user would prefer 2. As a list owner, ANY change causes queries and unhappiness among the ranks of the subscribers. And as site administrator, I would have to coordinate removal of passwords or even the new time-limited password idea with our main list owner, who has her own scripting to hide the passwords from the subscribers (who don't do things via the Mailman web pages). I concur with the idea of getting the simple patch out for the CAN-2005-0202 problem quickly in 2.1.6 and getting the password removal/changes into a 2.1.7 [or 2.2 as has also been suggested] (pretty soon and with very little if anything else). We shouldn't assume MySQL as the SQL server; we shouldn't assume LDAP as the password database. Here, we're phasing out MySQL in favor of PostgreSQL for licensing reasons, and trying to phase out LDAP in favor of SQL for stability reasons. But we can't make those decisions for others, of course. Bigger stuff I think has to wait for Mailman 3...this would include password databases, subscriber databases site wide, etc. --John (who for medical reasons can't be of any help, but must continue cheering from the sidelines. Sorry!) On 2/10/2005 10:55, Chuq Von Rospach [EMAIL PROTECTED] wrote: this might not be a bad idea, but -- would require all operations to be validated via a URL emailed to the affected address. But I could live with that. On Feb 10, 2005, at 10:44 AM, Adrian Bye wrote: Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] [Fwd: Re: [Mailman-Announce] Mailman 2.1.6 beta 1]
On 1/21/2005 13:31, Tokio Kikuchi [EMAIL PROTECTED] wrote: think I can add some code before the 2.1.6 final release to exchage Re: and prefix order for the subject prefix without numbering. (Yes, we now have a nice feature to add numbering in the subject prefix.) Can you do the same for AW and some of the other non-English forms of Re? I'm only asking because you'll be working in the code anyhow. Oh yes, I'm doing this also. Are there any other like this one? ;-) I can't currently remember any other than AW. And I don't think AW will go away, RFCs or not...one program which seems to do it is X-Mailer: Microsoft Office Outlook, Build 11.0.6353 when in a German location (or configured to act German, or something). --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] What would send to bare administrator
OK, that subject might hit a filter somewhere. ;-) Mark Shapiro wrote in another thread, in mailman-users: If you haven't changed SMTP_LOG_EACH_FAILURE in mm_cfg.py, the 3 failures should be logged in Mailman's smtp-failure log. Which prompted me to look there, and find Jan 18 14:47:56 2005 (20931) delivery to administrator failed with code 501: administrator: recipient address must contain a domain That's true, the way the MTA (Exim) is configured. A quick grep in the source didn't reveal a case where Mailman attempts to send mail to the unqualified recipient administrator. Does anyone happen to know where it is? When I get back (from the doctor) I'll try to find out what was going on Tuesday around that time. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] What would send to bare administrator
On 1/21/2005 14:06, Mark Sapiro [EMAIL PROTECTED] wrote: John W. Baxter wrote: A quick grep in the source didn't reveal a case where Mailman attempts to send mail to the unqualified recipient administrator. Does anyone happen to know where it is? I don't know, but is it possible that 'owner' or 'moderator' for some list - maybe the site (mailman) list - is set to 'administrator'? The smtp-failure entry matches a post log entry (with 1 failure) exactly in time. The mailing list to which a message was posted does not now contain the word administrator in the results of bin/dumpdb lists/rose-movies/config.pck | grep -3 administrator Same is true for .../config.pck.last, which is not at all surprising (the list is large enough to have frequent changes). I'll ask the list administrator (long-time friend) whether she remembers putting administrator into the list as member or as a list official. The list is a weekly announce-only list (soon to be monthly). This week's instance of the failure does not repeat prior failures (the two most recent prior failures were in a different list, back in November and had an obvious cause). I'll watch the results of next week's posting. --John ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Maybe it's time to release 2.1.6
On 12/1/2004 6:05, Barry Warsaw [EMAIL PROTECTED] wrote: I have no problems requiring Python 2.4 for Mailman 2.2, although I would like to get some feedback from the community before we decide for sure. I wouldn't be opposed to requiring at least Python 2.3, but I definitely think we should drop support for earlier Pythons since nothing earlier than 2.3 is being maintained any more. The Debian part of the community in particular (of which I am not part). I wonder when Python 2.4 will wander into a Debian release. Perhaps a query on the -users list about requiring Python 2.4 with Mailman 2.2 would produce a solid reason not to. --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Dates again
On 11/20/2004 13:26, Kenneth Porter [EMAIL PROTECTED] wrote: --On Saturday, November 20, 2004 6:22 AM -0500 Steven Kuck [EMAIL PROTECTED] wrote: As I said, I can guarantee messages from the future are wrong. Disagree? Perhaps messages from more than a day (or N days) in the past could be bounced saying: Either your system clock is wrong or your message was unreasonably delayed. Either fix your clock, or make sure your message is still current and send it again. Alternately, the message could be held for approval or date fixing, and you could set that user as Date Impaired so that all messages from that individual get fixed - if they're off. This seems a reasonable approach, given a configurable delivery delay tolerance. One could also cross-check References headers against messages already received, to set a lower limit on the time stamp. If a message claims to have been sent prior to one it references (modulo some tolerance), then it can be bounced/modified/moderated. Keep in mind that there are MUAs which set the Date: as the message is begun, not when it is sent. If the sender leaves it as a draft for a couple of days before sending, the Date: will be two days old. (What one wants to do with that date is another matter.) --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Can we remove nimda.txt ?
On 10/16/2004 14:13, David Relson [EMAIL PROTECTED] wrote: On Sat, 16 Oct 2004 08:52:15 -0700 John W. Baxter wrote: ...[snip]... You might want to refer folks who want to run test virus messages through their Mailman system (system = the MTA and its filtering and Mailman and whatever else is involved at a given site) to http://www.eicar.org (note...eicar.com is very different). They are??? www.eicar.org and www.eicar.com look identical (and have the same IP address). Oops...they are the same. This was Safari helpfully completing a URL it had seen before within eicar.org, and not completing it--not having see it--in eicar.com. The proper reference would probably be the more complete eicar.org/anti_virus_test_file.htm or eicar.com/anti_virus_test_file.htm Thanks for objecting! ;-) --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Can we remove nimda.txt ?
On 10/15/2004 22:52, Tokio Kikuchi [EMAIL PROTECTED] wrote: Also, I want to ask 'nimda.txt' in the tests/msgs directory is of any use in the mailman source code. None of the test scripts refer to this file. I even did find . | xargs grep nimda only to get Binary file ./tests/msgs matches. If none of you can find usage of this file, I want to remove from the source tree because some companies prohibit to download a file which contain nimda file. (I know it's nonsense but ...) My guess is that the nimda.txt file is left over and can be removed without harm. You might want to refer folks who want to run test virus messages through their Mailman system (system = the MTA and its filtering and Mailman and whatever else is involved at a given site) to http://www.eicar.org (note...eicar.com is very different). By including the reference, you avoid having anything in the distribution which triggers (sensible) virus scanners. --John (who just used eicar yesterday in another context) ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Timestamps in archive are +1 hr
Version of Mailman? System on which you're running? Assuming Linux, what is the third (last) line of cat /etc/adjtime I expect either LOCAL or UTC...our Mailman machine has UTC, and--which I had never noticed--is an hour ahead on the From lines in the archive. Hmmm. Mailman 2.1.2; RedHat 9 --John On 8/17/2004 2:12, Chris Boulter [EMAIL PROTECTED] wrote: Apologies for noise, but I posted this to mailman-users last month and got no replies. It doesn't seem like something which would be all that hard to fix for someone who knows Python/Mailman better than I do. Any ideas? - Forwarded message from Chris Boulter [EMAIL PROTECTED] - Date: Wed, 28 Jul 2004 15:30:35 +0100 From: Chris Boulter [EMAIL PROTECTED] Subject: [Mailman-Users] Timestamps in archive are +1 hr To: [EMAIL PROTECTED] Hi, The timestamps on messages in our Mailman archives are all 1 hour ahead of reality. Any ideas? I'm in the UK, where it's currently summertime, which is UTC +0100. Typing 'date' on our Mailman box gives Wednesday July 28 15:24:33 BST 2004 which looks correct to me. I've found that I can fix the time by changing i18n.py line 60 (in the ctime function) from year, mon, day, hh, mm, ss, wday, yday, dst = time.localtime(date) ^ to year, mon, day, hh, mm, ss, wday, yday, dst = time.gmtime(date) ^^ and rebuilding the archives, but I don't want to leave this hack in place. If it's useful to know, a test mail I sent at 1253 local time today had its seconds-since-epoch set to 01091019325 by the time it got to the archive. Many thanks. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] [Greg Stark gsstark@mit.edu] Re: Bounceremoval parameters default values
On 7/1/2004 9:57, J C Lawrence [EMAIL PROTECTED] wrote: On Thu, 1 Jul 2004 09:46:47 -0700 somuchfun [EMAIL PROTECTED] wrote: J.C., I agree with you that there is never a right time. BUT, when introducing a new feature (like mailman did with the VERP bounce probes) it is wise to have the option to turn this feature off (perhaps until 2.1.6 comes out) to give people time to adjust their settings and systems. They can of course always gain that same time and more by simply not upgrading. Which is decidedly NOT encouraged by this snippet from Barry's 2.1.5 announcement: This version also contains a fix for an exploit that could allow 3rd parties to retrieve member passwords. It is thus highly recommended that all existing sites upgrade to the latest version. --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] message filters - how to define regex string which allowes any mail address
On 3/30/2004 8:01, lp [EMAIL PROTECTED] wrote: If anyone knows the regex string that defines any mail address reagrdless of what stands before and after @, please give me an exact example of the string. Well, the first edition of Mastering Regular Expressions by Jeffrey E. F. Friedl (spelled correctly) had such a regular expression in small print occupying a full page near the back. [He developed pieces of it in various parts of the book.] It had a bug, so there was a correct version at O'Reilly's site in the book's errata area. Unfortunately, the book is now in its second edition, and Mr. Friedl seems to have left the bug out of that regular expression, so it isn't in the current errata and I can't point it out to you. Check a bookstore with a good O'Reilly selection or a library...the book should be available in one or the other of those places so you can enjoy the RE. You probably don't want to use the regular expression. --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Virus sent to lists from my domain - add password for moderated users
On 3/15/2004 11:11, Chuq Von Rospach [EMAIL PROTECTED] wrote: and I don't have a good answer for that, not at all. not sure how to close that hole offhand. we made it easy to figure out it IS a list, we show an address that the virus can tell has posting privs -- and we do no validation that it's actually coming from that address. ugh) I muttered here a couple of years ago about digital signing of messages which come from a non-moderated sender. I know it introduces non-trivial problems. I don't think the viruses manage SMTP AUTH yet (these days, they're intent on using their own SMTP servers and forging senders, so the needed authenticator probably isn't available on the machine they've infected...that could change)...one could certainly [try to] force mail to come that way. Here, incoming mail goes through our virus scan before getting farmed out to the mailing list machine. So far, that seems to have done its job. (We're weak on the spam side for the lists, but basically strong enough so far--almost all the few spam incidents have been moderators making errors.) --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] Text for the mass subscribe upload a file option.
In Mailman 2.1.1, the mass subscription page has this text under the textbox, introducing the Choose File button or specify a file to upload: I just talked with a not-dumb list owner who selected an Excel file, producing a wonderful list of 22 non-deletable, non-modifiable entries, which had addresses jumbled together with strings like %0F%00%00. After that conversation, I would suggest that the text read or specify a plain text file to upload: Fortunately, the list in question was new, so we elected to blow it away and try again. --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Subscriber list
On 9/13/2003 18:45, Phil Barnett [EMAIL PROTECTED] wrote: On Saturday 06 September 2003 6:15 pm, [EMAIL PROTECTED] wrote: I would like to retrieve my complete list of subscriber (i'm using mailman) in a text file but i don't know how to do it, can someone help me please ? (i've more than 2 subscribers) Thank you very much (sorry for my poor english talking, i'm french) /home/mailman/bin/list_members listname ./listname.out The above is the reply we always see to this question, on mailman-developers and on mailman-users, but it is impractical for some fraction of the list administrators out there. Either the email help command is out of date, or the list can be retrieved from email *without* having to bother some curmudgeonly sysadmin (such as myself). The help command says: who password See everyone who is on this mailing list. The roster is limited to list administrators and moderators only; you must supply the list admin or moderator password to retrieve the roster. I just checked...the command works for me...for a smallish list (under 70 subscribers). --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Non-member post confirmation
At 10:21 -0400 8/28/2003, Barry Warsaw wrote: In additon to the full subscription option there could perhaps be a thread subscription which would subscribe the sender to only receive mails from the thread started by him/her. This might become somewhat heavy though. It's a great idea that's been bantied about for years (e.g. Roundup's nosy lists). But that would have to be a feature for a 2.2 release. And would have problems with uncooperative MUAs and uncooperative MUA users, either of which could take an interesting (to the restricted subscriber) message outside the thread. Good luck. Are Topics working well enough to be useful (I haven't tried any)? --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Non-member post confirmation
At 22:42 +0200 8/28/2003, Brad Knowles wrote: There is already the option Should the list moderators get immediate notice of new requests, as well as daily notices about collected ones?, which I was very grateful to be able to turn off. Perhaps more useful the list admin could set periods other than daily (millenniumly is tempting but too long ;-)), and the timing (eg, tell me at 6AM, Noon, and 4PM). Or per admin or moderator: tell Barry at 6AM; tell John at Noon; etc. A lot of code...would it be used? --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: [Mailman-Users] Invite vs. autoresponders
At 11:49 +0100 1/3/2003, Fil wrote: SB I've recently discovered that vacation autoresponders will SB subscribe recipients to Mailman lists when they get invited. Dang. This is because the From address contains the confirmation cookie encoded in the address. This might kill this idea for ease-of-use confirmations. I would imagine that, if the autoresponder is set to answer emails coming with a 'Precedence: list' header, the bug is with them, not with Mailman. You don't want to kill a good functionality just because most autoresponders are very poorly written - avoiding loops is enough ;) Well, there are different needs for different Mailman sites. If you have to convince your provider that every address in your list truly wanted to be there, it's unhandy for there to be such a simple example of involuntary subscription, which the provider can demonstrate at will. Same for sites which choose to block phoney opt in schemes, and which contain members of your list. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] email comparison bug?
At 23:28 -0500 1/1/2003, Barry A. Warsaw wrote: JWB == John W Baxter [EMAIL PROTECTED] writes: JWB Since HerName *can* be a different account than is JWB hername, I think we're stuck, even though it almost never JWB is. When there is a sitewide database of Mailman JWB users...we'll STILL be stuck, I fear, although the GUI might JWB allow a user to say the equivalent of that's me, too. Mailman's policy is that membership is by case-insensitive email address, and it preserves the case of the subscribed address only for the recipient address (either envelope or From:). When there's a unified user database (read: Mailman 3.0), an email address with any combination of case will still point to the same user record, but it may be possible for users to add delivery addresses with different cases. To me, it sounds reasonable. To folks in the last holdout case-sensitive local part domain, it likely doesn't. ;-) And given the policy, the behavior I defended is indeed wrong. --John (who doesn't know anyone in that last holdout case sensitive local part domain) -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA Soggy mail is caused by postage dew. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman2.1 beta5
At 1:02 -0500 11/20/2002, Phil Barnett wrote: Sending passwords as plaintext in 2002 is downright negligent considering the current state of sniffing, monitoring and penetration. So...we stop calling them passwords. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] [ mailman-Bugs-635462 ] Admin pagesHTML does not set TEXT color
At 9:37 -0500 11/8/2002, Dale Newfield wrote: On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote: Admin pages HTML does not set TEXT color Why is it mailman's job to protect stupid users from their own browser settings? This one sounded like it was posted not from a stupid user but from a careful tester. If mailman has an intended appearance, it should cause that appearance to happen unless the user--in a browser which will--has refused to allow the site to override her local style sheet. Personally, I liked the old days, when the user's browser settings were allowed to control appearance details, and HTML described content. Of course, one could hardly hire out as a designer following that idea, so it didn't last long. --John (one of the few who remembers that the first T in HTTP stands for Text) -- John Baxter Port Ludlow, WA USA Always allow for the innate perversity of inanimate matter. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Anti-spam killer app?
At 13:10 -0700 8/16/2002, Chuq Von Rospach wrote: Take a look at this -- http://www.paulgraham.com/spam.html It's a new technique for identifying spam. The more I look into the details, the more I think we have the anti-spam killer app, becaues it tunes itself to the individual (or site), adapts as the anti-spammers adapt, and the technique used is fairly easy to implement and damn difficult for a spammer to avoid Damn, I wish I'd thought of this. Me, too. ;-) I find it fascinating that the last URL reference at the bottom (yes, I read that far) is to the page at Apple's site describing the filtering in Apple's revised Mail.app in Mac OS X 10.2. I think the idea has a lot of promise. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
[Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
At 21:02 -0600 7/29/2002, Jason R. Mastaler wrote:
In a perfect universe, you'd have a global
whitelist containing the address of every non-spammer on the planet.
In a perfect universe, there would be no spammers on the planet. ;-)
--John
--
John W. Baxter Port Ludlow, WA, USA
set emptyRecord to {behindTheCurtain: Pay no attention to the string
behind the curtain!}
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman-21/listinfo/mailman-developers
[Mailman-Developers] Re: Opening up a few can o' worms here...
At 19:53 -0700 7/29/2002, Ka-Ping Yee wrote: If you generate an image containing the entire e-mail address, it can be made extremely hard to read, even with state-of-the-art OCR. It also becomes hard to read for those who don't have their browser download images. Plus you have to avoid typical ad sizes. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] Opening up a few can o' worms here...
At 17:46 -0400 7/16/2002, Barry A. Warsaw wrote: CVR == Chuq Von Rospach [EMAIL PROTECTED] writes: CVR Problem is, many users don't know how. And one could argue CVR who ought to solve this problem. Should users be forced to CVR jump through hoops to use a mail list safely? Or is it the CVR user's decision how safe to be? Nope, I think it's the ISPs that will solve the problem, although it might be in ways mom-and-pops don't like. I don't think the ISPs *can* solve the problem in the near-to-medium-term future. [Longer term, with the demise of SMTP and its everything open to all except for a few bandaids approach, maybe.] At some point, the SpamAssassin/quarantine model breaks down...when you quarantine 10 large messages to let one smaller message go through, you're somewhere close to that point. As it is, we're busily installing four machines to do the work that one would do quite well in the absence of spammers (and they'll have help from another machine or two so that users can see their quarantined mail and rescue their false positives). And yes, SpamAssassin is part of that picture. Plus, I fear the new breed spammers (the ones who actually think their advertising is useful and welcome and only sent to opt-in lists, although they buy the lists from guys who [figuratively] sell them from under a trenchcoat at the entrance to a dark alley) will cause legislation to be passed forbidding filtering at the mail server level. It nearly happened last time around. Ah, well...we'll see how it goes. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] Opening up a few can o' worms here...
At 20:49 -0400 7/16/2002, Jay R. Ashworth wrote: But *why isn't this the recipients' problem*? Because the recipient gives up, and takes her ISP payments elsewhere, or really gives up and takes them nowhere (which I'm tempted to do myself when I retire). --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] Opening up a few can o' worms here...
Bob Puff@NLE [EMAIL PROTECTED] Not to get too far OT here but... I've seen the next generation of spammer software at work recently. Spammer's machine makes direct SMTP connection to my box, gives MY address as the FROM:, TO:, and REPLY-TO:. This bypasses all the open relay testing, and would only leave stuff like SA to detect it. Actually, you missed version a of this, in which a user is picked, and messages are sent to 8 [about] or fewer alphabetically-near addresses on the same domain. I *think* the or fewer mostly came from stale addresses being bounced. So this thing was really clever, right? Not really...there was a supposed Received: header below the Subject: header. With a made up host name in the supposedly sending domain, and SMTP not esmtp protocol. Not hard to catch and freeze by parsing headers, although I froze based on another header instead. (The latter turned out not to be specific to the spam in question [just because it wasn't found in any of the message I have in my last couple of years of history didn't make it unusual, just old, as it turned out]. It recently caught another juicy spammer who was easy to deal with but whom I wouldn't have noticed if I hadn't had to vette the frozen messages.) Plan B of this series* is the [EMAIL PROTECTED] to [EMAIL PROTECTED] form you're seeing...which sometimes is, it turns out [EMAIL PROTECTED] to [EMAIL PROTECTED] This form lacks the misplaced phony Received: header. *I see it as part of the series...the perps may not. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA mailman-developers...where no canned worm is safe. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] OSX installation problem - no mailmanuser
At 12:37 +0100 7/12/2002, Robert Crosbie wrote: John W Baxter hath declared on Thursday the 11 day of July 2002 :-: Greg Westin [EMAIL PROTECTED] wrote: I sent this question to the mailman-users list and got no response, so I thought maybe I should try here. I don't know if this is a problem because I'm a novice at these UNIX installations, or if there's something wrong with the Darwin installer: I haven't looked at the configure script (at all...I don't know what language it's in), Basically a shell script... but the symptoms sound as if the script is not using normal system calls to retrieve the mailman user information... the Pythonic pwd.getpwnam() for example would get it just fine. Is it doing Perhaps you should have checked the script, it does in fact use pwd.getpwuid() and/or pwd.getpwnam(). I assume these work properly on OSX. Well, pwd.getpwnam() doesn't work properly but the failure is not involved here. (The encrypted password is returned by getpwnam regardless of whether root or someone else runs it. Coupled with the traditional 8-character crypt() used for the passwords, this is a major flaw in Apple's security. This isn't a Python thing...the Perl equivalent also gets the password field.) I haven't put Mailman on my Mac OS X machine. [I haven't bothered to replace sendmail, either, but before actually allowing port 25 connections I need a mail program I can configure...fortunately while I've been driving Unix since 1995 at work (same chair), we ditched sendmail when Exim became viable. So I know almost as little about sendmail as Aunt Sally does.] --john -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] OSX installation problem - no mailmanuser
Greg Westin [EMAIL PROTECTED] wrote: I sent this question to the mailman-users list and got no response, so I thought maybe I should try here. I don't know if this is a problem because I'm a novice at these UNIX installations, or if there's something wrong with the Darwin installer: I haven't looked at the configure script (at all...I don't know what language it's in), but the symptoms sound as if the script is not using normal system calls to retrieve the mailman user information... the Pythonic pwd.getpwnam() for example would get it just fine. Is it doing the equivalent of grep mailman /etc/passwd ?...if so it cannot succeed in a proper Mac OS X (although one could create the user, find the numeric UID, and use vipw to install the user in /etc/passwd and whatever we have to install the group in /etc/group. Barry...you probably know this, but NetInfo is going away in a month or so (Jaguar) to be replaced by an LDAP-based solution. So doing a NetInfo-specific fix would probably be unwise. --John (not under Jaguar NDA, and without Jaguar) -- John BaxterPort Ludlow, WA, USA I am NOT out of the office. I will respond if and when I get around to it. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] Another stupid question
At 23:21 -0400 5/22/2002, Jay R. Ashworth wrote: On Wed, May 22, 2002 at 10:27:58PM -0400, Barry A. Warsaw wrote: ... So, you need to fix host_name (and probably web_page_url). Only the former can be changed on the General admin page. Both of course can be changed via withlist. Or I can remove the list and reinstantiate it, right? Yes, but if you are at the stage of the list's lifetime when that is appropriate, then it would seem that this list is a good one on which to practice using bin/withlist. Unless you're already comfortable with it. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] Replybot change proposed
I propose that the Replybot not send responses to any message marked Precedence: bulk unless there is a corresponding X-Ack: yes header. Should that be expanded by adding Precedence: junk ? --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] patch for using Bouncers/Catchall.py with Python 2.2.1
At 1:00 -0400 5/10/2002, Barry A. Warsaw wrote: JWB == John W Baxter [EMAIL PROTECTED] writes: JWB Interesting...my Python 2.2.1 on Mac OS X does include those JWB modules (and issues a deprecation warning upon import at the JWB interpreter command line). I didn't do anything special to JWB include them. And that module specifically imports the warnings module to silence the deprecation warnings in Python 2.2.x. Did you generate this patch because you saw those messages, or things were broken for you? Someone else stated that the old regular modules were missing on Mac OS X and generated the patch. For me they are present on Mac OS X. I don't know why they are present for me and not for the patch generator. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] Another broken message
At 13:38 -0400 5/9/2002, Ron Jarrell wrote: Ok, I got another instance (that makes 5 I've seen now) of mailman sticking the headers into the body of the note.. There were extremely abbreviated headers, a blank line, a mangled header, and then the rest of the headers in the body of the note. The body starts: [EMAIL PROTECTED] for [EMAIL PROTECTED]; Thu, 9 May 2002 17:08:55 + Received: from [12.91.124.228] by webmail.worldnet.att.net; Thu, 09 May 2002 17:08:55 + Barry, having seen several examples now, it looks like something in the header code every so often dumps a null line into the output while building the message, thus causing the rest of the headers to look like they're in the body... If I were writing such an error, I would probably do it first by having a problem with doing header continuations, if the end of what should be the last line of the continued header exactly fills the allotted space for a line. (Having fixed that, I might get the same result more creatively. ;-) In fact, in other contexts I have done that. Too often. --John (who hopes to learn to leave the errors out altogether sometime) -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
Re: [Mailman-Developers] Warning: nasty variant of this new virus.
At 14:35 -0700 4/23/2002, Chuq Von Rospach wrote: I just got sent a new copy of the Klez.E virus. The text it sends to the user is this: -- Klez.E is the most common world-wide spreading worm.It's very dangerous by corrupting your files. Ah...there's one now. It came in a text/html part, with quoted-printable encoding. The clever HTML which precedes the above material is (in its entirety) (I stuck the spaces into the first tag to try to avoid confusing some dumb mail client or overly-smart scanner). H T MLHEAD/HEADBODY FONTKlez.E... The social engineering in the English translation of the message isn't badly done. File name in this sample is Fy.bat (which I suspect I'm interpreting correctly). --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: [Mailman-Users] Re: Editability ofmessages
At 18:04 -0400 4/19/2002, Barry A. Warsaw wrote: ... specifically, we seem to exhaust our open file limit about every 3rd or 4th day. ... It's disturbing and we'll have to do something about it, although hopefully not as drastic as reverting to Exim3. I'm just wondering if any other Exim4 users are seeing similar problems. We haven't moved to either Mailman 2.1 or Exim 4 (on the Mailman machine) yet. But...we are seeing a Python-based web dynamic page server (not Zope...in-house) leaving open files behind with a fairly new Python. We've temporized by having a monitor which does a suitable lsof and counts the relevant open files...killing and restarting that server when the count reaches 1000. I'll pass along to the (really sharp) guy who is working on that problem that you're seeing something at least vaguely similar. We've been operating on the theory that the problem is in our code, but...perhaps not? --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] message posting in a loop with mailman2.1b1
At 16:28 -0700 4/16/2002, Marc MERLIN wrote: I'm not saying that mailman is incorrect on the interpretation of the RFC, I'm saying that if mailman feeds an incorrect Email address or something that causes the MTA to reject the mail, it will endlessly spam all the subscribers that are being delivered to every time mailman tries. This can't be the desired behaviour... Nor is it what I see running Mailman with Exim. But I haven't ventured into 2.1b1 yet. How does Mailman deliver the messages to Exim? --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] bin/qrunner picking up changes
At 8:19 -0500 3/29/2002, Mentor Cana wrote: With the latest CVS, whenever list's configuration changes (i.e. new headers or footers) a bin/mailmanctl restart is needed. This could confuse lists owners who expect (rightfully so) to see the changed footers or headers on their lists as soon as they save the configuration. Should the Submit Your Changes button do a bin/mailmanctl restart after successfully saving list's changes? (I'm not sure of this behavior is limited to headers and footers only) The issue is bigger than presented above (I don't have a 2.1.anything installation to play with). But simply telling a list owner to run bin/mailmanctl restart won't do the trick: most list owners don't have the power to run that command (or any shell access at all). Therefore, I'm pretty sure a solution is in the works. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Modifications to msg
At 18:56 -0800 3/18/2002, Dan Mick wrote: RFC 2822 rules on the number of specific headers a message can have. E.g. it can have many Received: headers, but only one Reply-To: header (although the latter allows for multiple addresses... go figure). Ease of parsing. No one but humans typically looks at Received:, but dumb MUAs need to use Reply-To:, so complicated tricks for accumulating a list are limited there. (at least that's what I'd guess at for a rationale.) There is rather tortured logic in the old (and maybe new) documents justifying the ability to have multiple addresses in the single From: header. Personally, I've never sent or received one of those, even as a test message (I'm sure to get one now, having said that ;-)). The other side of the coin is that there almost have to be multiple received headers (OK, there could be one, munged some more by each handling MTA, but that sounds dangerous for several reasons including ultimate size), since multiple MTAs along the message's travel MUST each include a Received: header (or would have to stick the information into the one Received: header given the other rule). And, of course, too many hops would be harder if the MTAs had to unwind a 30 sub-item Received: header. So let's turn the question around: of what headers is there a logical reason for multiples. 1. Received, for the reasons mentioned. 2. X-anything (I suspect, since there's little control over those) But not Date: (despite the appearance of multiple ones of those in some messages) and several others. Reply to: ?? There probably shouldn't be huge numbers of Reply to: addresses. Multiple addresses are probably allowed on the same sort of reasoning as multiple addresses in From:--the boss and the secretary thing. (Unlimited reply to headers sounds like a great way to get a Spam multiplier effect, but that wasn't a consideration at RFC writing time.) And remember, too, that some things in RFCs are the way they are because that's the way they are (and are hard to explain any other way). --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] big list
At 12:15 -0500 3/8/2002, Barry A. Warsaw wrote: It would be really cool if we could get a bunch of MTA authors together (I only care about the open source ones wink) to define a protocol for letting the MTA doing the stitching. I think Postfix, and probably Exim support a way to do this for the envelope sender, but the really interesting bits happen when the body of the message can be personalized. The outgoing MTA's the most efficient place to do this, but you have to get it the information it needs to chew on. I know there's been some talk about subsuming the outgoing functionality into MM, but I see such a bulk mailer/stitcher as a separate project, that could be integrated into MM through a new DELIVERY_MODULE. I don't expect to have time to work on that myself, so there's an opportunity for someone who wants to contribute. I suspect you'll get a lot of resistance from MTA authors to the idea of an MTA (mail transfer agent) messing with the bodies of the messages. That's MUA work. This is more for a purpose-built tool which knows how to send messages to the world's MTAs and how to prepare messages, but does not know anything about receiving messages from general local senders or from the world. In other words, a potentially useful different product. Aside: how far we've come from the old mainframe LISTSERV, the network of which carefully sent one copy along with a list to addresses to various neighbors near the addressees for further distribution. So quite likely, only one copy crossed the Atlantic...possibly one one went from Chicago to Florida, etc etc. As to VERPing a big list with the *current* tool: don't (if it hurts, don't do it, and I doubt whether throwing enough more hardware at the 50,000 address list is feasible). VERP a bunch of little lists roughly sequentially. The originator of the thread might try the first 1,000 and see whether 50 1000 member lists will work. *Particularly* when nearly 50,000 bounces are expected (the list is bouncers from other lists, per the initial message). --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] big list
At 23:31 +0100 3/8/2002, Fil wrote: Sometimes you want to try and stress things, just to give beta feedback to Barry. I've shown a problem with computing all VERPed messages before sending (as opposed to *while sending*), I'm quite happy with that being in a beta (or alpha) moment before the much awaited MM2.1. Indeed, and that part of the thing you did was excellent. (I find it interesting that a second try worked somewhat well, at least initially.) If you wanted quick results, the approach turned out not to be right...but it certainly stressed well. Cheers! -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Please Allow Me To Introduce Myself...
At 15:01 -0800 3/8/2002, James J. Besemer wrote: However you characterize them, don't you agree they are the future (which was the main point of my sentence)? For better or worse, I detect an inexorable trend. Trend, yes. Perhaps it's wishful thinking, but I don't think inexorable. Counter trends: [US] ADA compliance wireless email appliances [Both would make XML mail sensible, but not tower-of-babel HTML.] None of which detracts from your point: Mailman needs more ability to deal with HTML mail. ---John (and besides, at age 62 now, I'll likely miss out on whatever happens...which if that is HTML email, is good) -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Please Allow Me To Introduce Myself...
At 16:14 -0800 3/6/2002, James J. Besemer wrote: Another faction doesn't object to HTML per se except that the text in such messages (for them) appear in too small a font and they can't figure out how to change it. Happens to me a lot since I read mail on my Macs, and a sensible size on a Windows machine (particularly in Times) is unreadably small here. (96 bit vs 72 bit issues). It happens on Web pages as well, where it's easy to change the size but I often don't bother. My solution is simple for mailing lists: if a message is hard to read, I don't read it (unless it seems to answer a question I posed, in which case I try). --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Protecting email addresses from spamharvesters
At 10:55 -0800 2/27/2002, Dan Mick wrote: wrong was misstated; what I meant to say was the user is not part of Mailman. But the user is part of the mailing list system. Usually the most troublesome part. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 10:15 -0800 2/20/2002, Chuq Von Rospach wrote: That, basically, allows us to stuff mailtos somewhere pointing to an address you can mail to to report site failures. I'll even go farther and say that address can simply be on a web page, not linked to a Mailto, and if you really, reallly want, obscure it further as a JPG or something. But I think that's all overkill, given that spammers now automatically spam root/postmaster/etc on domains anyway. Which (as the reader of many of those, and as the person who adds content filters) I find amusing: they deliberately attract the attention of the one most likely to do something. I guess it makes sense when they think about individual's machines sitting there accepting mail; it doesn't make sense when then send to a server which serves lots of users. It reminds me of the punt returner signalling for a fair catch when the ball will come down near the goal line. What that says to the onrushing troops is ignore me and my teammates: we can't hurt you anyhow...go after the ball and keep it this side of the line. Exactly what the troops' coach wants them to be told. So I recommend this: You no longer advertise admin's real addresses. Instead, you advertise a feedback that sends messages to the admin, to discourage mailing directly. A year ago, I probably would have insisted on SOME kind of email contact point, but frankly -- the percentage of users who can't use a web page is pretty much zero now. [Good justification snipped.] I think you're on to something, Chuq. It also helps those admins who prefer to use a role address rather than a personal one, as things stand now. Saves inventing yet another of those which isn't specially handled by the MTA/Mailman combination. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 13:42 -0800 2/20/2002, Chuq Von Rospach wrote: And any decent library also has a rare books room, which IS tightly locked up. And while the content of a mail list qualifies as a public library to some degree, the subscriber addresses live in that rare book room. At least in Chuq's context, in which Apple claims in their privacy policy to protect the addresses of us innocent subscribers to their lists. That context may not match the context of other list operators, who may feel that the subscribers are out in the main stacks somewhere. Or in a drawer in the librarian's desk for suitable review. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam onpostedaddresses...
At 20:36 -0500 2/20/2002, Jay R. Ashworth wrote: [Quoting Chuq] See above. You don't get the analogy right. [Jay] No, I merely don't value the email address's privacy as highly as you do. I get about 50 spam a day in 200 new messages including about 14 mailing lists -- I'm entitled to hold that opinion if I want. You *can't* make addresses overly private; they cease to be usable. At least, given the supporting tools and infrastructure we have today. I have a domain, for no particularly good reason. (I saw the word in a book ad in Science News...I bought the book and the domain based on the ad. And since you could look it up it's scandaroon.com.) Once I had the domain, I started registering each product (or company's products) with a unique local part @scandaroon.com. Late last year, I had a sudden infusion of Spam addressed to [EMAIL PROTECTED] [Company shall remain nameless ;-)] Sending mail to that address now produces a 550 response whose text is sold down the river by Palm (Which might be wrong...they might have leaked it instead...which IMHO is worse.) Palm is probably following the privacy policy as it has evolved since I registered the (early production) Palm IIIx. For Usenet posting, I use an @spamcop.net address...the harvesters don't seem to bother with those...no obfuscation seems to be needed. (And yes, I get to deal with our SpamCop reports, but for THIS purpose the service works very well.) Scrambling quickly back on topic: some list admins could do well to try a SpamCop address--or the like elsewhere--for list admin purposes for Mailman lists. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 0:08 -0500 2/21/2002, Dale Newfield wrote: If the question and answer can be arbitary on a site by site, or better, hit by hit basis, then it becomes infeasible to build a spambot to enter such sites. If it's arbitrary, it's generated by some algorithm. If it's generated by some algorithm, I just need to figure out the algorithm and I can always get it. Not to mention that people surprisingly often mess up answers to questions as easy as Who is buried in Grant's Tomb? --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA Who is buried in Grant's Pass? Many people who lived there, and some who had moved away. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 23:15 -0500 2/20/2002, Dale Newfield wrote: On Wed, 20 Feb 2002, Damien Morton wrote: I still think the email-address-as-jpeg solution is prohibitively expensive to reverse; effectively impossible for machines, entirely easy for people. ... It can't be enlarged for people that have poor vision. Opera is a counter-example, but doesn't defeat your point. (Tidbits the cat enlarged the web page my Windows laptop was idling on to 200% earlier today in a walk across the keyboard: Opera has keystrokes for nearly everything.) --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
RE: [Mailman-Developers] Interesting study -- spam on postedaddresses...
At 7:12 -0500 2/18/2002, Damien Morton wrote: There are several approaches to this, including the use of javascript email decryptors and/or publishing email addresses as rendered images. I don't think we can assume that the user who feels a need to send mail to the admin has a JavaScript-capable browser with JavaScript turned on. Nor can we require it, IMHO. --John (right now, I can't remember which browsers on which machines have Javascript turned on. Not good) -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
[Mailman-Developers] Future: Safe Auto-moderated Announce List
I see the basic how do I let the right people post to this announce list automatically question often enough to indicate that there is a perceived need. Let's put digital signature technology to work. For some post 2.1 release (and probably patchable into 2.1 by suitable people), extend the privacy options to include: List (two columns...duplicate senders probably allowed for the case of a work key and a home key or an assistant's key for authorized forging, or whatever): Automatically post messages from these senders PROVIDED they are digitally signed using the key listed for the sender. Checkbox: Automatically and silently reject (with logging) any message not from a listed sender and properly signed. Variations (not silently rejected, etc, if desired...but sending a rejection message gives the would-be rogue poster information). It seems to me that this can be turned into a suitable solution to the auto-moderated announce list desire, without a whole lot of coding. I didn't see such a feature request on SourceForge...if I missed it I apologize (I've spent no more than 15 minutes driving SourceForge). --John (whose site has about 5 lists which would benefit from this feature) OA (Obligatory acronym): SAMAL -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Mailman CVS works on OS X!
At 13:20 -0800 1/23/2002, John W Baxter wrote: [Off-list deliberately...OK to quote back onto the list if for some odd reason you want to.] Aargh...fortunately, there was no reason aside from off-topicness for me to try to send off-list. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: way to minimize IO load with MTA supported VERP
At 14:18 -0500 12/7/2001, Bob Puff@NLE wrote: Speaking of Exim.. one thing that really bothers me about Exim is the message(s) it sends when it has to wait to deliver the message... these would be interpreted as bounces, although they really are not. I've seen a few such messages, only to have the message delivered normally. That would trigger some bounce logic to at least pick up on what really isn't (yet) a bounce. Exim's delayed delivery warnings are orderly enough that it would be quite easy to ignore them in bounce processing. In several ways, they don't look like failure messages. Meanwhile, they let a user who has mistyped an address know about it sooner than without the messages. For an Exim running in support of live users. Assuming, of course, that the Exim administrator has resisted the temptation to improve the delayed delivery message. If she's done that, users are likely to fall off lists. One hopes that the Exim admin and the Mailman admin are speaking to each other. If the Exim is running just to handle Mailman, the warning message can be done away with entirely (and the retry intervals can be adjusted, and several other such adjustments made). Trivially. But of course, you can't configure away messages generated by remote sites you don't control. --John ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Re: [Mailman-Users] Bounce Options
At 2:18 -0500 12/1/01, Barry A. Warsaw wrote: I'm more concerned with the user who fills up his disk and doesn't notice it for a week because they're on vacation. I'd like Mailman to be robust against this, and I think the average non-deliveries over a couple of weeks, with consignment to probation probably catches most of this use case. I'd prefer that such folks subscribe again if still interested. You've provided that option, so that's not a complaint about the design. Note that the one last warning may well bounce in this case. On the other hand, I was on one list with a one bounce and you're out rule (clearly stated in the welcome message). That's too draconian for even me to use (I had to resubscribe about 4 times over 3 years). They were using Majordomo, and the person in charge had a quick trigger finger. ;-) --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Messing with Defaults.py
At 1:39 -0500 10/31/2001, Bob Puff@NLE wrote: One more question. I realize the docs say never to mess with Defaults.py, but use the mm_cfg.py. What happens if you do mess with Defaults.py? Are modules somehow linked to certain byte offsets in it that, if modified, makes things go boom? When you upgrade Mailman, your edited Defaults.py is replaced. Your mm_cfg.py is left alone. No strange linking...it's just source code. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] Reply-To: handling
At 22:15 -0700 10/19/2001, J C Lawrence wrote: BTW: Have you checked Mutt's behaviour yet? Could/would someone check Outlook's behaviour? Eudora 5.1 beta for Mac OS X (wherein I am at the moment) honors multiple address Reply-To: headers. It's highly likely that Eudora has done so from the beginning (Steve believes in standards even though he hasn't been allowed to add the list header handling yet: odd in that Qualcomm was involved in developing the list header RFC). It's likely that the little Windows offshoot from Eudora (called Eudora) also does it right, although it's a largely different team doing the work. I can test if no one else here can easily. --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
Re: [Mailman-Developers] (2.0.6) pipermail takes 1 minute to rebuild indexes on large lists
At 9:58 +0900 10/10/2001, Ben Gertzfield wrote: Yes, this is probably the right solution. In fact, I'm actually leaning towards suggesting that Mailman just come with or depend upon hypermail for archiving; we're just re-inventing the wheel by trying to modify pipermail over and over, and it's really not going to scale. A problem here is that Hypermail is far from the only game in town. I don't know its current state: hopefully much better than when we tossed it out about 5 years ago. Should mailman be picking the outside archiver to use, or should it just make it easy to use SOME outside archiver? (If there is some archiver which is the GNU archiver in the sense that Mailman is the GNU mailing list manager, I suppose that one could reasonably be favored.) --John -- John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
