As per public Gitlab stats for Mailman Core repo, 25 issues have been
closed in April so far, which is the record of the last 12 months and beats
the previous four months total.
From a merge requests perspective, it is the record too, and the merged
requests number pace is growing by ~15% over the last four months, reaching
a quarter of a hundred in April.
I know that it's just a month from the previous Mailman Core release, but
given the stats above should the next release be planned earlier than usual?
There was recently a mail on the (closed) Mailman security list from
the CERT Coordination Center which had this strange CC field:
CC: '@mail.python.org, C(a)mail.python.org, E(a)mail.python.org,
R(a)mail.python.org, T(a)mail.python.org, o(a)mail.python.org,
r(a)mail.python.org, d(a)mail.python.org, i(a)mail.python.org,
n(a)mail.python.org, a(a)mail.python.org, t(a)mail.python.org,
e(a)mail.python.org, c(a)mail.python.org, "", "."@mail.python.org,
I guess those are "conformant" email addresses, but they seem unlikely
to be mailboxes at python.org. I'm not sure if these addresses were
added by the generating software at CERT, some MTA, or Mailman.
Has anybody seen anything like this before?
P.S. I hope I'm not spoiling this for any amateur sleuths who wanted
to figure it out for themselves, but yes, except for the apostrophe
and the empty address, those are the letters in "CERT Coordination
Center <cert(a)cert.org>", in order, with dupes eliminated.
P.P.S. It's about a conference, not a CVE. Hakuna matata!
[I prefer discussion be directed to mailman-developers, so Reply-To is
set. But if you're not subscribed to -developers, following up here
is OK, and I'll eventually summarize to -developers. Just don't
followup to both.]
I just noticed that among the agents that send non-conformant long
lines is HyperKitty. Nowadays violating the 80 octet
limit is common and MUAs mostly handle it, but the 1000 octet limit is
enforced by many MTAs
I think that HyperKitty should format mail per RFC 3676 format=flowed
https://tools.ietf.org/html/rfc3676#section-4. However, I don't use
"modern" (aka crappy HTML-oriented) clients, so I don't know whether
they handle format=flowed properly.
Discussion greatly desired.
 RFC 5321: MTAs MAY impose a limit >= 1000 octets including
CRLF. RFC 5322: MUST be <= 1000 octets including CRLF, SHOULD be
<= 80 octets including CRLF.
 In practice, most (?) MTAs just break the line at 998 octets and
insert CRLF rather than reject the message. I assume they would break
happily in the middle of a multi-byte character, i.e., any non-ASCII
in a UTF-8 text.
I discovered this just today, after a list I'm subscribed to enabled it.
I have a filter which tries to validate original signatures by removing footers
and subject tags. Removing "X-Mailman-Original-" is going to be the next addition.
I guess the purpose of this option is to spare a dkim=fail result in the
recipient's header. However, for documentation purposes[*], I'd be comforted
by some document, discussion, or even a crispy comment about the intended
usefulness of masking existing signatures. Google found nothing. Any pointer?
[*] I try and document that original signature validation here:
I was using the mailman's development environment for a long time to
understand the working and codebase. But today without changing anything I
got a mailman server error 500.
Is there any problem with mailman core?
What troubleshooting is needed to fix this issue?
Dear Mailman Developers,
I am currently working on the proposal of List Configuration Tool in
GSoC idea list. As I thought in the details of several functions of
the tool, I wonder what kind of configurations should be exported, and
what should not.
Q1. We can get nearly all the configurations for a list from the
core's REST API
but some of the data should not be exported, such as `created_at`,
`last_post_at`, and etc. Hence, we may need a filter to extract out
the meaningful configurations to export out. I wonder whether we have
a more convenient way to get all meaningful configurations, and what
kind of configuration fields are expected to be exported from the
Q2. Besides all the configurations obtained from the listconf
mentioned in Q1, we have more configurations for a list, such as
member list. In the Idea Page
says that the membership roster should not be included by default.
Since we already have the `list_mass_subscribe` method for importing a
lot of subscriptions at once, so should the list configuration tool
include the functionality to handle membership automatically or just
does not include the memberships in the exported configuration?
For Q1, I do have some thinking for some important configuration
fields that should not be exported:
owner_address: should be filtered out, since only the list owner can
import the configuration template, the owner_address should be set
when the owner apply the configuration template to the list instead of
import from the previous configuration.
mail_host, fqdn_listname: should be filtered out, since lists are
created under the domains, domains should be created before the lists
are created. Hence, only the name before the domain should be included
in the exported configuration, and the full fqdn_listname can be
generated when creating the list.
I do need more suggestions on what to choose in the configuration that
can be exported. Any suggestion is welcome.
I am Aditya Komaravolu (Gitlab profile: https://gitlab.com/Aditya-Komaravolu),
a second year student pursuing Bachelor of Technology from Vidya Jyothi
Institute of Technology, India.
I have done a few small contributions to the organization and I am
confident enough that I will be able to contribute in a better way by
learning from the mentors/developers of the organisation.
GSoC is a very good opportunity to learn, bind and code with the community.
I am very much interested to participate in GSoC 2021 for Mailman as a
student. I would love to work for the project "Improved UI for Subscription
Management " given in (
https://wiki.list.org/DEV/Google%20Summer%20of%20Code%202021). I really
want to know what I should be learning to contribute/move in the direction
of this project. Any support from your end would be highly appreciated !
Respected Mailman Developers
My name is Shubhank(https://gitlab.com/shubhank-saxena). I am a final year
engineering undergraduate from India.
I am interested to participate in GSoC 2021 under Mailman. I have gone
through the instructions provided by the organisation, and have got one of
my MR reviewed and merged in the Mailman Core.
I have now started to write a proposal in the same direction and I was
wondering how can I start the discussion regarding the Mailman Core
projects that are given on the webpage (
https://wiki.list.org/DEV/Google%20Summer%20of%20Code%202021). I am
interested in the project "Support for REST Callbacks in Core".
Also, is the IRC channel active? I did not see any conversations happening
so I was wondering if the mode of communication has shifted strictly to the
Thank you for your time!
Dear Mailman Developers,
This is Steven1677(https://gitlab.com/Steven1677) on GitLab. I want to
contribute to the mailman3 project as a GSoC student.
I am starting to write my proposal for GSoC. I wonder whether our
personal information will go public if we send the proposal to the
this mail list?
I fully understand that applying for GSoC requires such information,
but I think the personal contact information (like phone number, email
addresses) should be only available to the members of the developer
team instead of the whole internet.
Hence, I am asking whether the whole proposal (including the basic
information of the student) should be sent to this mail list?
I'm upgrading a mailman2 installation to mailman3. And I using a docker implementation, created by me and not Maxking's implementation.
Everything is installed and is served correctly.
I have created a postfix container that relays emails to a smtp server, and I can send emails by telnet from it.
When I create a new thread in Hyperkitty, I receive an error from postfix container that the user (mailing list name) is not found.
And I believe that is obvious because the aliases db are not accessible by postfix.
So, my questions are:
- Is there a way to share aliases db between containers(different hosts) of mailman and postfix? I thought about sharing volumes but I'm not quite sure if it's the best solution
- I've seen:
virtual_alias_maps = mysql:/etc/postfix/virtual/existing_aliases.cf, var/lib/mailman/data/virtual-mailman
to add in postfix main.cf. Is it possible to do the same thing to aliases and transport_maps? And if so, how to set it in mailman configuration, because this is for mailman
I've seen this thread:
And it seams kind or less the same situation.
Does anyone have an idea or can give some pointers in how to accomplish this?