[Mailman-Developers] GSoC 2013 (GNU Mailman) - introductions

[Sneha Priscilla]

Hello!

I'm Sneha Priscilla, a final year undergraduate CS student from Bangalore,
India.

I was a previous Summer of Code student for Systers last year and I have in
the process,  worked with a lot of Mailman (mostly the stable 2.1 version).

I am especially interested in Postorius and would like to implement one of
the following ideas this summer:
1.Better User Settings Management
2.Design interface "themes" for specific types of list
3.Enhance list style capabilities

If any of the above are not sufficient to serve as an independent project,
I thought I could team it up with any others above or with the project idea:

Convenient access to logs via admin interface

I would love to have some guidance regarding the above projects and
their feasibility , maybe how to go about it.


A little about myself:
I have 4 years of programming experience, 1 year in Python, coding for
Systers for GSoC 2012. After that summer, I've worked with Mailman 3 and
Postorius and have  found adding features to Postorius a lot of fun.
I've also worked on a bug in the month of January which was merged during
PyCon:
 https://code.launchpad.net/~stylistica/postorius/inline_helptext
Apart from this, I've also filed 2 bugs related to Postorius and which I am
currently working on.
I love algorithms and clean UI design - I have some experience with Django
 and my current final year project uses Bootstrap for CSS.

I'm hoping to work with Mailman in this year's GSoC as I already have a
tiny bit of experience with it and this would serve as an ideal opportunity
to make a big contribution and also give me a chance to work with Mailman
formally and prove my mettle.

I am accessible via email and also available on Launchpad and IRC by the
nick: stylistica .

Looking forward to (Hopefully!) working with the Mailman team.

Thanks and Regards,
Priscilla
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Patrick Ben Koetter]

* Barry Warsaw :
> On Apr 12, 2013, at 08:28 AM, Patrick Ben Koetter wrote:
> 
> >I think it would be real nice to have a MILTER interface at LMTP server level
> >to allow mail modification as required. Mailman runs in large environments 
> >and
> >all the 'large organizations' I have worked asked my team and me to customize
> >how mail is processed. MILTER is a great interface to modify mail.
> 
> Do you mean a hook in Mailman's LMTP server process?  I thought about that in

Yes, I mean to hook MILTER capability into Mailman's LMTP server process.

> my previous message but decided not to mention it because it's not clear to me
> how performant Mailman's current smtpd-based (read: async) LMTP server is.

It's not clear to me either, but now that you made me think about it I begin
to ask myself how fast is fast enough and I also ask myself are we dealing
with a bogey (had to look this up. hope it fits) or are trying to address a
reasonable bottleneck. (I've experienced quite a few "problematic" situations
in mail transport which turned out to be more driven by myth and oral history
than by vested knowledge).

I agree we should measure, just in order not to speculate, but let me send
some thoughts ahead before we take out to test performance:

- Input/output ratio on a mailing list system is 1:n. Performance requirements
  on the receiving side should be the least to worry about. 

- In most usage scenarios that come to my mind companies run an MLM as a
  supplement to their 'regular' mail system. Only a minor ratio of mail that
  enters the mail system is routed forward to the MLM (here: MM3 LMTP server).

- At the moment (MM2) mail enters Mailman via a script that is called. Scripts
  are _a lot_ slower than a server process. My understanding is MM3 will have
  an LMTP server process. Any site that switches to MM3 should experience a
  performance boost on the receiving side.

It seems to me most people will be off fine. Unfortunately I think "most
people" will not need to use a MILTER, too.

What characterizes the remaining group:

- They run sites dedicated solely to mailing lists.

- They need special filtering (read: MILTER and other methods).

- They split load via clusters.

- They have their own development teams to customize and optimize software as
  required

> What I mean is, I'm not sure how much additional work we want the LMTP server
> to do.

