[RFC] misc moderation patches

[RFC] misc moderation patches

[Steve Beattie]

[-- Attachment #1.1: Type: text/plain, Size: 2350 bytes --]

Here are some patches mostly related to moderating emails for
discussion. I currently admin some lists with mailman, but would like
to move to mlmmj.

mlmmj-X-List-Administrivia_header.patch

	This patch adds two headers, an "X-List_administrivia: Yes" header
	for a few of the administrative messages that mlmmj sends out, and
	a header "X-mlmmj-mod-msg-id:" with the random string that is used
	as the argument for the 'moderate' command. The former is used
	similarly by mailman, and I filter based on it; I don't strictly
	need it if I have the latter header. The latter is really useful
	for writing scripts to moderate multiple messages at a time,
	rather than requiring them to parse out the Reply-To: header.

	If it's deemed worthwhile to keep the administrivia header,
	there's likely more locations that could use it, or it should
	just be added automatically in prepstdreply(). Another
	alternative would be to add these headers in the listtexts.

mlmmj-multiple_moderation_args.patch

	This patch adds the ability to moderate multiple messages by
	sending mlmmj a single message with multiple cookies addressed
	in the form

	  	listname+moderate-COOKIE[-COOKIE...]@domain.tld

	(This is one of my gripes with mailman, that in order to reject
	multiple spam messages by email, my script has to send a message
	for each message to reject, rather than just one message per
	list.) I left the moderation of subscriptions alone.

mlmmj-reject_command.patch

	This adds a 'reject' command to support rejecting messages for
	moderation, rather than accepting them as the 'moderate' command
	does. It supports rejecting multiple messages by taking messages
	in the form

		listname+reject-COOKIE[-COOKIE...]@domain.tld

	I didn't add support for rejecting subscriptions; that should
	probably be fixed.

mlmmj-add_moderator_command.patch

	This patch converts the From: address (currently
	"listname-moderators") in moderation messages to be a real address
	supported by mlmmj and adds the corresponding 'moderators'
	command. I'm not sure proper envelope filtering is done here,
	though.

As these patches touch similar areas of code, they are expected to be
applied in the order above.

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

[-- Attachment #1.2: mlmmj-X-List-Administrivia_header.patch --]
[-- Type: text/x-patch, Size: 2685 bytes --]

---
 src/mlmmj-process.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Index: b/src/mlmmj-process.c
===================================================================
--- a/src/mlmmj-process.c
+++ b/src/mlmmj-process.c
@@ -79,6 +79,7 @@ void newmoderated(const char *listdir, c
 	int queuefd, moderatorsfd, mailfd;
 	size_t count = 0;
 	char *maildata[4] = { "moderateaddr", NULL, "moderators", NULL };
+	char *adminhdrs = "X-List-Administrivia: Yes";
 #if 0
 	printf("mailfilename = [%s], mailbasename = [%s]\n", mailfilename,
 			                                     mailbasename);
@@ -114,6 +115,7 @@ void newmoderated(const char *listdir, c
 
 	maildata[1] = replyto;
 	maildata[3] = moderators;
+	adminhdrs = concatstr(3, adminhdrs, "\nX-mlmmj-mod-msg-id: ", mailbasename);
 
 	from = concatstr(4, listname, listdelim, "owner@", listfqdn);
 	to = concatstr(3, listname, "-moderators@", listfqdn); /* FIXME JFA: Should this be converted? Why, why not? */
@@ -123,7 +125,7 @@ void newmoderated(const char *listdir, c
 	myfree(listfqdn);
 
 	queuefilename = prepstdreply(listdir, "moderation", "$listowner$",
-				     to, replyto, 2, maildata, NULL);
+				     to, replyto, 2, maildata, adminhdrs);
 
 	if((queuefd = open(queuefilename, O_WRONLY|O_APPEND)) < 0) {
 		log_error(LOG_ARGS, "Could not open '%s'", queuefilename);
@@ -347,6 +349,7 @@ int main(int argc, char **argv)
 	char *queuefilename, *recipextra = NULL, *owner = NULL;
 	char *maxmailsizestr;
 	char *maildata[4] = { "posteraddr", NULL, "maxmailsize", NULL };
+	char *adminhdr = "X-List-Administrivia: Yes";
 	char *envstr, *efrom;
 	struct stat st;
 	uid_t uid;
@@ -657,7 +660,7 @@ int main(int argc, char **argv)
 			queuefilename = prepstdreply(listdir,
 					"maxmailsize", "$listowner$",
 					fromemails.emaillist[0],
-					NULL, 2, maildata, NULL);
+					NULL, 2, maildata, adminhdr);
 			MY_ASSERT(queuefilename)
 			myfree(listdelim);
 			myfree(listname);
@@ -768,7 +771,7 @@ int main(int argc, char **argv)
 				     listfqdn);
 		queuefilename = prepstdreply(listdir, "notintocc",
 					"$listowner$", fromemails.emaillist[0],
-					     NULL, 0, NULL, NULL);
+					     NULL, 0, NULL, adminhdr);
 		MY_ASSERT(queuefilename)
 		myfree(listdelim);
 		myfree(listname);
@@ -829,7 +832,7 @@ int main(int argc, char **argv)
 					"bounces-help@", listfqdn);
 			queuefilename = prepstdreply(listdir, "subonlypost",
 					"$listowner$", fromemails.emaillist[0],
-						     NULL, 1, maildata, NULL);
+						     NULL, 1, maildata, adminhdr);
 			MY_ASSERT(queuefilename)
 			myfree(listaddr);
 			myfree(listdelim);

