最終更新

電信八号 ― バグ/脆弱性レポート


電信八号についての不具合を広報するページです。
主に公開版リリース後に発見されたものについて扱います。既知の不具合や制限事項については、付属のヘルプをご覧ください。
※ その他細かな不具合については、電信八号パッチ一覧を御覧ください。

  現最新公開版は、V32.1.7.5 です。

V32.1.7.1

Windowsのテンポラリフォルダー(環境変数 temp、もしくは tmp)にドライブのルート(W:\ など)を指定していると、動作に支障があります。

ドライブルートが指定されていると、添付ファイル付きメールを開くときに 「SHGetFileInfo returned NULL」というエラーが発生し、添付ファイルが取り出せません。
テンポラリフォルダーには W:\temp の様に、サブフォルダーを指定してください。電八用の環境変数を設定することも可能です。詳しくは FAQ#4.10 を参照してください。

この不具合は、V32.1.7.3で解消されました。

Windows8(8.1を含む)で、ログウインドウを表示したまま電八を終了しようとしても終了できない場合があります。

これは制限事項として認識されており、V32.1.7.3で解消されました。

Windows Vista以降で、フォルダを最小化したときにフォルダ名が満足に表示されません。

標準の視覚テーマはウインドウ右上のボタンの横幅がXP以前よりも大きくなっており、フォルダを最小化した際、タイトルバーのフォルダ名を表示するスペースがかなり狭くなってしまいます。

これは制限事項として認識されており、V32.1.7.3で対策機能が付きました。詳しくは FAQ#4.9 を参照して下さい。


過去のレポート

 以下の記述は旧公開版に対するもので、最新版 では解消されています。
 ※ 元々不正な [UP!] krnlupd3.exe 問題を除く。

V32.1.6.1

メールフォルダを自動生成するときに、パスの途中であっても書き込み不可能なフォルダがあると作成に失敗します。

Windows XPで、\Program Files\ 上にインストールして使用しているとき、\Program Files\が書き込み不可能になって遭遇することが多いようです。(初期のWindowsXPは書き込み禁止ではないので、後になってWindowsUpdate等の適用で書き込めなくなる。)

\Program Files\を書き込み可能にすると改善されます。ただし、もともと電八は\Program Files\ 上にインストールして使用しないことをお薦めしています。

この不具合は、提案されているパッチ 08239 他が採用された 32.1.6.3 で改善されました。

TOPコマンド応答にて、POPサーバーがヘッダ/本文セパレータを返さない場合、受信タイムアウトします。

お使いのサーバーがこのような不正な応答を返すと、TOPコマンドを使用する詳細確認、及びMessage-Idによる新着判定を使用した受信がタイムアウトで失敗します。

サーバーの問題ではありますが、提案されているパッチ 08200 他が採用された V32.1.6.3 で改善されました。

V32.1.5.3

デフォルトのアクセラレータキーを削除しても再起動すると復活するバグが有ります。

V32.1.5.3で、デフォルトで割り当てられているアクセラレータキーの割り当てを削除しても、電八を再起動すると復活しています。

この不具合は、提案されているパッチ 06223 他が採用された 32.1.6.1 で改善されました。

バージョンアップ後に追加された送信メールの「相手[再送相手]」表示が自分のアドレス(From:)になる問題があります。

V32.1.5.1で「相手[再送相手]」の表示が、送信系/受信系で固定ではなくユーザが変更可能になりました。バージョンアップ直後は全てのフォルダでFrom表示になっています。

お手数ですが、送信系フォルダで送信相手のアドレスを表示する為には、手動で[フォルダ]->[相手表示変更]を行ってください。

この不具合は、提案されているパッチ 06012 他が採用された 32.1.5.3 で改善されました。

「サーバ別の設定」の[添付]の文字コード設定が実際と異なるバグがあります。

現在、「サーバ別の設定」で[添付]の(添付ファイル名)「文字コード」の設定表記が実際とずれており、
 無変換に設定→JIS
 JISに設定→EUC
 EUCに設定→無変換
になります。

通常デフォルトの設定で問題は有りませんが、特定の文字コードでエンコードする必要がある場合には、お手数ですが上記のように読み替えてご利用ください。

