-----BEGIN PGP SIGNED MESSAGE-----
I am happy to announce the first release candidate for Mailman 2.1.15.
Python 2.4 is the minimum supported, but Python 2.6 is recommended.
This release should work with Python 2.7, but has not been tested with
This release includes minor security enhancements, new features and
bug fixes. See the Changelog at
<https://launchpad.net/mailman/2.1/2.1.15rc1> 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:
Mailman 2.1.15rc1 can be downloaded from
It is anticipated that the 2.1.15 final release will be on or about
June 13. Bugs found between now and then will be fixed if possible,
but I hope that most if not all changes between now and June 13 will
be i18n updates. Please send any updates to the templates and/or
message catalogs in the 2.1.15rc1 release directly to me no later than
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.7 (MingW32)
-----END PGP SIGNATURE-----
I have recently shifted my site and mailing list on Hostgator server here in India.
Today, I've got an E-Mail from them saying that as per the mail policy, our members can send 500 mails per hour but we are exceeding the number of mails a day!
While the fact is we have around 360 members and we send hardly 50 to 60 messages in entire day of 24:00.
so, I am unable to understand what's wrong with us. Are some of our mails account got hacked and compromised?
Hostgator team has send me the number of messages and Email addresses sent from:
They also send me some Random recipient addresses.
Please advise me, what it looks like, problem with some mailman setting at our end? any issue with the technicality of my service provider? or as I suspect, are above mail accounts being misused?
Hi Mailmen and -women,
I'd like to administrate some ~20 email lists of a team of people
working together via mailman. Once a user leaves the team, I should
unsubscribe this user from all lists that he's on. How do I do this
without having to click through 20 web interfaces?
First I thought, hey, I simply send an unsubscribe email, just like the
subscribe email. Well, that doesn't work though, since unsubscription
always requires the user password, which I don't have of course. So I
searched around and found this thread:
about exactly this. Now, that suggests a global change by patching a
python script. But since the mail server I'm using is actually for a
whole institute, the administrator probably has little interest to
globally change his Mailman/Commands/cmd_unsubscribe.py just because of
my 20 mailing lists, in particular since some of his other lists may be
more security sensitive than mine. In addition, if I try to patch this
file rather than having some patch from somebody who actually knows
python ;-) he probably won't like it anyway...
So I continued searching and stumbled across the possibility of doing
this via wget:
Wow, that would be fantastic! :-) I could simply shell script that, not
even worrying whether the user is subscribed to all 20 lists and just
batch-unsubscribe (if the user wouldn't be on a given list, nothing
would happen, so that's OK) Now, I'm not super sure I got the command
line right, this is what I tried:
and I also tried to directly enter
into my browser. In both cases what I got back was:
<head><title>Bug in Mailman version 2.1.9</title></head>
<body bgcolor=#ffffff><h2>Bug in Mailman version 2.1.9</h2>
<p><h3>We're sorry, we hit a bug!</h3>
<p>Please inform the webmaster for this site of this
problem. Printing of traceback and other system information has been
explicitly inhibited, but the webmaster can find this information in the
Mailman error logs.
and now I'm lost :-\ Can somebody help me? How can I unsubscribe a given
user from a couple of mailing lists at the same time without having to
go through the clumsy web interface for each of the mailing lists?
Your help is greatly appreciated - thank you very much!
I just installed, and just as promptly un-installed mailman on Ubuntu
server 10.04.4 LTS. The offered pacakge version of mailman for this
release, which I used, is 2.1.13-1.
I have a few questions which perhaps someone could answer, if anyone
knows the thinking behind Canonical's (and the package maintainer's)
motives/reasons for what was done.
The most awkward change, for me, is the elimination altogether of the
mailman user. Mailman native scripts and utilities apparently get run
as root, which as always brings up a whole kettle of security questions.
On top of that, I've written a script package to parse and automatically
unsubscribe list subscribers based on AOL's "Email feedback reports" for
all the lists I host, using, among other things, mailman's python
library and the withlist utility. These scripts depend on the existence
of a non-privileged Mailman user account with a home dir
of /usr/lib/mailman. Yes, I could hack the scripts to make things work,
but I'm in the process of a major server move between Linux platforms
from different distributions and my time is budgeted.
Why was this done?
It looks as if I'm going to have to install mailman from source on
Ubuntu. I believe the Gentoo download, installed on my older servers,
hewed much more closely to the methods and design of the Mailman devs,
but I'm wondering what I'm missing here, or if the change was just due
to lazy package design on Canonical's part.
Lindsay Haisley | "Real programmers use butterflies"
FMP Computer Services |
512-259-1190 | - xkcd
Emails from a group in my "Basic Mailing List 'can be found and read
by/from Google and other search engines. How can I do to hide these
e-mails/group, so that others can not read them? At this way, any one can
read the emails.
I didn't found any options about it.Some one can help me ?
I'm using the mailman vhost branch (is this the 'best' thing to use to
do multi-domain mailing list hosting?)
When I enter /mailman/admin/2030 it first asks for the password, after
that I get an error page 'Bug in Mailman version 2.1.14'
This happens on all the lists, but it did used to work but I'm not sure
what has happened to break it now.
The Error log can be seen at http://pastebin.com/KZKMwCap
There is an old discussion in this list's archives on this topic at
Unfortunately, it didn't help me.
The problem, as I understand it, is that when you change the digest
setting, it also affects the non-digest setting. The archived thread
didn't resolve or clarify this for me. We are experiencing this
Set the following option to "plain". Note that this is a digest
option, not a non-digest option.
When receiving digests, which format is default? Plain
Then set the following option to "regular":
Which delivery mode is the default for new users? Regular
Now add a new member to the list.
What happens is that the new member is set to non-digest and plain
If you now change "mime_is_default_digest" to MIME and add a new
member, the new member is set to non-digest and rich text defaults.
So the digest option is changing the default settings for non-digest
new members. This is both confusing and limiting.
We want digest emails sent out in "plain" format by default. But we
want the non-digest option with rich text to be the default for all
new users. There doesn't seem to be a way to achieve this. Hopefully,
there is a setting I'm overlooking.
Is this an appropriate place to discuss the broader topic of how to best
use Mailman? Now that we have it running well, we would like to take
additional steps to ensure that the list's emails are delivered as well as
they can be.
The 37Signals article caught my attention. I would enjoy knowing others's
thoughts about how to apply these (or other) suggestions to Mailman.
It seems to me that Mailman provides at least some of the intelligence (via
logs) that 37Signals custom developed on top of Postfix. Am I right? The
core suggestions seem to be universalL SPF records, DKIM signing, reverse
DNS entries, etc.. (And, btw, I don't yet know how to implement any of
those things except SPF records.)
Giving away the secrets of 99.3% email
We send a lot of mail for Basecamp <http://basecamphq.com/?source=svn_post>,
and Campfire <http://campfirenow.com/?source=svn_post> (and some for
Sortfolio <http://sortfolio.com>, the Jobs Board <http://jobs.37signals.com>,
Writeboard <http://writeboard.com>, and Tadalist <http://tadalist>). One of
the most frequently asked questions we get is about how we handle mail
delivery and ensure that emails are making it to people’s inboxes.
First, some numbers to give a little context to what we mean by “a lot” of
email. In the last 7 days, we’ve sent just shy of 16 million emails, with
approximately 99.3% of them being accepted by the remote mail server.
Email delivery rate is a little bit of a tough thing to benchmark, but by
most accounts we’re doing pretty well at those rates (for comparison, the
tiny fraction of email that we use a third party for has had between a
96.9% and 98.6% delivery rate for our most recent mailings).
How we send email
We send almost all of our outgoing email from our own servers in our data
center located just outside of Chicago. We use Campaign
Monitor<http://campaignmonitor.com>for our mailing lists, but all of
the email that’s generated by our
applications is sent from our own servers.
We run three mail-relay servers running Postfix that take mail from our
application and jobs servers and queue it for delivery to tens of thousands
of remote mail servers, sending from about 15 unique IP addresses.
How we monitor delivery
We have developed some instrumentation so we can monitor how we are doing
on getting messages to our users’ inbox. Our applications tag each outgoing
message with a unique header with a hashed value that gets recorded by the
application before the message is sent.
To gather delivery information, we run a script that tails the Postfix logs
and extracts the delivery time and status for each piece of mail, including
any error message received from the receiving mail server, and links it
back to the hash the application stored. We store this information for 30
days so that our fantastic support team <http://smiley.37signals.com> is
able to help customers track down why they may not have received an email.
We also send these statistics to our statsd server so they can be reported
through our metrics dashboard. This “live” and historical information can
then be used by our operations team to check how we’re doing on aggregate
mail delivery for each application.
Why run your own mail servers?
Over the last few years, at least a dozen services that specialize in
sending email have popped up, ranging from the bare-bones to the
full-service. Despite all these “email as a service” startups we’ve kept
our mail delivery in-house, for a couple of reasons:
- *We don’t know anyone who could do it better.* With a 99.3% delivery
rate, we haven’t found a third party provider that actually does better in
a way they’re willing to guarantee.
- *Setup hassle* Most of the third party services require that you
verify each address that sends email by clicking a link that gets sent to
that address. We send email from thousands and thousands of email addresses
for our products, and the hassle of automatically registering and
confirming them is significant. Automating the process still introduces
unnecessary delivery delays.
Given all this, why should we pay someone tens of thousands of dollars to
do it? We shouldn’t, and we don’t.
*Read more about how we keep delivery rates high after the jump…*
How we keep our mail delivery rates up
Lets be honest from the get-go. Mail delivery is more of an art than a
science. We’ve found that even when you “play by the rules”, there’s still
times when a major provider will reject all your mail without notice.
Usually it takes a couple emails to to the providers abuse address, and
things get resolved. In spite of these “out of our control” issues, we’ve
found a few things help us keep delivery rates up:
1. *Constantly monitor spam
.* We have a set of Nagios alerts that regularly check if we’re listed
on any delivery blacklists, and whenever they go off we take whatever
corrective action we need to get back off the blacklist.
2. Have valid SPF
impersonate your users. When running a web app like
Basecamp <http://basecamphq.com/?source=svn_post>, which sends email
that are generated by another user, it can be tempting to send the email
from that user (e.g., so that a comment I wrote on Basecamp would appear to
come from noah at 37signals dot com), which might make people feel more
comfortable. Unfortunately, this is a surefire way to end up on spam lists,
since you’ll likely be sending from an IP address that does not have the
valid SPF records. And chances are, if the user’s domain does have
an SPFrecord, it doesn’t include your application’s IP.
3. Sign the mail! DKIM and Domain Keys <http://www.dkim.org/>. Yahoo and
Gmail both score signed email higher.
4. Dedicated and conditioned email sending IPs.
5. Configure reverse dns
Most of the “big boys” won’t accept mail from your servers if your reverse
dns entries don’t match. You might need your IP provider to help with
setting up these records.
6. Enroll in feedback
We haven’t automated our parsing of feedback, but a daily / weekly review
of feedback loop emails helps us know when there’s an unhappy user, or
other problem. Too many complaints and you’ve got trouble.
A problem we haven’t solved
By far the biggest cause of failed email delivery we see is due to bad
email addresses that were entered in to the system—problems like ‘
joe(a)gmal.xn--com-to0a or ‘sue(a)yahooo.xn--com-to0a. By and large, these pass a regular
expression check for email addresses, but aren’t actually valid addresses.
There’s no perfect solution here, but we’ve been experimenting with
checking for valid DNS records or actually attempting to connect to the
mail server as part of the validation of an email address, and with
notifying people within the application when we aren’t able to deliver mail
A few tools
- MX Toolbox <http://www.mxtoolbox.com> is a great site for doing a
quick check on your mail servers and your customer’s mail servers.
- Sender Score <https://www.senderscore.org/> is really a marketing tool
for Return Path, but it can be used to get insight about how some of the
“big boys” are scoring your sending IPs.
- Postmark <http://spamcheck.postmarkapp.com/> offers a web tool
and APIto get the SpamAssassin score for a message, which can be
identifying things you can improve to boost delivery rates.
Some hacker has deleted our mailing list using backdoor shell spyware.
I expected my service provider would retrieve the list by restoring full backup. they restored the data, but mailing list is still not there!
Now, is there anyway to get it back? or we have to create new mailing list.
Since the above incidence is very shocking and disturbing for me and our subscribers, I would anticipate any ultimate and best possible solutions from you experts on this board.