Mailman-Developers December 2009

mailman-developers@python.org

7 participants
8 discussions

Re: [Mailman-Developers] Reply-To munging considered *carefully*

by Stephen J. Turnbull

Michael B. Trausch writes: > My main, central, and driving point is a desire to create a system that > is both idiot friendly and expert friendly, and my desire is to have all > known common (end-user) and uncommon (technical user) use cases be > handled in a manner that is consistent and portable. That's what we want, too, Brother Michael. The difference between you and us is that we believe in the RFC process, we believe in decentralization, and we believe that if we design a better way to do it in that context, software developers will adopt it and users will get the benefits merely by upgrading their favorite software (or changing, if another implementation becomes more attractive in the process).

11 years, 1 month

Mailman 2.1.13 released

by Mark Sapiro

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am happy to announce the final release of Mailman 2.1.13. Mailman 2.1.13 is a bug fix release and contains a new localization for the Asturian language. Python 2.4 is the minimum supported, but Python 2.5.or 2.6 is recommended. See the changelog at <https://launchpad.net/mailman/2.1/2.1.13> for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman Mailman 2.1.13 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ - -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEARECAAYFAksxF7oACgkQVVuXXpU7hpMBmwCgvJT3lqRcAJcAV+7PwvBcx1Hs pDUAoI9iJiKjB+8gVSJeVkoz+TKmrBN2 =FE2n -----END PGP SIGNATURE-----

11 years, 2 months

Mailman-Developers list's welcome mail formatting errors

by Gabor FUNK

Hi list, Just subscribed. I take this broken recently or noone read or cared to report that this list's welcome mail have some "problems". Header says, it is: Content-Type: text/plain; charset="us-ascii" [so it is not my mailer broken] but body contains "<"-s instead of "<"-s. ">"-s seems to be ok. some quotes: find out more information about this list at <http://mail.python.org/mailman/listinfo/mailman-users>. Most ... There is also an announce-only mailing list mailman-announce (see <http://mail.python.org/mailman/listinfo/mailman-announce>), and a ... Project page at <http://sf.net/projects/mailman>. You might also want to check out the Mailman home page at <http://www.list.org/>. .. You might want to start by reading the Mailman FAQ (see <http://www.python.org/cgi-bin/faqw-mm.py>). Also check out the searchable archives at <http://www.mail-archive.com/mailman-developers%40python.org/>. etc... g.

11 years, 2 months

Mailman 2.1.13rc1 released

by Mark Sapiro

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am happy to announce the first release candidate of Mailman 2.1.13. Mailman 2.1.13 is a bug fix release and contains a new localization for the Asturian language. Python 2.4 is the minimum supported, but Python 2.5.or 2.6 is recommended. See the changelog at <https://launchpad.net/mailman/2.1/2.1.13rc1> for more details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see: http://www.list.org http://www.gnu.org/software/mailman Mailman 2.1.13 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ Note to translators: The mailman.pot is up to date in this release and has been merged with the individual message catalogs. If possible, please review your translations and submit any changes before December 21 if you want to get them in the 2.1.13 final release. - -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEARECAAYFAksmk3EACgkQVVuXXpU7hpMFvQCdFQV4sgxkVEDuUNlgiNALXe6/ 3jYAnAn/5+SQSPby3c3eG7MJhC187cA6 =Pby4 -----END PGP SIGNATURE-----

11 years, 2 months

Anybody looking for an insane project?

by Barry Warsaw

If anybody is looking for something cool, crazy, and experimental to work on for Mailman 3, I have am idea that would fun to explore if I had more free time. I wonder if RFC 3028[1] could be useful in Mailman. This RFC defines the Sieve language for mail filtering. I seem to recall that there's a Python implementation of it, but atm I cannot find it. It's probably most appropriate for advanced users, but perhaps the new web ui could provide some simple access to the more common actions. Some places where it would be useful: * list admins for filtering out off-topic posts * site admins for filtering out known spammers * a better user-defined topic selection machinery * users for defining which of their registered addresses to deliver to I'm sure we'd think of lots more cool and wacky ways to use this if we had it. So, who'd like to take up the challenge? -Barry [1] http://www.faqs.org/rfcs/rfc3028.html

11 years, 2 months