この不具合は、提案されているパッチ 05942 他が採用された 32.1.5.3 で改善されました。

マルチパートメッセージのパーツの実体化の際に、長さが1024バイト以上の行で文字欠けを起こすバグがあります。

このバグが問題になるメールの例:

この不具合は、提案されているパッチ 05578 他が採用された 32.1.4.5 で改善されました。

非常に高速なブロードバンド回線(光接続100Mbpsのような)を利用しているとサイズの大きなメールが受信できない、という現象があります。

このような場合には、一旦 V32.1.3.1; sp2 にデグレードしましょう。

この現象は、提案されているパッチ 04955 他が採用された 32.1.4.3 が公開され改善されました。

警告! オフラインデコードで既存の電八形式メール(.txt)を再振り分けすると、本文冒頭でホワイトスペースから始まる行があるとそれが失われます。

注:この現象は、受信時デコードでは起きません。

この不具合は、提案されているパッチ 03416 が採用された V32.1.4.1 が公開され改善されました。

警告! 次のような条件が重なると、添付ファイルの受信時デコードに失敗して添付ファイルの内容が失われます。

  1. そのパートが Content-Type: text で電八がサポートしている charset である (あるいは charset 属性がない)
  2. そのパートが Content-Transfer-Encoding: base64 または quoted-printable
  3. そのパートが Content-Disposition: inline (あるいは Content-Disposition: ヘッダがない)
  4. デコード後に改行(CRLF)を含まない行がある添付テキスト (base64 でも quoted-printable でも)
  5. そのパートの後にも同レベルのパートがある (直後が --boundary-- でない)

お手数ですが、このような添付ファイルの消失は困ると思われるかたは、

  1. サーバに依存しない設定の[その他]タブの「□一時ファイルを削除する」のチェックを外して、万一受信した場合は、該当一時ファイルを取っておく。
  2. サーバ別の設定で「□受信後もサーバ上のメールを削除しない」にチェックして、万一受信した場合は、該当メールを再度受信できるようにしておく。

のいずれかの措置を取っておき、対策された電信八号がリリースされるのをお待ちください。

この現象は、緊急安定化パッチ 03213b が採用された 32.1.3.1 修正版が公開され改善されました。

警告! 改行が CR のみの異常なメールを受信するとディスクの空き領域を使い尽くして異常終了します。

本来あってはならないのですが、改行が RFC 準拠の( インターネット標準の ) CRLF ではなくて、 CR だけのメールが POP3 サーバに届いてしまうことがあります。改行が CR だけのテキストは、例えば Apple 社製のパソコン等でローカルには使われますが、これをインターネットに直接流してはいけない決まりです。また、たとえ流れてもメールサーバが堅牢であれば、配送を拒否するか改行が強制挿入されます。
現在流行中の WORM_BADTRANS.B もある特定の条件の元で、このような異常メールを生成するため、メールサーバも透過的で放任主義だと、電信八号はこれに遭遇しやすくなっています。
お手数ですが、このような場合は、お使いのプロバイダ等メールサーバ管理者にお問い合わせください。

この現象は、緊急安定化パッチ 03213a が採用された 32.1.3.1 修正版が公開され改善されました。

なお、改行が LF だけ( UNIX 系の OS 等で使われます )の場合には、このような不具合は発生しないはずです。受信した後に電八に形式違反で叱られはします。

警告! 大きさゼロのメールを受信しようとすると、電信八号が異常終了します。

 本来、メールにはヘッダ情報が存在するためサイズが0ではあり得ませんが、サーバの障害などでPOP3 サーバ上に「大きさゼロのメール」ができることがあります。
 手動受信した場合、電信八号の Log ウィンドウに
  C: STAT
  S: +OK 1 0

 または
  C: LIST
 の後の一行に
  S: <メール番号> 0
 などと表示されたり、メールが来ていますダイアログに
  -001 【】
 などと表示される場合です。
 この状態をプロバイダやサーバ管理者に報告せず、放置すると、あなたやあなたと同じサーバを使っている人のメールが喪失し続ける危険があります。
 お手数ですが、次のような回避手段をお取りください。

