########################################################################## ########################################################################## stripmime - by Adam Glass modified by Dave Sherohman Current version: 0.8.3a-dps, 8/18/2000 ########################################################################## ########################################################################## In this document: - FIRST THINGS FIRST - WHAT IS STRIPMIME? - COMMAND LINE ARGUMENTS - KNOWN BUGS - FEEDBACK? - LICENSE ------------------ FIRST THINGS FIRST ------------------ If you've downloaded a previous version of stripmime, please read the CHANGES file. There have been some pretty major changes in recent versions. And if you're actually planning on using stripmime for anything, READ THIS WHOLE DOCUMENT. There are all sorts of quirks and bugs and problems that you'll want to know about before you let stripmime anywhere near your data. ------------------ WHAT IS STRIPMIME? ------------------ stripmime is a quick and dirty Perl script to strip MIME sections out of email messages. In case it isn't plainly obvious what I mean when I say "quick and dirty", here's what you should expect: - MIME processing software that was written by someone who hasn't ever read even a single page of ANY of the MIME RFCs. No joke! Trust this software accordingly! (I.e., DON'T.) - Software that *seems* to work but might have major bugs, lose or destroy data, etc. - The assumption that the user knows what (s)he's doing with MIME, Perl, procmail, regexps, etc. (You weren't expecting real documentation, were you?) - Code that might or might not comply with the MIME specification (though it gets closer with every release.) And yet, if you really do know what you're doing with MIME and/or Perl, you could probably rewrite stripmime in an hour or two and have it work better and faster. In which case, go do that; the code I wrote is hideous. But if you don't, please please please provide me with bug reports, feedback, etc. And when you are reporting problems, please send me a copy of whatever message stripmime failed on. Finally, if you do plan to use stripmime (eeek!), check the download site regularly -- I'm actively fixing bugs and reposting fixed code. Stripmime does not let you do anything useful with the MIME components in messages -- it filters them out. If you want to *do* something with the MIME attachments, use something like metamail or write your own utility. Stripmime makes MIME *go* *away*. This is not SAVEmime, it's STRIPmime. (Though with the -m command line flag which you'll see below, it will rewrites the message to look like a text/plain only message.) I wrote stripmime because I got tired of having email messages clogged up with MIME junk. Particularly on the mailing lists I run. You will probably want to use stripmime with something like procmail, since, at present, it can only act as a filter. STDIN -> stripmime -> STDOUT. Hypothetical usage in a procmail recipe might be something like: :0 * ^Content-Type: .* { :0 f | /path/to/stripmime :0: $mailbox } Hypothetical usage in a sendmail/majordomo mailing list might be something like: mailing_list: "|/path/to/stripmime|/path/to/majordomo/wrapper -l list" NOT that either usage is guaranteed to work in (m)any installations. You are STRONGLY advised to do your own testing before actually using stripmime. This is alpha-test quality software here, folks. Bugs! Lots of 'em! No joke! ---------------------- COMMAND LINE ARGUMENTS ---------------------- I didn't specify any of them in the examples above, but stripmime has a bunch of wonderful options, and if you manage to lose this document, type "stripmime --help" and it will happily tell you all about them. But since you actually took the time to read this "readme" document (pretty bored, huh?), I may as well tell you about the options here, too... As the --help text says: usage: ./stripmime [--help] [--version] [-mhc] [-ief ] Expects an email message on STDIN and echoes the email to STDOUT except for MIME attachments. Options: -i -- comma-separated MIME types to include in output -e -- comma-separated MIME types to exclude from output -f -- comma-separated MIME types to "forward" (prepend "> ") -b -- echo the non-MIME part of the message body (default ignores it) -m -- echo MIME separators and message/section header info (default won't) -r -- print a warning when stripmime removes a MIME section from the message -R -- print a warning when stripmime removes a named MIME section -h -- doesn't echo the message headers (default will) -c -- only echo basic headers in forward (-f) MIME types (overridden by -m) (etc) If you want stripmime to pass through text/plain only, you don't actually need to call it with any arguments. By default, text/plain and message/delivery-status are passed through to standard out. If you'd also like to pass text/html, you'd do something like this: ____________ % stripmime -i text/html the_output Any other MIME types that appeared in the input stream (e.g., text/rastafarian) wouldn't be passed through to standard out. If you want to include the text/html stuff like in the previous example, but you DON'T want text/plain, you can remove it with: _____________ % stripmime -i text/html -e text/plain the_output The -m option will cause the output to include important MIME headers and boundary markers and other stuff that will keep the message looking MIMEy. Not that leaving it all MIMEy is the point of stripmime, but, hey, you're the boss. Using -m with -f will produce results that any well-written MIME-processor should probably vomit on. More on -f later. The -r option will cause stripmime to insert a message into the output stream announcing when it removes a MIME type, while -R will print announcements only when removing a MIME section with a name. If you want to customize this announcement, it appears around line 26 in the code. The string "{}" in the template variable ($pr_template) is replaced with the MIME type that was replaced. If you don't want to announce the type, don't put "{}" in the template. If you want it to span multiple lines or mention the MIME type repeatedly, use \n and extra "{}" strings as needed. Knock yourself out. If "SECTION" appears in the template string, it will similarly be replaced with the name of the MIME section whose removal is being announced (or with nothing if the section doesn't have a name). This can produce nonsensical output if "SECTION" is used with -r instead of -R. I can't imagine why you'd want to do this, but if you don't want stripmime to print out the message's headers, use -h and it won't. Know those annoying non-MIME sections in MIME messages? The ones that say things like, "This message contains MIME data, but your mail reader is too stupid to know that." Stripmime gets rid of that crap now, but if you really like it, use the -b flag, and it won't. Before I explain what -c does, let me explain -f... -f is sort of like -i, except that instead of merely echoing those MIME types to standard out, it will tack a "> " onto the beginning of each line. So if you're annoyed that Netscape Messenger users' forwarded messages appear as a separate MIME type of message/rfc822, you could use -f to have that converted into something that looks better. _________________ % stripmime -f message/rfc822 the_output Actually, you don't even need to do that, 'cuz message/rfc822 is a special type (like text/plain) that's included by default. The only difference is that there's an implicit -i on text/plain, and an implicit -f on message/rfc822. If you don't like that, do -e on one or both of them, or change the default behavior in the code. See if I care. Now that I've explained -f, I can tell you about -c. In a -f forwarded message, if you don't want all of the headers in the forwarded message, using -c will trim the forwarded message's headers down to just: To, From, Date, Subject, and Cc. Nifty! And, by the way, the MIME type arguments are just comma-separated lists, so you can also do stuff like the following: ___________________________________ % stripmime -i text/html,text/braille,audio/mp3 the_output In other words, include all three types. I suggest you grab a couple of MIME-infested email messages and pipe them through stripmime to get the hang of things (and maybe catch some of the more obvious bugs) before you put it to use for anything. ---------- KNOWN BUGS ---------- I suspect there are a lot that I don't know about, but I haven't been able to find them. Hmm, maybe that's a tautology. Still, be careful. The ones I DO know about: - stripmime breaks if it sees messages with cr/nl terminated lines - stripmime may or may not handle 8-bit ISO characters well - with multipart/* messages, the -i/-e/-f command line arguments will be applied to inner MIME subsections of the outer multipart/* type, which maybe shouldn't happen, or maybe is correct & good. --------- FEEDBACK? --------- Questions? Comments? If you have more to say than just "you write shitty Perl code", send me email at adam@clarity.net. I know I can't write code for shit. That's why I'm not a programmer. ------------ LICENSE: GPL ------------ Finally, this is all covered under the GNU Public License, so, um, don't go selling it, or whatever it is that the GPL prohibits you from doing. Go read the details at: http://www.gnu.org/copyleft/gpl.txt