🚀 go-pugleaf

In article <69dogm$9oa@masamune.dais.is.tohoku.ac.jp>,
  kabe@dais.is.tohoku.ac.jp writes:

> >> RFC1468 を字面通りに解釈して適用するなら明らかに不正です。
> 
> １．理由は single-byte-seq がない、ということだけなんでしょうか。
>   CRLFでないとか、文字が文字として扱われていないことは問題外？

SMTP で転送する時の形態が問題になりますので(実をいうと確認したことはな
いんですが)改行は CRLF になっているはずです。たしかにそのような意味で
は uuencode の結果がそのままメールの中に含まれる, というのはいいすぎだっ
たかもしれません。
(bare-LF で直接送ることもできなくはありませんが...)

「文字が文字として扱われていない」というのは意図がよくわかりません。

> ２．ではRFC1468適合にてuuencodeされたエンティティをmessageに含めるには
>   どうするのが「正しい」んでしょうか。

まず, uuencode されたものが入っているかどうかにかかわらず, メール末尾
の問題を考えれば RFC1468 の字面通りのメールを生で SMTP で送ることはで
きません。
(詳しくは <rsqu3bbm6mq.fsf@carbon.jaist.ac.jp> を見て下さい。NNTP になっ
てますが SMTP でも同じです。)

この問題を解決するために使える手段は(私が知っている範囲では) 2つありま
す。

1. MIME の multipart/mixed でくるむ。
  multipart においては個々のパートは CRLF で終らなくても構いませんので 
RFC1468 に従ったメッセージを詰め込むことができます。

2. MIME で Content-Transfer-Encoding: base64 としてしまう。
  こーすれば base64 でエンコードした上で任意のバイト列を送れますから,
RFC1468 に従ったメッセージを送ることができます。
(ただし, RFC1468 は何故かヘッダ込みで Formal Syntax を書いてありますか
ら, これにも従おうとすると, base64 は使えません。なんでかっていうと 
MIME では message/rfc822 は base64 で送ってはいけないと決まっているか
らです。)
(quoted-printable でもかまいません。)

さて, 上のどちらかをつかって RFC1468 に従ったメールを SMTP で送れるよ
うになったとしましょう。

そうすると, 次は何とかして uuencode の結果を RFC1468 に合う形式にして
あげなければいけません。

uuencode の結果を文字列と思うのならば話は簡単です。printable ASCII の
文字列を RFC1468 に従うようなバイト列に「エンコード」する方法はたくさ
んありますのでそうすればいいわけです。ようするに ASCII の designator 
を各行に少なくとも 1つ(base64 しないならば多くとも 332個くらい)入れる
わけですが。

uuencode の結果をバイト列と思うならば... uuencode の結果全体が 1行にな
るわけですから, end 直後の bare-LF の後にでも designator を入れておけ
ばいいんじゃないでしょうか。これを生で SMTP に通すと uuencode 全体に 
998バイト制限がかかるので, 使い物にならないとは思いますけれど。
(それに, MIME の text/* では bare-LF, bare-CR を使ってはいけないという
制限に引っかかることになります。)

> ３．charset=ISO-2022-JP でないmessage(charsetなしを含む)に対しては
>   一般にどうするのが「正しい」んでしょうか。

uuencode の結果を文字列だと思う限りは charset でどのような文字を表現で
きるのか, ということに問題は帰着します。

たとえば, Shift_JIS は(解釈によっては)uuencode の結果に含まれる文字を
全ては送れません。
(Shift_JIS は (JIS X 0208 のほうを FULLWIDTH REVERSE SOLIDUS だと思え
ば) REVERSE SOLIDUS --- バックスラッシュ --- は送れません... よね?)

また, charset がない場合は送信, 受信双方での合意が問題となります。
(正確にはたとえ charset があっても「charset を有効とみなす」という合意
がないといけないわけですけれど。)

送信, 受信双方で MIME を適用することに合意しているなら話は簡単です。
MIME では charset なしなら US-ASCII と決まっていますから, uuencode の
結果は何の問題もなく表現できます。しかも, 内部表現が ASCII なら(改行を
考えなければ)直接ほうり込んでもかまわない, という幸せな状況となります。

MIME を適用しないならば... 個々の約束にしたがって下さい。

> ４．当方では今までは偶然、生のuuencodeを含むメールをやりとりしていて
>   不都合はありませんでしたが、RFC1468的に「正しい」方法を使用すると、
>   建前はともかく現実に不都合は増えるでしょうか、減るでしょうか。

増えるでしょう。

(NetNews の話になってしまいますが)
MSIN では uuencode されたデータを見つけ出すのに失敗するようです。

また, Mozilla で designator だけが含まれる行が空行に見えない, という話
もあります。(自分で見たわけではないのでいまひとつ挙動をちゃんと理解し
ているかどうかは自信がないのですが。)

> ５．なぜend行だけやり玉に挙げられるのでしょうか。他の行については
>   問題はないんでしょうか。

「end 行は RFC に照らし合わせて問題ない」という類の主張をたくさん見か
けて我慢ができなくなったからです。
(RFC を参照するならちゃんと読んで欲しい...)

もちろん, 他の行にも問題はあります。

> ６．この記事は「不正」でしょうか。それによる弊害は。

RFC1468 を字面通りに適用すれば不正であり, 弊害は私の知る限りでは存在し
ません。
-- 
[田中 哲][たなか あきら][Tanaka Akira]