Re: [RFC] misc moderation patches

[Steve Beattie <sbeattie@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

On Thu, Jul 05, 2007 at 11:13:10PM +0200, Morten K.Poulsen wrote:
> Steve Beattie <sbeattie@suse.de> wrote:
> > Here are some patches mostly related to moderating emails for
> > discussion.
> 
> I've looked at your patches, and they look clean. I have a few
> comments. See below.
> 
> We're in the RC-period for 1.2.15

Yes, I was aware of the RC-release which is why I was posting for
comment rather than inclusion. The patches I posted were against
1.2.15-RC1. Unfortunately, the timing failed to work out that I didn't get
to these before the RC1 release; timing's never been my strong point. :-)

> (feedback please!),

The only problems I've run into with the RC have been due to bogons
introduced by myself, but I barely scratch the surface in terms of using
the functionality of mlmmj. Others will need to comment on the current RC.

> so your patches will not be merged to CVS right now. Please remind me
> of them when 1.2.15 is out :)

Sure, will do. I've pushed a quilt series up to
http://www.nxnw.org/~steve/warez/mlmmj/ which is where I'll update the
patches to incorporate your feedback.

> > mlmmj-X-List-Administrivia_header.patch
> > 
> > 	This patch adds two headers, an "X-List_administrivia: Yes" header
> [snip]
> > 	or it should just be added automatically in prepstdreply().
> 
> Yes, please do that.

Fixed in the quilt series.

> > mlmmj-multiple_moderation_args.patch
> [snip]
> > 	I left the moderation of subscriptions alone.
> 
> Could you add that as well?

Possibly. The multiple cookie parsing splits on dashes, and I figured it
would break on email addresses containing dashes as well, which is why I
avoided adding support for multiple addresses. I'm not sure how exactly
to format the reply commands in a way that will be easily parsable; ideas?

> > mlmmj-reject_command.patch
> [snip]
> > 	I didn't add support for rejecting subscriptions; that should
> > 	probably be fixed.
> 
> Yes, please.

Okay.

> Also, please send out a reject mail. Otherwise it's a
> discard - not reject.

Doh, yes, of course. Though would a discard command be accepted as
well? The vast majority of moderation that I do is of spam rather than
content-based, where the From: address has been forged; returning a
rejected message would just add to the spam problem and not do anything
useful. But for a content moderated list, it makes sense to send out a
reject message; however, presumably in that situation a moderator would
like to be able to send a custom message to explain why the message was
rejected. Perhaps just returning the body of the moderation message to
the original sender?

> > mlmmj-add_moderator_command.patch
> [snip]
> > 	I'm not sure proper envelope filtering is done here,
> > 	though.
> 
> Envelope filtering?

It's entirely probable I am confused. I was looking at the code in
src/mlmmj-process.c that handles the 'owner' command:

   569                          /* strip envelope from before resending */
   570                          delheaders->count = 0;
   571                          delheaders->strs = NULL;
   572                          delheaders->strs = myrealloc(delheaders->strs,
   573                                  (delheaders->count+3) * sizeof(char *));
   574                          delheaders->strs[delheaders->count++] =
   575                                  mystrdup("From ");
   576                          delheaders->strs[delheaders->count++] =
   577                                  mystrdup("Return-Path:");
   578                          delheaders->strs[delheaders->count] = NULL;

and (a) wasn't sure why this command was handled here rather than in
the listcontrol(), and (b) assumed the 'moderators' command would need
to do something similar. But SMTP envelopes are an area that I don't
quite grok, and pointers to clues are welcome.

Thanks.
-- 
Steve Beattie
SUSE Labs, Novell Inc. 
<sbeattie@suse.de>
http://NxNW.org/~steve/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]