Sebastian Drude <sebadru(_at_)zedat(_dot_)fu-berlin(_dot_)de> writes:
There's a problem with the solution suggested by David, it seems to
me:
If any kind of additional part qualifies as a file attachment,
perhaps this will do the job:
:0
* HOST ?? server_that_should_handle_only_single-part_messages
* ^Content-Type:.*multipart
! $LOGNAME(_at_)other(_dot_)server
I get many messages from public free mailing-space such as hotmail.
The text of those messages is sent two times within the message --
once in an HTML-version and once as plain text.
...
Coming back to the point: As the two versions of what I would call the
body of the mail are treated as different parts, all these messages
have a header-line that maches "^Content-Type:.*multipart", although
only some of them have an attachment proper.
This is where the MIME subtype comes in. When a content is sent in
multiple forms, such as both plain text and html, it is sent with
content-type multpart/alternative. A MUA is supposed to select one of
the parts that it knows how to display and just display it, ignoring the
others. If it knows how to display more than one of the sub-contents it
should prefer the last of them, as they are supposed to be ordered in
increasing faithfulness to the original data (thus a text/plain content
will generally appear before a text/html content).
On the otherhand, a multipart/mixed content is composed of several
independent contents that are to be presented in serial order
(simultaneous presentation is implied by the multipart/parallel
content-type). At the present time, when people speak of a message with
an attachment, they generally mean that the top-level content-type is
multipart/mixed, the first subcontent of which is a 'textual' content
(possibly in the form of a multipart/alternative containing text/plain
and text/html typed contents). The second and following subcontents are
then the 'attachments'.
So, if you want to forward messages that contain 'attachments', you need
to check for a content-type of multipart/mixed:
:0
* HOST ?? server_that_should_handle_only_single-part_messages
* ^Content-Type:.*multipart.*mixed
! $LOGNAME(_at_)other(_dot_)server
(By the way, as I use the good old text-oriented pine for reading my
mail, I would really love to get rid of the html-part, it seems to be
an unnecessary waste of net ressources and disk space anyway...
Deleting the html-part within pine when saving it to a specific folder
makes the message contain only an indication of an "attachment", wich
is the plain text, and I have to open the body separetedly --
ennerving... I havn't set up procmail for pre-filtering the mail yet
:-<, also because I like to have the "answer"-flag set before saving
the message to the final folder for not loosing control -- is there a
smart way to get this done automatically by procmail?...)
Well, you could write a perl (or python, or whatever) program that when
feed a message containing multipart/alternative contents would replace
them with their simplest subcontent. Unfortunately, I don't know of
such a program. While not trivial to write, the various MIME::* modules
should handle the input/output side. Hmm, let's see:
#!/usr/bin/perl
use MIME::Parser;
my $p = new MIME::Parser;
$e = $p->read(\*STDIN) or die "$0: couldn't parse MIME stream";
recurse($e);
$e->print(\*STDOUT) or die "$0: couldn't spew MIME stream";
sub recurse {
my($ent) = @_;
my(@parts);
return unless $ent->is_multipart; # Just in case
@parts = $ent->parts;
if ($ent->mime_type ne "multipart/alternative") { # simply recurse
foreach (@parts) {
next unless $_->is_multipart;
recurse($_);
}
} else { # replace with the first subpart
$ent->parts($parts[0]);
$ent->make_singlepart;
}
}
__END__
If I read the manpages correctly, that should work. Of course, I
haven't fed it to perl _at_all_, much less tested it, so don't just put
it in place without trying it out on expendable messages first.
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail