MIME-CONSTRUCT(1p) | User Contributed Perl Documentation | MIME-CONSTRUCT(1p) |
mime-construct - construct and optionally mail MIME messages
mime-construct switch...
Sorry, it's hard to provide a meaningful synopsis. See the examples.
mime-construct constructs and (by default) mails MIME messages. It is entirely driven from the command line, it is designed to be used by other programs, or people who act like programs.
These arguments add text to the top-level header of the message, or control who it gets sent to.
This switch passes the -t switch to sendmail (mime-construct doesn't try to parse the headers you provide), so it doesn't really do anything if you're not mailing the message.
It's okay if you specify the --multipart type but the message turns out to be a single part, the type you supply will just be ignored.
There isn't 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.
It's okay if you specify the --prelude but the message turns out to be a single part, the prelude you supply will just be ignored.
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 doesn't make sense to use them without a following part, so mime-construct will sputter and die if you try to do that.
Using --attachment name does not cause mime-construct 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).
You might prefer to use the --file-attach switch, which does read from the named file.
The data you supply mustn't be encoded already, mime-construct will encode it according to the type you specify here. Valid encodings are 7bit, 8bit, binary, quoted-printable, and base64. It's easy to generate an illegal MIME message by specifying the encoding yourself.
You might prefer to use the --file-auto or --file-attach switches, which set the --type automatically based on a file's name.
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 isn't to be multipart).
--file-auto causes the Content-Type to be set based on the file's name, if possible.
--file-attach does that and sets the --attachment name as well.
Be sure to include the trailing newline on str unless there really isn't 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).
--attach is an alias for --file-attach, and --body is an alias for --string.
Normally the path or str will have been generated by a different invocation of mime-construct which was given the --subpart switch.
Arguments to switches which take a file name (such as --file and --subpart-file) can have some magic. If there is no file with the path supplied a regular Perl open() is done on it. See "EXAMPLES".
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 -
Send a plain text part and attach a file, setting the file's content type and --attachment name automatically.
mime-construct --to "$recip" --subject "$file" \ --string "Here's the file I told you about.$nl" \ --file-attach "$file"
Most people think of attachments as multipart messages, but they don't 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 Perl's open() when constructing file names. Eg, you can run processes XXX bad examples, there's 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.
Here's an example of using a separate invocation of mime-construct 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 mime-construct "--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 mime-construct to construct 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 you've got.
The code is licensed under the GNU GPL. Check http://www.argon.org/~roderick/ for updated versions.
Roderick Schertler <roderick@argon.org>
2023-01-06 | perl v5.36.0 |