In message , Mayayana
writes:
"J. P. Gilliver (John)" wrote

| HTML email then they should see an inline image as an
| attachment. Otherwise they'll see it where you put
| it in the message. Both are base64-encoded text
| sections in the email. There's no difference in that.
|
| Nope: nothing to do with HTML. If I send a truly inline image, _in the
| middle of an email/post_, most other clients will see the image _and the
| text that follows it_ as two attachments.

If you add an inline image that is HTML. If you

No.

look at the raw code of the email you should see
the email specified as multi-part. A unique boundary
string will separate text/html/binaries. You can only

True, there will be a boundary string before and after any embedded
attachment (image or otherwise). But I can send an email that goes

text
attachment
more text

.. If I examine the raw code of the email, it'll have

(headers)
text
boundary string
encoded attachment
boundary string
more text

add an inline image in an HTML section, and that

No HTML.

image data can only go in a separate boundaried
content section.

Yes, it will be in a "separate boundaries content section". But it
_doesn't_ have to be at the end.

If you give me an email address (use a throwaway one if you're
paranoid), I'll send you an example.

I wonder if maybe this has to do with how you're
using the client software itself. In theory there's
no reason that an image can't come before text,
but it still has to be in a different content section
with a boundary, because only one type of content
goes in a section.

Yes, obviously, encoded data has to be delimited from plain text.

And I've never seen it done. In
virtually all cases, an email is done in plain text, followed
by HTML, followed by any base64-encoded files. A
plain text email would skip the HTML section.

No, I'm not talking about two-version emails, where the entire email is
repeated twice, once in plain text and once in HTML.

Maybe you're trying to put inline images in a
plain text email and the software is "humoring you"?

No, I've looked at (even edited, occasionally) the raw data form of
emails, and there's no HTML - or any other tag - in them.
______________________________
plain text with attachments
______________________________

from
to
date
subject
Message-ID
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="BOUNDARY_STRING_1"
X-Mailer: [your program name here]
#
--BOUNDARY_STRING_1
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
#
(email text here)
#
--BOUNDARY_STRING_1
Content-Type: image/jpeg;
name="earth_sm.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="earth_sm.jpg"
#
(base 64 here)
#
--BOUNDARY_STRING_1--


Something like that, but my client can add more plain text after the
image.

_________________________
HTML with pictures
_________________________

from
to
subject
date
Message-ID
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="BOUNDARY_STRING_1";
type="multipart/alternative"
X-Mailer: [your program name here]
#
--BOUNDARY_STRING_1
Content-Type: multipart/alternative;
boundary="BOUNDARY_STRING_2"
#
--BOUNDARY_STRING_2
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
#
(default text for non-html email readers)
#
--BOUNDARY_STRING_2
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
#
(html body here.......
IMG SRC=3D"cidic.gif"
......)
#
--BOUNDARY_STRING_2-- (end of alternative boundary.)
#
--BOUNDARY_STRING_1
Content-Type: image/gif; (or image/jpg, etc.)
name="pic.gif"
Content-Transfer-Encoding: base64
Content-ID: pic.gif
#
(base 64 here)
# (repeat for other pics if present: space, boundary,
content, space, base64, space)
--BOUNDARY_STRING_1--

Well, that's a dual-part email, since you included the plain text "for
non-html readers" as well. (I'm pretty sure I've seen emails without the
plain text version, i. e. HTML only.) I can believe that maybe HTML
messages can only have the images at the end with a pointer to them in
the text.

--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

If it ain't broke, don't download updates.
- Al Drake in alt.windows7.general, 2015-4-4