How much should it be able to do at all? Do you collect and log statistics at
the moment? Personally I like the "delays=0.04/0.01/0.05/0.1" entry in
Postfix's log. Quote from postconf(5):

   The format of the "delays=a/b/c/d" logging is as follows:

   ·  a = time from message arrival to last active queue entry

   ·  b = time from last active queue entry to connection setup

   ·  c = time in connection setup, including DNS, EHLO and STARTTLS

   ·  d = time in message transmission

   -- $ man 5 postconf | less +/delay_logging_resolution_limit


> It would be cool if someone did some performance testing of the LMTP
> implementation, and it would be cool if someone tried to add some hooks into
> that server.  It might also be interesting to look into alternative
> implementations.  Another reason to push for getting Mailman 3 onto Python 3
> would be the ability to leverage Guido's Tulip work for better async IO
> performance.

I'm short on time to do performance testing myself, but I'll forward the
request to my team members since we are doing tests at the moment anyway.
Maybe someone finds time to squeeze LMTP server testing in.

My first idea would be to use either Postfix smtp-source (multi-threaded
SMTP/LMTP test generator) or swaks (Swiss Army Knife for SMTP)
 and create a wrapper around it that
produces the load.


> >Has anyone ever mentioned SNMP as a feature for Mailman?
> 
> Nope, but that would be interesting too.

We (sys4) will contribute the MIB and monitoring server during development, if
someone takes onto the programming.

p@rick

-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich
 
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] MM 2.1 - Relative vs. absolute URLs in admin and admindb interfaces.

[Barry Warsaw]

On Apr 12, 2013, at 01:28 PM, Mark Sapiro wrote:

>Does anyone know?

Probably not .

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] MM 2.1 - Relative vs. absolute URLs in admin and admindb interfaces.

[Mark Sapiro]

There is a thread in mailman-users at
.

In short the user's difficulty is her world facing host name doesn't
work inside her LAN so from inside, she accesses the web interface via
IP address or some other host name. This leads to the issue that some
links and form actions in the web admin and admindb interfaces are
absolute using the list's web_page_url which has the host name that
doesn't work inside the LAN.

Granted, this can be addressed in the network or the work station's
/etc/hosts file, but the question arises as to whether these URLs need
to be absolute, particularly because they're already in the minority.

I was going to call this a MM 2.1 bug and fix it but then I came across
this 10 year old comment from Barry at
.

   We had lots of problems when non-absolute urls where used,
   although I don't remember the exact details of the problems.
Eventually we'll probably make all urls absolute and get
   rid of this argument to GetScriptURL().

So my question is would there be issues if the URL in the form action
and the leter/digit links on the web admin Membership List page or those
in the admindb interface were relative instead of absolute and what
might those issues be?

Does anyone know?

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] GSOC

[Kushal Khandelwal]

Hey ,

My name is Kushal Khandelwal and I am a third year undergraduate in
engineering.I am interested in developing for Mailman. I have experience in
programming with Python , and I am also into web development using PHP HTML
CSS and javascript. Also I am good at data mining and vizualization and
currently working on Natural Language processing.

I would like to work on the following projects :
1)Design interface "themes" for specific types of list
2) Log Monitor
3) Web Posting Interface

Please guide me how should go about developing the projects ?
I am currently setting up my local mailman development repo.

-- 

Kushal Khandelwal


Birla Institute of Technology & Science, Pilani

K K Birla Goa Campus
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Sreyanth]

And this is my another idea, which I am interested to work on

4. My own project idea: Mining the list logs and recognize interesting
patterns for better enhancements (the admin need not have data mining
experience)

​We can actually have this integrated to the admin console where the logs
can be accessed, at the same time, some interesting patterns can shown,
along with stats and all (just a basic idea, need to work on this more).
Depending on the detected patterns, the admin may want to change some
settings! Given my experience with IR and Django, I feel this is a
potential GSoC project!

Any suggestions?​



