Re: 自ホスト（名｜アドレス）を取 得 する汎用的な方法

[Masanori HATA]

畑です。

# 話が MIME に及んだので、fj.net.mime にもクロスポストします。
# Follow 先は適宜削ってください。

Shinji KONO wrote:
> あぁ、それは割りと大変ですね。MIME header は空白と改行の
> 扱いにプロトコル上の欠陥があるので完全な対応は不可能です。
> 妥協しないと。

この辺の詳細をご教示願えませんでしょうか？　扱いがややこしいのはわかるの
ですが、RFC 2047 を見る限り欠陥という風に思えるところには気がつかなかっ
たので……。

> nkf には mime encode は入れてないし。外部コマンドならいくつ
> かあるはずですけど。metamail は古いか。MH の mhn とか。:-p

nkf って有名なツールだということは知っていたのですが、河野さんが開発者の
お一人だと、今回初めて知りました。-_-;

# これだから、非 UNIX User は……。

--
Masanori HATA

[Hideki Kato]

加藤＠ＯＤＮです．

In article <dn3oc8$366$1...@caraway.media.kyoto-u.ac.jp>, Masanori HATA wrote:
>畑です。
>
># 話が MIME に及んだので、fj.net.mime にもクロスポストします。
># Follow 先は適宜削ってください。
>
>Shinji KONO wrote:
>> あぁ、それは割りと大変ですね。MIME header は空白と改行の
>> 扱いにプロトコル上の欠陥があるので完全な対応は不可能です。
>> 妥協しないと。
>
>この辺の詳細をご教示願えませんでしょうか？　扱いがややこしいのはわかるの
>ですが、RFC 2047 を見る限り欠陥という風に思えるところには気がつかなかっ
>たので……。

長い場合は分割しなければなりませんから，複数の encoded word の処理は必須
です．この encoded words の間の空白類の処理が問題になります．

自己矛盾するわけにはいきませんから，上記空白類の処理に関して，
１．符号化時に encode してしまい，復号時には削除する．
２．符号化時に残し，復号時にも残す（encoded word には空白は入れない)．
２’．符号化時に残し，復号時には一個にしてしまう．
の３種類位が考えられますが，どの方法でも何らかの問題が起きます．

>モジュール側が自動で（折り返しも考慮に入れて）
>MIME ヘッダ化（ただし、US-ASCII も含めて丸ごと MIME ヘッダ化する手抜きは
>しないやり方で）してくれるようなものを作ろうとしています。

例えば，この記述から畑さんは１．を採用されるおつもりのようですが，これで
すと２．の方針のものを復号した時に単語間の空白が無くなってしまいます．
--
Hideki Kato <mailto:ka...@pop12.odn.ne.jp>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Masanori HATA]

畑です。

Hideki Kato wrote:
>>>あぁ、それは割りと大変ですね。MIME header は空白と改行の
>>>扱いにプロトコル上の欠陥があるので完全な対応は不可能です。
>>>妥協しないと。
>>
>>この辺の詳細をご教示願えませんでしょうか？　扱いがややこしいのはわかるの
>>ですが、RFC 2047 を見る限り欠陥という風に思えるところには気がつかなかっ
>>たので……。
>
> 長い場合は分割しなければなりませんから，複数の encoded word の処理は必須
> です．この encoded words の間の空白類の処理が問題になります．
>
> 自己矛盾するわけにはいきませんから，上記空白類の処理に関して，
> １．符号化時に encode してしまい，復号時には削除する．
> ２．符号化時に残し，復号時にも残す（encoded word には空白は入れない)．
> ２’．符号化時に残し，復号時には一個にしてしまう．
> の３種類位が考えられますが，どの方法でも何らかの問題が起きます．

> 例えば，この記述から畑さんは１．を採用されるおつもりのようですが，これで
> すと２．の方針のものを復号した時に単語間の空白が無くなってしまいます．

RFC 2047 の「6.2. Display of 'encoded-word's」によると
> When displaying a particular header field that contains multiple
> 'encoded-word's, any 'linear-white-space' that separates a pair of
> adjacent 'encoded-word's is ignored. (This is to allow the use of
> multiple 'encoded-word's to represent long strings of unencoded text,
> without having to separate 'encoded-word's where spaces occur in the
> unencoded text.)

となっていて、「encoded-word と encoded-word の間の空白文字は表示時に無
視される」と書いてあるので、復号時の挙動に関してはは１．の方針が（RFC
的）標準だと考えていました。

