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).
-----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.orghttp://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-----
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.
-----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.orghttp://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-----
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
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
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.0a4https://launchpad.net/mailman
Please note: Mailman 3.0a4 is not production ready yet.
Enjoy,
-Barry
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