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'."
Hi, This problem is not caused by mailman, but I still want to give it a
shot here. I'm hosting a mailing list on top of mailman. Emails are
supposed to be sent out by AWS ses. However, ses requires that sender
address must be verified, which leads to a problem that emails sent by
subscribers to mailing list cannot be sent to other subcirbers, since their
addresses are not verified. And it is impossible to verified every
subscriber. Are there smtp service providers allowing unverified email
address to send out emails, or do I have other solutions?
This is a weird one. I think of myself as knowing my way around Mailman
pretty well for a user/admin/installer/upgrader. I'm upgrading to a
Debian 9 system from CentOS 6.5. Debian's Apache configs took a bit of
getting used to, but I actually like them better. It uses Apache 2.4.2.
I wanted to install Mailman from source, since the latest version is
2.1.26, Debian has 2.1.23, and IIRC that's too old to have some screen
reader optimizations I want. So I built, installed, all working well. I
copied over the Mailman config from my CentOS system to use in Apache,
making some changes so it'd work under 2.4.2. Here it is:
# httpd configuration settings for use with mailman.
ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/
Require all granted
Alias /pipermail/ /var/lib/mailman/archives/public/
Options Indexes MultiViews FollowSymLinks
Require all granted
# Uncomment the following line, to redirect queries to /mailman to the
# listinfo page (recommended).
# RedirectMatch ^/mailman[/]*$ /mailman/listinfo
The problem is that the CGI isn't working. If I go to
http://temphostname/mailman/listinfo/mailman for example, Apache says
/usr/lib/mailman/cgi-bin/listinfo/mailman doesn't exist. If I just go to
/mailman/listinfo I get an Elf binary thrown at me, rather than the page
saying there are no advertised lists. If I do the same thing from the
server using the Lynx web browser, I get the same binary thrown at me,
with a page title, "Mailman CGI error!" It sounds to me like Apache
2.4.2 isn't seeing that /usr/lib/mailman/cgi-bin is, in fact, CGI
scripts, and is trying to treat them like regular files. Has something
else changed between Apache versions?
Dear all happy campers,
I need to upgrade from Mailman 2.1 - my hardware needs upgrading (badly) and the address mangling is having my subscribers rip their hair out. I need to get this done before they start on my already thinning hair!
I’m ready and eager to move on to MM3 on a Linux box. First I tried to install it myself. After all, I had installed MM2 and it worked fine until AOL and Yahoo messed it up, My computer (an iMac) presents with a black screen on startup and is apt to die at any moment. I ran into trouble some 4/5 through the installation - I simply got lost in jingo. I then hired a pro, but he had real-life issues that kept him distracted and he also had trouble with the installation. I switched to a second pro, a friend, who has tried valiantly for a few months (on and off) but has basically given up now. This is his latest comment on his efforts after I (gently) nagged him:
I have looked into it a few times now and I keep running into the same blocks. I don't see much moving either. I was hoping someone (Mailman developing community) would come up with a better working solution.
My concern is that the Mailman3 is not ready. There are too many dead ends and undocumented stuff. For Mailman2 I have a working integration with iRedMail, that does not seem to work with 3.
So far I don't have anyone who knows how to make Mailman3 work integrated with iRedMail (or similar). Things I have tried and documented are not a conclusive working installation.
So, is MM3 ready for the big screen? If so, is there some way/how/where/when that my friend can get help helping me with the installation other than the published installation docs, which did not work for us?
I have looked for both free and commercial alternatives to MM, but, frankly, I don’t think that there is anything that comes close to what we have. One of my lists started out on LISTSERV many decades ago. I moved it to Appls’s list server and then I moved it to MM after Apple starting with OS/X. Apparently LISTSERV is still around and is being updated, but I’m not keen on going back there, and it’s very expensive too boot.
Any help with this is greatly appreciated!
I have a list which uses Mailman 2.1.27 running on cPanel 78.0.44.
The list has a size limit for the contributions (max_message_size).
When a user sends a message which exceeds the limit, he receives a message that his contribution will either need approval of a moderator or be deleted.
Can this message be edited so that the user is informed that his contribution is deleted (so not to mention the possibility of a moderator approval)?
And is it possible to "auto-delete" contributions exceeding the size limit - without the interaction of a moderator?
Thank you, Christian
Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)
Hilfe fuer Strassenkinder in Ghana: https://www.chance-for-children.org
Mailman 2.1.26. I modified all our lists that did not have munge_from set for DMARC compliance. I ran a few tests and was able to send and receive email from my test list. Now I’m getting reports that large numbers of emails are bouncing and members are being unsubscribed. I had someone forward a bounce message to me and it says it was rejected because it was suspected as spam. In this sample email the headers show the original sender has some DKIM headers and I do not have mailman set to remove DKIM headers. From the docs I found on the mailman wiki it said to not remove the DKIM headers.
This particular list server is on a domain that does not use DKIM but does have an SPF record set to soft fail and the DMARC is set to p=none for monitoring only. The headers in the sample email shows “dkim=fail (signature did not verify)” so I’m thinking I may need to have mailman strip out the DKIM headers from the original sender. Before I modified this particular list I created a test list and added some members from one particular organization. The test list worked fine even though the original DKIM signatures were not removed.
I also found this post where this guy says you need to remove the DKIM headers: https://blog.dogan.ch/2016/11/24/making-mailman-dmarc-compatible/
Occasionally my mailman instance (2.1.9) gets into a weird state where one
or more of its OutgoingRunner processes appears to hang (usually on a large
email with a large number of recipients), causing a backlog of all other
mail on that process's "shard" (or whatever the terminology is for how
mailman divides up mail between runners based on hash). When it gets into
this state, doing a mailman restart doesn't manage to successfully kill the
"hung" process - it stays around after the restart (along with the
mailmanctl instance that started it). Doing a tcpdump on the process
usually shows that it's still sending data, but at a trickle (or sometimes
not). Any ideas what could cause this, or how to resolve it?
I hope that someone here can help me (or point me in the right direction).
We are migrating from sendmail (virtuser) mail routing to LDAP routing. Setting up routing for users is pretty straightforward using the inetLocalMailRecipient class and the mail/mailLocalAddress/mailRoutingAddress attributes. But I was wondering what would be the best (correct) way to represent the mailman alias addresses in LDAP (i.e., list-admin, list-bounces, list-confirm, etc.). Would each get its own entry in LDAP or is there a better way? Any help would be appreciated.
[University of Richmond]
Steven C. Zinski
Sr. Network Programmer
Network Services, Jepson Hall
221 Richmond Way
University of Richmond, Virginia, 23173
804-289-8773 • szinski(a)richmond.edu<mailto:firstname.lastname@example.org> • https://is.richmond.edu
We have a number of Mailman V2 lists with "Munge-from" turned on, due to
DMARC issues at receiving mail systems. This rewrites the From:
addresses to something like:
From: Dan Halbert via SOME-LIST <SOME-LIST(a)example.org>
The problem is some email clients (I'm not sure which ones) pick up
these "From:" addresses and add them automatically to the user's address
book. Then, when the user wants to send a private (not list) message to
some person on the mailing list, they start typing the person's name,
and the email client may autocomplete with the list address, not the
person's address. If the sender doesn't check the address carefully,
they may send to the list inadvertently. This has led to several mildly
embarrassing private messages being sent to a list.
Is there some configuration I can set up that can alter these "From:"
addresses to avoid putting the person's name first, but still including
it? Or is there some other way to ameliorate this problem? We could
choose something other than "Munge-from", but we do not want to lose the
identity of the sender, which is worse.
We are using a third-party provider and have no direct control over the
formatting of the rewritten "From:" header; I would change the Mailman
code directly if I could.