また、その復号時の方針を前提として、符号化時の挙動に関しては、（encode
される文字列に挟まれた）空白文字を内包して encode してしまった後、元から
あった（例えば subject の原文として存在した）空白文字とは別個に、encoded
-word と encoded-word を separate するためのデリミタとしての空白文字を新
たに追加して最終的な MIME header 文字列とする、という方針を採用しています。

--
Masanori HATA

[Hideki Kato]

加藤＠ＯＤＮです．

In article <dnas3u$6vi$1...@caraway.media.kyoto-u.ac.jp>, Masanori HATA wrote:
>畑です。

>RFC 2047 の「6.2. Display of 'encoded-word's」によると

>> When displaying a particular header field that contains multiple
>> 'encoded-word's, any 'linear-white-space' that separates a pair of
>> adjacent 'encoded-word's is ignored. (This is to allow the use of
>> multiple 'encoded-word's to represent long strings of unencoded text,
>> without having to separate 'encoded-word's where spaces occur in the
>> unencoded text.)
>
>となっていて、「encoded-word と encoded-word の間の空白文字は表示時に無
>視される」と書いてあるので、復号時の挙動に関してはは１．の方針が（RFC
>的）標準だと考えていました。

本来はそうするのが正しいのかも知れませんが，欧米圏では，encode はそれが
必要な単語のみに対して行い，単語間の空白は encode せずそのまま残す，とい
う実装が広く採用されていた様に記憶しています．
＃元々分かち書きされている言語ではそれが自然なんでしょう．．．

>また、その復号時の方針を前提として、符号化時の挙動に関しては、（encode
>される文字列に挟まれた）空白文字を内包して encode してしまった後、元から
>あった（例えば subject の原文として存在した）空白文字とは別個に、encoded
>-word と encoded-word を separate するためのデリミタとしての空白文字を新
>たに追加して最終的な MIME header 文字列とする、という方針を採用しています。

これは必然でしょう．（確か）デリミタの空白無しはまずかった（きちんとデ
コードされない事があった）と記憶しています．

＃規則に関係した話と既存のメイラー絡みの問題がごっちゃになっていますが，
＃ご容赦下さい．

[Masanori HATA]

畑です。

Hideki Kato wrote:
>>RFC 2047 の「6.2. Display of 'encoded-word's」によると
>>
>>>When displaying a particular header field that contains multiple
>>>'encoded-word's, any 'linear-white-space' that separates a pair of
>>>adjacent 'encoded-word's is ignored. (This is to allow the use of
>>>multiple 'encoded-word's to represent long strings of unencoded text,
>>>without having to separate 'encoded-word's where spaces occur in the
>>>unencoded text.)
>>
>>となっていて、「encoded-word と encoded-word の間の空白文字は表示時に無
>>視される」と書いてあるので、復号時の挙動に関してはは１．の方針が（RFC
>>的）標準だと考えていました。
>
> 本来はそうするのが正しいのかも知れませんが，欧米圏では，encode はそれが
> 必要な単語のみに対して行い，単語間の空白は encode せずそのまま残す，とい
> う実装が広く採用されていた様に記憶しています．
> ＃元々分かち書きされている言語ではそれが自然なんでしょう．．．

（中略）
> ＃規則に関係した話と既存のメイラー絡みの問題がごっちゃになっていますが，
> ＃ご容赦下さい．

なるほど、加藤さんのご指摘で畑のぼんやりした頭が多少クリアになりました。
僕の発想が、RFC さえ規範にしていれば、あとはどうでもいいや──的な、態度で
あったのが問題だったみたいです。メイラーの実装実態のことについては相当無
頓着でした。

少なくとも、日本語では、encode に関しては「文字列中の範囲」として考える
方がいいと思いますが（ISO-2022-JP の発想がこれですよね）、欧語の場合は、
個別の単語を encode するか否かという発想になるのでしょうね。RFC 2047 中
で ABNF で
phrase = 1*( encoded-word / word )
と定義されているわけですね。

# 結局、UTF-8 のメールを送信テストしてみたところ、（相当ユーザ人口があ
# ると思われる）Yahoo! Japan の Web メーラでは、UTF-8 に未対応で文字化
# け（MIME はちゃんとデコードするのにね）してガックリ。要望は出してお
# いたけど、いつになったら対応してもらえるのやら。
# あと、携帯メールなんかも未だ UTF-8 は駄目かもれませんね。

--
Masanori HATA

[Masanori HATA]

畑です。

# 題名を変えて、ポスト先・フォローアップ先も変えておきます。

