As i about this, i wonder if the OpenPGP integration project shouldn't
be broken into two phases, so that the tricky nuances could be handled
more simply.
I'm imagining a first phase ("message authentication") would not expect
or handle encrypted messages, but would just use cryptographic
signatur
On 13-05-09 11:17 AM, Daniel Kahn Gillmor wrote:
I'm imagining a first phase ("message authentication") would not expect
or handle encrypted messages, but would just use cryptographic
signatures to verify the authenticity of origin of the incoming message,
enhancing (and/or replacing) some of th
On Thu, May 9, 2013 at 10:47 PM, Daniel Kahn Gillmor
wrote:
> As i about this, i wonder if the OpenPGP integration project shouldn't
> be broken into two phases, so that the tricky nuances could be handled
> more simply.
>
> I'm imagining a first phase ("message authentication") would not expect
>
On 05/11/2013 03:17 AM, Abhilash Raj wrote:
> After the Barry's comment on my proposal I decided to cut down the
> proposal to implement use of OpenPGP signatures for posting
> privileges instead of both signed and encrypted list.
> Most of the infrastructure for encrypted list will be created al
On Friday 17 May 2013 05:16 AM, Daniel Kahn Gillmor wrote:
> On 05/11/2013 03:17 AM, Abhilash Raj wrote:
>
>> After the Barry's comment on my proposal I decided to cut down
>> the proposal to implement use of OpenPGP signatures for posting
>> privileges instead of both signed and encrypted list.
On 05/23/2013 12:06 PM, Abhilash Raj wrote:
> For the encrypted lists yes, the key will be marked as 'encryption
> capable'. The list owner has to upload the public-private keypair for
> the list.
>
>> [dkg wrote:]
>> ***SIGNED_POSTS***
>>
>> Might there be a reason for the list to have a keypair
Daniel Kahn Gillmor writes:
> Is implementing this option something that would be part of the first
> phase of the work, or should it be part of a later phase?
He can implement it whenever he wants :-), but if I were his GSoC
mentor, he'd be getting paid for something else (ie, the pure
authent
Hi!
On Thu, May 23, 2013 at 02:26:46PM -0400, Daniel Kahn Gillmor wrote:
> On 05/23/2013 12:06 PM, Abhilash Raj wrote:
> > My doubt is that how do we actually decide what is the best policy for
> > us to follow? One person may agree to my point, other may not, third
> > may have a different point
On Thursday 23 May 2013 11:56 PM, Daniel Kahn Gillmor wrote:
> On 05/23/2013 12:06 PM, Abhilash Raj wrote:
>
>> For the encrypted lists yes, the key will be marked as
>> 'encryption capable'. The list owner has to upload the
>> public-private keypair for the list.
>>
>>> [dkg wrote:] ***SIGNED_PO
On Friday 24 May 2013 11:24 AM, Stephen J. Turnbull wrote:
> I don't recall for sure but I don't think so. I tend to think it's
> too much effort. We do worry about routing cycles and handle that
> with X-Been-Seen fields. Message-IDs themselves are not very useful;
> in my own experience repea
On Friday 24 May 2013 12:03 PM, Joost van Baal-Ilić wrote:
> I've just typesetted
> http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime/audit.pdf
> and
> http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-patch/pgp-smime/audit2/audit2.
Abhilash Raj writes:
> This part is little difficult to ponder on. Suppose a user signs up
> for a list. He creates a user account and subscribes to a particular
> list which needs his pub-key and implements signing.
In Mailman 3, users and subscriptions are separate concepts. We
should assum
On 05/26/2013 12:57 PM, Stephen J. Turnbull wrote:
> > > sure, but the From: header is forgeable, right? so if Alice knows
> > > that Bob was subscribed to list X in the past, and is subscribed to
> > > list Y today, then she could dig up his old posts in list X, and
> > > forward them (From:
Daniel Kahn Gillmor writes:
> The only way that a DKIM check would fail for the given attack, would be
> if the DKIM included the To: and Cc: headers and the list was configured
> to reject mail that either (a) failed or did not have a DKIM signature,
> or (b) did not include the list's addres
14 matches
Mail list logo
