Multipart MIME

[Jamie Paul Griffin]

Hi

Does anyone have or know of a perl or python script, or even a shell
script, that removes the multipart/(mixed|alternative| ... ) parts of
incoming mail and leaves or converts the message into plain text?

Also, i wouldn't want to lose any attachments that people might send me.
I have looked and looked on google, found loads of scripts but none them
quite seem right. I just wondered if anyone on this list might have
written or use a script like this. Ideally, i'd like to put it into a
procmail recipe. 

Jamie.

Re: Multipart MIME

[Joerg Dorchain]

On Mon, Nov 26, 2012 at 09:57:33AM +, Jamie Paul Griffin wrote:
> 
> Does anyone have or know of a perl or python script, or even a shell
> script, that removes the multipart/(mixed|alternative| ... ) parts of
> incoming mail and leaves or converts the message into plain text?

I have two scripts for that. Both are not perfect and sometimes
eat mails or attachments, esp. from MUAs with certain bugs
(specifically Apple mail, html, and attachments are a known
culprit)

The effect comes from inherently from the way is works, it parses
the mime-structures and recreates it, thereby not necessarily
groking all unknowns.

Bye,

Joerg

a) remove text/html part from maultipart/alternativ
# Clean MIME mails
:0 fhbw
* ^Content-Type:.*multipart/
# Apple mail attachment bug
* ! ^X-Mailer: Apple Mail
| fixmail.pl


#!/usr/bin/perl -w
#
# This is a mail filter. Takes multipart from STDIN, deletes
# superfluous MIME-parts and reduces multipart/alternative to
# singlepart, finally writes cleaned MIME mail to STDOUT.
#
# By Boris 'pi' Piwinger <3...@piology.org>. Please let me know if you
# improve it or fix bugs.
#
# Based on tinnef.pl (there is not much left, though;-) by Gerd Knorr
# . Get it there: http://www.ch-open.ch/~cho13093/
#
# This code is public domain. It comes with absolutely no warranty.
# If it eats your mails for lunch, that's your problem. If you don't
# like this, don't use it.
#
# Best with Procmail, e.g.:
#
# # Clean MIME mails
# :0
# * ^Content-Type:.*multipart/
# {
#   :0c:
#   tmp/fixmail
#   :0fhbw
#   | fixmail.pl
# }

# Save the From line
my$from = ;
# Create parser, we are being daring here (huge mails might cause problems)
use MIME::Parser;
my$done="";
my$parser=MIME::Parser->new;
$parser->output_to_core(1);
my$top=$parser->read(\*STDIN) or die "Couldn't parse MIME stream.\n";
$top=&analyze($top);
$top->head->add('X-pi-MIME-Parts-removed',$done) if $done;
$top->sync_headers(Length=>'COMPUTE');
# Print From line
print $from;
$top->print(\*STDOUT);
exit 0;

sub analyze {
  my($body,$i)=(@_,0);
  my($parts)=$body->{ME_Parts};
  if ($body->mime_type eq "multipart/alternative") {
# Reduce multipart/alternative
$i=-1;
$i++ until ($$parts[$i]->mime_type eq "text/plain" || $i==$#{$parts});
if ($$parts[$i]->mime_type eq "text/plain") {
  @$parts=@$parts[$i];
  $done.=" multipart/alternative";
}
  } else {
# Kill superfluous junk:
# - text/x-vcard
# - application/x-pkcs7-signature
# - application/ms-tnef
# Recursion on multipart
while ($i<=$#{$parts}) {
# try pkcs7 for a while (mutt supports it now)
#  if ($$parts[$i]->mime_type =~ 
/(text\/x-vcard|application\/(?:x-pkcs7-signature|ms-tnef))/) {
  if ($$parts[$i]->mime_type =~ /(text\/x-vcard|application\/(?:ms-tnef))/) 
{
$done.=" $1";
splice(@$parts,$i,1);
  } elsif ($$parts[$i]->mime_type =~ /^multipart\//) {
$$parts[$i]=&analyze($$parts[$i]);
$i++;
  } else {$i++}
}
  }
  $body->{ME_Parts}=$parts;
  if ($body->mime_type =~ /^multipart\/related/ && 
$body->head->mime_attr("content-type.type") eq "multipart/alternative")
{$body->head->mime_attr("content-type.type" => "text/plain")}
  $body->make_singlepart if $body->parts==1;
  return $body;
}

b) adds a plain/text part to html-only mails
# Add text/plain
:0 fhbw
* ^Content-Type:.*text/html
| addtext.pl