Shinji KONO wrote:
>>この辺の詳細をご教示願えませんでしょうか？　扱いがややこしいのはわかるの
>>ですが、RFC 2047 を見る限り欠陥という風に思えるところには気がつかなかっ
>>たので……。
>

> =?...?= の間には任意の空白改行を入れて良いですよね。一方で、
> 空白はbase64 encodeしないっていうルールがあるので、元からあ
> る空白は、=?...?= の外にでます。さらに、長くなりすぎたbase64
> は適当に分割して良いってことになってます。この時に=?...?= を
> 続けてはだめで、空白または改行をいれなくてはなりません。
>
> ってことは、元からある空白と、長くなり過ぎて分割された空白と
> は区別がつきません。この空白を無くすことは元々の空白を消す可
> 能性があるので、それは許されません。消さないと余計な空白が入
> る可能性があります。
>
> HTMLでも類似の問題があって改行されたHTML textは、表示される
> 時に改行が変更されますが、その時に強制的に一つ空白がはいりま
> す。入れないと英語が読めなくなり、入れると日本語が不自然にな
> ります。
>
> 単語を空白で区切る言語とかはそれで問題ないんですが、日本語み
> たいに長い空白のない文が続く言語で分割が起きると、不自然に空
> 白が挿入されてしまいます。空白が増えると分割される可能性が増
> えるので、さらに空白が増えるという現象が起きます。
>
> HTMLは改行自体を削ってしまえば良いんですが、MIME subject で
> はそれもできない。空白改行を含めてencodeして、=?...?= 間の空
> 白改行は無視するとか、?= の他に「続く空白改行を無視する終了
> マーク」を用意するとかすれば解決するんですけどね。

MIME (RFC 2047) というよりも RFC 2822 のヘッダの折り返し（folding）ルー
ル自体の欠陥のせいみたいですね。

RFC 2822 の WSP として定義されているものを SP と HTAB で使い分けるように
修正すれば従来の（欧語中心に設計された）仕様に大きな影響を与えることな
く、日本語（中国語・韓国語も同様ですが）にとっての欠陥を解消できるように
思えます。

HTAB を FWS として使用した場合は、折り返し解除（unfolding）時に削除され
る WSP として扱うというルールにすればいいと思うわけです。

from RFC 2822:
> Unfolding is accomplished by simply removing any CRLF that is
> immediately followed by WSP.

Modification idea for RFC 2822:
Unfolding is accomplished in two ways:
1. By simply removing any CRLF that is immediately followed by SP.
2. By removing any CRLF (that is immediately followed by HTAB)
together with the following HTAB.

そもそも、HTAB なんて制御文字なので、題名やアドレスの表示名の空白として
使う人は欧米でも少ないと思われます。

こういうことにすれば、8bit システム下では、MIME エンコードヘッダは不要に
なり、quoted-string さえ必要なときに用いれば、生 UTF-8 の題名
（unstructured）やアドレス（structured）の表示名（display-name）でも可能
になりますね。

--
Masanori HATA

[Masanori HATA]

畑です。その後（:-D）です。

# フォロー内容によってフォロー先をお絞り下さい。

Masanori HATA wrote:
> MIME (RFC 2047) というよりも RFC 2822 のヘッダの折り返し（folding）ルー
> ル自体の欠陥のせいみたいですね。
>
> RFC 2822 の WSP として定義されているものを SP と HTAB で使い分けるように
> 修正すれば従来の（欧語中心に設計された）仕様に大きな影響を与えることな
> く、日本語（中国語・韓国語も同様ですが）にとっての欠陥を解消できるように
> 思えます。
>
> HTAB を FWS として使用した場合は、折り返し解除（unfolding）時に削除され
> る WSP として扱うというルールにすればいいと思うわけです。

（中略）

> こういうことにすれば、8bit システム下では、MIME エンコードヘッダは不要に
> なり、quoted-string さえ必要なときに用いれば、生 UTF-8 の題名
> （unstructured）やアドレス（structured）の表示名（display-name）でも可能
> になりますね。

──なんてことを考えたりしていましたが、もう一つ別なやり方を考えました。

それは、長い文字列を折り返するために、強制的に空白文字を挿入する場合、空白
文字の後に続けて、制御文字のBS（バックスペース：ASCIIコード8）をペアにする
という方法です。これも、メールリーダ側でBSの解釈についてコンセンサスを得ら
れていなければ、意味はありませんので、単なる提案にすぎませんが。

