-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathparse.html
621 lines (497 loc) · 21.1 KB
/
parse.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<title>Parser</title>
<script data-main="app" src="require.js"></script>
</head>
<body>
<h1>MIME parsing test</h1>
<p>Copy and paste a mime message to the box below to parse it</p>
<p><textarea id="in" style="width: 100%; height: 300px;">Subject: Ryan Finnie's MIME Torture Test v1.0
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-qYxqvD9rbH0PNeExagh1"
Message-Id: <1066976914.4721.5.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 23:28:34 -0700
--=-qYxqvD9rbH0PNeExagh1
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
Welcome to Ryan Finnie's MIME torture test. This message was designed
to introduce a couple of the newer features of MIME-aware MUAs, features
that have come around since the days of the original MIME torture test.
Just to be clear, this message SUPPLEMENTS the original torture test,
not replaces it. The original test is still very much valid these days,
and new MUAs should strive to first pass the original test, then this
one.
By the way, the message/rfc822 parts have Content-Descriptions
containing Futurama quotes. Bonus points if the MUA display these
somewhere.
Have fun!
Ryan Finnie
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: I'll be whatever I wanna do. --Fry
Content-Type: message/rfc822
Subject: plain jane message
From: Ryan Finnie <[email protected]>
Message-Id: <1066973156.4264.42.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:25:56 -0700
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
Subject: plain jane message
From: Ryan Finnie <[email protected]>
Content-Type: text/plain
Message-Id: <1066973156.4264.42.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:25:56 -0700
Content-Transfer-Encoding: 7bit
This is a plain text/plain message. Nothing fancy here...
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: Would you kindly shut your noise-hole? --Bender
Content-Type: message/rfc822
Subject: messages inside messages inside...
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-9Brg7LoMERBrIDtMRose"
Message-Id: <1066976111.4263.74.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 23:15:11 -0700
--=-9Brg7LoMERBrIDtMRose
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
While a message/rfc822 part inside another message/rfc822 part in a
message isn't too strange, 200 iterations of that would be. The MUA
should have some sense when to stop looping through.
--=-9Brg7LoMERBrIDtMRose
Content-Disposition: inline
Content-Description: At the risk of sounding negative, no. --Leela
Content-Type: message/rfc822
Subject: the original message
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-XFYecI7w+0shpolXq8bb"
Message-Id: <1066975745.4263.70.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 23:09:05 -0700
--=-XFYecI7w+0shpolXq8bb
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
by this point, I should be the 3rd layer deep!
I also have an attachment.
--=-XFYecI7w+0shpolXq8bb
Content-Disposition: attachment; filename=foo.gz
Content-Transfer-Encoding: base64
Content-Type: application/x-gzip; NAME=foo.gz
H4sIAOHBmD8AA4vML1XPyVHISy1LLVJIy8xLUchNVeQCAHbe764WAAAA
--=-XFYecI7w+0shpolXq8bb--
--=-9Brg7LoMERBrIDtMRose--
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: Dirt doesn't need luck! --Professor
Content-Type: message/rfc822
Subject: this message JUST contains an attachment
From: Ryan Finnie <[email protected]>
Content-Disposition: attachment; filename=blah.gz
Content-Transfer-Encoding: base64
Content-Description: Attachment has identical content to above foo.gz
Message-Id: <1066974048.4264.62.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:40:49 -0700
Content-Type: application/x-gzip; NAME=blah.gz
SubjectthismessageJUSTcontainsanattachmentFromRyanFinnierfinniedomaindomTobo
bdomaindomContentDispositionattachmentfilenameAblahgzContentTypeapplication/
xgzipnameAblahgzContentTransferEncodingbase64ContentDescriptionAttachmenthas
identicalcontenttoabovefoogzMessageId1066974048426462camellocalhostMimeVersi
on10Date23Oct20032240490700H4sIAOHBmD8AA4vML1XPyVHISy1LLVJIy8xLUchNVeQCAHbe7
64WA
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: Hold still, I don't have good depth perception! --Leela
Content-Type: message/rfc822
Subject: Attachment filename vs. name
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-1066975756jd02"
Message-Id: <1066975756.4263.70.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 23:09:16 -0700
--=-1066975756jd02
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
In this message's attachment, the Content-Disposition has a
filename of blah1.gz, while the Content-Type has a name of
blah2.gz. What should be done? Well, since this is an attachment
(as indicated in the Content-Disposition), the MUA should
suggest a filename of blah1.gz. The MUA *COULD* find a way to
represent the name of blah2.gz somewhere else, it's not needed.
--=-1066975756jd02
Content-Disposition: attachment; filename=blah1.gz
Content-Transfer-Encoding: base64
Content-Description: filename is blah1.gz, name is blah2.gz
Content-Type: application/x-gzip; NAME=blah2.gz
H4sIAOHBmD8AA4vML1XPyVHISy1LLVJIy8xLUchNVeQCAHbe764WAAAA
--=-1066975756jd02--
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: Hello little man. I WILL DESTROY YOU! --Moro
Content-Type: message/rfc822
Subject: No filename? No problem!
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-1066975756jd03"
Message-Id: <1066975761.4263.70.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 23:09:21 -0700
--=-1066975756jd03
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
When searching for a suitable name to suggest for a filename,
the MUA should probably follow this order. First, look for
Content-Disposition's filename attribute. If that is missing,
look for Content-Type's file attribute. If that is also missing,
I would recomment taking the Content-Description, stripping off
any characters that cannot be used in a filename, and suggesting
that.
If none of those fields are available, the MUA could just make
up a random filename. SOMETHING is better than nothing.
--=-1066975756jd03
Content-Disposition: attachment
Content-Transfer-Encoding: base64
Content-Description: I'm getting sick of witty things to say
Content-Type: application/x-gzip
H4sIAOHBmD8AA4vML1XPyVHISy1LLVJIy8xLUchNVeQCAHbe764WAAAA
--=-1066975756jd03--
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: Friends! Help! A guinea pig tricked me! --Zoidberg
Content-Type: message/rfc822
Subject: html and text, both inline
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-ZCKMfHzvHMyK1iBu4kff"
Message-Id: <1066974044.4264.62.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:40:45 -0700
--=-ZCKMfHzvHMyK1iBu4kff
Content-Type: text/html; CHARSET=utf-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/1.1.10">
</HEAD>
<BODY>
<FONT COLOR="#f8cc00">This is the HTML part.</FONT><BR>
It should be displayed inline.
</BODY>
</HTML>
--=-ZCKMfHzvHMyK1iBu4kff
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
This is the text part.
It should ALSO be displayed inline.
--=-ZCKMfHzvHMyK1iBu4kff--
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: Smeesh! --Amy
Content-Type: message/rfc822
Subject: text and text, both inline
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-pNc4wtlOIxs8RcX7H/AK"
Message-Id: <1066974089.4265.64.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:41:29 -0700
--=-pNc4wtlOIxs8RcX7H/AK
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
This is the first text part.
It should be displayed inline.
--=-pNc4wtlOIxs8RcX7H/AK
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
This is the second text part.
It should also be displayed inline.
--=-pNc4wtlOIxs8RcX7H/AK--
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: That's not a cigar. Uh... and it's not mine. --Hermes
Content-Type: message/rfc822
Subject: HTML and... HTML?
From: Ryan Finnie <[email protected]>
Content-Type: multipart/mixed; boundary="=-zxh/IezwzZITiphpcbJZ"
Message-Id: <1066973957.4263.59.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:39:17 -0700
--=-zxh/IezwzZITiphpcbJZ
Content-Type: text/html; CHARSET=utf-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/1.1.10">
</HEAD>
<BODY>
<B>Bold!!!</B><BR>
<BR>
What do we have here... This message is an HTML message. Also attached
is an HTML FILE. Both of these are in a multipart/mixed part.<BR>
<BR>
Now, the first HTML part (what you're reading now) should be displayed
if the MUA is HTML-capable. If it is not, the MUA could possibly offer
this part up as an attachment to download, seeing as how no plaintext
part is offered as an alternative.<BR>
<BR>
However, the second HTML part is listed with a disposition as
attachment. Therefore, it should be offered as an attachment, not
displayed inline.
</BODY>
</HTML>
--=-zxh/IezwzZITiphpcbJZ
Content-Disposition: attachment; filename=htmlfile.html
Content-Type: text/html; NAME=htmlfile.html; CHARSET=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head><title>This is an Attachment</title></head>
<body>
<p>The title says it all...</p>
</body>
</html>
--=-zxh/IezwzZITiphpcbJZ--
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: The spirit is willing, but the flesh is spongy, and
bruised. --Zapp
Content-Type: message/rfc822
Subject: smiley!
From: Ryan Finnie <[email protected]>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vH3FQO9a8icUn1ROCoAi"
Message-Id: <1066972996.4264.39.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:23:16 -0700
--=-vH3FQO9a8icUn1ROCoAi
Content-Type: multipart/mixed; boundary="=-CgV5jm9HAY9VbUlAuneA"
--=-CgV5jm9HAY9VbUlAuneA
Content-Type: multipart/related; type="multipart/alternative";
boundary="=-GpwozF9CQ7NdF+fd+vMG"
--=-GpwozF9CQ7NdF+fd+vMG
Content-Type: multipart/alternative; boundary="=-dHujWM/Xizz57x/JOmDF"
--=-dHujWM/Xizz57x/JOmDF
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
If this sentence is red, you are viewing the HTML part.
Wow, what a complicated message. This message is laid out as so:
multipart/signed
| multipart/mixed
| | mutipart/related
| | | multipart/alternative
| | | | text/plain
| | | | text/html
| | | image/png (smiley)
| | image/gif (dot)
| application/pgp-signature
:)
A smiley face should be embedded into the HTML part above (if you are
viewing the HTML part), while the red square dot should be attached, not
displayed inline. Additionally, this whole message is PGP signed.
This message introduces a few tricks that the MUA should cope with.=20
First of all, the related / alternative combination doesn't make much
sense. Here's the current setup in pseudo-code:
relationship between (alternative: HTML or text part) and PNG part
Why would the text part be related in anyway to the PNG? Instead, the
correct and more logical way to do things would be:
alternative: (relationship between HTML and PNG parts) or text part
However, many MUAs compose a message using the first method, so this
should be taken care of when parsing the message.
Additionally, notice that the inline image has a disposition of
"attachment". Despite this being in there, the smiley should be
embedded inline in the HTML part, not offered as an attachment.=20
Conversely, the GIF image should be offered as an attachment, not
displayed inline.
If the MUA is not PGP capable, at the very least it should recognize
multipart/signed the same as multipart/mixed, and offer the
application/pgp-signature part as an attachment.
--=-dHujWM/Xizz57x/JOmDF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/1.1.10">
</HEAD>
<BODY>
<FONT COLOR=3D"#f80000">If this sentence is red, you are viewing the HTML p=
art.</FONT><BR>
Wow, what a complicated message. This message is laid out as so:<BR>
<BR>
multipart/signed<BR>
| multipart/mixed<BR>
| | mutipart/related<BR>
| | | multipart/alternative<BR>
| | | | text/plain<BR>
| | | | text/html<BR>
| | | image/png (smiley)<BR>
| | image/gif (dot)<BR>
| application/pgp-signature<BR>
<BR>
<IMG SRC=3D"cid:1066971953.4232.15.camel@localhost" ALIGN=3D"bottom" ALT=3D=
":)" BORDER=3D"0"><BR>
<BR>
A smiley face should be embedded into the HTML part above (if you are viewi=
ng the HTML part), while the red square dot should be attached, not display=
ed inline. Additionally, this whole message is PGP signed.<BR>
<BR>
This message introduces a few tricks that the MUA should cope with. F=
irst of all, the related / alternative combination doesn't make much sense.=
Here's the current setup in pseudo-code:<BR>
<BR>
<I>relationship between (alternative: HTML or text part) and PNG part</I><B=
R>
<BR>
Why would the text part be related in anyway to the PNG? Instead, the=
correct and more logical way to do things would be:<BR>
<BR>
alternative: (relationship between HTML and PNG parts) or text part<BR>
<BR>
However, many MUAs compose a message using the first method, so this should=
be taken care of when parsing the message.<BR>
<BR>
Additionally, notice that the inline image has a disposition of "attac=
hment". Despite this being in there, the smiley should be embedd=
ed inline in the HTML part, not offered as an attachment. Conversely,=
the GIF image should be offered as an attachment, not displayed inline.<BR=
>
<BR>
If the MUA is not PGP capable, at the very least it should recognize multip=
art/signed the same as multipart/mixed, and offer the application/pgp-signa=
ture part as an attachment.
</BODY>
</HTML>
--=-dHujWM/Xizz57x/JOmDF--
--=-GpwozF9CQ7NdF+fd+vMG
Content-ID: <1066971953.4232.15.camel@localhost>
Content-Disposition: attachment; filename=smiley-3.png
Content-Type: image/png; name=smiley-3.png
Content-Transfer-Encoding: base64
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAC+klEQVR42n2TbUjVdxTHP/+H69Xd
a2VWlFe69rzthZJUoxeNOWoFGxEhYRRFmZSVW2u9ab2KejWE1qDNBkEQhS82VoiaZkVPmoWaKNM5
mA+opbd771//997//T/+epHBarEPHA6Hc84XDnwP/JcwcBS4AVgzcR04ONN7C+md+pcPCz44dPLA
arZs/gg1UABuGkvvp7X1Iad+itE/YtUAle8TuH26sujzqq/LkJQsnOQQVmIASVJQMhehZORiJwc5
d76FH2pf3gY2Aigzy7+eObqmtOqbXbjGGHZqCM+eQpJ9AHhWFCc5CAjWf1KAkppc+qg3vRCol4Fw
0aqcisOVW3HTE7hmBElSKD/5GFkNMhH1KDvegST78CwNSfZxeM88VuYrh4CwAuxqvxL6MnPuWiy9
H1kNUPH9fZofDKPpHn8/z+Z6Yw8JK5stX5VhRO6h+OfiV3WaHxtPVKAwmF+KqXUDMkgqZ0+UoKcE
P57/GXOqh46ODqrPXUQfufb6YOGxJOQD2CaHQnnlAJ4zDXggHBYvK6ap6Rau+RIz1k7djd+YHrqM
pXUC4KQnWTRPAdiuRqNRkFQG/omRNJOsKVQw408xtS4QDsI10AaqEY6O8Fzq70fJy3XI8gsA5HTa
rBdOkvwFKj39EWrr/sJzEnj29OvsphGugfBsLlwbZnjcYN36LxiLuADtMtCUetFAcE4ee8s+pbHV
YtOemwhHx3MSaPEY3X9OUnqsk5a2OMeP7KC3t4u+3gRALUC4cEW2eN62Q4ze3SAiz74TDxvOiI+X
BcTsoCoyfJKYn6OKmrMbxGRnlXhyJSSqv80Vq0KSAFa+ceKl0wcK9lfsW42TGsE/pxhfcDmKfz6e
FUPg4iRH6Ov6g9EJh1t341xusWuAyn9b+c7BrbklJ8oDZGTOQpL9ePY08SmDpCEwbcHwuE370yku
Nlj3gM/e90yXliyU9+8sCVJYlEUgU8IwBZruMThm83uzxsAYV4Hd/A9h4BjQBthAFOgDLgDF7w6/
ArI6YJ0eTQeGAAAAAElFTkSuQmCC
--=-GpwozF9CQ7NdF+fd+vMG--
--=-CgV5jm9HAY9VbUlAuneA
Content-Disposition: attachment; filename=dot.gif
Content-Type: image/gif; name=dot.gif
Content-Transfer-Encoding: base64
R0lGODdhCgAKAKEAAAAAANUAAP///8PDwywAAAAACgAKAEACHZSPMssLKoIMYLyR1I2z3sZsE2VB
owcBqlqurloAADs=
--=-CgV5jm9HAY9VbUlAuneA--
--=-vH3FQO9a8icUn1ROCoAi
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQA/mLdEKZYQqSA+yiURAjAnAJ90G22jbX/Broy0F541R0UUbsb6zgCeJn0d
02Vq9Sv6aXE+YM0lRn3jZDc=
=uwCM
-----END PGP SIGNATURE-----
--=-vH3FQO9a8icUn1ROCoAi--
--=-qYxqvD9rbH0PNeExagh1
Content-Disposition: inline
Content-Description: Kittens give Morbo gas. --Morbo
Content-Type: message/rfc822
Subject: the PROPER way to do alternative/related
From: Ryan Finnie <[email protected]>
Content-Type: multipart/alternative; type="multipart/alternative"; boundary="=-tyGlQ9JvB5uvPWzozI+y"
Message-Id: <1066973557.4265.51.camel@localhost>
Mime-Version: 1.0
X-Mailer: Not Evolution
Date: 23 Oct 2003 22:32:37 -0700
--=-tyGlQ9JvB5uvPWzozI+y
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 8bit
If this sentence is green, you're viewing the HTML part.
Now, this is the way that all MUAs SHOULD treat this kind of situation.
The layout is like so:
multipart/alternative
| text/plain
| multipart/related
| | text/html
| | image/gif
See? The GIF (which by the way should be inline towards the top of this
message) is related to the HTML, and that whole block is an alternative
to a text/plain part. This is the opposite of the way shown in the
previous email.
Also, the embedded image here does not have a filename. As mentioned
above, the MUA should suggest something as a filename, even here (the
user may want to save the embedded image, so a filename would be
helpful). In this case, I would recommend appending the random text
to be suggested to the user with the part's subtype, in this case
something like c20vsidlkvm.gif.
--=-tyGlQ9JvB5uvPWzozI+y
Content-Type: multipart/related; boundary="=-bFkxH1S3HVGcxi+o/5jG"
--=-bFkxH1S3HVGcxi+o/5jG
Content-Type: text/html; CHARSET=utf-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/1.1.10">
</HEAD>
<BODY>
<FONT COLOR="#00fc00">If this sentence is green, you're viewing the HTML part.</FONT><BR>
<IMG SRC="cid:1066973340.4232.46.camel@localhost" ALIGN="top" ALT="" BORDER="0"><BR>
Now, this is the way that all MUAs <B>SHOULD</B> treat this kind of situation. The layout is like so:<BR>
<BR>
multipart/alternative<BR>
| text/plain<BR>
| multipart/related<BR>
| | text/html<BR>
| | image/gif<BR>
<BR>
See? The GIF (which by the way should be inline towards the top of this message) is related to the HTML, and that whole block is an alternative to a text/plain part. This is the opposite of the way shown in the previous email.<BR>
<BR>
Also, the embedded image here does not have a filename. As mentioned above, the MUA should suggest something as a filename, even here (the user may want to save the embedded image, so a filename would be helpful). In this case, I would recommend appending the random text to be suggested to the user with the part's subtype, in this case something like c20vsidlkvm.gif.
</BODY>
</HTML>
--=-bFkxH1S3HVGcxi+o/5jG
Content-ID: <1066973340.4232.46.camel@localhost>
Content-Transfer-Encoding: base64
Content-Type: image/gif
R0lGODlhBQALAPIAAKIA/64A/8ZL/////8BS/2QDANZ//wAAACH5BAEAAAMALAAAAAAFAAsAAAMY
OBIytsIYEoiEl0lqFWgKM4zkUJzjWQwJADs=
--=-bFkxH1S3HVGcxi+o/5jG--
--=-tyGlQ9JvB5uvPWzozI+y--
--=-qYxqvD9rbH0PNeExagh1--
</textarea></p>
<p>Max body chunk size in bytes: <input type="text" id="chunksize" value="255" /> (max 128kB)</p>
<p>Input chunk size: <input type="text" id="inputsize" value="1" /> (max 128kB)</p>
<p><button onclick="parse();">Parse</button></p>
<p>Input text is "streamed" to the parser set count of bytes at the time, so it might take a few seconds until you see something if "Input chunk size" value is very small. "DONE" indicates that the input is fully streamed and parsed.</p>
<pre id="log"></pre>
</body>
</html>