On Fri, Apr 12, 2013 at 8:47 PM, Sreyanth  wrote:

> Hi all! Thank you very much for awesome discussion here!
>
> On Fri, Apr 12, 2013 at 1:22 AM, Terri Oda  wrote:
>
>>  On 13-04-11 10:44 AM, Stephen J. Turnbull wrote:
>>
>> 1.  Mailman is the wrong place to do filtering.  It's equally
>> effective, normally covers more messages, and is somewhat more
>> efficient in resource usage to do it at the MTA.
>> 2.  Any new algorithms **should** be made available at the MTA level
>> where they can be best put to use by more people.  This implies
>> something that either plugs into existing filters (such as
>> spamassassin) or MTAs (ie, milters) rather than a Handler.
>> 3.  Adapting existing filters is generally pretty trivial: you write a
>> 10-line custom Handler that pipes it to an external process.  This
>> isn't big enough for a GSoC project.
>> 4.  To the extent that new algorithms are involved, I have doubts that
>> Mailman mentors have the kind of expertise needed to really help
>> with such a project (I could be wrong, but I certainly don't know
>> much about that kind of text processing, and I don't know that
>> anybody else in Mailman has expertise in it).
>>
>> I agree.​​
>
>>
>> Writing individual pipelines may be trivial, but making a user interface
>> for managing said pipelines is non-trivial.  Right now, our pipeline
>> management interface is "there's a text box in postorius that lets you
>> choose a pipeline.  It's not even a dropdown, and you may be screwed if you
>> make a typo" which is obviously not how I want it when we release. ;)
>>
>> I see a potential project timeline going something like this:
>>
>> A. make a set of custom Mailman 3 Handlers for some well-known existing
>> anti-spam/anti-malware software.  (Maybe 2-3 weeks of work here, finding
>> 2-4 reasonable pieces of software, setting them up, writing the handlers,
>> and testing them)
>>
>> B. make an interface in Postorius so list admins can
>> enable/disable/reorder these and any whitelisting happening within
>> mailman.  This should involve making an interface in Postorius that gives
>> admins the ability to change the Pipeline being used, and will likely
>> involve a small amount of user testing to make sure said interface doesn't
>> have risk of disastrous results if the administrator does the wrong thing.
>> (Another 3-4 weeks of work including user testing, unit tests, and
>> documentation)
>>
>> C. Figure out how to set up some sort of packager that can install
>> handlers + antispam software so that the site admin has an easy way to set
>> these up if requested. (Another 3-4 weeks of work, including testing any
>> scripts on a few different OSes and extensive documentation)
>>
>> D. If there's any time leftover, implement some clever new filter (and
>> appropriate Handler) that makes use of the list information itself (e.g.
>> subscriber list, archives, etc.) to make better spam decisions. (at this
>> point, you've got maybe 2 weeks left in the GSoC timeline)
>>
>> This really looks great! Almost what I actually expected from a project
> like this.
> But, like Stephen and Barry pointed out, I am unsure as to how far this
> comes under GSoC's purview.
> ​​
>
>>
>> I think that constitutes enough useful-to-mailman work to justify the
>> google funds, gets us some customizable spam filtering (which as you say,
>> is a frequently requested feature), but doesn't turn us into something
>> we're not.  That's why anti-spam made this year's gsoc list even though
>> we've always said "do it in the MTA" and I'm not about to change that
>> policy in general.
>>
>> Do feel free to disagree with me, of course, Stephen. Or complain that
>> I'm using the lure of antispam to get someone solve my user interface for
>> pipelines problem, which I totally am. ;)
>>
>>  Terri
>>
>> Thanks for such a great timeline Terri. I dont have issues with this. As
> Stephen and Barry said, I even liked the idea of having a MILTER interfaced
> at LMTP level.
>
> On a overall positive note, I am quite convinced that giving the admin of
> the list with great flexible options to choose from (and as Barry pointed
> out, why should everything be exposed to the admin via Postorius?, which
> may not be of the admin's interest! ). I believe this could be make a nice
> GSoC project, but with many spam filters wh

Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Sreyanth]