そんなわけで、unstructured ヘッダ（例：題名ヘッダ）に関して、RFC 2047 の
MIME 符号化ヘッダ方式を無視して、MIME 符号化しない、素の UTF-8 の文字列を
RFC 2822 の制限文字数 78 バイト以内に折返しする方式を採用してみました。や
っているのは、多バイト長文字の場合は、途中で強制改行がされることのないよう
に注意している程度です。

下にプロトタイプを載せておきます。

# 再帰的表現ですっきり書けたつもりです。;-)
# ついでに日本語使いまくり。

MIME 符号化する方式のものはまた別途作る予定です。

--
Masanori HATA

#!/usr/local/bin/perl -w
use 5.008;
use strict;
use warnings;
use utf8;

use Carp;

# 定数の宣言
my $行長 = 78;
my $短語 = $行長 - 1;
my $長語 = $短語 + 1;
my $改行 = "\x0D\x0A";
my $空白文字種 = "\x20\x09";
my $第八位文字種 = "\x80-\xFF";
my $強制改行時空白 = "\x20\x08";

# パッケージ内グローバル変数の宣言
my($処理済, $未処理);

sub 短いASCII語 ($) {
my $処理対象 = $_[0];

$処理済 =~ m/($改行|^)([^$改行]*)$/;
my $最後尾 = $2;

if (length($処理対象) <= $行長 - length($最後尾)) {
$処理済 .= $処理対象;
}
else {
$処理済 .= $改行 . $処理対象;
}
}

sub 長いASCII語 ($) {
my $処理対象 = $_[0];

$処理済 =~ m/($改行|^)([^$改行]*)$/;
my $最後尾 = $2;

my $余地 = $行長 - length($最後尾);

if ($余地 and $余地 >= length($処理対象)) {
$処理済 .= $処理対象;
}
elsif ($余地) {
$処理済 .= substr($処理対象, 0, $余地);
# 再帰
&長いASCII語( substr($処理対象, $余地) );
}
else {
$処理済 .= $改行 . $強制改行時空白;
# 再帰
&長いASCII語($処理対象);
}
}

sub 長い第八位文字含有語 ($) {
utf8::decode(my $処理対象 = $_[0]);
utf8::encode(my $一文字 = substr($処理対象, 0, 1));

$処理済 =~ m/($改行|^)([^$改行]*)$/;
my $最後尾 = $2;

if (length($一文字) <= $行長 - length($最後尾)) {
$処理済 .= $一文字;
}
else {
$処理済 .= $改行 . $強制改行時空白 . $一文字;
}

utf8::encode(my $残り = substr($処理対象, 1));
# 再帰
&長い第八位文字含有語($残り) if $残り;
}

sub 折返す ($$) {
$処理済 = $_[0] . ':';
utf8::encode($未処理 = "\x20" . $_[1]);

while ($未処理) {
if ($未処理 =~ s/^[$空白文字種][^$空白文字種]{1,$短語}(?=[$空白文字種]|$)//) {
短いASCII語($&);
}
elsif ($未処理 =~ s/^[$空白文字種]//) {
短いASCII語($&);
}
elsif ($未処理 =~ s/^[^$空白文字種^$第八位文字種]{$長語,}(?=[$空白文字種]|$)//) {
長いASCII語($&);
}
elsif ($未処理 =~ s/^[^$空白文字種]{$長語,}(?=[$空白文字種]|$)//) {
長い第八位文字含有語($&);
}
else {
carp 'unsupposed regex error: ' . $未処理 . ';';
}
}
}

# 以下、使用例
my $領域名 = 'Subject';
my $領域内容 = 'これは筆です。これは筆です。これは筆です。これは筆です。';
折返す($領域名, $領域内容);
print $処理済;

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <dp0i4q$d3k$1...@caraway.media.kyoto-u.ac.jp>

Masanori HATA <ha...@iname.com> writes:
> それは、長い文字列を折り返するために、強制的に空白文字を挿入する場合、空白
> 文字の後に続けて、制御文字のBS（バックスペース：ASCIIコード8）をペアにする
> という方法です。これも、メールリーダ側でBSの解釈についてコンセンサスを得ら
> れていなければ、意味はありませんので、単なる提案にすぎませんが。

nroff みたいで面白いけれど、筋が違う気がします。規格としては、
1000バイトくらいの長い行を許して、「行の折り返しはやらないこ
とにする」という方が簡単だと思います。

nroff は、BS で二重打ちしたり下線を引いたりします。less など
はそれを解釈してエスケープシーケンスに変えます。nroff は、
Unix の man コマンドが使っているやつね。

