quirks with pm-lib pm-jamime-kill.rc

A few days ago I installed from sourceforge procmail-lib-2004.1216/lib
(with procmail 3.22 bundled with SuSE Linux 9.2) as I was looking for
something which could get rid of those annoying HTML attachments which
some people generate together with the plain text mail body (educating
people not to send them seems a lost cause).

I inserted the call to pm-jamime-kill.rc at some position (before the
spam checking and whitelist processing) in my own set of procmail
recipes, http://sax.iasf-milano.inaf.it/~lucio/Procmail/

I noticed three quirks, two of them I solved but the third remains.

(*) the first quirk is that apparently pm-jamime-kill.rc wasn't
triggered unless I explicitly preceded it with a setting of
JA_MIME_TYPE = "text/html" on Content-Type (as in the example in the
documentation)

with this a "plain" text+html message is handled correctly
(attachment removed and kwd X-Mime-Type-Killed inserted, which I
configured my pine to make visible). Also some "complex" messages
text+html+something else are also handled correctly (attachment
replaced by a null text attachment ... I'd prefer a keyword, but
can live with the null attachment).

(*) the second quirk is that some of the messages I tested (thing with
legitimate attachments, e.g. text+pdf) pass through intact, but the
following messages appear in the procmail log (might be slightly
inconvenient for the crontab which handles the log)

procmail: Skipped "0"
procmail: Skipped "* ^Content-Type:.*image/()\/(jpeg|tiff|png|gif|bmp)"
procmail: Skipped "{"
procmail: Closing brace unexpected

This was cured replacing "0" with ":0 E" at line 377 of
pm-jamime-kill.rc

(*) the third quirk still occurs. In some cases I get the following
log messages

/bin/sh: mimencode: No such file or directory
procmail: Program failure (127) of "mimencode"
procmail: Rescue of unfiltered data succeeded

There is no program called "mimencode" on my system, nor in the
SuSE 9.2 distribution.

I'm afraid this could cause data loss. I suspect the messages
affected are mostly spam anyhow, but I'm quite sure a legitimate
one was affected. Of course I cannot reproduce it since the
original message is lost.

I was able to reproduce it forwarding to me a message from an old
folder, which my pine attachment index shows as

1.1 55 lines Text/PLAIN
1.2 42 lines Text/HTML (charset: UTF-8 "Internet-standard
Unicode")
2 ~576 lines Text/PLAIN (charset: UTF-8 "Internet-standard
Unicode") (N

Here I'd expect 1.2 to be removed, and 2 to remain (it was actually
the main data file). Instead after seeing the log messages quoted
above, only 1.1 survives.

What's happening here and what's the easiest way out ? What's the
purpose of this mimencode and does it exist in binary form for SuSE ?
Or can I just replace it's definition in pm-javar.rc with something
trivial like a plain "cat" ?

--
------------------------------------------------------------ ----------
nospam@mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

Re: quirks with pm-lib pm-jamime-kill.rc

On Wed, Feb 15 2006, LC's NoSpam Newsreading wrote:

> A few days ago I installed from sourceforge procmail-lib-2004.1216/lib
> (with procmail 3.22 bundled with SuSE Linux 9.2) as I was looking for
> something which could get rid of those annoying HTML attachments which
> some people generate together with the plain text mail body (educating
> people not to send them seems a lost cause).
>
> I inserted the call to pm-jamime-kill.rc at some position (before the
> spam checking and whitelist processing) in my own set of procmail
> recipes, http://sax.iasf-milano.inaf.it/~lucio/Procmail/
>
> I noticed three quirks, two of them I solved but the third remains.

[snip]
> (*) the third quirk still occurs. In some cases I get the following
> log messages
>
> /bin/sh: mimencode: No such file or directory
> procmail: Program failure (127) of "mimencode"
> procmail: Rescue of unfiltered data succeeded
>
> There is no program called "mimencode" on my system, nor in the
> SuSE 9.2 distribution.

You need to install metamail, which includes mimencode.

[snip]
> What's happening here and what's the easiest way out ? What's the
> purpose of this mimencode and does it exist in binary form for SuSE ?

Mimencode is a program for translating between different mail oriented
encoding formats defined by MIME, such as base64 and quoted-printable.

I would think it would be standard on most distributions.
--
Neil.
Hire the morally handicapped.

Re: quirks with pm-lib pm-jamime-kill.rc

On Wed, 15 Feb 2006, Neil Woods wrote:
> On Wed, Feb 15 2006, LC's NoSpam Newsreading wrote:

[about pm-jamime-kill.rc]

> > (*) the third quirk still occurs. In some cases I get the following
> > log messages
> >
> > /bin/sh: mimencode: No such file or directory

> You need to install metamail, which includes mimencode.
> I would think it would be standard on most distributions.

OK, thanks, metamail is in the SuSE distribution. I installed it, and
now I do not get the error messages any more ... but ...

.... pm-jamime-kill.rc is still processing incorrectly my test file
(a mail I received which consists of three parts

1.1 55 lines Text/PLAIN
1.2 42 lines Text/HTML (charset: UTF-8 "Internet-standard Unicode")
2 ~576 lines Text/PLAIN (charset: UTF-8 "Internet-standard Unicode")

both sections 1.2 and 2 are stripped off, while I'd expect only 1.2 to
be removed.

The same occurred to me when I replaced the macro MIME_BIN_QP (which in
pm-jamime-kill.rc is the one invoking mimencode) with an invocation of
"cat", or when I commented out the "&qp" section completely.

So it was not the absence of mimencode, but something which occurs
before. I'm afraid /pm-jamime-kill.rc is confused by the nested
structure of the message ... I report the relevant stuff below :


Content-Type: multipart/mixed; boundary="=-41vKaU75peBZ1bz9kW2h"
--=-41vKaU75peBZ1bz9kW2h
Content-Type: multipart/alternative; boundary="=-jesLdzyUZYDAnshpxTkZ"
--=-jesLdzyUZYDAnshpxTkZ
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

body of message, preserved

--=-jesLdzyUZYDAnshpxTkZ
Content-Type: text/html; charset=utf-8

body of html to be eliminated

--=-jesLdzyUZYDAnshpxTkZ--

--=-41vKaU75peBZ1bz9kW2h
Content-Disposition: attachment; filename=xmds_brera_swire.tbl
Content-Type: text/plain; name=xmds_brera_swire.tbl; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

body of text file INCORRECTLY deleted

--=-41vKaU75peBZ1bz9kW2h--

--
------------------------------------------------------------ ----------
nospam@mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

Re: quirks with pm-lib pm-jamime-kill.rc

LC's NoSpam Newsreading account writes:

> A few days ago I installed from sourceforge procmail-lib-2004.1216/lib
> (with procmail 3.22 bundled with SuSE Linux 9.2)

Is possibly could you verify if the bug appears in latest code, which
is in the CVS.

http://sourceforge.net/cvs/?group_id=11052

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pm-lib login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pm-lib co pm-lib

> procmail: Skipped "0"
> procmail: Skipped "* ^Content-Type:.*image/()\/(jpeg|tiff|png|gif|bmp)"
> procmail: Skipped "{"
> procmail: Closing brace unexpected

[snip]

Procmail isn't particular effective tool for MIME, due to MIME's
complexity that would require higher level language like Perl or
Python.

I'll take a look what I can do with your test example soon.

Jari