#!/usr/bin/perl -w

# This is a mail filter. Takes a mail from STDIN,
# adds a text/plain section to every text/html not in
# multipart/alternative, finally writes cleaned MIME mail to
# STDOUT.
#
# text/plain is generated by lynx -dump
#
# TODO: fix charset
#
# Inspired by fixmail.pl by Boris 'pi' Piwinger
# <3...@piology.org>
# 
# (c) Joerg Dorchain 
# This code is public domain. It comes with absolutely no warranty.
# If it eats your mails for lunch, that's your problem. If you don't
# like this, don't use it.
#
# Best with Procmail, e.g.:
#
# # Add text/plain
# :0
# * ^Content-Type:.*text/html
# {
#   :0c:
#   tmp/addtext
#   :0fhbw
#   | addtext.pl
# }



use IPC::Run qw(run);

# Save the From line
my $from = ;

# Create parser, we are being daring here (huge mails might cause
# problems)
use MIME::Parser;
my $done="";

my $parser=MIME::Parser->new;
$parser->output_to_core(1);
my $top=$parser->read(\*STDIN) or die "Couldn't parse MIME stream.\n";

$top = &analyse($top);
$top->head->add('X-JD-Mime-Part-added',$done) if $done;
$top->sync_headers(Length=>'COMPUTE');

# Print From line
print $from;
$top->print(\*STDOUT);
exit 0;

sub analyse {
my ($top) = (@_);

if ($top->is_multipart) {
  my ($i,$ti,$hi);
  my ($parts) = $top->{ME_Parts};
  for($i = 0; $i < $#{$parts}; $i++) {
if ($top->effective_type ne "multipart/alternative") {
  $$parts[$i] = &analyse($$parts[$i]);
} else {
  if ($$parts[$i]->effective_type eq "text/plain") { $ti = $i; }
  if ($$parts[$i]->effective_type eq "text/html") { $hi = 

Re: Please set your line wrap to a sane value (was ... Re: Is there any gmane.org user in the list?)

[Chris Bannister]

On Sun, Nov 25, 2012 at 07:14:45PM +, Tony's unattended mail wrote:
> On 2012-11-25, Chris Bannister  wrote:
> >
> > With regards to mailing list posts, which is what the original post
> > of mine was addressing, sending HTML posts is very wasteful. They
> > are archived in various places on the Net, where they are stored for
> > ever and a day. Yeah, yeah, hard disks are cheap etc. etc. etc, but
> > that is not the issue¹.
> 
> "Waste" is something that in itself has no value.  But formatting has
> value added to the presentation.  So it's a stretch to label html as
> "waste", before even discussing the significance of it.

I don't see how an html email adds any value whatsoever to a post on a
software support mailing list. Au contraire, it is a PITA having to deal
with them.

> In the context for which you attempt to make an argument about HTML
> being wasteful, it's quite silly considering how much waste is
> inherent in a mailing list.  Mailing lists distribute the full body of
> each and every message to each and every member -- who will look at
> the headers and decide what to read.

With good trimming practice that, shouldn't be too much of a problem.
Remember, the whole point of the support mailing list's raison d'etre is
to provide support, so I think you are clutching at straws when you
start along that line.

> the tags -- something that actually adds value?  The tags present in
> unread messages are dwarfed by the content in unread messages.

You'll never convince me that an HTML message adds value, sorry.

> One could perhaps make a case that the HTML tags are wasteful from the
> angle that they're not as short as they could be.  But even then
> you're still stepping over dollars to pick up pennies.

Dealing with waste in web pages, is an entirely, completely different
topic and no relevance here. I'm not even going to start on the crap
code that Frontpage produces ... cough, cough, sorry.

> Moreover, text is highly compressible.  So if you're keen to make
> perfection the enemy of availability, you should be on the fringe
> advocating for a binary format and a scheme that distributes headers
> only, until specifically retreived for reading.

Some archives have gzipped monthly downloads, which is a good idea.
With regards to a binary format, I'm not sure if you are joking or not,
but It might be an interesting idea to force everyone to have a pgp key
compress every post and sign it, and if the signature doesn't verify,
reject it? 

Then again, if spammers managed to get hold of people's secret keys, all
hell would break loose. No on second thoughts scrap that.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

New user tagline and signature help

[Chris Willard]

Hello All,

I'm a new mutt user and would like to use random taglines and
signatures.

I have worked out how to use send-hooks to change the signatures but
would like some advice on what scripts/programs are best for creating
the signatures.

Are HTag or signify any good as I have found these via google?

Regards,

Chris

-- 
Chris Willard
ch...@meliser.co.uk

Re: New user tagline and signature help

[Rado Q]

=- Chris Willard wrote on Mon 26.Nov'12 at 14:27:36 + -=

> I'm a new mutt user and would like to use random taglines and
> signatures.
> 
> I have worked out how to use send-hooks to change the signatures
> but would like some advice on what scripts/programs are best for
> creating the signatures.

'fortune'

-- 
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.

Re: Macro doen’t work...?

[Darksair]

On Sun, Nov 25, 2012 at 06:58:00PM -0800, Michael Elkins wrote:
> On Sun, Nov 25, 2012 at 07:13:01PM -0500, Darksair wrote:
> >Possibly a stupid question, but I have a macro to remove all “O” marks
> >
> > macro index "\Co" "~OO" \
> > "Mark all old as read"
> >
> >But when I press ^o, nothing happens?  I’m using Mutt 1.5.21 on a Mac.
>
> That macro works when I try it.  I can suggest a couple of things:

Thanks for your suggestion.  After reading your mail I realized it must
be something outside Mutt.  Then I found this

http://apple.stackexchange.com/q/3253/6921

which says Mac’s TTY ignores C-o by default for some reason.  I unset it
with `stty discard undef', and the macro is working now.

-- 
Darksair
http://darksair.org/
http://twitter.com/#!/Corsair
http://libre.fm/user/Corsair | http://www.last.fm/user/Darksair

Re: Please set your line wrap to a sane value (was ... Re: Is there any gmane.org user in the list?)

[Tony's unattended mail]

On 2012-11-26, Chris Bannister  wrote:
>> "Waste" is something that in itself has no value.  But formatting has
>> value added to the presentation.  So it's a stretch to label html as
>> "waste", before even discussing the significance of it.
>
> I don't see how an html email adds any value whatsoever to a post on
> a software support mailing list. Au contraire, it is a PITA having
> to deal with them.

HTML adds value the same way a large bold font adds value to the
chapter heading of a novel, or the same way monospaced text adds value
to excerpts of literal text within a technical manual.

>> In the context for which you attempt to make an argument about HTML
>> being wasteful, it's quite silly considering how much waste is
>> inherent in a mailing list.  Mailing lists distribute the full body
>> of each and every message to each and every member -- who will look
>> at the headers and decide what to read.
>
> With good trimming practice that, shouldn't be too much of a
> problem.

Trimming is insignificant with respect to the difference in content
text to formatting text.  Trimmed or not, the proportion of formatting
text to content text is static.  Again, you're stepping over dollars
to pick up pennies when you disregard the comparatively collossal
waste of wholly unread messages, vs. the ~1% of unread messages that
would constitude unused formatting.

> Remember, the whole point of the support mailing list's raison
> d'etre is to provide support, so I think you are clutching at straws
> when you start along that line.

Clutching at straws would be to call a few key tags like ""
"significantly wasteful" in a system that has copious waste by 2
orders of magnitude inherent in the design of the distribution.

>> the tags -- something that actually adds value?  The tags present
>> in unread messages are dwarfed by the content in unread messages.
>
> You'll never convince me that an HTML message adds value, sorry.

You're not thinking beyond yourself.  An odd-man-out may not
appreciate having an appropriate combination of both monospaced text
and variable width text in a technical manual, but unfortunately for
you, you cannot claim something lacks value simply because a single
person (yourself) does not find value in it.  You would have to
convince us that *everyone* would not get value in it for it to not
have value.

I may not see value in a particular feature of a language (say a 72
point font), but certainly I realize that the feature may be useful to
someone, and therefore "has value" (perhaps to elderly folks), despite
me personally not getting value from it.

>> One could perhaps make a case that the HTML tags are wasteful from
>> the angle that they're not as short as they could be.  But even
>> then you're still stepping over dollars to pick up pennies.
>
> Dealing with waste in web pages, is an entirely, completely
> different topic and no relevance here. I'm not even going to start
> on the crap code that Frontpage produces ... cough, cough, sorry.

I wasn't talking about web pages.  Since you were not coming up with
any reasonable rationale to consider HTML wasteful, I was giving you
something that was better than the straws you were clutching at.  But
even this more plausible demonstration of HTML waste is still
insignificant with respect to distribution waste.

>> Moreover, text is highly compressible.  So if you're keen to make
>> perfection the enemy of availability, you should be on the fringe
>> advocating for a binary format and a scheme that distributes
>> headers only, until specifically retreived for reading.
>
> Some archives have gzipped monthly downloads, which is a good idea.
> With regards to a binary format, I'm not sure if you are joking or
> not, but It might be an interesting idea to force everyone to have a
> pgp key compress every post and sign it, and if the signature
> doesn't verify, reject it?

No, I was not seriously proposing that as a reasonable way to combat
waste.  It would be foolish to introduce that kind of complexity and
reduced availability to mitigate what you're percieving as "waste".
But as I said, if you're keen to make perfection the enemy of
availability...

I would however support radical and fundamental changes on entirely
different grounds.  Waste would clearly have a back-seat, if it could
manage to merit any consideration at all, with the primary goal being
a means to:

* mitigate spam
* enhance anonymity
* increase participation
* mitigate centralized censorship
* implement community collective scoring/ranking
* empower authors to express better formatting in a way that is
  conducive to higher quality rendering

Re: Please set your line wrap to a sane value (was ... Re: Is there any gmane.org user in the list?)

[Jamie Paul Griffin]

[ Tony's unattended mail Wrote On Mon 26.Nov'12 at 16:59:03 GMT ]

don't you think this discussion has been exhausted to death now? 

It only started out as a request to wrap lines in my email bodies. 

Re: Please set your line wrap to a sane value (was ... Re: Is there any gmane.org user in the list?)

[Jeremy Kitchen]

On Mon, Nov 26, 2012 at 05:14:30PM +, Jamie Paul Griffin wrote:
> [ Tony's unattended mail Wrote On Mon 26.Nov'12 at 16:59:03 GMT ]
> 
> don't you think this discussion has been exhausted to death now? 
> 
> It only started out as a request to wrap lines in my email bodies. 

I do find that part kind of funny.

You were asked to wrap, came up with a reasonable excuse why you
weren't, got a solution in reply and said "ok, thanks, I'll do that".

Three weeks later...

-Jeremy

-- 
.O.Jeremy Kitchen (o_
..O   kitc...@kitchen.io  //\
OOO  twitter.com/kitchen  V_/_


pgpuwH3QNJQBR.pgp
Description: PGP signature

Re: New user tagline and signature help

[Chris Willard]

Hello Rado,

Thanks. I am currently testing it.

Chris

On Mon, 26 Nov 2012, Rado Q wrote:

[snip (8 lines)]> 
> 'fortune'
> 

-- 
Chris Willard
ch...@meliser.co.uk

Re: mutt over hyperterminal

[Linda]

On 11/20/2012 11:30 PM, David Champion wrote:

* On 20 Nov 2012, Linda wrote:

I am dialing in to an ubuntu 12.04 LTS machine that has mutt with
hyperterminal on windows 7. When it displays the index some of the subjects
are garbage characters instead of the subject. I tried set charset=UTF8 and
set charset=ISO-8859-1 but neither solves the problem. Does anyone have a
suggestion on how to get this to work?

I don't use Windows much, but I seem to recall noting that
HyperTerminal's terminal emulation is very bad.  I wish I had facts
rather than anecdote at hand.  But, not meaning to be glib, I'd suggest
trying Putty or Tera Term instead.  Both support serial connections (in
addition to ssh and telnet) and I know that I've used them with success,
though I've forgotten details.

http://the.earth.li/~sgtatham/putty/0.62/htmldoc/Chapter4.html#config-serial
http://en.wikipedia.org/wiki/Tera_Term

Thanks to David and Matthias I now have this working. First 
I used David's links to figure out how to do putty. Once I 
realized all I needed was choose serial and type atdt phone 
number to dial the number and make the connection It worked 
perfectly. Then I used Matthias hint of the LANG variable I 
ran echo $LANG to find out the value and choose it under the 
translate options to set it. Thank you so much for pointing 
me in the right direction.

  Linda

Re: Multipart MIME

[mutt]

Jamie Paul Griffin wrote:

> Hi
> 
> Does anyone have or know of a perl or python script, or even a shell
> script, that removes the multipart/(mixed|alternative| ... ) parts of
> incoming mail and leaves or converts the message into plain text?
> Also, i wouldn't want to lose any attachments that people might send me.
> 
> Jamie.

hi,

i wrote something like that. by default, it converts to text anything
that can be converted to text and deletes everything else but you
can turn off any specific transformation. it can delete specific
mail headers. it translates (most) winmail.dat attachments. if a
transformation fails, it leaves the original in place for safety by
default. it works via procmail on individual messages or it can be
applied to an entire mbox file.

it requires the presence of various utilities (e.g. perl, antiword
or catdoc, xls2csv, lynx, pdftotext and mktemp). you'd probably just
need lynx and mktemp installed.

it is available at:

http://raf.org/textmail/

and its help message is:

usage: textmail [options]
options:
  -h   - Print the help message then exit
  -m   - Print the manpage then exit
  -w   - Print the manpage in html format then exit
  -r   - Print the manpage in nroff format then exit
  -M   - Output in mailbox format
  -T   - Output in raw mail format (for smtp)
  -W   - Don't replace MS Word attachments with text
  -E   - Don't replace MS Excel attachments with csv
  -H   - Don't replace HTML attachments with text
  -R   - Don't replace RTF attachments with text
  -P   - Don't replace PDF attachments with text
  -U   - Don't translate winmail.dat attachments
  -L   - Don't reduce appledouble attachments
  -I   - Don't delete image attachments
  -A   - Don't delete audio attachments
  -V   - Don't delete video attachments
  -X   - Don't delete MS Windows executable attachments
  -B   - Don't recode text that was base64-encoded
  -S   - Don't replace spaces in filenames with underscores
  -Z   - Do translate signed content (discards signatures)
  -O   - Delete all application/octet-stream attachments
  -!   - Delete all application/* attachments
  -D hdrs  - Delete headers (list of header prefixes and filenames)
  -K types - Keep attachments (list of mimetypes and filenames)
  -f   - On translation error, keep translation, not original
  -?   - Print paths of helper applications then exit

Filters a mail message or mbox, replacing MS Word, MS Excel, HTML, RTF and 
PDF
attachments with the plain text contained therein. By default, the following
attachments are also deleted: image, audio, video and MS Windows 
executables.
MS winmail.dat attachments are replaced by any attachments contained therein
which are then replaced by text or deleted in the same fashion. Any of these
actions can be suppressed with the command line options. Mail headers can 
also
be selectively deleted.

it may or may not be quite what you want. without the -H option,
it replaces multipart/aternative where the alternatives are html
and text with just the text part.

you might want to try it with the following options:

:0 fw
| textmail -MWERPIAVXBS

that would only translate html and leave all other attachments as they
are except for winmail.dat attachments. if you want to leave winmail.dat
attachments untranslated as well, add the -U option to the command.

use at your own risk, obviously. :-)

cheers,
raf

Re: Multipart MIME

[Gary Johnson]

On 2012-11-27, mutt wrote:
> Jamie Paul Griffin wrote:
> 
> > Hi
> > 
> > Does anyone have or know of a perl or python script, or even a shell
> > script, that removes the multipart/(mixed|alternative| ... ) parts of
> > incoming mail and leaves or converts the message into plain text?
> > Also, i wouldn't want to lose any attachments that people might send me.
> > 
> > Jamie.
> 
> hi,
> 
> i wrote something like that. by default, it converts to text anything
> that can be converted to text and deletes everything else but you
> can turn off any specific transformation. it can delete specific
> mail headers. it translates (most) winmail.dat attachments. if a
> transformation fails, it leaves the original in place for safety by
> default. it works via procmail on individual messages or it can be
> applied to an entire mbox file.
> 
> it requires the presence of various utilities (e.g. perl, antiword
> or catdoc, xls2csv, lynx, pdftotext and mktemp). you'd probably just
> need lynx and mktemp installed.

Why aren't you all using mutt's built-in ability to select
MIME-type-to-text converters?  There's no risk of losing a message
through improper conversion, you have some limited choice over
conversion methods (depending on whether the message/attachment is
displayed by the pager or via the attachment menu), and since the
message itself is unaffected, you can use different methods of
viewing messages in different environments and at different times as
your methods improve.

Regards,
Gary

Re: Multipart MIME

[mutt]

Gary Johnson wrote:

> On 2012-11-27, mutt wrote:
> > Jamie Paul Griffin wrote:
> > 
> > > Hi
> > > 
> > > Does anyone have or know of a perl or python script, or even a shell
> > > script, that removes the multipart/(mixed|alternative| ... ) parts of
> > > incoming mail and leaves or converts the message into plain text?
> > > Also, i wouldn't want to lose any attachments that people might send me.
> > > 
> > > Jamie.
> > 
> > hi,
> > 
> > i wrote something like that. by default, it converts to text anything
> > that can be converted to text and deletes everything else but you
> > can turn off any specific transformation. it can delete specific
> > mail headers. it translates (most) winmail.dat attachments. if a
> > transformation fails, it leaves the original in place for safety by
> > default. it works via procmail on individual messages or it can be
> > applied to an entire mbox file.
> > 
> > it requires the presence of various utilities (e.g. perl, antiword
> > or catdoc, xls2csv, lynx, pdftotext and mktemp). you'd probably just
> > need lynx and mktemp installed.
> 
> Why aren't you all using mutt's built-in ability to select
> MIME-type-to-text converters?  There's no risk of losing a message
> through improper conversion, you have some limited choice over
> conversion methods (depending on whether the message/attachment is
> displayed by the pager or via the attachment menu), and since the
> message itself is unaffected, you can use different methods of
> viewing messages in different environments and at different times as
> your methods improve.
> 
> Regards,
> Gary

the phrase "the message itself is unaffected" is the main reason.
i wanted to delete/convert the attachments permanently.
what you suggest wouldn't do that.

i was receiving many large emails in my work mailbox at the time.
they were large because they contained many useless attachments.
i wanted to keep the semantic content of the messages and
i wanted to delete the useless parts of the messages.
by doing so, my mailbox was about a tenth of the size it
would otherwise have been.

Re: Multipart MIME

[Jamie Paul Griffin]

[ Gary Johnson Wrote On Tue 27.Nov'12 at  1:10:24 GMT ]

> On 2012-11-27, mutt wrote:

> > i wrote something like that. by default, it converts to text anything
> > that can be converted to text and deletes everything else but you
> > can turn off any specific transformation. it can delete specific
> > mail headers. it translates (most) winmail.dat attachments. if a
> > transformation fails, it leaves the original in place for safety by
> > default. it works via procmail on individual messages or it can be
> > applied to an entire mbox file.
> > 
> > it requires the presence of various utilities (e.g. perl, antiword
> > or catdoc, xls2csv, lynx, pdftotext and mktemp). you'd probably just
> > need lynx and mktemp installed.

Raf and Joerg, thanks both for sharing your scripts. Both seem to do
what I need, i'll give them both a go and let you know. Thank you. 

Raf - does your script require a threaded perl? The default perl
installation on OpenBSD is not threaded, so i'll have to addresss that
if your script does need that.

> 
> Why aren't you all using mutt's built-in ability to select
> MIME-type-to-text converters?  There's no risk of losing a message
> through improper conversion, you have some limited choice over
> conversion methods (depending on whether the message/attachment is
> displayed by the pager or via the attachment menu), and since the
> message itself is unaffected, you can use different methods of
> viewing messages in different environments and at different times as
> your methods improve.
> 
> Regards,
> Gary

Hi Gary, there are 2 reasons for me asking about this; one, is that I do
use mail(1) alot and it lacks some ability to deal with some of the MIME
crap people send. The second is a bit silly really, but I want David's
python script to be able to add an Expires: header to all of my
messages, many of the messages I want to expire, are those I get from
companies like Amazon, and Apple, and Tesco (a horrible big UK company
:-) ) - it is having some trouble dealing with these messages that have
multipart/(mixed|relative|alternative ...) but not all. I just decided I
don't want them like that anyway and i'd like something to place into
procmail that just gets rid of it all. 

I am learning Python and perl - teaching myself at the moment but my
skills in these languages is not yet competent enough to write something
like this. Also, I know that many people over the years will have
experienced the same frsutration with such mail and so if someone has
written some good code to deal with this problem, it is useful for me to
see how they've achieved it and also saves time by not having to rewrite
something that's already been done. I figured, if there's anyone who's
experienced this issue, it'll be someone who is subscribed to this list,
hence me asking here. mutt users tend to people that care about how
their mail is formatted and displayed. 

Best wishes, Jamie. 

Re: Multipart MIME

[Will Yardley]

On Mon, Nov 26, 2012 at 09:57:33AM +, Jamie Paul Griffin wrote:
> 
> Does anyone have or know of a perl or python script, or even a shell
> script, that removes the multipart/(mixed|alternative| ... ) parts of
> incoming mail and leaves or converts the message into plain text?

Have you looked at 'demime' yet?

/w