rough consensus and running code 方式も短期的にはいいけれど、
長期的には損ということも最近目立つ気がします。ドメイン名の表
記とか、それをひどくした URL とか。MIME のボロボロの規格も30
年後も使ってたら笑うけれど、直すなら早い方がいいわけです。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

In article <YAS.05De...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes

> nroff みたいで面白いけれど、筋が違う気がします。規格としては、
> 1000バイトくらいの長い行を許して、「行の折り返しはやらないこ
> とにする」という方が簡単だと思います。

日本語の改行と英語の改行を区別するとか、全部をbase64とか、
まぁ、いろいろ方法はありますね。

> rough consensus and running code 方式も短期的にはいいけれど、
> 長期的には損ということも最近目立つ気がします。ドメイン名の表
> 記とか、それをひどくした URL とか。MIME のボロボロの規格も30
> 年後も使ってたら笑うけれど、直すなら早い方がいいわけです。

まったく....
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科

[Masanori HATA]

畑です。

Yasushi Shinjo wrote:
>>それは、長い文字列を折り返するために、強制的に空白文字を挿入する場合、空白
>>文字の後に続けて、制御文字のBS（バックスペース：ASCIIコード8）をペアにする
>>という方法です。これも、メールリーダ側でBSの解釈についてコンセンサスを得ら
>>れていなければ、意味はありませんので、単なる提案にすぎませんが。
>
> nroff みたいで面白いけれど、筋が違う気がします。規格としては、
> 1000バイトくらいの長い行を許して、「行の折り返しはやらないこ
> とにする」という方が簡単だと思います。

公の規格の話というよりも、単なる自主ルールという程度のつもりでした。
とはいえ、「行の折返しはやらないことにする」はいい考えだと思いますので、
（自分が書くフォームメーラ用のメール文作成プログラムでは）選択方式にする
ことにします。

1. 折返ししないが、1000バイト制限を課す。
2. 強制折返し（SP + BS を勝手に挿入）する代わりにサイズ制限はない。

> rough consensus and running code 方式も短期的にはいいけれど、
> 長期的には損ということも最近目立つ気がします。ドメイン名の表
> 記とか、それをひどくした URL とか。MIME のボロボロの規格も30
> 年後も使ってたら笑うけれど、直すなら早い方がいいわけです。

この点については、新城さんや河野さんたちのおっしゃることはわかるのです
が、*実際問題として*直せるのでしょうか？　RFC 822 がやっと改訂されて RFC
2822 になったと思ってもあんな状態なわけですし、QWERTY なキーボード配列と
同じで、一旦走り出してしまったものを根こそぎ変えるのは中々容易でないと思
います。未だ走り出していないものをこれから新しく立ち上げるにあたって、
rough consensus を戒め、走り始めさせる前にじっくり練り上げるべき、という
話としてはわかります。

