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
anonymous...!
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.
Thank you!
Mal
Hi,
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'."
Thanks
Mary
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?
Thanks.
Leon
Dear Mailman Cognoscenti,
I'm helping one of my list owners send out 5K plus invitations to
students to subscribe to his mailing list. Our current configuration:
Mailman v2.1.20
RHEL v5.11
Semdmail v8.13.8
Apache v2.2.3
Since this was the first time doing this, I suggested breaking the
batch input into 3 groups, 50, 500, and the rest. The 50 went fine,
as did the 500, but the largest batch gave him a generic web server
error:
> Internal Server Error
>
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
>
> Please contact the server administrator, root(a)conundrum.unh.edu and
> inform them of the time the error occurred, and anything you might
> have done that may have caused the error.
>
> More information about this error may be available in the server
> error log.
I looked at the logs and I couldn't find anything that hinted at what
went wrong. So I asked the owner to send me the last back and I'd
give it a try. I wrote a script that removed folks already subscribed
to his list and split the remaining subscribers up into 6 files with a
thousand records each. I just tried uploading the 1st batch of 1K,
with the following options:
Subscribe these users now... (*) Invite
Send welcome message... (*) No
Send notifications... (*) No
And entered a 7 line paragraph explaining the invitation.
I ended up having the same error happen. Looking at the Mailman logs,
I can't see any difference before or after my submission. In the
HTTPD logs, I see:
>> [Fri Aug 26 19:59:23 2016] [warn] [client 132.177.215.132] Timeout
>> waiting for output from CGI script
>> /usr/local/mailman/cgi-bin/admin, referer:
>> https://lists.unh.edu/mailman/admin/campus.connection/members/add
>> [Fri Aug 26 19:59:23 2016] [error] [client 132.177.215.132]
>> Premature end of script headers: admin, referer:
>> https://lists.unh.edu/mailman/admin/campus.connection/members/add
So is there an inherent limit to the number of invites that can be
submitted via the web form?
As a work around, how would I do large invites on behalf of the owner
from the command line, including the 'extra text' that is allowed via
the web interface?
--
Cordially,
the UNH Mailing List Server Admins
Bill Costa, senior admin
(603) 862-3056
Is there an efficient way to change the domain name that mailman is
affiliated with?
I have two mailing lists that were created for an organization before
that organization had their own domain. At the time the organization was
sure they did not want their own domain and would not be getting a
domain.
Since then, they have chosen to get a domain and set up a web site.
I would like to move their mailing lists onto their domain. It looks
like the process for this is:
1) get the list of subscribers
2) delete the mailing list from the one domain (losing the archives)
3) create the mailing list on the new domain
4) subscribe the list of subscribers
This process doesn't seem too difficult, but I would prefer to keep the
archives, if possible.
Both domains are on the same server, running CentOS7 and PLESK 12.5, if
that makes a difference.
Thanks,
Keith
Hi all, Mark, Barry,
Ive finally formalized my cookbook to install mailman. The base installation is a mail server (the usual suspects: postfix and dovecot) that hosts multiple domains (virtual domains). I wanted the flexibility of virtual domains so I can consolidate mail server hosting for several domains that I have.
The cookbook can be found here: https://caesarsamsi.wordpress.com/2016/12/31/install-a-lamp-server-and-mail… due to its file size (about 140KB) which can’t be attached to this mailing list email.
You could probably use the insights from the cookbook to install mailman on a simple one domain mail server.
Let me know if clarification is needed and typos or errors found.
Cheers, I hope you enjoy the journey!
Caesar.
(Note PS at bottom!)
Hi. I'm prepping to migrate a bunch of lists (one at a time, due to
huge number of lists and huge size of archives) from one server to
another, and I've hit a snag with the first list I'm trying. After
migrating the list (as described below), I can go to the lists admindb
page on the new server and get the list of pending requests that was on
the old server, but immediately the request database gets truncated.
(It stays a valid pickle file, it just gets all the requests emptied out
of it, so the file itself is much shorter but non-zero length.)
This happens *when I load* the admindb page, not when I submit the form.
That seems really weird to me, since I'd expect a page load would only
read the pickle, not write it.
The old server is running Debian and Mailman 2.1.13 (from the Debian
package). The new server is running Ubuntu and Mailman 2.1.16 (from the
Ubuntu Trusty package; we need to run Trusty for now for complex and
uninteresting reasons; I'd rather run 2.1.18, and may look into running
that on Trusty once I get the basic migration issues resolved).
Relevant UIDs and GIDs (www-data:www-data and list:list) are the same on
both systems.
Short version: I rsync -aSHov /var/lib/mailman/lists/$listname/
new-server:/var/lib/mailman/lists/$listname and similarly copy the
public and private archives (preserving symlinks as needed).
check_perms on both systems reveals similar errors which look cosmetic
(things like rotated logs, temporary directories where I've copied
things, and the like), but I haven't yet let it run to completion
because of the volume of our archives. Then I change host_name via the
web interface and m.web_page_url interactively with withlist (using
fix_url seems not to work when changing http: to https:) and m.Save().
One *possibly* relevant detail is that the new host doesn't currently
have a valid certificate. (It's using the old host's cert, and I
manually allow the exception in my web browser for testing.) But for
Mailman 2, the only http{,s} traffic should be sent from my browser, right?
This kind of has the feel of a permissions problem, but clearly the CGI
scripts can read from and write to the request.pck database. (And
changes to the list config data in config.pck seem to be working
normally.) As I said, check_perms hasn't run to completion yet because
it's plowing through the (already pre-rsync'ed) archives, but it got
through the things in /var/lib/mailman/lists and didn't find anything
wrong with this list.
There's nothing interesting in the Mailman logs (which Debian/Ubuntu put
in /var/log/mailman), and the only thing in the Apache error logs is a
warning that the cert it has configured doesn't match its hostname.
Anybody have any ideas?
Jay
PS -- I composed this all last night. Today, the behavior has changed:
This morning, a new message was received by the list (forwarded from the
old list server to the new list server, and added to request.pck on the
new server by the new Mailman installation). Now, when I load the
admindb page, the old requests (which were in the request.pck copied
from the old server) are all immediately thrown away (although displayed
in the admindb form) but the new request which came in this morning
remains. So it kind of looks like something about the old requests
causes the list to think they're invalid and discard them when it loads
them. I initially saw this behavior with "require_explicit_destination"
on and "acceptable_aliases" empty, but turning off
"require_explicit_destination" and putting just the local part of the
list address in "acceptable_aliases" doesn't make any difference.
--
Jay Sekora
Linux system administrator and postmaster,
The Infrastructure Group
MIT Computer Science and Artificial Intelligence Laboratory
[adding list back for archive]
I’ve also added:
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['yugi.us<http://yugi.us>','mail.yugi.us<http://mail.yugi.us>']
VIRTUAL_MAILMAN_LOCAL_DOMAIN = ‘localhost'
Restarted mailman, postfix, and apache2.
I still get in /var/log/mail.log
Dec 22 12:17:50 localhost postfix/trivial-rewrite[6456]: warning: hash:/var/lib/mailman/data/virtual-mailman is unavailable. open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
On Dec 22, 2016, at 12:10 PM, Caesar Samsi <cmsamsi(a)hotmail.com<mailto:cmsamsi@hotmail.com>> wrote:
It’s mail.yugi.us<http://mail.yugi.us/>
On Dec 22, 2016, at 12:06 PM, Mark Sapiro <mark(a)msapiro.net<mailto:mark@msapiro.net>> wrote:
On 12/22/2016 11:24 AM, Caesar Samsi wrote:
*What is the value of the list's host_name attribute (near the bottom of
the list's web admin General Options page).
*
Overview of all yugi.us<http://yugi.us/> mailing lists
<http://yugi.us/cgi-bin/mailman/listinfo>
Go to <http://yugi.us/cgi-bin/mailman/admin/mailman>, log in and scroll
down until you see
Host name this list prefers for email.
(Details for host_name)
(about 5 settings from the bottom). What is that set to?
*What's in mm_cfg.py? (Make sure you're looking at the correct one.)*
...
#-------------------------------------------------------------
# Default domain for email addresses of newly created MLs
DEFAULT_EMAIL_HOST = 'yugi.us<http://yugi.us/>'
#-------------------------------------------------------------
# Default host for web interface of newly created MLs
DEFAULT_URL_HOST = 'yugi.us<http://yugi.us/>'
#-------------------------------------------------------------
# Required when setting any of its arguments.
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
You are missing POSTFIX_STYLE_VIRTUAL_DOMAINS. See
<https://mail.python.org/pipermail/mailman-users/2016-December/081685.html>
which says in part
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['yugi.us<http://yugi.us/>']
If you want to generate data/virtual-mailman for lists in the
mail.yugi.us<http://mail.yugi.us/> email domain, this should be
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['mail.yugi.us<http://mail.yugi.us/>']
or
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['yugi.us<http://yugi.us/>', 'mail.yugi.us<http://mail.yugi.us/>']
if you want both.
--
Mark Sapiro <mark(a)msapiro.net<mailto:mark@msapiro.net>> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
Does anyone know of a provider who hosts Mailman and who has a good
reputation with American ISPs - Verizon and ATT, etc? These providers
somehow have notoriety blocking mailing list emails. I'm currently hosting
with a provider based in Oz, but having some difficulties when it comes to
Verizon and ATT. AOL, Gmail, Hotmail, Outlook, Yahoo etc are all accepting
mails, but majority of the subscribers are with Verizon/ATT and that has
really affected one list that I have so I need to change.
Please recommend one.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft."
My mail server has been blacklisted by several major e-mail providers
because of backscatter spam generated by my Mailman installation:
(1) Spammers harvest the "listname-request(a)domain.com" address from a
public Web page (presumably the Mailman admin page).
(2) Spam with forged "From:" headers is sent to
"listname-request(a)domain.com".
(3) Mailman sends "subscribe confirmation" messages to the addressees in
the forged "From" fields.
How can I stop this? I am willing to give up "subscribe to this list by
e-mail", and require all subscriptions to be via the Web.
I used to use, and manage, mailing lists that handled all subscribe and
unsubscribe requests by e-mail. But now almost all genuine subscription
requests to my lists are made through the Web interface.
(I also used to run e-mail auto-responders, for example to send an FAQ in
response to any e-mail message sent to a special e-mail address. I have
stopped them all, for similar reasons -- they were attracting spam with
forged "from" addresses, thus generating spam to those "from" addresses.)
I have found several discussions of variants of this issue on this list,
going back at least 10 years. But so far as I can tell, there is not yet a
simple option in the Web admin (or a config file) for each Mailman list,
"Accept subscription requests by e-mail? Yes/No".
I understand that this may take time to implement, but this problem has
been known for a very long time. I would like to see this put on the
feature request list, however that is done. In the meantime, I need a
workaround if I am to continue using Mailman at all.
I would still prefer to have e-mail confirmation of new subscriptions, but
I don't think that would cause as much of a backscatter problem: The
"-request" address can be harvested form the public Web, but the
"-confirm" address would be much less likely to do so.
But if it is simpler to implement, it would be OK to require new
subscriptions to be confirmed through the Web interface.
Temporarily, I have completely disabled the list that was attracting spam
to its "-request" address. This isn't a viable long-term option.
Is there any workaround, either through the Web interface or by editing
Mailman configuration files, to disable the "-request" address or cause
all mail to that address to be dropped without generating a reply?
FWIW, I am using Mailman through Plesk, which offers it as an option.
Plesk knows that "-request" is already in use by Mailman, and won't let me
create that address or alias or manage it except through Mailman.
Thanks in advance for any advice you can offer,
Edward Hasbrouck
----------------
Edward Hasbrouck
<edward(a)hasbrouck.org>
<https://hasbrouck.org>
<https://twitter.com/ehasbrouck>
+1-415-824-0214
"The Practical Nomad: How to Travel Around the World" (5th ed., 2011)
<https://hasbrouck.org/PN>
Consultant to The Identity Project:
<https://papersplease.org>
GnuPG/PGP public key:
<https://hasbrouck.org/ehasbrouck.asc>
fingerprint:
0B0B 8F74 CEA3 83AB 97B3 F6AF BB7E F636 165C 22F5