[Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration

[Barry Warsaw]

On Jun 16, 2013, at 01:48 AM, Stephen J. Turnbull wrote:

> > * the message is queued in incoming queue
> > * the incoming runner wakes up, finds the message and calls a few
> >   functions to verify the signature of the message(assuming the function
> >   already has public key of the user from somewhere)
>
>I think you need to study the architecture more carefully.  I don't
>think it's appropriate for the incoming runner to be calling
>functions, rather there should be a Rule in the pipeline that does
>this checking.

Right.  Remember that all the incoming runner does[*] is take a message that's
already been parsed, and send it through the "posting chain".  That's the
process whereby the message and its metadata flow through rules to determine
whether the post is allowed.  Clearly, signature checking should occur in a
rule.  This will also make it easier for you to test.

> > * If the message signature is found to be valid the message is then
> >   passed on to onther runners as usual (without stripping of the
> >   signature as per my assumption till now, need discussion on this) else
> >   it is dropped or bounced depending on the state of verification( like
> >   if the signature is older we can inform the sender as the delay may
> >   have been due to smtp deliver and simply drop the message if the
> >   signature is verified to be wrong).

The outcome of the signature checking rule is a boolean result.  There will be
an action associated with that.  Because of the way links and rules work, the
action is only taken if the rule hits.  This means that I think the rule
should probably return True if the message is *unsigned* and the action in
that case is to jump to one of the Hold, Reject, or Discard chains (depending
on a configuration variable - but we can discuss this).

If the rule misses (i.e. returns False) then it means the signature was valid
and rule processing just continues on.

I know this is a little backwards, but it's probably the best match for the
current rule/chain model.

>Maybe.  Again you should check current style.  I Think what you
>propose is OK, as Rules and Handlers can live in the same file since
>they are distinguished by their signatures.  But I forget exactly how
>Barry organizes this stuff.

Currently there are separate directories for rules and handlers.  For now,
it's best to follow that model.

-Barry

[*] It also creates IAddress records for any email addresses it's never seen
before, but that's besides the point under discussion.