0) 電信八号が安定して動作できるようにする。
   a) (必要なら)デコードされなかったメールを FD 等に待避
      標準では、C:\Window\Temp の下の _den????.tmp (???? は4桁の数字)
   b) (メモリ不足が起きていれば) OS を再起動
   c) (ファイルシステムに不具合があれば)修復
 ※ 理論と実験の結果、ここまでは滅多なことでは必要ない。
   d) (必要なら)自動ログインを解除
      標準では、Denshin8.ini を編集する。
      編集箇所は、
        [Automatic Login]
        Use=1
      これを
        Use=0
      に書き換えて保存する。
   e) 電信八号を再起動(→キャッシュ再構築が起きる)
1) (あれば)デコードされなかったメールをデコードする。
 ※ オフラインデコードのファイル選択ダイアログを開けば、
    .tmp のあるディレクトリを開くので探す必要はない。
    0-a で退避している場合は、FD 等のドライブを選択。
2) 手動受信に切り替える。
 ※ 問題のあるサーバを
   a) 巡回先から外す
   b) 「受信後もサーバ上のメールを削除しない」ようにする
3) 問題の大きさゼロのメールを避けてメールを選択受信する。
4) 仕事を片づける。
5) しかるのちプロバイダかサーバ管理者に異常を報告し、調査改善を依頼する。
 ※ メールで報告すると、事態を悪化させますので、電話等の手段をお使いください。

 この現象は、提案されているパッチ 03035b, 03035d が採用された 32.1.3.1 修正版が公開され改善されました。
 ( 電八倶楽部メーリングリスト内では、すでに限定公開されています。[den8club:15964] )
 また、次バージョンでも採用されることにより改善されるはずですが、
検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。

警告! 返信のための編集中に、返信元のメールの入っていた電八フォルダを閉じると、編集が終了して保存した後、電八が返信元メールのステータスを「返信済み」に変更できず、異常終了します。

なお、編集が終了したメールは消えません。

お手数ですが、返信編集中は、返信元のメールの入っている電八フォルダは閉じないようにご使用ください。

警告! テンプレート(.cmp)ファイルに $DEN8DIR=$ENV{DEN8DIR};$DEN8DIR のような記述をすると、$DEN8DIR が展開された文字列の前に「不定な半角1文字」が付加されてしまう不具合が見つかりました。

お手数ですが、次のバージョンが出るまで手動で削除するか、
  ...$DEN8DIR=$ENV{DEN8DIR}( 直後に改行<CRLF>、この改行は除去されます )
  $DEN8DIR...
のように書いておいてください。

この不具合は、028 draft 2 に含まれるコード 02987a が採用された 32.1.3.1 修正版が公開され改善されました。

また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。

警告! 設定ファイルの [Decoding] セクションにデフォルトどおり、TextSubtypes=html;x-server-persed-html;css と書いてあっても Shift_JIS にデコードしてしまいます。

当面、各項目の頭に / を付けて設定しておいてください。

この現象は、提案されているパッチ 02705, 02706 他が採用された 32.1.3.1 修正版が公開され改善されました。

また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。

Netscape Mailer 日本語版に、JIS (ISO-2022-JP) コードの添付ファイル名を取り出し時に正しく解釈できない、という現象があります。

※ メールのソースを表示する場合は、正しく扱われたりするそうです。
Netscape Mailer を利用している相手には、半角英数字以外のファイル名のファイルを添付したメールを電八から送らないようにしましょう。電八のバグだと思われてしまいます。

この現象は、提案されているパッチ 02636 他が採用された 32.1.3.1 修正版が公開され改善されました。
(同梱の ReadmeSP.txt 参照。→添付ファイル名エンコード/デコードを RFC2231 対応にした、の項)

また、次バージョンでも採用されることにより改善されるはずですが、検証・UI改良してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。

警告! 分割されたメールを受信した際、それらのメールが電八受信系フォルダの1,002通目以降にあると、結合時の自動検索に失敗します。

このような場合、メール数の少ない作業用の電八受信系フォルダに移して、結合してください。

この不具合は、提案されているパッチ 02807 が採用された 32.1.3.1 修正版が公開され改善されました。
 ※ 分割メールの結合は、そのメールフォルダが「フォルダ(F)→番号振り直し(B)」された状態で行なってください。

また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。

