The second attachment is empty, right? Remove the last boundary. It is followed by nothing, and thus produces an empty attachment.

Wrong way. When avoiding perfectly working modules, one should at least read the relevant RFCs, in this case RFC 2046. It clearly states:

The boundary delimiter line following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter line is identical to the previous delimiter lines, with the addition of two more hyphens after the boundary parameter value.

(Chapter 5.1.1. "Common Syntax", page 20)

So, the code line must be changed from

$smtp->datasend("--$boundary\n");
[download]

to

$smtp->datasend("--$boundary--\n");
[download]

Also, the boundary string should not appear anywhere else in the mail body. RFC 2046 states:

NOTE: Because boundary delimiters must not appear in the body parts being encapsulated, a user agent must exercise care to choose a unique boundary parameter value. The boundary parameter value in the example above could have been the result of an algorithm designed to produce boundary delimiters with a very low probability of already existing in the data to be encapsulated without having to prescan the data. Alternate algorithms might result in more "readable" boundary delimiters for a recipient with an old user agent, but would require more attention to the possibility that the boundary delimiter might appear at the beginning of some line in the encapsulated part. The simplest boundary delimiter line possible is something like "---", with a closing boundary delimiter line of "-----".

And RFC 2045 adds:

Since the hyphen character ("-") may be represented as itself in the Quoted-Printable encoding, care must be taken, when encapsulating a quoted-printable encoded body inside one or more multipart entities, to ensure that the boundary delimiter does not appear anywhere in the encoded body. (A good strategy is to choose a boundary that includes a character sequence such as "=_" which can never appear in a quoted-printable body. See the definition of multipart messages in RFC 2046.)

So, a "good" boundary string contains pseudo-random or hashed data and is not a single word.

Some boundaries found in my inbox:

MIME::Lite constructs a boundary string like this:

# Generate a new boundary to use.
# The unsupported $VANILLA is for test purposes only.

sub gen_boundary {
    return ( "_----------=_" . ( $VANILLA ? '' : int(time) . $$ ) . $B
+Count++ );
}
[download]

(Ignore $VANILLA.) What you get is a fixed string, plus a few concatenated numbers (timestamp, process ID, and a simple counter). Overall, it should be quite unique, and it is unlikely to occur elsewhere in a message. No, this is not exciting, but it works.

Alexander