every night at 00:00 i get an email by mailman3:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/django_extensions/management/commands/runjobs.py", line 34, in runjobs
File "/usr/lib/python2.7/dist-packages/hyperkitty/jobs/sync_mailman.py", line 37, in execute
File "/usr/lib/python2.7/dist-packages/hyperkitty/lib/mailman.py", line 147, in sync_with_mailman
File "/usr/lib/python2.7/dist-packages/hyperkitty/models/sender.py", line 57, in set_mailman_id
mm_user = client.get_user(self.address)
File "/usr/lib/python2.7/dist-packages/mailmanclient/client.py", line 192, in get_user
File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/connection.py", line 99, in call
response, content = Http().request(url, method, data_str, headers)
File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1616, in request
(response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1358, in _request
(response, content) = self._conn_request(conn, request_uri, method, body, headers)
File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1314, in _conn_request
response = conn.getresponse()
File "/usr/lib/python2.7/httplib.py", line 1148, in getresponse
ERROR OCCURED IN DAILY JOB: sync_mailman (APP: hyperkitty)
Mailman3 runs on Ubuntu 18.04 and is installed via the apt-get repository packages.
Mailman3 is working and created lists are functional.
Therefor i would like to know can i neglect this message ? Or is this message a hint for an Error i should investigate and looking for a solution ?
For my own purposes I have created some patches which apply to the
current mailman pip package.
The first of them is for my purposes necessary, and has been discussed
here before: being able to specify the address used to listen for tcp
connections independently of the address the server considers it to be
accessible at. A possible change to this patch would be to check
whether this address was undefined but the old hostname was defined,
and use that if so. For me this is not needed, and in any case it is a
trivial change to make.
The second patch adds a bunch of additional logging calls to various
network-related parts of the package. I wrote these into the package
because I was seeking the cause of template expansion causing messages
to be silently dropped. I eventually found the cause was that I had an
incorrect setting of the template root URL, but I regard the lack of
anything in the logs as just as much of a bug. One important part of
those changes was that I added a try/catch around two parts of the
'decorate' code, which is where the silent dropping occurred. If you
only take one part of this patch, I encourage you to take this part.
For the third patch, I discovered that the task runner was at one point
busy-waiting to the tune of 100% cpu, and the cause was the way that
the runner checked to see if there was work left in the queue. I am not
quite sure what was the exact problem, but I think it was that there
was something to do, but it was not achievable at that time, and the
result was continual retry. The third patch changes the logic slightly
so that this no longer occurs - retry will happen, but somewhat more
I hope you find some use in these three.
Finally, I am currently experiencing problems with templates and would
appreciate any thoughts:
1. If I do not set up 'individual' or 'full' personalisation, all is
well and the default footer templates are expanded as expected. However
setting up personalisation causes template expansion to fail
completely, and messages get sent with a blank expansion.
2. I would find the postorius UI much easier to cope with if the
default template was 'populated' into the UI wherever it was non-blank,
rather than the UI starting off as if no templates were defined at all.
I ran across a strange issue today. A client reported the inability to
remove a non-member in the following format:
The reported error from Postorius was:
"The user could not be removed"
I used https://verifalia.com/validate-email to validate the email
address and it is syntactically correct.
I am using mailman 3.2.1 for several mailing lists. My colleagues want me to stop all mails with the subject "The results of your email commands".
I found some contributions here, but nowhere a solution for this question.
Does anybody has any suggestion?
Maybe I could try to handle this outside of mailman, but then I would have to pass this task on to someone I dont know .... :-(
Thanks for all hints. :-)
I am pleased to announce new stable releases for:
- Postorius: 1.3.3
- Hyperkitty: 1.3.3
- Mailmanclient: 3.3.1
- Django-mailman3: 1.3.3
Python 3.6+ and Django 2.0+ is supported for all of them. Django 3.0 support for Hyperkitty requires manually upgrading a dependency (django-haystack>=3.0b2, once a stable version of this has been released, it shouldn't require manually upgrading).
There are tons of bug-fixes across the board and some new features.
Biggest visible change is switch to Bootstrap 4, which has been long pending for us. Bootstrap 4 completely changes the CSS grid model using the new Flexbox. There might be some small changes or breakages when using on mobile. Please report such issues to us via Gitlab!
Some other notable changes are in Postorius, which includes many more list settings exposed include content filtering settings, bounce processing (which was added in the previous release of Mailman Core) settings and some other ones. Settings page is also slightly different with all the sections on the vertical menu on left instead of horizontal tabs. You can now also specify a reason when rejecting held messages.
There was also a gnarly bug, which caused the name of some members to be the string "None". For the longest time, I couldn't figure out the reason for it, but it ended up being a simple fix in mailmanclient's json serialization of display_name, which would result in Python's None value being passed as string "None" to Mailman's API for subscription.
There is also better support for filtering visible lists based on the current vhost, which I see a few people are already waiting for from mailman-users list.
A full changelog has been added to each project in the top.
Abhilash Raj (maxking)
I am currently running Mailman 3 with version 3.3.1 and in
built postfix version 2.10.1-6 on RHEL 7.5 with PostgreSQL 11.7 version
with default values in production environment from the past 4 months
almost. As of now, we are having around 1327 lists created on this.
When I am trying to do some operations like creating the
lists, deleting the lists or accessing the lists through the GUI, I am
getting the below error. If I am trying to do the operations through API or
through mailman shell, still I am not able to connect to the API.
Something went wrong
Mailman REST API not available. Please start Mailman core.
But my mailman core was working fine in the background. At
the same time I was able to do other operations on a few other lists.
By the time I am getting the above error, the mailman.log
recorded the below messages.
*[2020-09-16 12:49:08 +0530]  [CRITICAL] WORKER TIMEOUT (pid:20234)*
*[2020-09-16 12:49:08 +0530]  [INFO] Worker exiting (pid: 20234)*
*[2020-09-16 12:49:09 +0530]  [INFO] Booting worker with pid: 21042*
My mailman.cfg configuration is as below. The timeout value
is the default value. I did not set any customized value.
*(venv3) [root@lsmgr mailman]# grep -v ^#
Then as per the suggestion I got earlier I configured the
[webservice] section in the above file as below.
* [root@lsmgr logs]# cat
*workers = 10*
*timeout = 90 *
After the above configuration, I found many errors like below in
*sqlalchemy.exc.NoSuchColumnError: "Could not locate column in row for
column 'pended.id <http://pended.id>'"*
*sqlalchemy.exc.ResourceClosedError: This result object does not return
rows. It has been closed automatically.*
*sqlalchemy.exc.DatabaseError: (psycopg2.DatabaseError) error with status
PGRES_TUPLES_OK and no message from the libpq*
The above might be few of the errors. FYI, for the creation of each list,
it is taking almost around 15 to 20 minutes. After multiple times of the
above error messages, at some time, I am fortunately getting the list
created or some other operation getting done.
I found the same scenario when the workers are from default 2
to 10. I don't understand where exactly I need to focus to solve the issue.
Please let me know if I have to share any other details for
you to suggest to me.
Thanks & Regards,
I created a new mailinglist and got during the test-process the following
errormessage in my mailman.log after:
Sep 19 22:55:08 2020 (1433) ACCEPT:
Sep 19 22:55:09 2020 (1436) Cannot connect to SMTP server localhost on port
HTTPSConnectionPool(host='webmail.domain-02.de', port=443): Max retries
exceeded with url:
:regular:footer (Caused by NewConnectionError('<urllib3.connec
tion.VerifiedHTTPSConnection object at 0x7fc8380f1748>: Failed to establish
a new connection: [Errno -2] Name or service not known'))
domain02.de isn't involved in mailman3 either as a user domain nor as a
After deleting the template
regular:footer the mail to the list is processed without problems:
Sep 19 22:56:22 2020 (1436) <000001d68ec7$2553e6e0$6ffbb4a0$(a)domain-01.de>
smtp to mylist(a)list.domain-03.de for 1 recips, completed in
Sep 19 22:56:22 2020 (1436) <000001d68ec7$2553e6e0$6ffbb4a0$(a)wbock.de> post
to mylist(a)list.domain-03.de from user(a)domain-01.de, 1331 bytes
Please help to solve this problem?
Thanks and regards
after creating a new list I got the following errormessage:
mailman aliases -> postmap: warning: /var/lib/mailman3/data/postfix_vmap,
line 17: expected format: key whitespace value
# AUTOMATICALLY GENERATED BY MAILMAN ON 2020-09-19 07:44:34
The last line in the left part contains 48 chars.
I solved the problem by adding a whitespace in the last line and I made a
new postmap for postfix_vmap.
But it would be better to solve the problem by changing the genaliases
process in the next update.
Thanks for the help with this! Other list members will also see the e-mail as coming from user(a)invalid.domain<mailto:firstname.lastname@example.org>. I will continue testing the other scenarios and will reply back as soon as possible.
Thanks again for the help with this and have a nice day!
On Mon, Sep 21, 2020 at 9:00 PM Mark Sapiro <mark(a)msapiro.net> wrote:
On 9/21/20 10:49 AM, peterbw(a)gmail.com<mailto:email@example.com> wrote:
> We've recently noticed an issue where users who are cc'd in a message where a mailing list is also within the cc list are getting rewritten a user(a)invalid.domain.
> This issue looks like it may be related to Outlook and how user names are displayed specifically. Here is an example:
> To: test_user(a)gmail.com<mailto:firstname.lastname@example.org>
> cc: listserv(a)lists.test.org<mailto:email@example.com>; Williams, Peter;
> "Williams, Peter" maps to a user e-mail in the Outlook Global Address book. When the message is sent the list will send the message with the first name and last name separated, for example the message will appear:
> to: test_user(a)gmail.com<mailto:firstname.lastname@example.org>
> cc: listserv(a)lists.test.org<mailto:email@example.com>, Williams(a)invalid.domain, Peter(a)invalid.domain
Because apparently Outlook is sending the message with the literal
> Cc: listserv(a)lists.test.org<mailto:firstname.lastname@example.org>; Williams, Peter;
instead of something like
> Cc: listserv(a)lists.test.org<mailto:email@example.com>, "Williams, Peter" <peters_real_address(a)example.com<mailto:firstname.lastname@example.org>>
Then some MTA in the chain is seeing the unqualified addresses Williams
and Peter and appending its own local domain.
> This only seems to happen with users who are cc'd who are also members of the list that is being cc'd. For example in the scenario above my e-mail that is cc'd is also a member of listserv(a)lists.test.org<mailto:email@example.com>.
In this case, where do you see this? i.e., do other list members see it
in the message they receive from the list?
I don't know why that would be. I'm certain that Mailman is not involved
in this and the Williams(a)invalid.domain and Peter(a)invalid.domain
addresses are in the Cc: as received by Mailman.
> This issue does not occur if the user e-mail address is listed before the mailing list in the cc field. So for example, if the cc in the scenario above contained Williams, Peter; listserv(a)lists.test.org<mailto:firstname.lastname@example.org>; it would route properly.
Again, I think this is Outlook.
What's in the Cc: of the mail that test_user(a)gmail.com<mailto:email@example.com> receives directly?
What happens if you send mail in this way with
cc: other_user(a)gmail.com<mailto:firstname.lastname@example.org>; Williams, Peter;
Again, what's in the Cc: of the mail that test_user(a)gmail.com<mailto:email@example.com> and
Also, please see <https://wiki.list.org/DOC/Mailman%20is%20not%20Listserv>.
Mark Sapiro <mark(a)msapiro.net<mailto:firstname.lastname@example.org>> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users(a)mailman3.org<mailto:email@example.com>
To unsubscribe send an email to mailman-users-leave(a)mailman3.org<mailto:firstname.lastname@example.org>