Hi all! Thank you very much for awesome discussion here!

On Fri, Apr 12, 2013 at 1:22 AM, Terri Oda  wrote:

>  On 13-04-11 10:44 AM, Stephen J. Turnbull wrote:
>
> 1.  Mailman is the wrong place to do filtering.  It's equally
> effective, normally covers more messages, and is somewhat more
> efficient in resource usage to do it at the MTA.
> 2.  Any new algorithms **should** be made available at the MTA level
> where they can be best put to use by more people.  This implies
> something that either plugs into existing filters (such as
> spamassassin) or MTAs (ie, milters) rather than a Handler.
> 3.  Adapting existing filters is generally pretty trivial: you write a
> 10-line custom Handler that pipes it to an external process.  This
> isn't big enough for a GSoC project.
> 4.  To the extent that new algorithms are involved, I have doubts that
> Mailman mentors have the kind of expertise needed to really help
> with such a project (I could be wrong, but I certainly don't know
> much about that kind of text processing, and I don't know that
> anybody else in Mailman has expertise in it).
>
> I agree.​​

>
> Writing individual pipelines may be trivial, but making a user interface
> for managing said pipelines is non-trivial.  Right now, our pipeline
> management interface is "there's a text box in postorius that lets you
> choose a pipeline.  It's not even a dropdown, and you may be screwed if you
> make a typo" which is obviously not how I want it when we release. ;)
>
> I see a potential project timeline going something like this:
>
> A. make a set of custom Mailman 3 Handlers for some well-known existing
> anti-spam/anti-malware software.  (Maybe 2-3 weeks of work here, finding
> 2-4 reasonable pieces of software, setting them up, writing the handlers,
> and testing them)
>
> B. make an interface in Postorius so list admins can
> enable/disable/reorder these and any whitelisting happening within
> mailman.  This should involve making an interface in Postorius that gives
> admins the ability to change the Pipeline being used, and will likely
> involve a small amount of user testing to make sure said interface doesn't
> have risk of disastrous results if the administrator does the wrong thing.
> (Another 3-4 weeks of work including user testing, unit tests, and
> documentation)
>
> C. Figure out how to set up some sort of packager that can install
> handlers + antispam software so that the site admin has an easy way to set
> these up if requested. (Another 3-4 weeks of work, including testing any
> scripts on a few different OSes and extensive documentation)
>
> D. If there's any time leftover, implement some clever new filter (and
> appropriate Handler) that makes use of the list information itself (e.g.
> subscriber list, archives, etc.) to make better spam decisions. (at this
> point, you've got maybe 2 weeks left in the GSoC timeline)
>
> This really looks great! Almost what I actually expected from a project
like this.
But, like Stephen and Barry pointed out, I am unsure as to how far this
comes under GSoC's purview.
​​

>
> I think that constitutes enough useful-to-mailman work to justify the
> google funds, gets us some customizable spam filtering (which as you say,
> is a frequently requested feature), but doesn't turn us into something
> we're not.  That's why anti-spam made this year's gsoc list even though
> we've always said "do it in the MTA" and I'm not about to change that
> policy in general.
>
> Do feel free to disagree with me, of course, Stephen. Or complain that I'm
> using the lure of antispam to get someone solve my user interface for
> pipelines problem, which I totally am. ;)
>
>  Terri
>
> Thanks for such a great timeline Terri. I dont have issues with this. As
Stephen and Barry said, I even liked the idea of having a MILTER interfaced
at LMTP level.

