On Fri 2015-02-27 14:46:40 -0500, Murray S. Kucherawy wrote:
> Sorry, by "sign" I meant "add a footer". I probably said "sign" because
> this is related to some DKIM work I've been planning, and the morning's
> caffeine was already wearing off.
> Thanks for that detailed answer (and Barry for his followup). It's
> precisely what I was looking for.
> How absurd would it be to propose a flag for Mailman that would take your
> first case (non-MIME, or single-part text/plain) and convert it to a
> multipart/mixed with a child part of the original text/plain, and then
> apply the algorithm you have?
I'm not one to make any decisions for mailman, but this sounds pretty
reasonable to me. In fact, the only argument against ever having such a
switch *not* set is that non-MIME-aware text-only MUAs will now see some
crufty MIME boundaries in the message that they didn't see before.
I'd bet the number of users of non-MIME-aware text-only MUAs receiving
mail from mailman that are incapable of wading through a bit of extra
MIME boundary info on otherwise text/plain messages is vanishingly
small. Most of those folks are probably at least used to seeing it as a
result of the overwhelming predominance of multipart/alternative on
today's SMTP network.
> The impetus here is DKIM survivability across lists. Suppose we had a DKIM
> canonicalization that was MIME-aware, so that it could sign the specific
> MIME parts or sets of parts. That signature would fail on the message as a
> whole -- with the footer part added -- but could in theory pass if an
> appended part were omitted from canonicalization. To put it in context,
> suppose there were a DKIM canonicalization where the signer signed (using
> your examples) the CDE message; the receiver gets FGHI which fails, but
> also has enough information to know that merely verifying FGH will pass; it
> then knows that FGH was "legitimate" and I was added post-signing, and may
> or may not be "safe" (for some value thereof) content.
> What I'm worried about with such a design is the trivial text/plain
> message. Obviously merely appending the footer destroys any hope of
> validating only the original content. We'd have to entertain the idea that
> Mailman would make the simple message into a multipart/mixed + text/plain,
> then append the footer part and sign that; the verifier would drop the
> footer and then strip off the MIME to see if it can verify the original
> signature that way. That seems like its easy to get wrong, though it's
> likely to be a very common case.
right, the MIME boundaries provide the parsing framework to enable this
kind of sub-part DKIM-verification.
One issue this process brings up is that it's now necessary to treat
pretty much every part of the message as though it is
multipart/signed -- that is, it needs to be handled bytewise opaquely,
on pain of breaking the DKIM header.
We already know that there are tools that do things like re-encode
messages from base64 to q-p, or change character sets, or just re-flow
long lines (FSVO "long") in the mime boundary subheaders. They're not
supposed to do this with multipart/signed messages, because the RFCs
point out that opaque handling is required, but they sometimes break
them anyway. I imagine the same risk would now apply to all DKIM-signed
messages using your scheme.
With that caveat in mind, it's clear that without your proposal, all
DKIM-signatures of messages with footers will break anyway. So this
does seem to be a strict improvement, even if there are a few corner
cases that aren't fully covered.
I am very happy to announce our new wiki!
If you go to wiki.list.org you will see our shiny new Moin-based wiki. We are
retiring the old Confluence-based wiki at the end of February. Until then,
you can access it at old-wiki.list.org.
Our very huge thanks go to Paul Boddie who did the amazing conversion work,
almost single-handedly reverse engineering the Confluence dump through several
iterations. Of course, our thanks also go to John Viega, owner of the
list.org domain and Mailman's inventor for helping us get the DNS flipped
over. Thanks too to everyone who gave feedback on the new wiki, contributed
to the old wiki, and continue to help edit this important resource for the
Our thanks also go to the Python Software Foundation and the PSF
infrastructure team for providing us with the virtual machine hosting our
If you had write access to the old wiki and want it again for the new wiki,
you will have to re-submit a request to mailman-cabal(a)python.org. Please be
sure to register with wiki.list.org and provide us with your user name.
With this conversion, I am happy to say that GNU Mailman is finally fully
hosted on free software. While we appreciate the years of service donated to
us by Atlassian and Contegix, it's important that we set an example by
utilizing an entirely free software stack for our development and outreach.
The wiki was our last remaining non-free bits.
Let the gardening begin!
(On behalf of the GNU Mailman steering committee)
P.S. We are working on the SSL certificate for the new wiki. Stay tuned.
Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA writes:
> I was wondering if there is a sort of tool that generates summaries
> for mailing list activity and charts like number of users, number
> of active users, etc. Would something like this be a good idea or
> is it already done?
There are such tools but they're not integrated into the Mailman 2 web
interface, and I think they're not in Postorius or Hyperkitty yet,
either. They're frequently requested and I think Postorius provides
some infrastructure for such things.
On Feb 27, 2015, at 01:02 PM, Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA wrote:
>A personalized mailing list will allow mailman users to send personalized
>emails to all the list members from a common email template.
Almost all the pieces are already there to support mail merging, at least as
a plugin. There's quite a bit of functionality in place to allow for
pluggable MTA delivery methods. Right now, there's only one. Search
src/mailman/config/schema.cfg for the [mta]outgoing variable.
We also already do a bit of mixin class composition to implement various
aspects of the existing personalized delivery machinery. The proper class is
chosen (based on the default [mta]outgoing value) from the value of
To support mail merge, we'd need a little more flexibility in composing these
basic bits. You'd like for individual mailing lists to be able to choose a
custom delivery mechanism from a set of site-defined choices, for example.
Then a plugin could define a new delivery class which does the database
lookups and the mail merge into the template at the point where the VERP'd
message is handed off to the upstream MTA. You'd register this new delivery
class with the system and them mailing lists could opt into it.
Can someone tell me if the following way is suitable for implementing a
plug in on mailman3 :
A folder contains all the .py codes needed to implement the plugin feature
aimed. In that folder we make an executable file i.e. .sh file, which runs
the script that adds the code mentioned above in the right places of
mailman3 src code.
On Feb 27, 2015, at 11:46 AM, Murray S. Kucherawy wrote:
>How absurd would it be to propose a flag for Mailman that would take your
>first case (non-MIME, or single-part text/plain) and convert it to a
>multipart/mixed with a child part of the original text/plain, and then
>apply the algorithm you have?
>What I'm worried about with such a design is the trivial text/plain
>message. Obviously merely appending the footer destroys any hope of
>validating only the original content. We'd have to entertain the idea that
>Mailman would make the simple message into a multipart/mixed + text/plain,
>then append the footer part and sign that; the verifier would drop the
>footer and then strip off the MIME to see if it can verify the original
>signature that way. That seems like its easy to get wrong, though it's
>likely to be a very common case.
The biggest downside, and probably the main reason we append the footer text
in the text/plain-compatible-charset case is because of crappy MUAs. I think
we *still* get complaints about the MIME composition not being rendered very
well. Their MUAs will show them attachments without the message content they
actually care about.
I wish I could say "fix the MUAs" but that's probably been futile since the
day email was invented. ;)
That said, it's not a totally unreasonable suggestion. I wonder if it makes
sense to have that be a user option (then, what's the default, what a standard
says, or whatever minimizes user complaints).
In my role as org admin for Python, I'm trying to make sure we have more
beginner-friendly ideas on the GSoC pages, and Mailman's among the
groups that doesn't have any. How embarrassing for me as a Mailman
developer. ;) It's also a problem for Mailman if we're applying as a
separate organization, as Google seldom allows orgs unless they have a
reasonable number of ideas suitable for open source newbies.
(The idea behind this is that many students are very new to Open Source
and we want them to at least get something out of the application
process, learn how to set up their environments and learn about what it
takes to get hired as a GSoC student. Even if they don't make it in
their first year, they'll be much more ready for later years!)
I'd love some help brainstorming some actual beginner-friendly ideas,
though, because I'm currently all idea'd out. Anyone want to suggest
some simpler things they'd like to see in Mailman that we could maybe
put on the list?
Suggesting and idea does not mean you have to volunteer to mentor them,
although I'm always looking for new mentors too!
I am final year computer science engineering student from UPTU. I want to
contribute to the organization by becoming a part of GSoC 2015. I know
I went through project ideas of Mailman and found "Github/development tools
integration" interesting. Please guide me for the next step. I want to
start exploring asap to get good grasp of the platform required.
I'm an Engineering student(computer science) pursuing my degree from
Government Engineering College(Calicut University), Thrissur, India. I went
through Mailman gsoc idea list.I'm interested in the project Mailman client
I am looking forward for a good response from your side regarding details
about the projects so that I could start contributing towards it.
Libraries: jQuery, underscorejs, zeptojs, KineticJS
Frameworks: Angularjs, Express, Django,
Tools: Vim, Git, Grunt, bower, Yeoman
name: "Kiran P S",