Proposed: remove address-obfuscation code from Mailman 3

by Rich Kulawiec

Summary: Spammers now have so many ways of "harvesting" addresses from so many systems, and so many ways of exchanging those with each other, that any email address which is actually used WILL eventually be harvested. (Where what "eventually" means varies widely, of course, but can be expected to steadily decrease.) Pretending that address obfuscation in mailing list [or newsgroup] archives will have any meaningful effect on this process gives users a false sense of security and has zero anti-spam value. Summary of summary: It's pointless. Explanation: Spammers maintain extensive databases of email addresses. Some of those databases are merely lists of addresses; others are more sophisticated and include data such as "harvested-date", "havesting-method", "last-seen date", "last-seen-context", "last-known-valid date" and more. Some of these databases are private; others are available for sale/lease. Some are maintained by spammers themselves, others by spammer support services don't directly engage in spamming. The harvesting engines used to acquire email addresses are myriad, as are the methods by which spammers acquire the raw data to use as input to them. *Some* of those methods, and there are many more, include: - subscribing to mailing lists - acquiring Usenet news (NNTP) feeds - querying mail servers - acquiring corporate email directories - insecure LDAP servers - insecure AD servers - use of backscatter/outscatter - use of auto-responders - use of mailing list mechanisms - use of abusive "callback" mechanisms - dictionary attacks - construction of plausible addresses (e.g. "firstname.lastname") - purchase of addresses in bulk on the open market. - purchase of addresses from vendors, web sites, etc. - purchase of addresses from registrars, ISPs, web hosts, etc. - domain registration (some registrars ARE spammers) [1] - misplaced/lost/sold media (hard disk, tape, CD, DVD, USB stick, etc.) and perhaps most significantly: - harvesting of the mail, address books and any other files present on any of the hundreds of millions of compromised Windows systems [2] Consider for example: the first time a newly-created address is used by someone (who is sending a message to it), it's now present on their system: in their saved outbound mail, or perhaps in their address book (if they have one), or in some cache. Any sensible malware resident on their system will of course pick it up and eventually hand it over to a harvesting agent. (Competent malware will harvest it in real time *and* associate it with the sender's address.) And if that particular system happens to be clean? Doesn't help much, because the more times that address is used, the more systems it's present on. And the more systems it's present on, the greater the probability that one of them is already compromised or will be soon. Thus even if we eliminate the originating end-user system as a possible source, we still have to consider the outbound mail server used by that end-user system, which is also a candidate for compromise. And then the inbound mail server used by the recipient, and then the recipient end-user system. And if there's some filtering appliance or intermediate system in place at either end, then it's there too. If the message is forwarded to a third party, then another set of systems is in play. If mail server logs are rolled up and moved to some central location, then it's there too. If backups are made, then it's present there, and subsequently may be present on any system where the backups are read/restored. And finally, if the destination of a mail message isn't an individual user, but an entire mailing list, then we must multiply the number of possible harvesting points by at least the number of people on the mailing list plus a factor for mail servers/gateways/filters/etc. (modulo overlaps). This in turns means that messages to sent to lists of any appreciable size (say, 1000 members) will turn up on considerably more than 1000 systems -- and the chances that all 1000-plus are secure are microscopic. Please note that the previous paragraph's recitation only covered the last vector I enumerated in the [indented] list above: compromised systems. That laundry list of methods also affords many other opportunities for addresses to find their way into spammers' hands. As just one pointed example out of a great many more that could be cited: how do you know that the address user(a)example.com which has just subscribed to the list you run is a real person and not just the front-end for an address-harvester that will pick up every address used to send traffic to the list? And so on. There are far too many others to enumerate, all of which have discussed at great length in anti-spam forums for many years, and are depressingly familiar to experienced practitioners working in the field. The bottom line is that any email address which is actually used [3], *especially* any email address used to send traffic to a mailing list, is going to be harvested. It's only a matter of when, not if, and "when" is getting sooner all the time. Incidentally, everyone (including me) can produce anecdotal tales of addresses that have remained surprisingly under-targeted by spammers over long periods of time. But this is clearly not the way to bet: it is in spammers' interests to ferret out as many addresses as possible and to use them as soon and as often as possible. Note, however, that some addresses are *deliberately* un-/under-targeted, so lack of substantial spam traffic to a given address is NOT an indicator that the address hasn't been harvested. That's because along with target lists, spammers maintain "suppression" lists, which they use to avoid hitting the addresses of people they think are likely to cause issues for them. [4] And obviously, people with postmaster or mailing list roles would be good candidates for membership on those lists. I know that if I were in their shoes, I'd add everyone who's ever sent a message to the mailman-* mailing lists to mine: a quick check indicates that it's on the order of only 10K addresses. Skipping those would be inconsequential when sending spam to a few hundred million addresses, and I trust it's obvious why spammers would benefit from doing so. With all this in mind, it's clearly pointless to pretend that address obfuscation in archives provides any protection at all. [5] It would be better to remove the code entirely than to continue to maintain the facade that it actually has any anti-spam value. Everyone should simply presume that all email addresses are in the hands of spammers and prepare defenses accordingly -- because even if that's not quite true yet, it will be soon enough. Notes: [1] I deliberately didn't mention mass WHOIS queries. While some efforts in this direction were made by spammers years ago, they've found it far more efficient and cost-effective to simply buy WHOIS data in bulk. There's always someone who wants to sell, and a CD/DVD or USB stick will suffice. This is why attempts by registrars to rate-limit queries or restrict access are not only foolish, but disengenuous: spammers already *have* the data, and can acquire updates at will, and they are clearly doing so via processes that lead back to registrars themselves. [2] The exact number of such systems is not only unknown, but unknowable, since any compromised system which (a) doesn't make its presence known (b) to a suitable detector will remain undetected indefinitely. However, two things are clear: (1) any estimate under 100 million should be laughed out of the room, and (2) there is no reason to suspect that the number is decreasing, and there are numerous reasons to suspect that it's increasing. Note, incidentally, that some detectors have reported observing 200,000 new such systems in a single day; and further note that it's now quite routine for individual botnets with several million *known* members to turn up. [3] Addresses which aren't used may remain out of spammer view for considerable time, depending on the care with which they're selected and maintained. However, this obviously excludes addresses used for participation in mailing lists. [4] For the purpose of this discussion, I'm just talking about suppression lists which enumerate individual email addresses. It's well-known that spammers also maintain suppression lists of MX's, domains, network allocations, ASNs, etc., in an attempt to avoid hitting spamtraps and/or hitting the mailboxes of those who might be in a position to file complaints or take action against them. [5] The only people left who are impeded in the slightest by obfuscation code are NON-spammers: that is, people who are trying to contact someone who has previously sent a message to some mailing list. ---Rsk