結局、実装にあたっては、走っている現状と理想をにらめっこして、敢えて採る
もの、敢えて捨てるもの、を自分で決めるしかないです。:-(

# でも確かに、ドメイン名についてはかなり強く賛成します。
# 国際ドメイン名になったところで、.jp と肝心の TLD がアルファベットでは
# ゲンナリしますね。TLD が日本語になって例えば .日本 とかになっても、な
# んだかドット区切のドメイン名の方式自体が日本語に合わない。
#「東京.日本」というドメイン名よりは「日本の東京」という表記の法が日本
# 語に馴染む。

--
Masanori HATA

[Masanori HATA]

畑（自己フォロー）です。

Masanori HATA wrote:
> 1. 折返ししないが、1000バイト制限を課す。
> 2. 強制折返し（SP + BS を勝手に挿入）する代わりにサイズ制限はない。

ここを修正。

1. 1000バイト長まで折返ししない。超過した場合のみ、SP+BS勝手挿入による強
制折返し。
2. 78バイト長まで折返ししない。超過した場合のみ、SP+BS勝手挿入による強制
折返し。

--
Masanori HATA

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <dp2a26$3j3$1...@caraway.media.kyoto-u.ac.jp>

Masanori HATA <ha...@iname.com> writes:
> > rough consensus and running code 方式も短期的にはいいけれど、
> > 長期的には損ということも最近目立つ気がします。ドメイン名の表
> > 記とか、それをひどくした URL とか。MIME のボロボロの規格も30
> > 年後も使ってたら笑うけれど、直すなら早い方がいいわけです。
> この点については、新城さんや河野さんたちのおっしゃることはわかるのです
> が、*実際問題として*直せるのでしょうか？

年末年始というか、正月には、自由な視点でいろいろ考えるとよい
かと思います。個人的には「我々はバカだから直せない」という思
考パタンは、普段はしません。

> # でも確かに、ドメイン名についてはかなり強く賛成します。
> # 国際ドメイン名になったところで、.jp と肝心の TLD がアルファベットでは
> # ゲンナリしますね。TLD が日本語になって例えば .日本 とかになっても、な
> # んだかドット区切のドメイン名の方式自体が日本語に合わない。

左から右にして欲しかったよね。「／日本／茨城」とか。URL のファ
イル名は、そうしているし。先頭が「／」でなければ相対名という
のも欲しい。

Java のパッケージ名に使うドメイン名は、左から右なので、少し
はいいです。ただ、ドメイン名自体が時間的な概念を含んでしまっ
ているので、長期間使うプログラムだとやはり問題です。（ドメイ
ン名が滅んで、プログラムが残る時に困る。）

> 公の規格の話というよりも、単なる自主ルールという程度のつもりでした。

結局は、小さいレベルではミームの戦いになっているのかもね。こ
うして、いいミームが増えていくといいけれど。

RFC822 については、古いメールのテキストが大量に残っているわ
けで、それを捨てるわけにもいかないので、RFC2822 が出てきても
必要性は残ります。メタ情報として「このメッセージは何年頃作ら
れた」のようなことがないと、うまく解釈できないのでしょう。

MIME の type に、message/rfc822 とか出てくるのは、見ている方
が恥ずかしい気がします。

[Eisaku YAMAGUCHI]

山口です．

随分時間も経っているようですので，ピンポイントに反応です．

Masanori HATA <ha...@iname.com> writes:

> 畑（自己フォロー）です。
>
> Masanori HATA wrote:
> > 1. 折返ししないが、1000バイト制限を課す。
> > 2. 強制折返し（SP + BS を勝手に挿入）する代わりにサイズ制限はない。
>
> ここを修正。
>
> 1. 1000バイト長まで折返ししない。超過した場合のみ、SP+BS勝手挿入による強
> 制折返し。

RFC では復帰改行込みで 1000 Octet までとされていますが，
sendmail の実装では 990 Octet に丸められるよう強制的に復帰改行が入りま
す．これはハードコーディングです．
また，Postfix はパラメータで調整できるようになっていた筈ですが，
sendmail のハードコーディングに倣って default で 990 Octet になって
います．

p.s.
MIME Encode された文字列にも長さの制限がありますから，それを遵守するよ
うにしないと，受け手に対して攻撃的な送信方法になります．

--
Eisaku YAMAGUCHI <eisaku (at-mark) ist.aichi-pu.ac.jp>
ヘッダでは調査活動のため，到達可能な別アドレスを名乗っています

[Masanori HATA]

畑です。

# 個人的な話ですが、今 BASIC（MS QBasic）だとか、ハッシュ値の計算に興味
# の対象が移ってしまっていて、本スレッド関係の Perl モジュールの開発は
# 中途で放置されている状態です。(^^;

Eisaku YAMAGUCHI wrote:
>>1. 1000バイト長まで折返ししない。超過した場合のみ、SP+BS勝手挿入による強
>>制折返し。
>
> RFC では復帰改行込みで 1000 Octet までとされていますが，
> sendmail の実装では 990 Octet に丸められるよう強制的に復帰改行が入りま
> す．これはハードコーディングです．
> また，Postfix はパラメータで調整できるようになっていた筈ですが，
> sendmail のハードコーディングに倣って default で 990 Octet になって
> います．

情報ありがとうございます。sendmail の実装の話については知りませんでし
た。これは、本件に限らず、RFC の規定と sendmail の実装との間に生じる一般
的な問題ということになると思いますが、何らかの考慮が必要ですね。:/

# 通常、題名やアドレスの表示名が 998 octet 超になることは稀なので、
# このあたりの規定と実装は曖昧なまま放置されてるのかもしれませんね。

> p.s.
> MIME Encode された文字列にも長さの制限がありますから，それを遵守するよ
> うにしないと，受け手に対して攻撃的な送信方法になります．

本件の場合は「MIME Encode を敢えて使わない」（生の多バイト長文字を使用す
る）というやり方を仮定した話になりますが、MIME Encode については、もし
encoded-word を使用する場合は RFC に則って長さ制限（75 文字）を遵守する
しかないと思います。

--
Masanori HATA