java - Trying to send "alternative" with MIME but it also shows up in capable mail client -

i'm trying send nice mime emails, html displayed whenever possible, , when not possible should have textual fallback.

that is, when html contains image, "alternative" part should show "img ... should here".

the problem see everything, alternative, in gmail.

is there wrong mime message?

here's content:

content-type: multipart/mixed; boundary="===============9061258228856181354==" mime-version: 1.0 from: me@gmail.com <me@gmail.com> to: me@gmail.com  --===============9061258228856181354== content-type: multipart/alternative; boundary="===============2889524977048828163==" mime-version: 1.0  --===============2889524977048828163== content-type: text/plain; charset="us-ascii" mime-version: 1.0 content-transfer-encoding: 7bit  img 1043833786270341319 should here --===============2889524977048828163==--  --===============9061258228856181354== content-type: image/jpeg; name="sky.jpg" mime-version: 1.0 content-id: <1043833786270341319> content-transfer-encoding: base64  /9j/4aaqskzjrgabaqaaaqabaad/2wbdaamcagmcagmdawmeawmebqgfbqqebqohbwyidaomdask cwsndhiqdq4rdgslebyqermufruvda8xgbyugbiufrt/2wbdaqmebauebqkfbqkudqsnfbqufbqu fbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbt/waarcaebaakdasia ahebaxeb/8qahqaaagidaqebaaaaaaaaaaaaagqbawugbwaicf/eadoqaaeeaqmdawifagybbamb  --===============9061258228856181354== content-type: multipart/related; boundary="===============7011550496984103126==" mime-version: 1.0  --===============7011550496984103126== content-type: text/html; charset="us-ascii" mime-version: 1.0 content-transfer-encoding: 7bit  <div><h1>bla</h1></div><img src="cid:1043833786270341319" title="1043833786270341319"/> --===============7011550496984103126==--  --===============9061258228856181354==-- 

notes: image code cut not huge code. again, goal show fallback non-html readers, should have different message html message. capable mailer should not show alternative message, right?

basically, mail not arraged correctly. there few ways arrange parts in mime message make sense mail agent. let's start simple , go through complicated option:

---

the simplest of text few attachments. example, want send cv someone, write few words of introduction , attach 1 or more document (cover letter, cv):

 mime───multipart/mixed─┬─text                        ├─attachment1                        └─attachment2 

multipart/mixed means e-mail agent show parts serially - 1 after other.

• if attachments' content-disposition inline, , e-mail agent capable show given attachment type, shown inside message - @ end.
• if attachments' content-disposition attachment, shown sort of icons or links saving attachments.

---

if want send pretty html message, customary include both plaintext version , html version. recipient may able read in e-mail reader doesn't support html. need use multipart/alternative:

 mime───multipart/mixed─┬─multipart/alternative─┬─text/plain                        │                       └─text/html                        ├─attachment1                        └─attachment2 

so, again, message content includes 3 parts, body , 2 attachments. body multipart/alternative, , contains plaintext version , html version. remember put plaintext first, , html second, convention mail agent pick last alternative knows how display.

the attachments going displayed serially after body, before, because next parts in main level, multipart/mixed.

---

now let's @ mail doesn't have "attachments", have images supposed embedded inside html. in case, mail agent needs know attachments not files sent on reader downloaded, should display them in association html. correct mime type multipart/related, show parts related. in case, need give them proper content ids, , use content ids in html. not part of mime standard, it's how html mail done these days.

as far mime concerned, such message like:

 mime───multipart/alternative─┬─text/plain                              └─multipart/related─┬─text/html                                                  ├─embedded image 1                                                  └─embedded image 2 

this time don't have attachments, can put multipart/alternative our top level content. has plaintext alternative first, before, second alternative mimemultipart("related").

inside it, have html part, , 2 images. html , images must parts of same multipart/related object.

---

now, if wanted attach document such message, 1 has html and images inside it? using this:

 mime───multipart/mixed─┬─multipart/alternative─┬─text/plain                        │                       └─multipart/related─┬─text/html                        │                                           ├─embedded image 1                        │                                           └─embedded image 2                        ├─attachment1                        └─attachment2 

so top level object multipart/mixed, allowing add attachments serially message. message "body" (the first part of multipart/mixed) complex structure of multipart/alternative embedded multipart/related. , other attachments follow that.

---

in summary:

• a multipart/mixed message has first part supposed readable message, , rest attachments. all parts shown reader's mail agent.
• a multipart/alternative message gives different display alternatives of same content, ordered common denominator rare presentation type (e.g. plain text→html→rich text→proprietary formatting) , recipient's mail program picks last 1 knows how display. you see 1 of alternatives.
• a multipart/related message used combine html body inline messages. first part html, other parts have content-ids html uses <img src="..." /> tags.

---

now let's @ own hierarchy, based on boundary strings. outermost level multipart/mixed boundary ===============9061258228856181354==. if places border appears, you'll see there 3 parts multipart/alternative.

the first part is:

content-type: multipart/alternative; boundary="===============2889524977048828163==" mime-version: 1.0  --===============2889524977048828163== content-type: text/plain; charset="us-ascii" mime-version: 1.0 content-transfer-encoding: 7bit  img 1043833786270341319 should here --===============2889524977048828163==-- 

this part multipart/alternative, but has 1 alternative part - content type text/plain.

the second part is:

content-type: image/jpeg; name="sky.jpg" mime-version: 1.0 content-id: <1043833786270341319> content-transfer-encoding: base64  /9j/4aaqskzjrgabaqaaaqabaad/2wbdaamcagmcagmdawmeawmebqgfbqqebqohbwyidaomdask cwsndhiqdq4rdgslebyqermufruvda8xgbyugbiufrt/2wbdaqmebauebqkfbqkudqsnfbqufbqu fbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbqufbt/waarcaebaakdasia ahebaxeb/8qahqaaagidaqebaaaaaaaaaaaaagqbawugbwaicf/eadoqaaeeaqmdawifagybbamb 

so it's image.

the third part is:

content-type: multipart/related; boundary="===============7011550496984103126==" mime-version: 1.0  --===============7011550496984103126== content-type: text/html; charset="us-ascii" mime-version: 1.0 content-transfer-encoding: 7bit  <div><h1>bla</h1></div><img src="cid:1043833786270341319" title="1043833786270341319"/> --===============7011550496984103126==-- 

well, it's multipart/related. has 1 part - text/html message. image not part of it.

so instead of having following hierarchy, appropriate 1 described (text plain , html alternatives, html part having embedded image)

 mime───multipart/alternative─┬─text/plain                              └─multipart/related─┬─text/html                                                  └─embedded image 

you have wrong hierarchy:

 mime───multipart/mixed─┬─multipart/alternative───text/plain                        ├─image                        └─multipart/related───text/html 

because parts in multipart/mixed, displayed serially, not alternatives. because text/plain , multipart/related not parts of same multipart/alternative, mail agent not aware alternatives each other. sees no other alternative text/plain, there 1 part in multipart/alternative.

because multipart/related part not contain images, there mail agents fail put image inside html properly. also, because of this, image shown serially or attachment - stands alone , not related else.

so have rearrange message conform proper hierarchy alternatives work , image related html.