On a overall positive note, I am quite convinced that giving the admin of
the list with great flexible options to choose from (and as Barry pointed
out, why should everything be exposed to the admin via Postorius?, which
may not be of the admin's interest! ). I believe this could be make a nice
GSoC project, but with many spam filters which people are already
acquainted with, I am not sure how far people tend to use this feature.

Also, I would like to hear more about : Boilerplate stripper AND Better
content-filtering / handling error messages.
​Boilerplate stripping is trivial to understand. But, can anyone elaborate
on Better content-filtering / handling error messages?
I strongly believe that Boilerplate stripping will be a cool thing to have
in Mailman and obviously, who would not want to welcome better
content-filtering / error handling techniques on board?​



-- 
*Yours Sincerely*
*
*
*Mora Sreyantha Chary*
*Computer Engineering '14*
*National Institute of Technology Karnataka*
*Surathkal, India 575 025*
___
Mailman-Developers mailing list

Re: [Mailman-Developers] A feature I'd like to emphasize for GSoC ...

[Barry Warsaw]

On Apr 12, 2013, at 12:50 PM, Stephen J. Turnbull wrote:

>... is *convenient access to logs via the admin interface*.

+1.  Can you add that to the wiki page?

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Barry Warsaw]

On Apr 11, 2013, at 01:52 PM, Terri Oda wrote:

>Writing individual pipelines may be trivial, but making a user interface for
>managing said pipelines is non-trivial.  Right now, our pipeline management
>interface is "there's a text box in postorius that lets you choose a
>pipeline.  It's not even a dropdown, and you may be screwed if you make a
>typo" which is obviously not how I want it when we release. ;)

Remember that in MM3 you have two processing queues.  Think of the first as
the "moderation" process and the second as the "modification" process.

http://pythonhosted.org/mailman/src/mailman/docs/8-miles-high.html#basic-messaging-handling-workflow

When the message is first accepted by the LMTP server, it is dumped into the
incoming queue.  The incoming runner will send the message through the rule
chain for target mailing list.  (There are actually two of these chains for
every mailing list - one for messages to the owner/moderator and one for
messages posted to the list.)  Rule chains are made up of individual links
where each link usually contains a rule and an action.  Rules only inspect the
message, never modify it (though they can add metadata to the associated
dictionary), and rules produce a binary decision.  If the rule "hits", the
action is take.  If the rule "misses", the next link in the chain is executed.

At the end of the rule chain is usually a "truth" rule which always hits, and
its action is to jump to the "accept" chain, which essentially just dumps the
message into the pipeline queue.

The pipeline runner only handles messages that have been approved for posting,
so it doesn't have to make any moderation decisions.  All it has to do is
modify the message for posting.  Again, there are two pipelines, one for owner
messages and one for list posts, but pipelines are much simpler.  They are
just sequences of handlers.  Each handler does whatever it wants to the
message, and it can use, add, or delete information from the metadata
dictionary to do this work.  E.g. handlers can remove or add RFC 822 headers,
filter content, add those informative footers, etc.  Handlers also copy the
messages to other queues, so that other runners can send the message to the
archives, NNTP, and the outgoing SMTPd.

I mention all this because to show that there are *lots* of ways the system
can be configured, and I'm not sure all should be exposed via Postorius.
Certainly the full power isn't something a list owner will usually want to be
confronted with ;).  Each chain and pipeline (as well as rules and handlers)
have a unique name, and the choice of chain and pipeline is part of a list's
style (i.e. initial setting), so that may be a better way to allow list owners
some flexibility in setting up their lists.

Anyway, some things to keep in mind. :)

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Barry Warsaw]

On Apr 12, 2013, at 08:28 AM, Patrick Ben Koetter wrote:

>I think it would be real nice to have a MILTER interface at LMTP server level
>to allow mail modification as required. Mailman runs in large environments and
>all the 'large organizations' I have worked asked my team and me to customize
>how mail is processed. MILTER is a great interface to modify mail.

Do you mean a hook in Mailman's LMTP server process?  I thought about that in
my previous message but decided not to mention it because it's not clear to me
how performant Mailman's current smtpd-based (read: async) LMTP server is.
What I mean is, I'm not sure how much additional work we want the LMTP server
to do.

