| MozillaZine.jp フォーラム https://forums.mozillazine.jp/ |
|
| Thunderbird(送信側)の問題ではないと証明したい... https://forums.mozillazine.jp/viewtopic.php?f=3&t=18306 |
ページ 1 ／ 4 |
| 作成者: | Ponta [ 2020年12月10日(木) 09:42 ] |
| 記事の件名: | Thunderbird(送信側)の問題ではないと証明したい... |
ここ数日、複数の顧客(受信側)から私の送ったメールに対して、「返信、転送時に過去メールの引用部分が削除されている」とのクレームが来るようになりました。調査したところ、受信側が全員Windows Live Mail 2012を使用していることが判明。2017年1月にサポートが終了しているメーラーですし、受信側の問題と確信しているのですが、ネット検索してもLive Mail側の不具合として指摘しているページがみつかりません。 顧客側も、「携帯などの別デバイスでは正常に受信できている」と言っているのに、当方の問題だ、と言ってききません。どなたか、Live Mail側の問題だと証明できる方いらっしゃいませんでしょうか？ よろしくお願いします。 |
|
| 作成者: | EarlgreyTea [ 2020年12月10日(木) 10:11 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
Ponta さんが書きました: どなたか、Live Mail側の問題だと証明できる方いらっしゃいませんでしょうか？ Windows Live メール で現象を再現させて検証しないことにはわかりません。 しかし今となっては公式から入手はできませんし、怪しいサイトから入手するのは遠慮したいところです。 下記のようなところで実際のユーザーに協力を求めて情報収集してみてください。 マイクロソフト コミュニティ Ponta さんが書きました: 顧客側も、「携帯などの別デバイスでは正常に受信できている」と言っているのに、当方の問題だ、と言ってききません。 その様子だと「証明」したとしても納得せずに拗れる可能性もあります。 顧客対応としては別のアプローチもご検討ください。 |
|
| 作成者: | Ponta [ 2020年12月10日(木) 10:20 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
EarlgreyTea様 アドバイスありがとうございます。リンクを見てみましたが、やはりサポート終了ソフトのためかカテゴリー自体が存在しません・・・ どなたか、Live Mail側のこうした現象について検証したり記述しているウェブサイトに心当たりがある方いらっしゃれば教えてください。よろしくお願いします。 |
|
| 作成者: | EarlgreyTea [ 2020年12月10日(木) 10:24 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
カテゴリー「Windows Essentials」です。 検索すればわかるはずです。 |
|
| 作成者: | とおりがかかりのユーザー [ 2020年12月10日(木) 15:55 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
もしかして、Thunderbird側の問題じゃないですか？ https://bigbell.co.jp/thunderbird%E3%81 ... %EF%BC%9F/ |
|
| 作成者: | EarlgreyTea [ 2020年12月10日(木) 17:17 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
とおりがかかりのユーザー さん 情報ありがとうございます。 Ponta さん もし、Thunderbird が返信したあとに文面の欠落が起きているなら、署名とみなしてstripかけていることが疑われます。 しかし、同じメールがモバイルデバイスとWindows Liveメールで結果が異なるなら、別の原因でしょう。 そこの事実関係をはっきりさせましょう。 |
|
| 作成者: | maji [ 2020年12月10日(木) 17:50 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
とおりがかかりのユーザー さん、maji とゆ者です。 とおりがかかりのユーザー さんが書きました: もしかして、Thunderbird側の問題じゃないですか？ https://bigbell.co.jp/thunderbird%E3%81 ... %EF%BC%9F/ もしかして、 通称「 DASH DASH SP 」(ダッシュ・ダッシュ・スペース)( sig-dashes )の事をおっしゃってるのかな？ これって Thunderbird 独自の問題ぢゃなくて インタネットメールの「エチケット」みたいなものだと思ってました。 例えば、、、、 ちょっとしたメモ - 署名区切り行：sig-dashes https://www.kanzaki.com/memo/2006/03/03-1 【RFC】メールでよく見かけるハイフン2つ「– 」って何 at softelメモ https://www.softel.co.jp/blogs/tech/archives/2681 あたりが参考になるのかな。 もしこれが理由で「-- 」の後を署名として引用や返信からカットしてるのであれば それは相手側のメールアプリ(→今回は古い Windows Live Mail)の問題でしょう。 ----- Ponta さんへ。 もしご自身のメールの署名部分に「-- 」( DASH DASH SP )があるのであれば とおりがかかりのユーザー さんや上記リンク記事を参考に ご自身のメールの署名から「-- 」を外してメール作ってみてください。 ----- 以下は 蛇足 です。 そう言えば、、、、、 私自身はコレを嫌って 何時の頃からか「 DASH DASH SP 」で無い署名にしてましたね。 では。 |
|
| 作成者: | Ponta [ 2020年12月10日(木) 18:54 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
皆様、色々とありがとうございます。 sig-dashesについてはここに投稿する前に私も気が付いていて、元の送信者の署名、私の署名ともに使用していない状態です。ですので、2つ前のEarlgreyTeaのコメントの、「しかし、同じメールがモバイルデバイスとWindows Liveメールで結果が異なるなら、別の原因でしょう」、という考えに賛成です。 なお、顧客側の協力のもと、OKだった返信と、ダメになった返信を特定したところ、当方10/27返信は異常なし、11/4返信は引用されるべき元の文が消えていることが分かりました。送信済みトレイに残っているメールを[Ctr+U]で確認したところ、ThunderbirdのバージョンがOKメールは68.12.1、NGメールは78.4.0であることが分かりました。68から78に更新されて今回の問題が発生したような気がします。 何か対策があればご教授お願いいたします。 |
|
| 作成者: | maji [ 2020年12月10日(木) 19:17 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
Ponta さん、maji です。 3つだけ確認させてください。 ----- まず 1つ目。 Ponta さんが書きました: なお、顧客側の協力のもと、 OKだった返信と、ダメになった返信を特定したところ、 当方10/27返信は異常なし、11/4返信は引用されるべき元の文が消えていることが分かりました。 送信済みトレイに残っているメールを[Ctr+U]で確認したところ、 ThunderbirdのバージョンがOKメールは68.12.1、NGメールは78.4.0であることが分かりました。 68から78に更新されて今回の問題が発生したような気がします。 上記の 「当方10/27返信は異常なし、11/4返信は引用されるべき元の文が消えている事が判った」 とは 当方(Pontaさん)が 10/27 に返信されたメールの中の元の文章は 相手側が受信した時にもちゃんとあって 当方(Pontaさん)が 11/4 に返信されたメールの中の元の文章は 相手側が受信した時には無くなっている とゆ事でしょうか。 それとも 当方(Pontaさん)が 10/27 に返信されたメールの中の元の文章は 相手側が受信した後に返信する際には引用されるが、 当方(Pontaさん)が 11/4 に返信されたメールの中の元の文章は 相手側が受信した時にはちゃんとあるが 相手側が受信した後に返信する際には引用されない とゆ事でしょうか？？ 次に 2つ目。 Thunderbirdのメール送信時の 1行の文字数は 規定値が 72バイト(日本語表示だと全角36文字)だったと思うのですが Ponta さんはこの値を変更されてますか？？？ そして 3つ目。 Ponta さんのお手元の Thunderbird には 何かアドオン導入されてますか？？？？ ----- では。 |
|
| 作成者: | Ponta [ 2020年12月10日(木) 19:36 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
maji さんが書きました: まず 1つ目。 上記の 「当方10/27返信は異常なし、11/4返信は引用されるべき元の文が消えている事が判った」 とは 当方(Pontaさん)が 10/27 に返信されたメールの中の元の文章は 相手側が受信した時にもちゃんとあって 当方(Pontaさん)が 11/4 に返信されたメールの中の元の文章は 相手側が受信した時には無くなっている とゆ事でしょうか。 ということです。 maji さんが書きました: 次に 2つ目。 Thunderbirdのメール送信時の 1行の文字数は 規定値が 72バイト(日本語表示だと全角36文字)だったと思うのですが Ponta さんはこの値を変更されてますか？？？ していません。 maji さんが書きました: そして 3つ目。 Ponta さんのお手元の Thunderbird には 何かアドオン導入されてますか？？？？ 何も入れてないはずです。。。。というのも、問題は会社のPCで起きており、今は帰宅し自宅にいるので確実なところは明日朝の確認となってしまいます・・・・よろしくお願いします。 |
|
| 作成者: | maji [ 2020年12月10日(木) 21:22 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
Ponta さん、maji です。 Ponta さんが書きました: 68から78に更新されて今回の問題が発生したような気がします。 もしほんとに 68から 78に更新されたタイミングで 不具合(？)生じてるのなら Ponta さんのお手元の 送信済トレイに残っている ・当方10/27返信(異常なし) ・11/4返信(引用されるべき元の文が消えている) のソースを見比べて 違いを探すしかないのかな。 違いが判れば 何か処置するアイデアも出てくるかも。 では。 |
|
| 作成者: | Ponta [ 2020年12月10日(木) 22:26 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
maji様 明日会社に行ったらソースを確認してみて再度ご報告します。 よろしくお願いします。 |
|
| 作成者: | EarlgreyTea [ 2020年12月10日(木) 22:44 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
Ponta さんが書きました: sig-dashesについてはここに投稿する前に私も気が付いていて、元の送信者の署名、私の署名ともに使用していない状態です。 そういう情報は最初に書いておきましょう。 Ponta さんが書きました: なお、顧客側の協力のもと、OKだった返信と、ダメになった返信を特定したところ、 理解のあるお客様でよかったですね。 Ponta さんが書きました: 当方10/27返信は異常なし、11/4返信は引用されるべき元の文が消えていることが分かりました。送信済みトレイに残っているメールを[Ctr+U]で確認したところ、ThunderbirdのバージョンがOKメールは68.12.1、NGメールは78.4.0であることが分かりました。 すでに maji さんが質問されていますが、しっかり確認しておきたいと思います。 問1：10/27返信と11/4返信は同一のスレッドメールですか？ (a) 先方がメールA(1)を送信->Pontaさんが受信して10/27にA(2)を返信 ->先方が受信してA(3)を返信->Pontaさんが受信して11/4にA(4)を返信 (b) 先方がメールA(1)を送信->Pontaさんが受信して10/27にA(2)を返信 先方がメールB(1)を送信->Pontaさんが受信して11/4にB(2)を返信 どちらでしょう。 問2：「異常なし」、「元の文が消えている」はどのように確認されましたか？ 上記問1のどの時点で、どのメール（受信/送信控え）のソースを確認したのでしょうか、ということです。 問3：「OKメールは68.12.1、NGメールは78.4.0」の根拠は？ User-Agent: フィールドの値を確認されたのだと思いますが、 調査したサンプル数がいくつあって、そのうち複数の68.12.1メールはすべてOKで、複数の78.4.0メールがすべてNGだったということでしょうか。 問4：OKメールとNGメールのソースに原因となるような特徴はありませんでしたか？ User-Agent: 自体はただの状況で原因ではないはずです。 上記質問の確認と返答をお願いします。 会社のPCでしか確認できないわけですから、明日を逃すと月曜まで進展なしになります。 もし調査に時間がかかるようでしたら、メールソースの抜粋を提示していただければこちらで分析することも可能です。 その際はメールの構造部分はそのままで、文面の中身やヘッダー情報中の公開できない情報を削除したり伏字に加工したうえで公開してください。 |
|
| 作成者: | Ponta [ 2020年12月11日(金) 08:56 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
EarlgreyTea様 EarlgreyTea さんが書きました: そういう情報は最初に書いておきましょう。 おっしゃる通りです、失礼しました。 EarlgreyTea さんが書きました: 問1：10/27返信と11/4返信は同一のスレッドメールですか？どちらでしょう。 (b) 先方がメールA(1)を送信->Pontaさんが受信して10/27にA(2)を返信 先方がメールB(1)を送信->Pontaさんが受信して11/4にB(2)を返信 です。 EarlgreyTea さんが書きました: 問2：「異常なし」、「元の文が消えている」はどのように確認されましたか？ 上記問1のどの時点で、どのメール（受信/送信控え）のソースを確認したのでしょうか、ということです。 顧客から受信画面のキャプチャをもらいました。ソースは、自分のPCの「送信済みトレイ」のメールを確認しました。 EarlgreyTea さんが書きました: 問3：「OKメールは68.12.1、NGメールは78.4.0」の根拠は？ User-Agent: フィールドの値を確認されたのだと思いますが、 調査したサンプル数がいくつあって、そのうち複数の68.12.1メールはすべてOKで、複数の78.4.0メールがすべてNGだったということでしょうか。 送信済みトレイにある私が打った返信のソースのUser-Agent:フィールドの値です。 現時点ではサンプル数はそれぞれ各1通のみです。可能であればこれから他のメールも調べてみます。 この返信の後、ソースの一部を掲載しますのよろしくお願いします。 |
|
| 作成者: | Ponta [ 2020年12月11日(金) 08:58 ] |
| 記事の件名: | Re: Thunderbird(送信側)の問題ではないと証明したい... |
maji様、EarlgreyTea様 色々とありがとうございます。 取り急ぎ、ソース比較です。違う部分がありました。 10/27返信のOKメール Content-Type: multipart/alternative; boundary="------------2C67E40185387DBAF3FCBC67" Content-Language: en-US This is a multi-part message in MIME format. --------------2C67E40185387DBAF3FCBC67 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 11/4返信のNGメール Content-Type: multipart/mixed; boundary="------------7BB389FFE5A4FF24AD957D59" Content-Language: en-US This is a multi-part message in MIME format. --------------7BB389FFE5A4FF24AD957D59 Content-Type: multipart/alternative; boundary="------------8C87201C4EB6DA747CBCBCF3" --------------8C87201C4EB6DA747CBCBCF3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 何かわかりますでしょうか？ よろしくお願いいたします。 |
|
| ページ 1 ／ 4 | All times are UTC + 9 hours |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|