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
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
|
Network Working Group N. Freed
Request for Comments: 2045 Innosoft
Obsoletes: 1521, 1522, 1590 N. Borenstein
Category: Standards Track First Virtual
November 1996
Multipurpose Internet Mail Extensions
(MIME) Part One:
Format of Internet Message Bodies
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
STD 11, RFC 822, defines a message representation protocol specifying
considerable detail about US-ASCII message headers, and leaves the
message content, or message body, as flat US-ASCII text. This set of
documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than
US-ASCII,
(2) an extensible set of different formats for non-textual
message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than
US-ASCII.
These documents are based on earlier work documented in RFC 934, STD
11, and RFC 1049, but extends and revises them. Because RFC 822 said
so little about message bodies, these documents are largely
orthogonal to (rather than a revision of) RFC 822.
This initial document specifies the various headers used to describe
the structure of MIME messages. The second document, RFC 2046,
defines the general structure of the MIME media typing system and
defines an initial set of media types. The third document, RFC 2047,
describes extensions to RFC 822 to allow non-US-ASCII text data in
Freed & Borenstein Standards Track [Page 1]
RFC 2045 Internet Message Bodies November 1996
Internet mail header fields. The fourth document, RFC 2048, specifies
various IANA registration procedures for MIME-related facilities. The
fifth and final document, RFC 2049, describes MIME conformance
criteria as well as providing some illustrative examples of MIME
message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which
themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
2049 describes differences and changes from previous versions.
Table of Contents
1. Introduction ......................................... 3
2. Definitions, Conventions, and Generic BNF Grammar .... 5
2.1 CRLF ................................................ 5
2.2 Character Set ....................................... 6
2.3 Message ............................................. 6
2.4 Entity .............................................. 6
2.5 Body Part ........................................... 7
2.6 Body ................................................ 7
2.7 7bit Data ........................................... 7
2.8 8bit Data ........................................... 7
2.9 Binary Data ......................................... 7
2.10 Lines .............................................. 7
3. MIME Header Fields ................................... 8
4. MIME-Version Header Field ............................ 8
5. Content-Type Header Field ............................ 10
5.1 Syntax of the Content-Type Header Field ............. 12
5.2 Content-Type Defaults ............................... 14
6. Content-Transfer-Encoding Header Field ............... 14
6.1 Content-Transfer-Encoding Syntax .................... 14
6.2 Content-Transfer-Encodings Semantics ................ 15
6.3 New Content-Transfer-Encodings ...................... 16
6.4 Interpretation and Use .............................. 16
6.5 Translating Encodings ............................... 18
6.6 Canonical Encoding Model ............................ 19
6.7 Quoted-Printable Content-Transfer-Encoding .......... 19
6.8 Base64 Content-Transfer-Encoding .................... 24
7. Content-ID Header Field .............................. 26
8. Content-Description Header Field ..................... 27
9. Additional MIME Header Fields ........................ 27
10. Summary ............................................. 27
11. Security Considerations ............................. 27
12. Authors' Addresses .................................. 28
A. Collected Grammar .................................... 29
Freed & Borenstein Standards Track [Page 2]
RFC 2045 Internet Message Bodies November 1996
1. Introduction
Since its publication in 1982, RFC 822 has defined the standard
format of textual mail messages on the Internet. Its success has
been such that the RFC 822 format has been adopted, wholly or
partially, well beyond the confines of the Internet and the Internet
SMTP transport defined by RFC 821. As the format has seen wider use,
a number of limitations have proven increasingly restrictive for the
user community.
RFC 822 was intended to specify a format for text messages. As such,
non-text messages, such as multimedia messages that might include
audio or images, are simply not mentioned. Even in the case of text,
however, RFC 822 is inadequate for the needs of mail users whose
languages require the use of character sets richer than US-ASCII.
Since RFC 822 does not specify mechanisms for mail containing audio,
video, Asian language text, or even text in most European languages,
additional specifications are needed.
One of the notable limitations of RFC 821/822 based mail systems is
the fact that they limit the contents of electronic mail messages to
relatively short lines (e.g. 1000 characters or less [RFC-821]) of
7bit US-ASCII. This forces users to convert any non-textual data
that they may wish to send into seven-bit bytes representable as
printable US-ASCII characters before invoking a local mail UA (User
Agent, a program with which human users send and receive mail).
Examples of such encodings currently used in the Internet include
pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
RFC 1421, the Andrew Toolkit Representation [ATK], and many others.
The limitations of RFC 822 mail become even more apparent as gateways
are designed to allow for the exchange of mail messages between RFC
822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
inclusion of non-textual material within electronic mail messages.
The current standards for the mapping of X.400 messages to RFC 822
messages specify either that X.400 non-textual material must be
converted to (not encoded in) IA5Text format, or that they must be
discarded, notifying the RFC 822 user that discarding has occurred.
This is clearly undesirable, as information that a user may wish to
receive is lost. Even though a user agent may not have the
capability of dealing with the non-textual material, the user might
have some mechanism external to the UA that can extract useful
information from the material. Moreover, it does not allow for the
fact that the message may eventually be gatewayed back into an X.400
message handling system (i.e., the X.400 message is "tunneled"
through Internet mail), where the non-textual information would
definitely become useful again.
Freed & Borenstein Standards Track [Page 3]
RFC 2045 Internet Message Bodies November 1996
This document describes several mechanisms that combine to solve most
of these problems without introducing any serious incompatibilities
with the existing world of RFC 822 mail. In particular, it
describes:
(1) A MIME-Version header field, which uses a version
number to declare a message to be conformant with MIME
and allows mail processing agents to distinguish
between such messages and those generated by older or
non-conformant software, which are presumed to lack
such a field.
(2) A Content-Type header field, generalized from RFC 1049,
which can be used to specify the media type and subtype
of data in the body of a message and to fully specify
the native representation (canonical form) of such
data.
(3) A Content-Transfer-Encoding header field, which can be
used to specify both the encoding transformation that
was applied to the body and the domain of the result.
Encoding transformations other than the identity
transformation are usually applied to data in order to
allow it to pass through mail transport mechanisms
which may have data or character set limitations.
(4) Two additional header fields that can be used to
further describe the data in a body, the Content-ID and
Content-Description header fields.
All of the header fields defined in this document are subject to the
general syntactic rules for header fields specified in RFC 822. In
particular, all of these header fields except for Content-Disposition
can include RFC 822 comments, which have no semantic content and
should be ignored during MIME processing.
Finally, to specify and promote interoperability, RFC 2049 provides a
basic applicability statement for a subset of the above mechanisms
that defines a minimal level of "conformance" with this document.
HISTORICAL NOTE: Several of the mechanisms described in this set of
documents may seem somewhat strange or even baroque at first reading.
It is important to note that compatibility with existing standards
AND robustness across existing practice were two of the highest
priorities of the working group that developed this set of documents.
In particular, compatibility was always favored over elegance.
Freed & Borenstein Standards Track [Page 4]
RFC 2045 Internet Message Bodies November 1996
Please refer to the current edition of the "Internet Official
Protocol Standards" for the standardization state and status of this
protocol. RFC 822 and STD 3, RFC 1123 also provide essential
background for MIME since no conforming implementation of MIME can
violate them. In addition, several other informational RFC documents
will be of interest to the MIME implementor, in particular RFC 1344,
RFC 1345, and RFC 1524.
2. Definitions, Conventions, and Generic BNF Grammar
Although the mechanisms specified in this set of documents are all
described in prose, most are also described formally in the augmented
BNF notation of RFC 822. Implementors will need to be familiar with
this notation in order to understand this set of documents, and are
referred to RFC 822 for a complete explanation of the augmented BNF
notation.
Some of the augmented BNF in this set of documents makes named
references to syntax rules defined in RFC 822. A complete formal
grammar, then, is obtained by combining the collected grammar
appendices in each document in this set with the BNF of RFC 822 plus
the modifications to RFC 822 defined in RFC 1123 (which specifically
changes the syntax for `return', `date' and `mailbox').
All numeric and octet values are given in decimal notation in this
set of documents. All media type values, subtype values, and
parameter names as defined are case-insensitive. However, parameter
values are case-sensitive unless otherwise specified for the specific
parameter.
FORMATTING NOTE: Notes, such at this one, provide additional
nonessential information which may be skipped by the reader without
missing anything essential. The primary purpose of these non-
essential notes is to convey information about the rationale of this
set of documents, or to place these documents in the proper
historical or evolutionary context. Such information may in
particular be skipped by those who are focused entirely on building a
conformant implementation, but may be of use to those who wish to
understand why certain design choices were made.
2.1. CRLF
The term CRLF, in this set of documents, refers to the sequence of
octets corresponding to the two US-ASCII characters CR (decimal value
13) and LF (decimal value 10) which, taken together, in this order,
denote a line break in RFC 822 mail.
Freed & Borenstein Standards Track [Page 5]
RFC 2045 Internet Message Bodies November 1996
2.2. Character Set
The term "character set" is used in MIME to refer to a method of
converting a sequence of octets into a sequence of characters. Note
that unconditional and unambiguous conversion in the other direction
is not required, in that not all characters may be representable by a
given character set and a character set may provide more than one
sequence of octets to represent a particular sequence of characters.
This definition is intended to allow various kinds of character
encodings, from simple single-table mappings such as US-ASCII to
complex table switching methods such as those that use ISO 2022's
techniques, to be used as character sets. However, the definition
associated with a MIME character set name must fully specify the
mapping to be performed. In particular, use of external profiling
information to determine the exact mapping is not permitted.
NOTE: The term "character set" was originally to describe such
straightforward schemes as US-ASCII and ISO-8859-1 which have a
simple one-to-one mapping from single octets to single characters.
Multi-octet coded character sets and switching techniques make the
situation more complex. For example, some communities use the term
"character encoding" for what MIME calls a "character set", while
using the phrase "coded character set" to denote an abstract mapping
from integers (not octets) to characters.
2.3. Message
The term "message", when not further qualified, means either a
(complete or "top-level") RFC 822 message being transferred on a
network, or a message encapsulated in a body of type "message/rfc822"
or "message/partial".
2.4. Entity
The term "entity", refers specifically to the MIME-defined header
fields and contents of either a message or one of the parts in the
body of a multipart entity. The specification of such entities is
the essence of MIME. Since the contents of an entity are often
called the "body", it makes sense to speak about the body of an
entity. Any sort of field may be present in the header of an entity,
but only those fields whose names begin with "content-" actually have
any MIME-related meaning. Note that this does NOT imply thay they
have no meaning at all -- an entity that is also a message has non-
MIME header fields whose meanings are defined by RFC 822.
Freed & Borenstein Standards Track [Page 6]
RFC 2045 Internet Message Bodies November 1996
2.5. Body Part
The term "body part" refers to an entity inside of a multipart
entity.
2.6. Body
The term "body", when not further qualified, means the body of an
entity, that is, the body of either a message or of a body part.
NOTE: The previous four definitions are clearly circular. This is
unavoidable, since the overall structure of a MIME message is indeed
recursive.
2.7. 7bit Data
"7bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]. No octets with decimal values greater than 127
are allowed and neither are NULs (octets with decimal value 0). CR
(decimal value 13) and LF (decimal value 10) octets only occur as
part of CRLF line separation sequences.
2.8. 8bit Data
"8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]), but octets with decimal values greater than 127
may be used. As with "7bit data" CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.
2.9. Binary Data
"Binary data" refers to data where any sequence of octets whatsoever
is allowed.
2.10. Lines
"Lines" are defined as sequences of octets separated by a CRLF
sequences. This is consistent with both RFC 821 and RFC 822.
"Lines" only refers to a unit of data in a message, which may or may
not correspond to something that is actually displayed by a user
agent.
Freed & Borenstein Standards Track [Page 7]
RFC 2045 Internet Message Bodies November 1996
3. MIME Header Fields
MIME defines a number of new RFC 822 header fields that are used to
describe the content of a MIME entity. These header fields occur in
at least two contexts:
(1) As part of a regular RFC 822 message header.
(2) In a MIME body part header within a multipart
construct.
The formal definition of these header fields is as follows:
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-headers
fields
version CRLF
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.
MIME-part-headers := entity-headers
[ fields ]
; Any field not beginning with
; "content-" can have no defined
; meaning and may be ignored.
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.
The syntax of the various specific MIME header fields will be
described in the following sections.
4. MIME-Version Header Field
Since RFC 822 was published in 1982, there has really been only one
format standard for Internet messages, and there has been little
perceived need to declare the format standard in use. This document
is an independent specification that complements RFC 822. Although
the extensions in this document have been defined in such a way as to
be compatible with RFC 822, there are still circumstances in which it
might be desirable for a mail-processing agent to know whether a
message was composed with the new standard in mind.
Freed & Borenstein Standards Track [Page 8]
RFC 2045 Internet Message Bodies November 1996
Therefore, this document defines a new header field, "MIME-Version",
which is to be used to declare the version of the Internet message
body format standard in use.
Messages composed in accordance with this document MUST include such
a header field, with the following verbatim text:
MIME-Version: 1.0
The presence of this header field is an assertion that the message
has been composed in compliance with this document.
Since it is possible that a future document might extend the message
format standard again, a formal BNF is given for the content of the
MIME-Version field:
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Thus, future format specifiers, which might replace or extend "1.0",
are constrained to be two integer fields, separated by a period. If
a message is received with a MIME-version value other than "1.0", it
cannot be assumed to conform with this document.
Note that the MIME-Version header field is required at the top level
of a message. It is not required for each body part of a multipart
entity. It is required for the embedded headers of a body of type
"message/rfc822" or "message/partial" if and only if the embedded
message is itself claimed to be MIME-conformant.
It is not possible to fully specify how a mail reader that conforms
with MIME as defined in this document should treat a message that
might arrive in the future with some value of MIME-Version other than
"1.0".
It is also worth noting that version control for specific media types
is not accomplished using the MIME-Version mechanism. In particular,
some formats (such as application/postscript) have version numbering
conventions that are internal to the media format. Where such
conventions exist, MIME does nothing to supersede them. Where no
such conventions exist, a MIME media type might use a "version"
parameter in the content-type field if necessary.
Freed & Borenstein Standards Track [Page 9]
RFC 2045 Internet Message Bodies November 1996
NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822
comment strings that are present must be ignored. In particular, the
following four MIME-Version fields are equivalent:
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
In the absence of a MIME-Version field, a receiving mail user agent
(whether conforming to MIME requirements or not) may optionally
choose to interpret the body of the message according to local
conventions. Many such conventions are currently in use and it
should be noted that in practice non-MIME messages can contain just
about anything.
It is impossible to be certain that a non-MIME mail message is
actually plain text in the US-ASCII character set since it might well
be a message that, using some set of nonstandard local conventions
that predate MIME, includes text in another character set or non-
textual data presented in a manner that cannot be automatically
recognized (e.g., a uuencoded compressed UNIX tar file).
5. Content-Type Header Field
The purpose of the Content-Type field is to describe the data
contained in the body fully enough that the receiving user agent can
pick an appropriate agent or mechanism to present the data to the
user, or otherwise deal with the data in an appropriate manner. The
value in this field is called a media type.
HISTORICAL NOTE: The Content-Type header field was first defined in
RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
that is largely compatible with the mechanism given here.
The Content-Type header field specifies the nature of the data in the
body of an entity by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for certain
media types. After the media type and subtype names, the remainder
of the header field is simply a set of parameters, specified in an
attribute=value notation. The ordering of parameters is not
significant.
Freed & Borenstein Standards Track [Page 10]
RFC 2045 Internet Message Bodies November 1996
In general, the top-level media type is used to declare the general
type of data, while the subtype specifies a specific format for that
type of data. Thus, a media type of "image/xyz" is enough to tell a
user agent that the data is an image, even if the user agent has no
knowledge of the specific image format "xyz". Such information can
be used, for example, to decide whether or not to show a user the raw
data from an unrecognized subtype -- such an action might be
reasonable for unrecognized subtypes of text, but not for
unrecognized subtypes of image or audio. For this reason, registered
subtypes of text, image, audio, and video should not contain embedded
information that is really of a different type. Such compound
formats should be represented using the "multipart" or "application"
types.
Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of
meaningful parameters depends on the media type and subtype. Most
parameters are associated with a single specific subtype. However, a
given top-level media type may define parameters which are applicable
to any subtype of that type. Parameters may be required by their
defining content type or subtype or they may be optional. MIME
implementations must ignore any parameters whose names they do not
recognize.
For example, the "charset" parameter is applicable to any subtype of
"text", while the "boundary" parameter is required for any subtype of
the "multipart" media type.
There are NO globally-meaningful parameters that apply to all media
types. Truly global mechanisms are best addressed, in the MIME
model, by the definition of additional Content-* header fields.
An initial set of seven top-level media types is defined in RFC 2046.
Five of these are discrete types whose content is essentially opaque
as far as MIME processing is concerned. The remaining two are
composite types whose contents require additional handling by MIME
processors.
This set of top-level media types is intended to be substantially
complete. It is expected that additions to the larger set of
supported types can generally be accomplished by the creation of new
subtypes of these initial types. In the future, more top-level types
may be defined only by a standards-track extension to this standard.
If another top-level type is to be used for any reason, it must be
given a name starting with "X-" to indicate its non-standard status
and to avoid a potential conflict with a future official name.
Freed & Borenstein Standards Track [Page 11]
RFC 2045 Internet Message Bodies November 1996
5.1. Syntax of the Content-Type Header Field
In the Augmented BNF notation of RFC 822, a Content-Type header field
value is defined as follows:
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
Freed & Borenstein Standards Track [Page 12]
RFC 2045 Internet Message Bodies November 1996
Note that the definition of "tspecials" is the same as the RFC 822
definition of "specials" with the addition of the three characters
"/", "?", and "=", and the removal of ".".
Note also that a subtype specification is MANDATORY -- it may not be
omitted from a Content-Type header field. As such, there are no
default subtypes.
The type, subtype, and parameter names are not case sensitive. For
example, TEXT, Text, and TeXt are all equivalent top-level media
types. Parameter values are normally case sensitive, but sometimes
are interpreted in a case-insensitive fashion, depending on the
intended use. (For example, multipart boundaries are case-sensitive,
but the "access-type" parameter for message/External-body is not
case-sensitive.)
Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value. In addition, comments are allowed in
accordance with RFC 822 rules for structured header fields. Thus the
following two forms
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
are completely equivalent.
Beyond this syntax, the only syntactic constraint on the definition
of subtype names is the desire that their uses must not conflict.
That is, it would be undesirable to have two different communities
using "Content-Type: application/foobar" to mean two different
things. The process of defining new media subtypes, then, is not
intended to be a mechanism for imposing restrictions, but simply a
mechanism for publicizing their definition and usage. There are,
therefore, two acceptable mechanisms for defining new media subtypes:
(1) Private values (starting with "X-") may be defined
bilaterally between two cooperating agents without
outside registration or standardization. Such values
cannot be registered or standardized.
(2) New standard values should be registered with IANA as
described in RFC 2048.
The second document in this set, RFC 2046, defines the initial set of
media types for MIME.
Freed & Borenstein Standards Track [Page 13]
RFC 2045 Internet Message Bodies November 1996
5.2. Content-Type Defaults
Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:
Content-type: text/plain; charset=us-ascii
This default is assumed if no Content-Type header field is specified.
It is also recommend that this default be assumed when a
syntactically invalid Content-Type header field is encountered. In
the presence of a MIME-Version header field and the absence of any
Content-Type header field, a receiving User Agent can also assume
that plain US-ASCII text was the sender's intent. Plain US-ASCII
text may still be assumed in the absence of a MIME-Version or the
presence of an syntactically invalid Content-Type header field, but
the sender's intent might have been otherwise.
6. Content-Transfer-Encoding Header Field
Many media types which could be usefully transported via email are
represented, in their "natural" format, as 8bit character or binary
data. Such data cannot be transmitted over some transfer protocols.
For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
data with lines no longer than 1000 characters including any trailing
CRLF line separator.
It is necessary, therefore, to define a standard mechanism for
encoding such data into a 7bit short line format. Proper labelling
of unencoded material in less restrictive formats for direct use over
less restrictive transports is also desireable. This document
specifies that such encodings will be indicated by a new "Content-
Transfer-Encoding" header field. This field has not been defined by
any previous standard.
6.1. Content-Transfer-Encoding Syntax
The Content-Transfer-Encoding field's value is a single token
specifying the type of encoding, as enumerated below. Formally:
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
These values are not case sensitive -- Base64 and BASE64 and bAsE64
are all equivalent. An encoding type of 7BIT requires that the body
Freed & Borenstein Standards Track [Page 14]
RFC 2045 Internet Message Bodies November 1996
is already in a 7bit mail-ready representation. This is the default
value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
6.2. Content-Transfer-Encodings Semantics
This single Content-Transfer-Encoding token actually provides two
pieces of information. It specifies what sort of encoding
transformation the body was subjected to and hence what decoding
operation must be used to restore it to its original form, and it
specifies what the domain of the result is.
The transformation part of any Content-Transfer-Encodings specifies,
either explicitly or implicitly, a single, well-defined decoding
algorithm, which for any sequence of encoded octets either transforms
it to the original sequence of octets which was encoded, or shows
that it is illegal as an encoded sequence. Content-Transfer-
Encodings transformations never depend on any additional external
profile information for proper operation. Note that while decoders
must produce a single, well-defined output for a valid encoding no
such restrictions exist for encoders: Encoding a given sequence of
octets to different, equivalent encoded sequences is perfectly legal.
Three transformations are currently defined: identity, the "quoted-
printable" encoding, and the "base64" encoding. The domains are
"binary", "8bit" and "7bit".
The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
mean that the identity (i.e. NO) encoding transformation has been
performed. As such, they serve simply as indicators of the domain of
the body data, and provide useful information about the sort of
encoding that might be needed for transmission in a given transport
system. The terms "7bit data", "8bit data", and "binary data" are
all defined in Section 2.
The quoted-printable and base64 encodings transform their input from
an arbitrary domain into material in the "7bit" range, thus making it
safe to carry over restricted transports. The specific definition of
the transformations are given below.
The proper Content-Transfer-Encoding label must always be used.
Labelling unencoded data containing 8bit characters as "7bit" is not
allowed, nor is labelling unencoded non-line-oriented data as
anything other than "binary" allowed.
Unlike media subtypes, a proliferation of Content-Transfer-Encoding
values is both undesirable and unnecessary. However, establishing
only a single transformation into the "7bit" domain does not seem
Freed & Borenstein Standards Track [Page 15]
RFC 2045 Internet Message Bodies November 1996
possible. There is a tradeoff between the desire for a compact and
efficient encoding of largely- binary data and the desire for a
somewhat readable encoding of data that is mostly, but not entirely,
7bit. For this reason, at least two encoding mechanisms are
necessary: a more or less readable encoding (quoted-printable) and a
"dense" or "uniform" encoding (base64).
Mail transport for unencoded 8bit data is defined in RFC 1652. As of
the initial publication of this document, there are no standardized
Internet mail transports for which it is legitimate to include
unencoded binary data in mail bodies. Thus there are no
circumstances in which the "binary" Content-Transfer-Encoding is
actually valid in Internet mail. However, in the event that binary
mail transport becomes a reality in Internet mail, or when MIME is
used in conjunction with any other binary-capable mail transport
mechanism, binary bodies must be labelled as such using this
mechanism.
NOTE: The five values defined for the Content-Transfer-Encoding field
imply nothing about the media type other than the algorithm by which
it was encoded or the transport system requirements if unencoded.
6.3. New Content-Transfer-Encodings
Implementors may, if necessary, define private Content-Transfer-
Encoding values, but must use an x-token, which is a name prefixed by
"X-", to indicate its non-standard status, e.g., "Content-Transfer-
Encoding: x-my-new-encoding". Additional standardized Content-
Transfer-Encoding values must be specified by a standards-track RFC.
The requirements such specifications must meet are given in RFC 2048.
As such, all content-transfer-encoding namespace except that
beginning with "X-" is explicitly reserved to the IETF for future
use.
Unlike media types and subtypes, the creation of new Content-
Transfer-Encoding values is STRONGLY discouraged, as it seems likely
to hinder interoperability with little potential benefit
6.4. Interpretation and Use
If a Content-Transfer-Encoding header field appears as part of a
message header, it applies to the entire body of that message. If a
Content-Transfer-Encoding header field appears as part of an entity's
headers, it applies only to the body of that entity. If an entity is
of type "multipart" the Content-Transfer-Encoding is not permitted to
have any value other than "7bit", "8bit" or "binary". Even more
severe restrictions apply to some subtypes of the "message" type.
Freed & Borenstein Standards Track [Page 16]
RFC 2045 Internet Message Bodies November 1996
It should be noted that most media types are defined in terms of
octets rather than bits, so that the mechanisms described here are
mechanisms for encoding arbitrary octet streams, not bit streams. If
a bit stream is to be encoded via one of these mechanisms, it must
first be converted to an 8bit byte stream using the network standard
bit order ("big-endian"), in which the earlier bits in a stream
become the higher-order bits in a 8bit byte. A bit stream not ending
at an 8bit boundary must be padded with zeroes. RFC 2046 provides a
mechanism for noting the addition of such padding in the case of the
application/octet-stream media type, which has a "padding" parameter.
The encoding mechanisms defined here explicitly encode all data in
US-ASCII. Thus, for example, suppose an entity has header fields
such as:
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
This must be interpreted to mean that the body is a base64 US-ASCII
encoding of data that was originally in ISO-8859-1, and will be in
that character set again after decoding.
Certain Content-Transfer-Encoding values may only be used on certain
media types. In particular, it is EXPRESSLY FORBIDDEN to use any
encodings other than "7bit", "8bit", or "binary" with any composite
media type, i.e. one that recursively includes other Content-Type
fields. Currently the only composite media types are "multipart" and
"message". All encodings that are desired for bodies of type
multipart or message must be done at the innermost level, by encoding
the actual body that needs to be encoded.
It should also be noted that, by definition, if a composite entity
has a transfer-encoding value such as "7bit", but one of the enclosed
entities has a less restrictive value such as "8bit", then either the
outer "7bit" labelling is in error, because 8bit data are included,
or the inner "8bit" labelling placed an unnecessarily high demand on
the transport system because the actual included data were actually
7bit-safe.
NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using
content-transfer-encodings on composite body data may seem overly
restrictive, it is necessary to prevent nested encodings, in which
data are passed through an encoding algorithm multiple times, and
must be decoded multiple times in order to be properly viewed.
Nested encodings add considerable complexity to user agents: Aside
from the obvious efficiency problems with such multiple encodings,
they can obscure the basic structure of a message. In particular,
they can imply that several decoding operations are necessary simply
Freed & Borenstein Standards Track [Page 17]
RFC 2045 Internet Message Bodies November 1996
to find out what types of bodies a message contains. Banning nested
encodings may complicate the job of certain mail gateways, but this
seems less of a problem than the effect of nested encodings on user
agents.
Any entity with an unrecognized Content-Transfer-Encoding must be
treated as if it has a Content-Type of "application/octet-stream",
regardless of what the Content-Type header field actually says.
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER-
ENCODING: It may seem that the Content-Transfer-Encoding could be
inferred from the characteristics of the media that is to be encoded,
or, at the very least, that certain Content-Transfer-Encodings could
be mandated for use with specific media types. There are several
reasons why this is not the case. First, given the varying types of
transports used for mail, some encodings may be appropriate for some
combinations of media types and transports but not for others. (For
example, in an 8bit transport, no encoding would be required for text
in certain character sets, while such encodings are clearly required
for 7bit SMTP.)
Second, certain media types may require different types of transfer
encoding under different circumstances. For example, many PostScript
bodies might consist entirely of short lines of 7bit data and hence
require no encoding at all. Other PostScript bodies (especially
those using Level 2 PostScript's binary encoding mechanism) may only
be reasonably represented using a binary transport encoding.
Finally, since the Content-Type field is intended to be an open-ended
specification mechanism, strict specification of an association
between media types and encodings effectively couples the
specification of an application protocol with a specific lower-level
transport. This is not desirable since the developers of a media
type should not have to be aware of all the transports in use and
what their limitations are.
6.5. Translating Encodings
The quoted-printable and base64 encodings are designed so that
conversion between them is possible. The only issue that arises in
such a conversion is the handling of hard line breaks in quoted-
printable encoding output. When converting from quoted-printable to
base64 a hard line break in the quoted-printable form represents a
CRLF sequence in the canonical form of the data. It must therefore be
converted to a corresponding encoded CRLF in the base64 form of the
data. Similarly, a CRLF sequence in the canonical form of the data
obtained after base64 decoding must be converted to a quoted-
printable hard line break, but ONLY when converting text data.
Freed & Borenstein Standards Track [Page 18]
RFC 2045 Internet Message Bodies November 1996
6.6. Canonical Encoding Model
There was some confusion, in the previous versions of this RFC,
regarding the model for when email data was to be converted to
canonical form and encoded, and in particular how this process would
affect the treatment of CRLFs, given that the representation of
newlines varies greatly from system to system, and the relationship
between content-transfer-encodings and character sets. A canonical
model for encoding is presented in RFC 2049 for this reason.
6.7. Quoted-Printable Content-Transfer-Encoding
The Quoted-Printable encoding is intended to represent data that
largely consists of octets that correspond to printable characters in
the US-ASCII character set. It encodes the data in such a way that
the resulting octets are unlikely to be modified by mail transport.
If the data being encoded are mostly US-ASCII text, the encoded form
of the data remains largely recognizable by humans. A body which is
entirely US-ASCII may also be encoded in Quoted-Printable to ensure
the integrity of the data should the message pass through a
character-translating, and/or line-wrapping gateway.
In this encoding, octets are to be represented as determined by the
following rules:
(1) (General 8bit representation) Any octet, except a CR or
LF that is part of a CRLF line break of the canonical
(standard) form of the data being encoded, may be
represented by an "=" followed by a two digit
hexadecimal representation of the octet's value. The
digits of the hexadecimal alphabet, for this purpose,
are "0123456789ABCDEF". Uppercase letters must be
used; lowercase letters are not allowed. Thus, for
example, the decimal value 12 (US-ASCII form feed) can
be represented by "=0C", and the decimal value 61 (US-
ASCII EQUAL SIGN) can be represented by "=3D". This
rule must be followed except when the following rules
allow an alternative encoding.
(2) (Literal representation) Octets with decimal values of
33 through 60 inclusive, and 62 through 126, inclusive,
MAY be represented as the US-ASCII characters which
correspond to those octets (EXCLAMATION POINT through
LESS THAN, and GREATER THAN through TILDE,
respectively).
(3) (White Space) Octets with values of 9 and 32 MAY be
represented as US-ASCII TAB (HT) and SPACE characters,
Freed & Borenstein Standards Track [Page 19]
RFC 2045 Internet Message Bodies November 1996
respectively, but MUST NOT be so represented at the end
of an encoded line. Any TAB (HT) or SPACE characters
on an encoded line MUST thus be followed on that line
by a printable character. In particular, an "=" at the
end of an encoded line, indicating a soft line break
(see rule #5) may follow one or more TAB (HT) or SPACE
characters. It follows that an octet with decimal
value 9 or 32 appearing at the end of an encoded line
must be represented according to Rule #1. This rule is
necessary because some MTAs (Message Transport Agents,
programs which transport messages from one user to
another, or perform a portion of such transfers) are
known to pad lines of text with SPACEs, and others are
known to remove "white space" characters from the end
of a line. Therefore, when decoding a Quoted-Printable
body, any trailing white space on a line must be
deleted, as it will necessarily have been added by
intermediate transport agents.
(4) (Line Breaks) A line break in a text body, represented
as a CRLF sequence in the text canonical form, must be
represented by a (RFC 822) line break, which is also a
CRLF sequence, in the Quoted-Printable encoding. Since
the canonical representation of media types other than
text do not generally include the representation of
line breaks as CRLF sequences, no hard line breaks
(i.e. line breaks that are intended to be meaningful
and to be displayed to the user) can occur in the
quoted-printable encoding of such types. Sequences
like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
appear in non-text data represented in quoted-
printable, of course.
Note that many implementations may elect to encode the
local representation of various content types directly
rather than converting to canonical form first,
encoding, and then converting back to local
representation. In particular, this may apply to plain
text material on systems that use newline conventions
other than a CRLF terminator sequence. Such an
implementation optimization is permissible, but only
when the combined canonicalization-encoding step is
equivalent to performing the three steps separately.
(5) (Soft Line Breaks) The Quoted-Printable encoding
REQUIRES that encoded lines be no more than 76
characters long. If longer lines are to be encoded
with the Quoted-Printable encoding, "soft" line breaks
Freed & Borenstein Standards Track [Page 20]
RFC 2045 Internet Message Bodies November 1996
must be used. An equal sign as the last character on a
encoded line indicates such a non-significant ("soft")
line break in the encoded text.
Thus if the "raw" form of the line is a single unencoded line that
says:
Now's the time for all folk to come to the aid of their country.
This can be represented, in the Quoted-Printable encoding, as:
Now's the time =
for all folk to come=
to the aid of their country.
This provides a mechanism with which long lines are encoded in such a
way as to be restored by the user agent. The 76 character limit does
not count the trailing CRLF, but counts all other characters,
including any equal signs.
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.)
NOTE: The quoted-printable encoding represents something of a
compromise between readability and reliability in transport. Bodies
encoded with the quoted-printable encoding will work reliably over
most mail gateways, but may not work perfectly over a few gateways,
notably those involving translation into EBCDIC. A higher level of
confidence is offered by the base64 Content-Transfer-Encoding. A way
to get reasonably reliable transport through EBCDIC gateways is to
also quote the US-ASCII characters
!"#$@[\]^`{|}~
according to rule #1.
Because quoted-printable data is generally assumed to be line-
oriented, it is to be expected that the representation of the breaks
between the lines of quoted-printable data may be altered in
transport, in the same manner that plain text mail has always been
altered in Internet mail when passing between systems with differing
newline conventions. If such alterations are likely to constitute a
Freed & Borenstein Standards Track [Page 21]
RFC 2045 Internet Message Bodies November 1996
corruption of the data, it is probably more sensible to use the
base64 encoding rather than the quoted-printable encoding.
NOTE: Several kinds of substrings cannot be generated according to
the encoding rules for the quoted-printable content-transfer-
encoding, and hence are formally illegal if they appear in the output
of a quoted-printable encoder. This note enumerates these cases and
suggests ways to handle such illegal substrings if any are
encountered in quoted-printable data that is to be decoded.
(1) An "=" followed by two hexadecimal digits, one or both
of which are lowercase letters in "abcdef", is formally
illegal. A robust implementation might choose to
recognize them as the corresponding uppercase letters.
(2) An "=" followed by a character that is neither a
hexadecimal digit (including "abcdef") nor the CR
character of a CRLF pair is illegal. This case can be
the result of US-ASCII text having been included in a
quoted-printable part of a message without itself
having been subjected to quoted-printable encoding. A
reasonable approach by a robust implementation might be
to include the "=" character and the following
character in the decoded data without any
transformation and, if possible, indicate to the user
that proper decoding was not possible at this point in
the data.
(3) An "=" cannot be the ultimate or penultimate character
in an encoded object. This could be handled as in case
(2) above.
(4) Control characters other than TAB, or CR and LF as
parts of CRLF pairs, must not appear. The same is true
for octets with decimal values greater than 126. If
found in incoming quoted-printable data by a decoder, a
robust implementation might exclude them from the
decoded data and warn the user that illegal characters
were discovered.
(5) Encoded lines must not be longer than 76 characters,
not counting the trailing CRLF. If longer lines are
found in incoming, encoded data, a robust
implementation might nevertheless decode the lines, and
might report the erroneous encoding to the user.
Freed & Borenstein Standards Track [Page 22]
RFC 2045 Internet Message Bodies November 1996
WARNING TO IMPLEMENTORS: If binary data is encoded in quoted-
printable, care must be taken to encode CR and LF characters as "=0D"
and "=0A", respectively. In particular, a CRLF sequence in binary
data should be encoded as "=0D=0A". Otherwise, if CRLF were
represented as a hard line break, it might be incorrectly decoded on
platforms with different line break conventions.
For formalists, the syntax of quoted-printable data is described by
the following grammar:
quoted-printable := qp-line *(CRLF qp-line)
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
; Maximum length of 76 characters
qp-segment := qp-section *(SPACE / TAB) "="
; Maximum length of 76 characters
qp-section := [*(ptext / SPACE / TAB) ptext]
ptext := hex-octet / safe-char
safe-char := <any octet with decimal value of 33 through
60 inclusive, and 62 through 126>
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; Octet must be used for characters > 127, =,
; SPACEs or TABs at the ends of lines, and is
; recommended for any character not listed in
; RFC 2049 as "mail-safe".
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
IMPORTANT: The addition of LWSP between the elements shown in this
BNF is NOT allowed since this BNF does not specify a structured
header field.
Freed & Borenstein Standards Track [Page 23]
RFC 2045 Internet Message Bodies November 1996
6.8. Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be humanly
readable. The encoding and decoding algorithms are simple, but the
encoded data are consistently only about 33 percent larger than the
unencoded data. This encoding is virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
NOTE: This subset has the important property that it is represented
identically in all versions of ISO 646, including US-ASCII, and all
characters in the subset are also represented identically in all
versions of EBCDIC. Other popular encodings, such as the encoding
used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and
the base85 encoding specified as part of Level 2 PostScript, do not
share these properties, and thus do not fulfill the portability
requirements a binary transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right, a
24-bit input group is formed by concatenating 3 8bit input groups.
These 24 bits are then treated as 4 concatenated 6-bit groups, each
of which is translated into a single digit in the base64 alphabet.
When encoding a bit stream via the base64 encoding, the bit stream
must be presumed to be ordered with the most-significant-bit first.
That is, the first bit in the stream will be the high-order bit in
the first 8bit byte, and the eighth bit will be the low-order bit in
the first 8bit byte, and so on.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string. These characters, identified in Table 1, below, are
selected so as to be universally representable, and the set excludes
characters with particular significance to SMTP (e.g., ".", CR, LF)
and to the multipart boundary delimiters defined in RFC 2046 (e.g.,
"-").
Freed & Borenstein Standards Track [Page 24]
RFC 2045 Internet Message Bodies November 1996
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances.
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body. When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups. Padding at the end of
the data is performed using the "=" character. Since all base64
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Because it is used only for padding at the end of the data, the
occurrence of any "=" characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
Freed & Borenstein Standards Track [Page 25]
RFC 2045 Internet Message Bodies November 1996
such assurance is possible, however, when the number of octets
transmitted was a multiple of three and no "=" characters are
present.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data.
Care must be taken to use the proper octets for line breaks if base64
encoding is applied directly to text material that has not been
converted to canonical form. In particular, text line breaks must be
converted into CRLF sequences prior to base64 encoding. The
important thing to note is that this may be done directly by the
encoder rather than in a prior canonicalization step in some
implementations.
NOTE: There is no need to worry about quoting potential boundary
delimiters within base64-encoded bodies within multipart entities
because no hyphen characters are used in the base64 encoding.
7. Content-ID Header Field
In constructing a high-level user agent, it may be desirable to allow
one body to make reference to another. Accordingly, bodies may be
labelled using the "Content-ID" header field, which is syntactically
identical to the "Message-ID" header field:
id := "Content-ID" ":" msg-id
Like the Message-ID values, Content-ID values must be generated to be
world-unique.
The Content-ID value may be used for uniquely identifying MIME
entities in several contexts, particularly for caching data
referenced by the message/external-body mechanism. Although the
Content-ID header is generally optional, its use is MANDATORY in
implementations which generate data of the optional MIME media type
"message/external-body". That is, each message/external-body entity
must have a Content-ID field to permit caching of such data.
It is also worth noting that the Content-ID value has special
semantics in the case of the multipart/alternative media type. This
is explained in the section of RFC 2046 dealing with
multipart/alternative.
Freed & Borenstein Standards Track [Page 26]
RFC 2045 Internet Message Bodies November 1996
8. Content-Description Header Field
The ability to associate some descriptive information with a given
body is often desirable. For example, it may be useful to mark an
"image" body as "a picture of the Space Shuttle Endeavor." Such text
may be placed in the Content-Description header field. This header
field is always optional.
description := "Content-Description" ":" *text
The description is presumed to be given in the US-ASCII character
set, although the mechanism specified in RFC 2047 may be used for
non-US-ASCII Content-Description values.
9. Additional MIME Header Fields
Future documents may elect to define additional MIME header fields
for various purposes. Any new header field that further describes
the content of a message should begin with the string "Content-" to
allow such fields which appear in a message header to be
distinguished from ordinary RFC 822 message header fields.
MIME-extension-field := <Any RFC 822 header field which
begins with the string
"Content-">
10. Summary
Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
header fields, it is possible to include, in a standardized way,
arbitrary types of data with RFC 822 conformant mail messages. No
restrictions imposed by either RFC 821 or RFC 822 are violated, and
care has been taken to avoid problems caused by additional
restrictions imposed by the characteristics of some Internet mail
transport mechanisms (see RFC 2049).
The next document in this set, RFC 2046, specifies the initial set of
media types that can be labelled and transported using these headers.
11. Security Considerations
Security issues are discussed in the second document in this set, RFC
2046.
Freed & Borenstein Standards Track [Page 27]
RFC 2045 Internet Message Bodies November 1996
12. Authors' Addresses
For more information, the authors of this document are best contacted
via Internet mail:
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.com
Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA
Phone: +1 201 540 8967
Fax: +1 201 993 3032
EMail: nsb@nsb.fv.com
MIME is a result of the work of the Internet Engineering Task Force
Working Group on RFC 822 Extensions. The chairman of that group,
Greg Vaudreuil, may be reached at:
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
EMail: Greg.Vaudreuil@Octel.Com
Freed & Borenstein Standards Track [Page 28]
RFC 2045 Internet Message Bodies November 1996
Appendix A -- Collected Grammar
This appendix contains the complete BNF grammar for all the syntax
specified by this document.
By itself, however, this grammar is incomplete. It refers by name to
several syntax rules that are defined by RFC 822. Rather than
reproduce those definitions here, and risk unintentional differences
between the two, this document simply refers the reader to RFC 822
for the remaining definitions. Wherever a term is undefined, it
refers to the RFC 822 definition.
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
composite-type := "message" / "multipart" / extension-token
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
description := "Content-Description" ":" *text
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
encoding := "Content-Transfer-Encoding" ":" mechanism
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
extension-token := ietf-token / x-token
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; Octet must be used for characters > 127, =,
; SPACEs or TABs at the ends of lines, and is
; recommended for any character not listed in
; RFC 2049 as "mail-safe".
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>
Freed & Borenstein Standards Track [Page 29]
RFC 2045 Internet Message Bodies November 1996
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
id := "Content-ID" ":" msg-id
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
MIME-extension-field := <Any RFC 822 header field which
begins with the string
"Content-">
MIME-message-headers := entity-headers
fields
version CRLF
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.
MIME-part-headers := entity-headers
[fields]
; Any field not beginning with
; "content-" can have no defined
; meaning and may be ignored.
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.
parameter := attribute "=" value
ptext := hex-octet / safe-char
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
; Maximum length of 76 characters
qp-section := [*(ptext / SPACE / TAB) ptext]
qp-segment := qp-section *(SPACE / TAB) "="
; Maximum length of 76 characters
quoted-printable := qp-line *(CRLF qp-line)
Freed & Borenstein Standards Track [Page 30]
RFC 2045 Internet Message Bodies November 1996
safe-char := <any octet with decimal value of 33 through
60 inclusive, and 62 through 126>
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
subtype := extension-token / iana-token
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
type := discrete-type / composite-type
value := token / quoted-string
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
Freed & Borenstein Standards Track [Page 31]
|