It would be cool if someone did some performance testing of the LMTP
implementation, and it would be cool if someone tried to add some hooks into
that server.  It might also be interesting to look into alternative
implementations.  Another reason to push for getting Mailman 3 onto Python 3
would be the ability to leverage Guido's Tulip work for better async IO
performance.

>Has anyone ever mentioned SNMP as a feature for Mailman?

Nope, but that would be interesting too.

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion

[Barry Warsaw]

On Apr 12, 2013, at 01:44 AM, Stephen J. Turnbull wrote:

>A couple of people have mentioned anti-spam, and it's a frequently
>requested feature.  Nevertheless, I don't think we should spend Google
>money and mentor time on it.

>From the core's perspective, I tend to agree that there is some interesting
things we'd like to add here, but it's probably not enough work to justify a
GSoC slot.  I'm not sure if additional ui work can pad that out.

I also agree that in general, we want to encourage sites to push anti-spam
defenses into the MTA as much as possible.  The counter argument is that we
get plenty of requests from folks who have no control over their MTA and want
to be able to configure Mailman to help reduce spam.  I think the following
avenues would be interesting to pursue.

* Assume the MTA is doing filtering, and that messages will fall into three
  categories: known bad (these get dropped at the MTA), known good (these flow
  through), unsure.  For the latter, the message will probably be marked in
  some way, e.g. a header with a spam score, and it would be good if Mailman
  has some facility (e.g. a rule) to parse that header and make disposition
  decisions based on that value.  One thing Mailman can do that the MTA cannot
  is allow for human intervention for disposition.

* Provide an option for messages to detour into spam filters like spamassassin
  during Mailman message processing.  This probably means a rule which calls
  out to SA or equivalent, and stores the score in some metadata.  A rule hit
  might mean that the message has a spam score higher than a threshold, in
  which case processing jumps to a chain which can discard, reject, or hold th
  message.

>Regarding anti-abuse, we would like to do something about problems
>like backscatter.  However, I have to wonder how much *code* (vs
>*specification* and *design*) is needed for those problems.  If the
>project is really spec-heavy, it's probably not really what Google has
>in mind (based on comments on the mentors' list, not on any official
>Google pronouncements, though).

Agreed.

-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] OpenPGP Integration on GSoC

[Daniel Kahn Gillmor]

On 04/11/2013 09:13 AM, Stefan Schlott wrote:

> True, the PGP file structure encapsulates the signature within the
> encryption (in contrast to S/MIME, which does it vice versa). But the
> standard PGP binary will strip both in one step, so keeping the
> signature won't work out of the box (at least I didn't manage to do
> that, I'd be really interested how to do that - would be useful for
> searchable mail archives).

It's certainly possible within the OpenPGP spec to have the mailing list
software decrypt its Encrypted Session Key (ESK) OpenPGP packet from an
encrypted message, and then add a new ESK packet (or replace the old
one) for each list subscriber.  IIUC, this should leave the original
message's signature intact.

Whether any of the various OpenPGP-related toolkits that are readily
available for python are capable of doing these operations is another
matter.

If you're playing with this stuff, i recommend reading the OpenPGP RFC,
which actually describes how all the data fits together:

  https://tools.ietf.org/html/rfc4880

you may also be interested in the PGP/MIME spec, which concerns how to
to format OpenPGP within an e-mail:

  https://tools.ietf.org/html/rfc3156

Note that the design proposed in this thread  is similar to the
schleuder2 design, though schleuder doesn't preserve the original
signer's signature either, but substitutes it with a message signature
from the mailing list itself.

This design also exposes the content of each message to the mailing list
software itself.  There are other architectures that make it so the
mailing list software never actually gets to see the content of the
message (see PSELS for an example).

--dkg



signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9