[-- Attachment #1.3: mlmmj-multiple_moderation_args.patch --]
[-- Type: text/x-patch, Size: 4651 bytes --]


(Note: some mail clients like mutt have hard coded limits on the length
of a To: address; e.g. mutt has a limit of 256 characters which it will
truncate if the address is longer than that.)
---
 src/listcontrol.c |   95 +++++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 69 insertions(+), 26 deletions(-)

Index: b/src/listcontrol.c
===================================================================
--- a/src/listcontrol.c
+++ b/src/listcontrol.c
@@ -98,6 +98,34 @@ static struct ctrl_command ctrl_commands
 	{ "list",               0 }
 };
 
+struct strlist *splitparam(const char *param, const char split)
+{
+	char *c;
+	struct strlist *params = mymalloc(sizeof(struct strlist));
+	size_t len;
+
+	params->count = 0;
+	params->strs = NULL;
+
+	if (!param)
+		return params;
+
+	while (*param && (c = strchr(param, split)) != NULL) {
+		len = c - param;
+		params->strs = myrealloc(params->strs, sizeof(c) * (params->count + 1));
+		params->strs[params->count] = mymalloc(len + 1);
+		strncpy(params->strs[params->count], param, len);
+		params->strs[params->count++][len] = '\0';
+		param = c + 1;
+	}
+
+	/* handle last param */
+	if (*param) {
+		params->strs = myrealloc(params->strs, sizeof(c) * (params->count + 1));
+		params->strs[params->count++] = mystrdup(param);
+	}
+	return params;
+}
 
 int listcontrol(struct email_container *fromemails, const char *listdir,
 		const char *controlstr, const char *mlmmjsub,
@@ -114,7 +142,9 @@ int listcontrol(struct email_container *
 	size_t cmdlen;
 	unsigned int ctrl;
 	struct strlist *owners;
-	int owner_idx;
+	struct strlist *params;
+	int owner_idx, rc;
+	pid_t childpid;
 	
 	/* A closed list doesn't allow subscribtion and unsubscription */
 	closedlist = statctrl(listdir, "closedlist");
@@ -588,13 +618,13 @@ int listcontrol(struct email_container *
 		exit(EXIT_FAILURE);
 		break;
 
-	/* listname+moderate-COOKIE@domain.tld */
+	/* listname+moderate-COOKIE[-COOKIE...]@domain.tld */
 	case CTRL_MODERATE:
 		/* TODO Add accept/reject parameter to moderate */
-		moderatefilename = concatstr(3, listdir, "/moderation/", param);
 
 		/* Subscriber moderation */
 		if(strncmp(param, "subscribe", 9) == 0) {
+			moderatefilename = concatstr(3, listdir, "/moderation/", param);
 			log_oper(listdir, OPLOGFNAME, "%s moderated %s",
 				fromemails->emaillist[0], moderatefilename);
 			execlp(mlmmjsub, mlmmjsub,
@@ -603,32 +633,45 @@ int listcontrol(struct email_container *
 					"-c", (char *)NULL);
 		}
 
-		sendfilename = concatstr(2, moderatefilename, ".sending");
+		rc = EXIT_SUCCESS;
+		params = splitparam(param, '-');
+		for (i = 0; i < params->count; i++) {
+			moderatefilename = concatstr(3, listdir, "/moderation/", params->strs[i]);
+
+			sendfilename = concatstr(2, moderatefilename, ".sending");
+
+			if (stat(moderatefilename, &stbuf) < 0) {
+				myfree(moderatefilename);
+				/* no mail to moderate */
+				errno = 0;
+				log_error(LOG_ARGS, "A moderate request was"
+					" sent with a mismatching cookie."
+					" Ignoring mail");
+				continue;
+			}
+			/* Rename it to avoid mail being sent twice */
+			if (rename(moderatefilename, sendfilename) < 0) {
+				log_error(LOG_ARGS, "Could not rename to .sending");
+				rc = EXIT_FAILURE;
+			}
 
-		if(stat(moderatefilename, &stbuf) < 0) {
+			log_oper(listdir, OPLOGFNAME, "%s moderated %s",
+				fromemails->emaillist[0], moderatefilename);
 			myfree(moderatefilename);
-			/* no mail to moderate */
-			errno = 0;
-			log_error(LOG_ARGS, "A moderate request was"
-				" sent with a mismatching cookie."
-				" Ignoring mail");
-			return -1;
-		}
-		/* Rename it to avoid mail being sent twice */
-		if(rename(moderatefilename, sendfilename) < 0) {
-			log_error(LOG_ARGS, "Could not rename to .sending");
-			exit(EXIT_FAILURE);
-		}
+			childpid = fork();
+			if (childpid < 0)
+				log_error(LOG_ARGS, "fork() failed!  Proceeding anyway");
 
-		log_oper(listdir, OPLOGFNAME, "%s moderated %s",
-				fromemails->emaillist[0], moderatefilename);
-		myfree(moderatefilename);
-		execlp(mlmmjsend, mlmmjsend,
-				"-L", listdir,
-				"-m", sendfilename, (char *)NULL);
-		log_error(LOG_ARGS, "execlp() of '%s' failed",
-					mlmmjsend);
-		exit(EXIT_FAILURE);
+			if (!childpid) {
+				execlp(mlmmjsend, mlmmjsend,
+					"-L", listdir,
+					"-m", sendfilename, (char *)NULL);
+				log_error(LOG_ARGS, "execlp() of '%s' failed",
+						mlmmjsend);
+				exit(EXIT_FAILURE);
+			}
+		}
+		exit(rc);
 		break;
 
 	/* listname+help@domain.tld */

[-- Attachment #1.4: mlmmj-reject_command.patch --]
[-- Type: text/x-patch, Size: 1915 bytes --]

---
 src/listcontrol.c |   26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

Index: b/src/listcontrol.c
===================================================================
--- a/src/listcontrol.c
+++ b/src/listcontrol.c
@@ -62,6 +62,7 @@ enum ctrl_e {
 	CTRL_CONFUNSUB,
 	CTRL_BOUNCES,
 	CTRL_MODERATE,
+	CTRL_REJECT,
 	CTRL_HELP,
 	CTRL_FAQ,
 	CTRL_GET,
@@ -92,6 +93,7 @@ static struct ctrl_command ctrl_commands
 	{ "confunsub",          1 },
 	{ "bounces",            1 },
 	{ "moderate",           1 },
+	{ "reject",             1 },
 	{ "help",               0 },
 	{ "faq",                0 },
 	{ "get",                1 },
@@ -620,8 +622,6 @@ int listcontrol(struct email_container *
 
 	/* listname+moderate-COOKIE[-COOKIE...]@domain.tld */
 	case CTRL_MODERATE:
-		/* TODO Add accept/reject parameter to moderate */
-
 		/* Subscriber moderation */
 		if(strncmp(param, "subscribe", 9) == 0) {
 			moderatefilename = concatstr(3, listdir, "/moderation/", param);
@@ -674,6 +674,28 @@ int listcontrol(struct email_container *
 		exit(rc);
 		break;
 
+	/* listname+reject-COOKIE[-COOKIE...]@domain.tld */
+	case CTRL_REJECT:
+		params = splitparam(param, '-');
+		for (i = 0; i < params->count; i++) {
+			moderatefilename = concatstr(3, listdir, "/moderation/", params->strs[i]);
+
+			if (stat(moderatefilename, &stbuf) < 0) {
+				/* no mail to moderate */
+				errno = 0;
+				log_error(LOG_ARGS, "A reject request was"
+					" sent with a mismatching cookie."
+					" Ignoring mail");
+			} else {
+				unlink(moderatefilename);
+				log_oper(listdir, OPLOGFNAME, "%s rejected %s",
+					fromemails->emaillist[0], moderatefilename);
+			}
+			myfree(moderatefilename);
+		}
+		exit(EXIT_SUCCESS);
+		break;
+
 	/* listname+help@domain.tld */
 	case CTRL_HELP:
 		if(!strchr(fromemails->emaillist[0], '@')) {

[-- Attachment #1.5: mlmmj-add_moderator_command.patch --]
[-- Type: text/x-patch, Size: 3779 bytes --]

---
 src/listcontrol.c   |   29 +++++++++++++++++++++++++++--
 src/mlmmj-process.c |    2 +-
 src/mlmmj-sub.c     |    2 +-
 3 files changed, 29 insertions(+), 4 deletions(-)

Index: b/src/mlmmj-sub.c
===================================================================
--- a/src/mlmmj-sub.c
+++ b/src/mlmmj-sub.c
@@ -131,7 +131,7 @@ void moderate_sub(const char *listdir, c
 	modfilebase = mybasename(modfilename);
 
 	from = concatstr(4, listname, listdelim, "owner@", listfqdn);
-	to = concatstr(3, listname, "-moderators@", listfqdn);
+	to = concatstr(4, listname, listdelim, "moderators@", listfqdn);
 	replyto = concatstr(6, listname, listdelim, "moderate-", modfilebase,
 			"@", listfqdn);
 	myfree(modfilebase);
Index: b/src/mlmmj-process.c
===================================================================
--- a/src/mlmmj-process.c
+++ b/src/mlmmj-process.c
@@ -118,7 +118,7 @@ void newmoderated(const char *listdir, c
 	adminhdrs = concatstr(3, adminhdrs, "\nX-mlmmj-mod-msg-id: ", mailbasename);
 
 	from = concatstr(4, listname, listdelim, "owner@", listfqdn);
-	to = concatstr(3, listname, "-moderators@", listfqdn); /* FIXME JFA: Should this be converted? Why, why not? */
+	to = concatstr(4, listname, listdelim, "moderators@", listfqdn); /* FIXME JFA: Should this be converted? Why, why not? */
 
 	myfree(listdelim);
 	myfree(listname);
Index: b/src/listcontrol.c
===================================================================
--- a/src/listcontrol.c
+++ b/src/listcontrol.c
@@ -35,6 +35,7 @@
 #include "listcontrol.h"
 #include "find_email_adr.h"
 #include "getlistdelim.h"
+#include "getlistaddr.h"
 #include "strgen.h"
 #include "send_help.h"
 #include "send_list.h"
@@ -62,6 +63,7 @@ enum ctrl_e {
 	CTRL_CONFUNSUB,
 	CTRL_BOUNCES,
 	CTRL_MODERATE,
+	CTRL_MODERATORS,
 	CTRL_REJECT,
 	CTRL_HELP,
 	CTRL_FAQ,
@@ -93,6 +95,7 @@ static struct ctrl_command ctrl_commands
 	{ "confunsub",          1 },
 	{ "bounces",            1 },
 	{ "moderate",           1 },
+	{ "moderators",         0 },
 	{ "reject",             1 },
 	{ "help",               0 },
 	{ "faq",                0 },
@@ -137,6 +140,7 @@ int listcontrol(struct email_container *
 	char *bouncenr, *tmpstr;
 	char *param = NULL, *conffilename, *moderatefilename;
 	char *c, *archivefilename, *sendfilename;
+	char *listfqdn, *listname, *listaddr = getlistaddr(listdir), *listdelim;
 	const char *subswitch;
 	struct stat stbuf;
 	int closedlist, nosubconfirm, tmpfd, noget, i, closedlistsub,
@@ -216,8 +220,9 @@ int listcontrol(struct email_container *
 		return -1;
 	}
 
-	/* We only need the control mail when bouncing, to save bounced msg */
-	if(ctrl != CTRL_BOUNCES)
+	/* We only need the control mail when bouncing, to save
+	   bounced msg, and when sending to moderators */
+	if(ctrl != CTRL_BOUNCES && ctrl != CTRL_MODERATORS)
 		unlink(mailname);
 
 	switch (ctrl) {
@@ -696,6 +701,26 @@ int listcontrol(struct email_container *
 		exit(EXIT_SUCCESS);
 		break;
 
+	/* listname+moderators@domain.tld */
+	case CTRL_MODERATORS:
+		listfqdn = genlistfqdn(listaddr);
+		listname = genlistname(listaddr);
+		listdelim = getlistdelim(listdir);
+		tmpstr = concatstr(4, listname, listdelim, "owner@", listfqdn);
+		log_oper(listdir, OPLOGFNAME, "mlmmj-recieve: sending"
+				" mail from %s to moderators",
+				fromemails->emaillist[0]);
+		execlp(mlmmjsend, mlmmjsend,
+				"-l", "2",
+				"-L", listdir,
+				"-m", mailname,
+				"-F", tmpstr,
+				"-a", (char *)NULL);
+		log_error(LOG_ARGS, "execlp() of '%s' failed",
+					mlmmjsend);
+		exit(EXIT_FAILURE);
+		break;
+
 	/* listname+help@domain.tld */
 	case CTRL_HELP:
 		if(!strchr(fromemails->emaillist[0], '@')) {

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

Re: [RFC] misc moderation patches

[Morten K. Poulsen]

Hi Steve,

Welcome, and thanks for contributing.

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 (feedback please!), so your
patches will not be merged to CVS right now. Please remind me
of them when 1.2.15 is out :)

> 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.

> mlmmj-multiple_moderation_args.patch
[snip]
> 	I left the moderation of subscriptions alone.

Could you add that as well?

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

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

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

Envelope filtering?

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: [RFC] misc moderation patches

[Steve Beattie]

[-- 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 --]

Re: [RFC] misc moderation patches

[Morten K. Poulsen]

Hi Steve,

Steve Beattie <sbeattie@suse.de> wrote:
> On Thu, Jul 05, 2007 at 11:13:10PM +0200, Morten K. Poulsen wrote:
>> 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.

Ok. Anybody else? Does the thing even compile on various systems?

It works for me on:
- Debian GNU/Linux 3.1
- FreeBSD 6.2
- OpenBSD 4.1

>> 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.

$ telnet www.nxnw.org 80
Trying 208.151.246.43...
telnet: connect to address 208.151.246.43: Connection timed out

(And no, I *don't* browse with telnet ;-)


>> > mlmmj-X-List-Administrivia_header.patch
[snip]
>> Yes, please do that.
> 
> Fixed in the quilt series.

Cool.

>> > 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?

But subscription moderation does not contain the (new) subscribers
address in the argument. It is something like
listname+moderate-subscribeCOOKIE@example.org

I am not sure why mmj reused the "moderate" keyword, and added the
magic "subscribe" before the cookie. That might change in mlmmj-2.0.0 ;-)

>> 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?

Discard would be OK. Both would be perfect.

> 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?

Yes, that is a good idea.

>> > 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 */

Oh yes, this code just removes "Return-Path: " and "From " headers,
which contain the SMTP envelope from. Those headers are only
useful when a mail is delivered (locally) and saved in a file. They
should never be present inside the SMTP DATA. That is why they
are being stripped here.

> and (a) wasn't sure why this command was handled here rather than in
> the listcontrol()

I am not sure:

    /* Why is this here, and not in listcontrol() ?  -- mortenp 20060409 */

mmj?

I think it is safe to move it.

> and (b) assumed the 'moderators' command would need to do
> something similar.

Yes.

> But SMTP envelopes are an area that I don't quite grok, and pointers
> to clues are welcome.

http://www.xkcd.com/c138.html ;-)

An example of a SMTP session might look like this:

# banner
S: 220 example.com SMTP server ready

# hello
C: HELO sender.test
S: 250 example.com

# envelope from
C: MAIL FROM:<user@sender.test>
S: 250 OK

# envelope to
C: RCPT TO:<somebody@example.com>
S: 250 OK

# the mail itself (headers + body)
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Joe User <user@sender.test>
C: To: Somebody <somebody@example.com>
C: Subject: blah blah blah
C:
C: mail body here
C: .
S: 250 OK, queued as 29381984

# end
C: QUIT
S: 221 Bye

The envelope addresses are used for mail (and bounce) routing. The
addresses in the DATA section are only used by user agents (and
some *very* broken transfer agents).

When delivering the mail to its final destination, the delivery agent
usually adds the envelope addresses to the DATA section. They are
often added as "Delivered-To: " (envelope to) and "Return-Path: "
or "From " (note! no colon) (envelope from).

RFC 821, RFC 1869 and RFC 2821 are good references.


Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: [RFC] misc moderation patches

[Morten K. Poulsen]

Hi Christoph,

On Sun, 2007-11-11 at 20:26 +0100, Christoph Thiel wrote:
> On Thu, Jul 05, 2007 at 11:13:10PM +0200, Morten K. Poulsen wrote:
> [...]
> 
> > 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 (feedback please!), so your
> > patches will not be merged to CVS right now. Please remind me
> > of them when 1.2.15 is out :)
> 
> Have those patches been applied yet?

No, not yet. MMJ reminded me about them a few weeks ago.

> Is there any chance of cutting a release any time soon?

I just started a new job one month ago (Ad: PointZero Hosting), and I am
currently commuting 5 hours a day, so probably not. But if there is a
slow day at work any time soon, I will merge Steve's patches and roll a
RC.

Does anybody else have patches, which I've forgotten about?

Morten

Re: [RFC] misc moderation patches

[Alexander Kardailsky]

Dear Morten,

Sunday, November 11, 2007, 11:29:30 PM, you wrote:

> Does anybody else have patches, which I've forgotten about?

  I sent you several months ago improved function recipient_extra that
  should work correct on any MTAs (especially with qmail) with any
  maillist aliases and with any commands.
  Would be good if you accept it.

-- 
Best regards,
 Alexander

Re: [RFC] misc moderation patches

[Morten K. Poulsen]

On Mon, 2007-11-12 at 13:00 +0300, Alexander Kardailsky wrote:
> > Does anybody else have patches, which I've forgotten about?
> 
>   I sent you several months ago improved function recipient_extra that
>   should work correct on any MTAs (especially with qmail) with any
>   maillist aliases and with any commands.

Yes, I remember it. I rejected it because it introduced a number of
problems, without fully solving the issue (using mlmmj lists with the
delimiter in their names with vpopmail).

Morten

Re: [RFC] misc moderation patches

[Alexander Kardailsky]

Dear Morten,

Monday, November 12, 2007, 11:11:51 PM, you wrote:

> On Mon, 2007-11-12 at 13:00 +0300, Alexander Kardailsky wrote:
>> > Does anybody else have patches, which I've forgotten about?
>> 
>>   I sent you several months ago improved function recipient_extra that
>>   should work correct on any MTAs (especially with qmail) with any
>>   maillist aliases and with any commands.

> Yes, I remember it. I rejected it because it introduced a number of
> problems, without fully solving the issue (using mlmmj lists with the
> delimiter in their names with vpopmail).

  Yes, you rejected small changes to if clauses. But later I sent the
  whole function that don't needed these changes. It doesn't affect
  old possibilities. It just adds new ones.
  Could you please give me an example with a problem? Thanks.

-- 
Best regards,
 Alexander

Re: [RFC] misc moderation patches

[Steve Beattie]

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

On Sun, Nov 11, 2007 at 09:29:30PM +0100, Morten K. Poulsen wrote:
> Hi Christoph,
> 
> On Sun, 2007-11-11 at 20:26 +0100, Christoph Thiel wrote:
> > On Thu, Jul 05, 2007 at 11:13:10PM +0200, Morten K. Poulsen wrote:
> > [...]
> > 
> > > 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 (feedback please!), so your
> > > patches will not be merged to CVS right now. Please remind me
> > > of them when 1.2.15 is out :)
> > 
> > Have those patches been applied yet?
> 
> No, not yet. MMJ reminded me about them a few weeks ago.

They weren't applied because there were some issues you raised that I
still need to address. Despite being laid off from Novell, I haven't had
time to get back to them, but I'll try to work on them later this week.
My apologies for not getting to it earlier.

-- 
Steve Beattie
<steve@nxnw.org>
http://NxNW.org/~steve/

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

Re: [RFC] misc moderation patches

[Morten K. Poulsen]

Hi Steve,

On Mon, 2007-11-12 at 12:40 -0800, Steve Beattie wrote:
> > No, not yet. MMJ reminded me about them a few weeks ago.
> 
> They weren't applied because there were some issues you raised that I
> still need to address.

Ah, ok. I had forgotten about that.

> Despite being laid off from Novell

I am sorry to hear that.

> I haven't had time to get back to them, but I'll try to work on them
> later this week. My apologies for not getting to it earlier.

No problem. I will wait for your patches, before rolling a RC.

Morten

Re: [RFC] misc moderation patches

[Morten K. Poulsen]

On Mon, 2007-11-12 at 23:34 +0300, Alexander Kardailsky wrote:
>   Yes, you rejected small changes to if clauses. But later I sent the
>   whole function that don't needed these changes. It doesn't affect
>   old possibilities. It just adds new ones.

And it breaks in some cases.

>   Could you please give me an example with a problem? Thanks.

$ echo 'Delivered-To: test-list+' >/tmp/mail
$ ./mlmmj-process -L /home/mopo/mlmmj-test/ -m /tmp/mail
$ echo $?
1
$ tail -n 1 /var/log/mail.err 
Nov 12 22:38:34 mopo-laptop ./mlmmj-process[13111]: mlmmj-process.c:327:
malloc(-134578623) failed! Bailing out!: Cannot allocate memory

Morten