Hello, I'm a high school senior from Rhode Island. I'm interested in
working on Mail Man for the Google Summer of Code. I was wondering
where I would best be able to help out. I had looked on the ideas
list <http://wiki.python.org/moin/SummerOfCode/2011/Mailman> and I
think I would be able to do the most with completing the Django web
u/i.
I have some experience with Django (as a personal project I'm working
on a web application that analyzes cross country results). So this
seems like the best area for me, but if anyone else knows of any
opportunities I'd love to hear about them.
I also don't have any experience with mailing lists. I did some
research on proper etiquette but if I brake any social rules I truly
apologize.
--
Thanks and Regards,
Matthew Brunelle
+1.401.829.1317
Twitter: @SeeMattPlay @SeeMattWork
Linkedin: www.linkedin.com/in/MatthewBrunelle
Hi everyone,
We're going to be participating in the Google Summer of Code again this year,
but this time, under the Python Software Foundation's banner. Here's our wiki
page for GSoC ideas, mentors, and students:
http://wiki.list.org/display/DEV/Google+Summer+of+Code+2011
and the PSF page with more details for signing up, etc.
Application deadline for students is Friday, April 8, so please hurry! I
believe student registration opened up today. Feel free contact us in
mailman-developers(a)python.org, or #mailman on freenode IRC.
-Barry
--On 28 February 2011 17:15:45 -0800 "Murray S. Kucherawy"
<msk(a)cloudmark.com> wrote:
>> -----Original Message-----
>> From: iane(a)sussex.ac.uk [mailto:iane@sussex.ac.uk]
>> Sent: Friday, February 25, 2011 6:09 AM
>> To: Murray S. Kucherawy; mailman-developers(a)python.org
>> Subject: Re: [Mailman-Developers] mailman and DKIM
>>
>> I think this is only valuable for users of ADSP. Other people would
>> expect their signatures to break, and be supplemented with a good
>> signature generated by the list server.
>
> I don't think that's the only class of users that would be interested in
> this problem.
>> Perhaps you could modify the syntax of the h= tag, to allow, say
>> [12]+subject+[5] to mean that 12 unknown characters may prefix the signed
>> header, and 5 may follow, provided they are bracketed. I'd suggest only
>> permitting bracketed additions, so perhaps this could be expressed as
>> 12+subject+5 instead. I suppose all of this might break existing
>> implementations, so perhaps a separate tag would be required.
>
> Perhaps, but the verifier needs to be told exactly how to identify the
> signed part in order to feed it to the hash algorithm. So instead,
> something like a rule that says "remove up to x bytes from the Subject:
> field, including any enclosing square brackets", with a constraint on
> allowed characters inside the square brackets, might be a better approach.
I think that's the same thing, isn't it?
>> Maybe the l= syntax could be extended. Eg, l=12544+512 would mean "I'm
>> signing 12544 octets, and permitting the addition of a further 512
>
> I would simply add an "la" tag defining the amount that can be appended
> rather than changing the syntax of "l=", so as to be back-compatible with
> current implementations.
Good point.
>> Well, if the sender knows that the list is going to add a List-ID header,
>> then it could add that before signing. I doubt this would scale well,
>> though.
>
> Why's that?
It's the "if the sender knows" bit that doesn't scale. On sites with more
than a few users, managing a list of remote email addresses that are lists
wouldn't be easy.
> -MSK
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers(a)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/iane%40sussex.a
> c.uk
>
> Security Policy: http://wiki.list.org/x/QIA9
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
--On 24 February 2011 19:36:31 -0800 "Murray S. Kucherawy"
<msk(a)cloudmark.com> wrote:
> Hi,
>
> I'm authoring a document within the DKIM working group at the IETF to
> talk about the use of DKIM in the context of mailing lists. I believe
> one or more of you is already at least monitoring the working group
> traffic on that topic, and thanks for that.
>
> Mailing Lists Managers legitimately modify messages sent through them.
> (After all, lists are, essentially, re-posting a new message and they can
> do what they want.) DKIM has a minimal feature that attempts to allow a
> signature to survive transiting mailing lists, by ignoring text added to
> the end.
>
> A suggestion has come up that I'd like to bounce off of you. We're
> interested in doing a better job of surviving the transit. That means
> that DKIM would have to adjust to other modifications made by MLMs, such
> as altering Subject: field contents.
I think this is only valuable for users of ADSP. Other people would expect
their signatures to break, and be supplemented with a good signature
generated by the list server.
> What a few of us would like to explore is the idea of collaborating with
> the MLM community to develop a profile for MLM message modifications that
> DKIM can be enhanced to survive. For example, a new canonicalization
> algorithm might tolerate the addition of a "[...]" string at the
> beginning of a Subject line. We would document this profile and MLM
> implementers can choose to support it.
>
> This would be a voluntary and cooperative effort. DKIM signers would
> have one more configuration choice. MLM operators would have a special
> kind of profile that could apply to a list. Or not.
>
> Our initial discussions have come up with a few idea. No doubt some are
> unworkable, but they should at least serve to get further discussion
> going:
>
> 1) add a way to DKIM to have small Subject: modifications be tolerated;
> something like "exclude from the signed portion any leading text in the
> Subject: field that is contained within square brackets and includes only
> letters, numbers, hyphens and underscores, to a maximum of 32
> characters", which would allow MLMs to add a short token such as the list
> name for use by receivers in mailbox sorting but would make it tough for
> abusers to put a URI there;
Perhaps you could modify the syntax of the h= tag, to allow, say
[12]+subject+[5] to mean that 12 unknown characters may prefix the signed
header, and 5 may follow, provided they are bracketed. I'd suggest only
permitting bracketed additions, so perhaps this could be expressed as
12+subject+5 instead. I suppose all of this might break existing
implementations, so perhaps a separate tag would be required.
> 2) encourage people to sign with "l=" tags, but recommend that receivers
> enforce a policy that says any appended text must be no more than a
> couple of lines long and contain no URLs, or some other similar
> restriction;
Maybe the l= syntax could be extended. Eg, l=12544+512 would mean "I'm
signing 12544 octets, and permitting the addition of a further 512
>
> 3) explore ways to increase use and utility of the List-* header fields.
Well, if the sender knows that the list is going to add a List-ID header,
then it could add that before signing. I doubt this would scale well,
though.
> I'd like to hear your views on such an approach and any other suggestions
> you may have. As a representative of The OpenDKIM Project, which is used
> by AOL and Yahoo to perform DKIM verifications, I can say we're in a
> position to conduct some real experiments and get the code out to a wide
> distribution if we come up with something that has the potential to be
> successful.
>
> Let me know what you think.
>
> Cheers,
> -MSK
>
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers(a)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/iane%40sussex.a
> c.uk
>
> Security Policy: http://wiki.list.org/x/QIA9
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
