-
Notifications
You must be signed in to change notification settings - Fork 4
/
22.txt
65 lines (52 loc) · 3.65 KB
/
22.txt
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
*媒体型パラメーター
,charset ,mime.charset ,非標準 ,charset
,[CODE(MIME)[[[x-spam-type]]]],,非標準,[[spam]] 処理情報
charset なんてパラメーターは定義されていません。
charset=us-ascii なんていう意味の無いものをつけてくる
MUA (MTA?) があるみたいです。
実装は無視する'''べき'''です。 charset パラメーターに
従って無理矢理変換すると、メッセージが壊れる可能性があります。
(charset=utf-16 だったりしたら、変換しないと壊れるだろうがなあ・・・。)
*RFC 2046 5.2.1. RFC822 Subtype
A media type of "message/rfc822" indicates that the body contains an
encapsulated message, with the syntax of an RFC 822 message.
However, unlike top-level RFC 822 messages, the restriction that each
"message/rfc822" body must include a "From", "Date", and at least one
destination header is removed and replaced with the requirement that
at least one of "From", "Subject", or "Date" must be present.
媒体型 "message/rfc822" は、本文が RFC 822 メッセージの構文の
カプセル化メッセージであることを示します。しかし、最上位 RFC 822
メッセージとは異なり、各 "message/rfc822" 本文が "From", "Date",
最低一つの宛先頭を入れなければならないという制限は撤廃し、
代わりに要件を "From", "Subject", "Date" の最低一つが無ければならない
とします。
It should be noted that, despite the use of the numbers "822", a
"message/rfc822" entity isn't restricted to material in strict
conformance to RFC822, nor are the semantics of "message/rfc822"
objects restricted to the semantics defined in RFC822. More
specifically, a "message/rfc822" message could well be a News article
or a MIME message.
注意されたいこととしては、「822」という番号を使ってはいますが、
"message/rfc822" 実体は RFC 822 に厳密に適合するものに制限しませんし、
"message/rfc822" 物体の意味を RFC 822 で定義された意味にも制限しません。
具体的には、 "message/rfc822" メッセージは、ニュース投稿や
MIME メッセージにも使うことが出来ます。
No encoding other than "7bit", "8bit", or "binary" is permitted for
the body of a "message/rfc822" entity. The message header fields are
always US-ASCII in any case, and data within the body can still be
encoded, in which case the Content-Transfer-Encoding header field in
the encapsulated message will reflect this. Non-US-ASCII text in the
headers of an encapsulated message can be specified using the
mechanisms described in RFC 2047.
"7bit", "8bit", "binary" 以外の符号化は "message/rfc822" 実体の本文には
認められていません。メッセージ頭領域は常にどんな場合も US-ASCII
で、本文中のデータは符号化されていても構いません。その場合はカプセル化
メッセージの Content-Transfer-Encoding 頭領域がこれを反映しています。
カプセル化メッセージの頭中の非 US-ASCII 文は、 RFC 2047 で説明されている
方法を使って記述出来ます。
* memo
[1] [CITE[qmail RFC violations]] ([TIME[2005-12-14 00:00:05 +09:00]] 版) <http://ya.maya.st/mail/qmail-violations.html>
[2] [CITE[FGA: Some of what is said about "qmail" is wrong]] ([TIME[2004-12-08 10:45:51 +09:00]] 版) <http://homepages.tesco.net/J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutBareLFs>
[3] [CITE@en[RFC 7103 - Advice for Safe Handling of Malformed Messages]]
( ([TIME[2014-01-27 23:43:50 +09:00]] 版))
<http://tools.ietf.org/html/rfc7103>