apparently it barely works anyway.  should probably disable the buttons if it
isn't available (if it was a proper plugin, this could be done)

it is a plugin now and even when disabling it, the UI is still there.
adding jvivek@novell.com to the cc list since you've been working on the plugin.

reassigning old bugs to get rid of triage@ximian.com as assignee.

FYI - This was also reported against Fedora Core:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137229

Created attachment 109892 [details] [review]
proposed evo patch

for evolution;

This patch adds ability of error propagation from junk plugin to UI in hook target. (which means for report junk, report not-junk and check junk). It will show the error in the status bar, because it can be somehow intrusive when receiving many mails and checking will fail.

Better to use g_set_error() than g_error_new() because it handles the case where the 'error' pointer is NULL. (I know it won't be in this case, but that's the convention for GError.  See [1] for examples.)  Patch looks good to me otherwise.

[1] http://library.gnome.org/devel/glib/unstable/glib-Error-Reporting.html

Slightly modified patch committed to trunk. Committed revision 35415.

I see I did a checking myself, so your suggestion will be better.

Patch needs to be updated.

Patch posts error message if return status from bogofilter is not 0.  This results in false error messages.

bogofilter returns:
 0 for spam; 1 for non-spam; 2 for unsure ; 3 for I/O or other errors.


if (waitres >= 0 && WIFEXITED (status)) {
	res = WEXITSTATUS (status);
} else {
	res = BOGOFILTER_ERROR;
}

if (res != 0)
		g_set_error (error, EM_JUNK_ERROR, res, _("Pipe to Bogofilter failed, error code: %d."), res);

res == 0 | res == 1 | res == 2 are non-error responses.

Thanks Reid, I committed fix to trunk. Committed revision 35443.

I just wonder whether same applies to SpamAssassin too...

it appears to be a bit different.  It looks like the code makes attempts to pass parameters to spamassassin to insure that the return response(s) are of the appropriate type being checked for.  

My guess based on a quick look is that things are OK -- the only way to be sure is to have someone who uses it setup the appropriate debug params and validate the output of the debug macro

#define d(x) (camel_debug("junk")?(x):0)

messages created.  It looks like output from invocations of the above is the only place that the response is noted

if (em_junk_sa_use_spamc && em_junk_sa_use_daemon) {
	out = g_byte_array_new ();
	argv[i++] = em_junk_sa_spamc_binary;
	argv[i++] = "-c";
	argv[i++] = "-t";
	argv[i++] = "60";
	if (!em_junk_sa_system_spamd_available) {
		argv[i++] = "-U";

		pthread_mutex_lock (&em_junk_sa_preferred_socket_path_lock);
		socket_i = i;
		argv[i++] = to_free = g_strdup (em_junk_sa_get_socket_path ());
		pthread_mutex_unlock (&em_junk_sa_preferred_socket_path_lock);
	}
} else {
	argv [i++] = "spamassassin";
	argv [i++] = "--exit-code";
	if (em_junk_sa_local_only)
		argv [i++] = "--local";
}

rv = pipe_to_sa_full (msg, NULL, argv, 0, 1, out, &target->error) != 0;

if (!rv && out && !strcmp ((const char *)out->data, "0/0\n")) {
	/* an error occurred */
	if (em_junk_sa_respawn_spamd ()) {
		g_byte_array_set_size (out, 0);

		pthread_mutex_lock (&em_junk_sa_preferred_socket_path_lock);
		g_free (to_free);
		argv [socket_i] = to_free = g_strdup (em_junk_sa_get_socket_path ());
		pthread_mutex_unlock (&em_junk_sa_preferred_socket_path_lock);

		rv = pipe_to_sa_full (msg, NULL, argv, 0, 1, out, &target->error) != 0;
	} else if (!em_junk_sa_use_spamc)
		/* in case respawning were too fast we fallback to spamassassin */
		rv = em_junk_sa_check_junk (ep, target);
}

d(fprintf (stderr, "em_junk_sa_check_junk rv = %d\n", rv));