11 years, 3 months

Mailman 3.0 alpha 4

by Barry Warsaw

I'm happy to announce the release of Mailman 3.0 alpha 4. Things are getting quite real now. It's pretty easy to hook Mailman up to Postfix for both incoming and outgoing mail[1] and you can create mailing lists and populate them with addresses. Currently, you must do this through the command line though. Please download the latest tarball or grab the bzr branch, and put it through some paces. Now is a good time to comment on the design and feature set for Mailman 3 as we are still in alpha. I'm still planning on releasing a first beta by the end of the year -- your testing, feedback, input, and contributions can help with that! You can download the tarball either from the Cheeseshop, or Launchpad: http://pypi.python.org/pypi/mailman/3.0.0a4 https://launchpad.net/mailman Please note: Mailman 3.0a4 is not production ready yet. Enjoy, -Barry

11 years, 3 months

MM 3 alpha 4: UnicodeWarning

by Patrick Ben Koetter

I just sent a message to my freshly installed MM 3 alpha 4 (on Ubuntu 9.04) and got the following warning: Nov 29 23:53:51 mailman postfix/lmtp[8620]: D409D32E12: to=<test(a)mailman.state-of-mind.de>, relay=127.0.0.1[127.0.0.1]:8025, delay=1.8, delays=0.07/0.01/0/1.7, dsn=2.0.0, status=sent (250 Ok) Nov 29 23:53:51 mailman postfix/qmgr[8613]: D409D32E12: removed /root/mailman/src/mailman/rules/administrivia.py:84: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal if line == '': The delivery worked though. p@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563

11 years, 3 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers December 2009