I want all mails sent to the list to come from the list's email address...
But, in this case, if the user forgets to sign their name at the
bottom of their mail body, effectively the mail to the list is
Is there a way to add the user name (or email address) to the top of
each mail so that the mails have the name of the sender, while the
mail itself comes from the list address?
I have looked high and low for an answer, but noone seems to have the solution.
I received the following error this morning. So I rerun configure again with the following command: ./configure --with-cgi-id=apache --prefix=/var/mailman. I'm still getting the same error. Is there any place that I can look for so that I can debug this problem better? Perhaps, looking at the config history file or something. Any other places that I can check the cause of this error?
"Mailman CGI error!!!
The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog:
Group mismatch error. Mailman expected the CGI
wrapper script to be executed as group "nobody", but
the system's web server executed the CGI script as
group "apache". Try tweaking the web server to run the
script as group "nobody", or re-run configure,
providing the command line option `--with-cgi-gid=apache'."
-----BEGIN PGP SIGNED MESSAGE-----
I have Mailman up and running. I just sent an e-mail to 5 lists and
the e-mail came duplicated to the recipients. I checked the header and
the only difference is the following:
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00
How can a avoid duplicates in future? What is the reason?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
-----END PGP SIGNATURE-----
we recently updated our (vhost patched) Mailman installation
from 2.1.14 to 2.1.18-1 (https://launchpad.net/~msapiro) in order to
workaround Yahoo's recent change to their SPF policy that this
version addresses. Virtual mailing list hosting worked fine up until
Here is an example of our mm_cfg.py :
DEFAULT_EMAIL_HOST = 'list.ourdomain.com'
DEFAULT_URL_HOST = 'list.ourdomain.com'
DEFAULT_URL_PATTERN = 'http://%s/mailman/'
VIRTUAL_HOST_OVERVIEW = On
If we change the default values above and run the below command, the
available mailing lists move from the old default to the new.
bin/withlist -l -a -r fix_url --
All add_virtualhost configuration lines are ignored.
Since withlist is able to read the changes in our mm_cfg.py, this
does not strike me as an issue with our configure options which were
I am unaware of a method we can use to further debug this, such as a
command that would effectively dump out Mailman's configuration
options, thus validating if it is even reading the add_virtualhost
President - Rocket Scientist
I run a mailing list of about 1-2 thousand subscribers for announcements
only. My ISP has started sending me automated messages claiming that
there is a high spam/virus sending rate from my IP address. It took me a
long time to get a straight answer from them, but eventually they told
me that they are not triggering on me sending email, but on the number
of bounces that come back.
My setup is that outgoing mail goes through the ISP's mail server (that
was their recommendation) but incoming mail comes directly to me. I send
out an announcement, and a few days or a week later I get an automated
message from the ISP suggesting I might be sending spam or a virus and
pointing me to the usual generic Windows anti-virus solutions.
All my computers here are Linux, so while it is not impossible that I
have been infected and am now part of a spammer's botnet, I think it's
I receive unhandled bounce notifications (no more than a handful of
those, which I then manually remove) and see notifications of addresses
that are removed for excessive bouncing, again no more than a handful at
a time. How can I see a list of members set to No Mail for bouncing?
Can you suggest anything I can do to avoid triggering the ISP's system?
(A hard question, I know, since we don't know precisely what triggers
it in the first place.)
Twenty years ago, I attended the first Python Workshop at NIST with about 20
other old school Pythonistas. Earlier this month I attended PyCon 2015 in
Montreal. PyCon is always exhilarating, but this one was incredibly special
for me personally, because my son was on spring break and joined me for the
first half of the conference.
Both the Python language and its community have grown a little bit <wink> in
the intervening years, but what hasn't changed is our love of the language,
and the truly amazing people we share that love with. The Python community
really is one of the very best open source communities on the planet.
The best community inside that great Python family has to be the GNU Mailman
team. They're all smart and cool, fun to hang out with, and fun to hack with.
With diverse backgrounds, each and every one are good friends and valued
technical peers. As has been the case for the last few years, we've sprinted
on Mailman 3, getting lots of great work done, but never quite getting
something we were satisfied enough with to release. The first alpha of
Mailman 3 was released a little over 7 years ago.
And so I'm here --and on behalf of Abhilash, Aurélien, Florian, John, Mark,
Stephen, Sumana, Terri, our GSoC students, and all the great people who have
contributed over the years-- to proudly announce the official release of GNU
Mailman 3.0, code named "Show Don't Tell".
Mailman 3 is really a suite of 5 tools:
* The core, which provides the mail delivery engine, the unified user model,
moderation and modification of email messages, and interfaces to external
* Postorius, our new Django-based web user interface for users and list
* HyperKitty, our new Django-based web archiver, providing rich access to the
historical record of mailing list traffic;
* mailman.client, the official Python bindings to the core's REST API;
* mailman-bundler, a set of scripts to make it easy to deploy the full
suite inside Python virtual environments.
What's new about Mailman 3? Well, lots! Some highlights include:
* Backed by a relational database;
* True support for multiple domains, with no cross-domain mailing list naming
* One user account to manage all your subscriptions on a site;
* The core's functionality exposed through an administrative REST+JSON API;
* All passwords hashed by default, and no monthly password reminders!
* Users can post to lists via the web interface;
* Built-in archive searching!
and more. Tons more.
There will be things you love about Mailman 3, and things you don't like.
You'll glimpse great possibilities and glaring holes. You'll be excited and
frustrated. Such is life with an all-volunteer free software project.
For the things you like, and the exciting possibilities, we encourage you to
experiment, to do wacky things we haven't thought of, integrate it with your
own tools, or just carefully go about deploying a Mailman 3 system. Tell us
how you're using it!
For the things you don't like, we invite you to join us. Come to the mailing
list <mailman-developers(a)python.org> and talk with us. Submit bug reports and
pull requests. Help us close the gaps and make Mailman 3 better.
Whether your interests are for Internet RFCs, web site development,
operations, or you just want to find a fun Python project to hack on with cool
people, as they say, contributions are welcome.
See the release notes, as well as links to download each component:
You probably want to start with the bundler and let it grab and install all
the other parts.
More information is available at:
#mailman on freenode
Happy Mailman Day,
-Barry & the Mailman Cabal
What’s on your wishlist for the perfect Mailman web interface?
If you can provide links to show where your ideas are done well that would help to illustrate your thoughts.
Any killer features that you’d like to see in the perfect Mailman web interface?