警告! UTF-7 でエンコードされたメールを受信した場合、+ と - に囲まれた実エンコード文字数が4の倍数だと正しく Shift_JIS に変換されますが、そうでないとデコードされない行が混在して、文字化けの様相を呈することがあります。

※ なお、V321.2b6-stable までの電八は、全く UTF-7 に対応していません。

日本語標準の ISO-2022-JP で送ってもらうようにしてください。

 この不具合は、提案されているパッチ 02654 が採用された 32.1.3.1 修正版が公開され改善されました。

 また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。

警告! 電八のバグではありませんが、NEC PC9801 対応 Windows 95 に、[UP!]カーネルアップデート3(KRNLUPD3.EXE)パッチを当てると、不正なビルド番号を返すので、電八や他のプログラムが正常に動作しません。

この不具合に対しては、マイクロソフト社が推奨している回避方法に従って、以前の状態に戻す必要があります。

警告!「フォルダ」メニュの「検索」機能で検索中に、右上の×でダイアログを閉じると電信八号が異常終了することがあります。

この不具合は、提案されているパッチ 02546c が採用された 32.1.3.1 修正版が公開され改善されました。

また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。

警告! V321.2b6-stable までの電八は、Win95/98/Me では 2GB、WinNT/2000 では 4GB を超える大容量パーティションに対応していません。このため、4GB 以上の空き容量があっても、10240 バイト以上の空きがないと報告してメールが受信できないことがあります。

大容量 HDD 利用者は、V32.1.3.1 に移行されることを強く推奨します。
 ※ なお、Win3.1、Win95 OSR1 以前は、そもそも OS が 2GB を超えるパーティションに対応していません。

警告! V321.2b6-stable までの電八には、From: 行に非常に長い文字列を設定し、文字列の中に特殊な実行コード( Exploit )を仕込まれると、受信前確認または受信時に、任意のコマンドを手元のパソコン上で実行されてしまうセキュリティホールがあります。

このセキュリティホールは、長過ぎるヘッダを切り詰めてくれる SMTP サーバ ( メール配送サーバ ) を経由している場合は、脅威になりませんが、そうでない場合は、自分宛のメールが勝手に読まれてしまう、パソコン上のデータが破壊される、といった重大なクラッキングを受ける可能性があります。( 現在のところ幸い被害報告はありません。)

この不具合は、提案されているパッチ 0189901915 が V32.1.3.1 で採用され改善されました。

続報です。長過ぎるヘッダを切り詰めてくれないサーバには、qmail、EMWAC などがあるようです。

警告! Alias.exe では問題ありませんが、Aliases.ali (住所録ファイル)が 32000 バイトより大きくなると alias buffer overflow となり、電八が起動しないか、または境界付近に漢字コードが来ると起動時に異常終了します。

この不具合は、提案されているパッチ 01598 が V32.1.3.1 で採用され改善されました。

警告! V321.1b4 以降の電八に内在しているバグを発見しました。トップレベルで Base64 エンコードされたメールを受信した場合は、ただちに電八を再起動してください。続けてもう一度同様のメールを受信した場合、メールが壊れるか、電信八号が異常終了する可能性があります。

普通に使っている限り、電八でそういうメールを送信することはありませんが、自分で編集してトップレベルで Base64 エンコードされたメールを作成して送信した場合も同様です。

この不具合は、提案されているパッチ 01296 が V32.1.3.1 で採用され改善されました。

警告! ReportWindow(プログレスバーを表示しているダイアログ)表示中にESCキーを押すと消えてしまって終了メニュ(Ctrl+Q)で異常終了します。

この不具合は、提案されているパッチ 00339 が V32.1.3.1 で採用され改善されました。

警告! 電信八号を初めて起動すると、サーバ別の設定を要求されます。その際、[実名]の長さは、29バイトまでにしてください。
それ以上入力すると設定ファイル( 標準では、Denshin8.ini )が壊れ、再起動できなくなります。

この場合、設定ファイルを直接メモ帳等で編集するハメに陥ります。設定ファイルを直接修正する自信のない方は、設定ファイルを削除してから再起動してください。

この不具合は、提案されているパッチ 00170a が V32.1.3.1で採用され改善されました。


電八ダウンロードページに戻る