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.