最終更新
電信八号についての不具合を広報するページです。
主に公開版リリース後に発見されたものについて扱います。既知の不具合や制限事項については、付属のヘルプをご覧ください。
※ その他細かな不具合については、電信八号パッチ一覧を御覧ください。
現最新公開版は、V32.1.7.5 です。
ドライブルートが指定されていると、添付ファイル付きメールを開くときに 「SHGetFileInfo returned NULL」というエラーが発生し、添付ファイルが取り出せません。
テンポラリフォルダーには W:\temp
の様に、サブフォルダーを指定してください。電八用の環境変数を設定することも可能です。詳しくは FAQ#4.10 を参照してください。
この不具合は、V32.1.7.3で解消されました。
これは制限事項として認識されており、V32.1.7.3で解消されました。
標準の視覚テーマはウインドウ右上のボタンの横幅がXP以前よりも大きくなっており、フォルダを最小化した際、タイトルバーのフォルダ名を表示するスペースがかなり狭くなってしまいます。
これは制限事項として認識されており、V32.1.7.3で対策機能が付きました。詳しくは FAQ#4.9 を参照して下さい。
以下の記述は旧公開版に対するもので、最新版 では解消されています。
※ 元々不正な krnlupd3.exe 問題を除く。
Windows XPで、\Program Files\ 上にインストールして使用しているとき、\Program Files\が書き込み不可能になって遭遇することが多いようです。(初期のWindowsXPは書き込み禁止ではないので、後になってWindowsUpdate等の適用で書き込めなくなる。)
\Program Files\を書き込み可能にすると改善されます。ただし、もともと電八は\Program Files\ 上にインストールして使用しないことをお薦めしています。
この不具合は、提案されているパッチ 08239 他が採用された 32.1.6.3 で改善されました。
お使いのサーバーがこのような不正な応答を返すと、TOPコマンドを使用する詳細確認、及びMessage-Idによる新着判定を使用した受信がタイムアウトで失敗します。
サーバーの問題ではありますが、提案されているパッチ 08200 他が採用された V32.1.6.3 で改善されました。
V32.1.5.3で、デフォルトで割り当てられているアクセラレータキーの割り当てを削除しても、電八を再起動すると復活しています。
この不具合は、提案されているパッチ 06223 他が採用された 32.1.6.1 で改善されました。
V32.1.5.1で「相手[再送相手]」の表示が、送信系/受信系で固定ではなくユーザが変更可能になりました。バージョンアップ直後は全てのフォルダでFrom表示になっています。
お手数ですが、送信系フォルダで送信相手のアドレスを表示する為には、手動で[フォルダ]->[相手表示変更]を行ってください。
この不具合は、提案されているパッチ 06012 他が採用された 32.1.5.3 で改善されました。
現在、「サーバ別の設定」で[添付]の(添付ファイル名)「文字コード」の設定表記が実際とずれており、
無変換に設定→JIS
JISに設定→EUC
EUCに設定→無変換
になります。
通常デフォルトの設定で問題は有りませんが、特定の文字コードでエンコードする必要がある場合には、お手数ですが上記のように読み替えてご利用ください。
この不具合は、提案されているパッチ 05942 他が採用された 32.1.5.3 で改善されました。
このバグが問題になるメールの例:
この不具合は、提案されているパッチ 05578 他が採用された 32.1.4.5 で改善されました。
このような場合には、一旦 V32.1.3.1; sp2 にデグレードしましょう。
この現象は、提案されているパッチ 04955 他が採用された 32.1.4.3 が公開され改善されました。
注:この現象は、受信時デコードでは起きません。
この不具合は、提案されているパッチ 03416 が採用された V32.1.4.1 が公開され改善されました。
お手数ですが、このような添付ファイルの消失は困ると思われるかたは、
のいずれかの措置を取っておき、対策された電信八号がリリースされるのをお待ちください。
この現象は、緊急安定化パッチ 03213b が採用された 32.1.3.1 修正版が公開され改善されました。
本来あってはならないのですが、改行が 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] )
また、次バージョンでも採用されることにより改善されるはずですが、
検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。
なお、編集が終了したメールは消えません。
お手数ですが、返信編集中は、返信元のメールの入っている電八フォルダは閉じないようにご使用ください。
お手数ですが、次のバージョンが出るまで手動で削除するか、
...$DEN8DIR=$ENV{DEN8DIR}
( 直後に改行<CRLF>、この改行は除去されます )
$DEN8DIR
...
のように書いておいてください。
この不具合は、028 draft 2 に含まれるコード 02987a が採用された 32.1.3.1 修正版が公開され改善されました。
また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。
当面、各項目の頭に / を付けて設定しておいてください。
この現象は、提案されているパッチ 02705, 02706 他が採用された 32.1.3.1 修正版が公開され改善されました。
また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。
※ メールのソースを表示する場合は、正しく扱われたりするそうです。
Netscape Mailer を利用している相手には、半角英数字以外のファイル名のファイルを添付したメールを電八から送らないようにしましょう。電八のバグだと思われてしまいます。
この現象は、提案されているパッチ 02636 他が採用された 32.1.3.1 修正版が公開され改善されました。
(同梱の ReadmeSP.txt 参照。→添付ファイル名エンコード/デコードを RFC2231 対応にした、の項)
また、次バージョンでも採用されることにより改善されるはずですが、検証・UI改良してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。
このような場合、メール数の少ない作業用の電八受信系フォルダに移して、結合してください。
この不具合は、提案されているパッチ 02807 が採用された 32.1.3.1 修正版が公開され改善されました。
※ 分割メールの結合は、そのメールフォルダが「フォルダ(F)→番号振り直し(B)」された状態で行なってください。
また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。
※ なお、V321.2b6-stable までの電八は、全く UTF-7 に対応していません。
日本語標準の ISO-2022-JP で送ってもらうようにしてください。
この不具合は、提案されているパッチ 02654 が採用された 32.1.3.1 修正版が公開され改善されました。
また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。
この不具合に対しては、マイクロソフト社が推奨している回避方法に従って、以前の状態に戻す必要があります。
この不具合は、提案されているパッチ 02546c が採用された 32.1.3.1 修正版が公開され改善されました。
また、次バージョンでも採用されることにより改善されますが、検証してくださる方がもっと必要です。われと思われる方は、ぜひ開発にご参加ください。
大容量 HDD 利用者は、V32.1.3.1 に移行されることを強く推奨します。
※ なお、Win3.1、Win95 OSR1 以前は、そもそも OS が 2GB を超えるパーティションに対応していません。
このセキュリティホールは、長過ぎるヘッダを切り詰めてくれる SMTP サーバ ( メール配送サーバ ) を経由している場合は、脅威になりませんが、そうでない場合は、自分宛のメールが勝手に読まれてしまう、パソコン上のデータが破壊される、といった重大なクラッキングを受ける可能性があります。( 現在のところ幸い被害報告はありません。)
この不具合は、提案されているパッチ 01899、01915 が V32.1.3.1 で採用され改善されました。
続報です。長過ぎるヘッダを切り詰めてくれないサーバには、qmail、EMWAC などがあるようです。
この不具合は、提案されているパッチ 01598 が V32.1.3.1 で採用され改善されました。
普通に使っている限り、電八でそういうメールを送信することはありませんが、自分で編集してトップレベルで Base64 エンコードされたメールを作成して送信した場合も同様です。
この不具合は、提案されているパッチ 01296 が V32.1.3.1 で採用され改善されました。
この不具合は、提案されているパッチ 00339 が V32.1.3.1 で採用され改善されました。
この場合、設定ファイルを直接メモ帳等で編集するハメに陥ります。設定ファイルを直接修正する自信のない方は、設定ファイルを削除してから再起動してください。
この不具合は、提案されているパッチ 00170a が V32.1.3.1で採用され改善されました。