|<B>--debugB>||Turn debugging on.|
|<B>--helpB>||Show the usage message and die.|
|<B>--outputB>||Dont mail the generated message, print it to stdout instead. This loses <B>--bccB> info.|
|<B>--subpartB>||Generate a subpart which can be used in another MIME message, rather than a top-level MIME message itself. This turns on <B>--outputB> and changes some internal semantics a bit. See the examples.|
|<B>--versionB>||Print the version and exit successfully, if this is the only arg. Otherwise, print the version and die.|
These arguments add text to the top-level header of the message, or control who it gets sent to.
<B>--bccB> address Add address to the recipient list. This doesnt actually add anything to the header, of course. If youre not actually mailing the message (if you use <B>--outputB> or <B>--subpartB>) <B>--bccB> will have no effect. <B>--ccB> address Add an address to the <B>Cc:B> list. <B>--embedded-toB> Send the message to the recipients already listed in the header, in addition to those given with <B>--toB>, <B>--ccB>, and <B>--bccB>. This makes sense if you use the <B>--headerB> switch to add your own <B>To:B> or <B>Cc:B>. In this case you probably dont want to use <B>--toB> or <B>--ccB> because they would create new headers rather than adding to the ones already in the message. <B>--headerB> str Add arbitrary text to the header. The str can be anything you like, including multiple lines. You can create invalid messages this way. If you include a blank line in the str youll really screw up the message. <B>--multipartB> str This specifies the multipart content type and options. The default is multipart/mixed. Dont include a boundary setting, thats supplied by <B>mime-constructB>. <B>--preludeB> str This adds str to the multipart prelude text. If you specify <B>--preludeB> multiple times the strs will all be concatenated.
There isnt any default for this text. It seems to me that nowadays adding an explanation of MIME to the beginning of a message is like explaining how to use a seat buckle to people who are riding in an airplane.
<B>--subjectB> str Specify the subject for the message. <B>--toB> address Add an address to the <B>To:B> list.
These switches control the per-part headers. If the message turns out not to be multipart they actually add data to the top level header.
Each of these applies only to the next part output. After each part is output they are reset to their default values. It doesnt make sense to use them without a following part, so <B>mime-constructB> will sputter and die if you try to do that.
<B>--attachmentB> name This adds a Content-Disposition: attachment header with the given name as the value of the filename attribute. Its just a convenience, since <B>mime-constructB> is often used to send files as attachments.
Using <B>--attachmentB> name does not cause <B>mime-constructB> to read any data from the file called name! It just uses that name in the header. The actual data which will go into this part of the message comes from one of the regular part output switches (given below).
<B>--encodingB> type This specifies the type of encoding you want this part to use. You normally shouldnt use this switch, though. If this switch isnt used <B>mime-constructB> will choose an appropriate encoding.
The data you supply mustnt be encoded already, <B>mime-constructB> will encode it according to the type you specify here. Valid encodings are <B>7bitB>, <B>8bitB>, <B>binaryB>, <B>quoted-printableB>, and <B>base64B>. Its easy to generate an illegal MIME message by specifying the encoding yourself.
<B>--part-headerB> str Add arbitrary text to the per-part header. The str can be anything you like, including multiple lines. You can create invalid messages this way. If you include a blank line in the str youll really screw up the message. <B>--typeB> type Specify the content type for this part. If you dont specify a <B>--typeB> it defaults to text/plain. The type you supply can contain not only the type proper but also options. The whole thing will just be plopped onto the end of Content-Type: and stuck into the header.
These switches add data to the body of the message. You use one of these for each for each part of a multipart message (or just one of them if the message isnt to be multipart).
Arguments to switches which take a file name (such as <B>--fileB> and <B>--subpart-fileB>) can have some magic. If there is no file with the path supplied a regular Perl open() is done on it. See EXAMPLES.
<B>--fileB> path <B>--file-autoB> path <B>--file-attachB> path <B>--attachB> path <B>--stringB> str <B>--bodyB> str Use the contents of the file path or the literal string str as the body of this part.
Be sure to include the trailing newline on str unless there really isnt supposed to be one. If you leave the trailing newline off the part will have to be encoded in base64 (because quoted-printable has an artificial limitation which prevents it from being able to encode such a data stream).
<B>--subpart-fileB> path <B>--subpart-stringB> str Use either the contents of path or str itself as the body of this part, but treat it as a subpart. This means that the data contains both some headers and some text. It also means that you cant use <B>--typeB> or <B>--encodingB> for this part.
The examples assume that $nl contains a newline. The other variables used are I hope self-explanatory.
Send a simple message.
mime-construct --to "$recip" --subject hi there --string "$body"
Send a message which is read from stdin.
fortune | mime-construct --to "$recip" --subject fortune --file -
mime-construct --to "$recip" --subject "$file" \ --string "Heres the file I told you about.$nl" \ --file-attach "$file"
Most people think of attachments as multipart messages, but they dont have to be. This generates a zip of all the files in the current directory and sends them as an attachment but as a single part message.
zip -q - * | mime-construct --to "$recip" --subject zipped directory \ --attachment dir.zip --type application/zip --file -
You can use the full expressiveness of Perls open() when constructing file names. Eg, you can run processes XXX bad examples, theres no file names
mime-construct --to "$recip" --subject "$subject" \ --string "Here are those two files you wanted.$nl" \ --type application/x-gzip --attachment file1.gz --file gzip -c file1 | \ --type application/x-gzip --attachment file1.gz --file gzip -c file2 |
or read from alternate file descriptors (<&=4 to read from file descriptor 4) or whatever. See perlopentut for a tutorial.
Heres an example of using a separate invocation of <B>mime-constructB> to create a subpart. This creates a message which has two parts at the top level. The first part is some text, the second part is a digest. The digest itself is a multipart message which contains a number of message/rfc822 parts.
msg_args= for msg in $msg_list do msg_args="$msg_args --type message/rfc822 --file $msg" done set fnord for recip in $recip_list do set "$@" --bcc $recip done shift mime-construct --subpart --multipart multipart/digest $msg_args | mime-construct \ --header "To: Digest recipients:;$nl" \ --subject Foo digest \ "$@" \ --file "$introduction" \ --subpart-file -
Here is how to send an encrypted messages (multipart/encrypted, as defined in RFC 1847). You use <B>mime-constructB> --subpart to generate the real message you want to send (which can be kind of MIME message non-text, multi-part, what have you), then encrypt that and use another <B>mime-constructB> to contruct and send the multipart/encrypted message which contains it.
enc_type=application/pgp-encrypted enc_params="Version: 1$nl" mime-construct --subpart --file body --file-auto image.jpg | gpg --encrypt --armor -r "$recip" | mime-construct --output \ --to "$recip" \ --subject "$subject" \ --multipart "multipart/encrypted; protocol=\"$enc_type\"" \ --type "$enc_type" \ --string "$enc_params" \ --type application/octet-stream \ --file -
The body of the message is always held in memory, so you can expect problems if you work with bodies which are large compared to the amount of memory youve got.
The code is licensed under the GNU GPL. Check http://www.argon.org/~roderick/ for updated versions.
Roderick Schertler <email@example.com>
|perl v5.20.3||MIME-CONSTRUCT (1)||2010-06-23|