Hi Abhilash Raj, Hi Steve
Thank you both for taking the time and considering to mentor me.
On 28.02.2016 04:48, Abhilash Raj wrote:
> If you don't know, I worked on this project some time back in GSoC 2013.
> The current state of that project is not very good and probably needs a
> *lot* of rebasing to do.
I did not know that. What were the problems?
On 28.02.2016 04:48, Abhilash Raj wrote:
> Here is a link[1] to discussions that have already been done before on this
I think that link is missing, I'm very interested in looking into this.
First of all, if this wasn't clear, my plan was to make a re-encryption
gateway. Messages are encrypted to the listservers keypair and
re-encrypted there for each of the recipients.
How did your implementation work, Abhilash Raj?
I had two modes of Operation in mind:
(a) One that doesn't encrypt all of the mail but gives users the option
to send and recieve pgp encrypted mails. This might be useful for very
small private lists where some communication is protected against
eavesdropping in other ways, when a list is in the progress of
introducing encrypted communication or for (other) testing purposes.
(b) A strict mode that keeps all the communication encrypted and won't
ever send out mail without encrypting it.
The strict (b) mode should certainly be default, and
> 8. Optionally forced encryption (such a list never sends mail to an
> adress to which it can't encrypt with a pubkey that has a certain
> level of trust and/or won't accept inbound mail in plaintext)
is in fact essential for the application to make sense. By Optionally, I
meant that it should be possible to not force encryption which would be
the (a) mode of operation.
On 28.02.2016 04:48, Abhilash Raj wrote:
>
> I have a few small questions doubts about your features below...
>
>
>> Some features could be:
>> 1. Automatic pubkey collection from inbound mail
>>
>
> What happens if I send a forged email with some user's email address as
> FROM and use a fake key? Automatic public key collection isn't a very good
> idea, you should be *very* careful about how you handle public keys.
The idea was to collect the public keys so an authority (list admin)
could manually set their trust levels which would be necessary in strict
(b) mode in order to use a key at all.
On 28.02.2016 04:48, Abhilash Raj wrote:
>> 2. Outbound mail encryption and signature validation
>>
>
> I would suggest you keep encryption as a part of extended goals in case of
> GSoC. You'd be surprised how many students are not able to finish their
> proposal in time.
I will try to make a realistic evaluation of what's possible in my GSoC
before i apply.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
> > 2. Outbound mail encryption and signature validation
> > 4. Inbound mail decryption and outbound mail signature
>
> I don't understand these pairs. Why encrypt mail *to* the server if
> it's only going to be decrypted on the way out? Why encrypt outgoing
> posts if they might have been read in the clear before being received?
On 28.02.2016 04:48, Abhilash Raj wrote:
> Shouldn't both be working differently? Encrypted
> emails distributed as encrypted email and signed email distributed as
> signed.
I paired them this way because outbound encryption and inbound signature
validation requires the application to manage the subscribers public
keys and inbound encryption requires the application to manage the lists
keypair so I would probably implement 1. and 2. as well as 3. and 4. at
the same time. 1-4 are part of the core functionality.
My list is badly structured.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
> End-to-end encryption or signature or both seems to be the right
> thing.
The concept of a mailserver doesn't allow real end-to-end encryption if
each recipient uses a different keypair.
A user would have to have the public keys of all the subscribers at the
time of sending a mail to the list and encrypt the mail for each of
them. This would require modification to the client software for this to
behave like a mailinglist, especially if subscribers join or leave the list.
A method for real end-to-end mailinglists is described in
Practical Encrypted Mailing Lists by Neal H. Walfield, feb 2016 [1]
but this is not what I want to do.
Another alternative would be to have a pgp proxy outside the list server
that does the re-encryption but this would not be as convenient as
having a re-encrypting listserver.
Considering that all subscribers recieve the mail and usually listserver
admins are subscribers theirselves, I think than an implementation where
the listserver recieves a copy as well definitly has some uses.
Users would have to be aware that the privacy of communication relies on
the protection of the listserver and listserver admins would have to be
aware that they need to protect the lists keypair.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
> Out of scope for one summer IMHO. It's not obvious what the security
> implications are. Better to do key generation off-line.
What security implications are you refering to? Some servers have true
hardware rngs. If there isn't enough entropy, no keys should generate
with /dev/random as entropy source. Having the proper crypto libraries
and random number sources is in the responsibility of the user.
With this concept, there will be a private key on the listserver and
this should be clear to the users. It has security implications but I
think they are admissible.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
> > 5. A mailinterface for organizing the encrypted lists, subscribers
> > public keys and trust levels
> > 6. A webinterface
>
> These too are out of scope. Again, security implications are unclear.
>
> > 7. PGP Information in the messages (e.g. was the incoming mail signed
> > by a trusted subscriber?)
>
> What does "trusted" mean?
Trusted means that the key has been marked as trusted by an authority
(list admin). The authority has to decide what actions have to be taken
to mark a key as trusted. This could be exchanging fingerprints in real
life or fingerprints could be confirmed by a trusted third party (eg a
list member that already knows that public key).
On 28.02.2016 04:48, Abhilash Raj wrote:
>> 5. A mailinterface for organizing the encrypted lists, subscribers
>> public keys and trust levels
>
>
> I would like to know more on how you plan to do this.
It could be one command to list all the pubkey fingerprints along with
the corresponding subscriber email adress, the trust level and another
command to set the trust level of a pubkey (by its fingerprint).
This would require the list admin to securely identify, for example
by pgp signing command mails.
I did not yet research how to implement mail commands.
On 28.02.2016 10:30, Stephen J. Turnbull wrote:
> Yes, crypto support (both encryption and signatures) are a FAQ.
> However, nobody has ever really provided specific requirements (ie,
> the threat model to defend against), so it's very hard to decide what
> to do, and documentation of whatever is done would be impossible.
I'm not exactly sure what a threat model is. But a scenario this would
protect from is eavesdropping on list communication by a mailserver – or
anyone in case inter-mailserver communication or access to a mailbox
isn't properly secured. A scenario where privacy could still be violated
is when an eavesdropper gains access to the mailserver or any
subscribers private key.
I don't understand, why would documentation be impossible?
[1]: http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf
Jonas
On 2016-02-28 1:34 PM, aahan bhatt wrote:
> Please explain about the gitlab integration in layman terms. I would like
> to contribute to the project.
Gitlab integration can mean a lot of things, and we've left this
particular project pretty open to see what people will suggest.
The tweet linked talks about moving a discussion from a mailing list to
a bug tracker. So imagine that you have a bunch of people discussing an
issue on a mailing list and after a few posts someone says "hm, that
configuration didn't work the way I expected, this sounds like a bug,
maybe we should file it" -- we want a way to dump the whole discussion
into a bug so when someone goes to fix it they have all the information.
You'd need to think a bit about privacy (were the mailing list posts
public? what about the bug tracker?) and relevance of information (what
if I only want some of the posts? what if I want to link the discussion
but only provide a summary?) to go from the idea of "make it easier to
file bugs using information from a mailing list discussion" to an actual
workable interface for doing that, but that's the core of it.
If you want to understand the whole gitlab integration idea better
beyond that one use case, try brainstorming a little bit about how the
pieces could work together. How could a mailing list integrate better
with a bug tracker? How could it integrate better with merge requests?
What information would people want to pass from one system to the
other and why?
For an example you might want to take a look at idea #27 on this page:
http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/
On 02/10/2016 10:03 AM, Harshit Bansal wrote:
> Hi Abhilash,
> In our previous discussion you mentioned that :
>
>> Permissions should also consider if the user wants to make his new style
>> public or keep it private. And should public styles be editable by
>> anyone or just read-only?
>
> I am unable to think of a use case in which it will be useful to have
> private styles.. Can you please suggest a suitable use case?
Well, i agree there is nothing "private" in list styles. We could just
make all styles read-only for everyone. But if someone wants to use the
style created by other users, it would be better idea to first make them
copy the style so that the behavior or their list doesn't change when
the owner changes the style.
Barry: If you have some time, I would like to hear some of your thoughts
on this thread? I believe you have some ideas of your own on how this is
supposed to work.
>
> Thanks,
> Harshit Bansal.
>
--
thanks,
Abhilash Raj
[Aside @Barry: what's the current state of DMARC handling in Mailman
3? (I assume below that there isn't any yet.) I guess porting some
or all of the Mailman 2 facilities be a good GSoC project?]
Please keep GSoC traffic on Mailman-Developers. Other developers have
need-to-know, as do other students. Also, there's a good chance one
of the other developers will get around to answering before I do,
especially as I just got a pile of work dumped on me at work (one of
our adjunct faculty got suddenly recalled to the Bank of Japan,
leaving 8 units of courses unstaffed from April 1). I'll stay current
with Mailman as much as a I can, but for the next few weeks that means
responding to non-work mail in 48 hours.
> The deliver method in deliver.py is responsible for sending the
> messages, and the errors are caught here and then classified as
> permanent or temporary. So currently, if I am not wrong, all the
> rejections that Mailman faces due to the dmarc reject policy of
> some domains, permanent error 550 I think, are caught here if there
> are any.
I don't think so. You'll not catch them in mta.deliver.py, which
talks to your outgoing SMTP gateway, which normally does not do DMARC
processing. On the other hand, the outgoing gateway doesn't make
Mailman wait until it knows what its remote peer will do; it queues
the message. So any rejections you see in mta.deliver.deliver() are
a local matter. Permanent failures likely indicate a configuration
problem, while temporary failures are probably due to maintenance on
the MTA or network problems or the like.
It's the final recipient MTA[1] that does DMARC processing, perhaps
hours or days after deliver() has returned :-). At that point a
(new!) bounce message is created and sent back through the mail
system to Sender or Errors-To, which is <list>-bounces. So this is
handled by the bounce runner, not the outgoing runner.
> I was curious to know how this specific problem is being handled by
> mailman right now. As in, how are the cases of subscribers of yahoo
> using mailman currently being handled?
First, subscribers using Yahoo! are not the problem. The DMARC
problem is that when anybody from Yahoo! posts, *all* subscribers are
at risk[2] of having their service bounce the post. If it was just
Yahoo! subscribers, we wouldn't have to do anything except tell them
that their mail service is deliberately sabotaged by Yahoo! It's the
collateral damage to well-behaved third parties that makes DMARC abuse
by AOL and Yahoo! so horrible.
Second, in Mailman 3, currently nothing is done AFAIK. The first
patch was submitted against Mailman 2 before release of Mailman 3.0.
People using Mailman 3 at this point are unlikely to have large
populations of p=reject posters.
In Mailman 2, there are a number of options. The one I recommend is
adding aol.com and yahoo.com to the subscription and poster ban
lists.<0.7 wink/> This has the advantage (?) of also being usable in
Mailman 3. A second is to configure the list without transforming the
message at all (no Subject tags, header, or footer), thus preserving
any valid DKIM signature. This also works in Mailman 3. These are
standard configuration options which you might use anyway for
completely different reasons. However, they sort undermine the
argument for using Mailman in the first place for many sites.
The third, more pleasant, alternative is to configure the list to
transform the message by changing the *address* in RFC5322.From to the
list, and putting some amount of user identity in the display name of
the RFC5322.From (eg, "From Aditya Divekar (adityadivekar03(a)gmail.com)
via Mailman-Users") of all messages. A fourth is to treat the message
as a literal forward by including the message as a message/rfc822 part.
These transformations are done by Mailman Handlers. Each has
disadvantages. From-munging basically prevents the recipient from
filtering on From. Few MUAs know how to handle a message "wrapped" in
a MIME part pleasantly, and some (especially AppleMail on iPhone)
choke badly.
Finally, the most sophisticated alternative is to parse the address
out of From, and do the DMARC DNS dance to determine if the sending
domain has a p=reject or p=quarantine policy. If so, use either the
From-munging strategy or the MIME-wrapping strategy. These still have
the disadvantages described above, but they only apply to posts From
domains abusing DMARC.
I don't think any of these would be that hard to port to Mailman 3, it
just hasn't been done yet.
Footnotes:
[1] This concept is a little ambiguous, in the case of things like
.forward files that point to another mail server.
[2] If their mail service participates in DMARC (there's no way of
knowing that unless you're a user there), and if they don't do their
own mitigation (eg, GMail treats many messages from p=reject domains
as p=quarantine).
On Mailman-Users, Mark Sapiro writes:
> Further, in the ban_list (and many other places in Mailman) if an
> address is intended to be a regular expression pattern, it must begin
> with '^', so you really want
>
> ^.*(a)domain\.com$
>
> to match any_address(a)domain.com.
I hope we haven't propagated this rather user-unfriendly interface
(the convention of accepting both regexps and literals, distinguishing
by "^" in column 0) to Mailman 3. Even as a Python programmer, I find
Mark's post somewhat confusing: I would design filters using
re.search, so that the above would actually be equivalent as a Python
regular expression to r"@domain\.com$". OTOH, if the implementation
uses re.match, the "^" is redundant, so I have a "say what?!" event.
If we have, I propose changing it to
Ban these addresses, one entry per line: [ ]
[ ] Entries are regular expressions.
or something like that. We also ought to have a "Python features for
Mailman administrators" section of the FAQ, starting with "what is a
regular expression", and giving examples of how to accomplish common
tasks like banning a whole domain with regular expressions. Typical
regexp FAQs are hard for non-programmers (and even beginning
programmers) to grasp.
I don't have time to actually work on these now, but if there's uptake
on the suggestion ("let's think about it" at +0 or above :-) I'll file
issues.
Please ignore the spurious, fumble fingered post of a few minutes ago.
I am pleased to announce the release of Mailman 2.1.21.
Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended.
This release includes a few new features and several bug fixes. Most of
the changes since the second release candidate are i18n updates, but
there are a few more bug fixes. See the attached README for details.
Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.
For more information, please see our web site at one of:
http://www.list.orghttp://www.gnu.org/software/mailmanhttp://mailman.sourceforge.net/http://mirror.list.org/
Mailman 2.1.21 can be downloaded from
https://launchpad.net/mailman/2.1/http://ftp.gnu.org/gnu/mailman/https://sourceforge.net/projects/mailman/
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Hello everyone.
I am Jasvir Singh Grewal, a graduate student from CSU Long Beach. I am
feeling very excited to introduce myself on this mailing list. I have
been working on open source technologies since 3 years. Last 2 years I
have spent primarily working on Django and Python and it'll be a
pleasure for me if I can use my skills for Mailman.
Thank You
--
Jasvir Singh Grewal
https://github.com/jasvir99
I saw an older message where someone was asking how to customize the
footer for mailman 3.
https://mail.python.org/pipermail/mailman-users/2015-October/079965.html
It didn't seem to ever be answered, and I couldn't find any follow up in
this list's archives.
This is a problem I'm struggling with now - I also found the
footer-generic.txt from the source where the exact footer I'm seeing is
coming from.
https://gitlab.com/mailman/mailman/blob/master/src/mailman/templates/en/foo…
I'm looking to modify the contents of this footer so it says something
slightly different. However, I can't find anywhere with Mailman 3 to
change anything about the footer.
Any help is greatly appreciated! Thank you!
Hello devs,
Google is announcing the list of selected organisation for GSOC 16 in few
hours. Hope you all will like to join.
Mentor are welcome as they are needed to guide the students and students
are also welcome who would like to contribute. Think about the project idea
and post it to mailing list for suggestions. Or choose the projects from
the list.
Hope we will got selected (fingers crossed) :)
I know I was talking to someone a while ago about maybe doing some fuzz
testing on Mailman. If anyone's interested, this might be a tool worth
trying out:
-------- Forwarded Message --------
Subject: [Python-Dev] [ANNOUNCE] fuzzpy
Date: Sun, 28 Feb 2016 21:44:39 -0600
From: Brian Cain <brian.cain(a)gmail.com>
To: python-dev(a)python.org
##################################################################
  *---------------------------------------------------*
  *   fuzzpy: CPython fuzz tester is now available  *
  *                     Â
    *
  *          Version 0.8        Â
  *
  *     https://bitbucket.org/ebadf/fuzzpy/     *
  *---------------------------------------------------*
I am pleased to announce the creation of a coverage-guided fuzz tester
for CPython. It's a pretty small wrapper around LLVM's libFuzzer that
enables some powerful testing logic. AFL (American Fuzzy Lop) is
another popular fuzzer lately -- libFuzzer is very similar in concept to
AFL. From what I've read on list archives, Victor Stinner had
previously done some good fuzz testing on CPython using fusil. This
project should expand on that concept.
I'd love to get feedback, suggestions, patches and anything else the
list can offer.
Q: What is fuzzpy for?
A: It's primarily for testing CPython itself, but could also be used for
individual python projects too. Pure-python projects will be the
simplest to integrate at this point. Also, interesting test cases
output by fuzzpy may end up being useful in testing others such as pypy,
pyston, etc.
Q: What is a fuzz tester?
A: It modifies inputs to a test case in order to find unique/rare failures.
Q: What does "coverage-guided" mean?
A: It means that libFuzzer is able to witness the specific code executed
as a result of a given test case. It feeds this information back into
an engine to modify the test cases to optimize for coverage.
Q: How can I help?
A1: donate cycles: build the project and crank away on one of the
existing tests. Relative to other common fuzzing, it's awfully slow,
so consider throwing as many cycles as you can afford to.
A2: contribute tests: write a ~10-line python script that exercises a
feature that you think could benefit from fuzz testing.
A3: if there's interest, I can accept cryptocoin donations to purchase
cycles on a cloud server.
##################################################################
--
-Brian