「なでしこv1」開発掲示板

お世話になっております。けいです。

またも、メール関連のお願いと、修正をお願いしたいと思います。

【症状】【再現方法】
受信したメールに「@live.jp」から送信されたメールが添付されていましたが、その際、下記エラーが表示され、処理が止まってしまいました。
[エラー] 関数『メール受信』の実行中にエラーが起きました。メール受信で受信したメール『』の解析でエラー。未定義のエンコード方式(関数)
以前、中国からのメールにおいても同様の症状が出たことがありました。

【要望】どのような解決が望ましいか？
通常通り、受信できるように

【バージョン】確認したバージョン
1.536　VISTA　Home Basic　SP2

【その他】
可能でしたら、現在メール受信後に展開されるテキストファイルには、「cc」が記載されていませんが、それも記載していただけるとありがたいです。

お手数おかけ致しますが、よろしくお願い致します。

エラーメッセージからすると、メールの、「Content-Transfer-Encoding」のヘッダにて指定されているものが対応していない形式の場合で、かつ、「Content-Type」がtextでは無い場合のようです。
エラーとなっているメールにて、それぞれ何が指定されているかわかりますでしょうか？
（添付ファイルなどで複数のパートがある、個々のパートごとに、扱われます）

ちなみに、対応している形式は「base64」と「quoted-printable」の２種類です。
その他、RFCで定義されているもの(つまり、未対応のもの)として、、「7bit」「8bit」「binary」がありそうですが、該当していますか？（通常、7bitや8bitはtextの場合に使われるようです）

うぇいく様

早速のご返信有り難うございます。けいです。

メールの該当箇所を確認したところ、以下のようになっておりました。


Content-Transfer-Encoding: 7bit
Content-Type: multipart/mixed;
Content-Type: text/plain;

転送されてきたメールは、以下です。

Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: base64
Content-Type: message/rfc822;
Content-Type: multipart/alternative;
Content-Type: text/plain; charset="iso-2022-jp"
Content-Type: text/html; charset="iso-2022-jp"


複数ヶ所有りましたので、全て記載しておきます。

転送元のメーラーは「Outlook Express 6」、貼付されてきているメールについては
「@live.jp」からHTMLメールで送られているものです。

以上、お手数おかけいたしますが、よろしくお願い致します。

回答ありがとうございます。
　個々のヘッダの組み合わせで考えると、メールを添付した際に使わる可能性のある、
Content-Type: message/rfc822; name=XXXXX
Content-Transfer-Encoding: 7bit
の組み合わせがエラーとなってしまうようでした。

対応を考えてみます。

いつもお世話になっております。けいです。

ご確認有り難うございます。

今度は別のエラーが発生しました(^^ゞ

[エラー] com.nadesi.exe.nakopad.temp.nako2.bak(13): 書式文字列 '%22!' の引数が見つかりません(関数

エラーがこれだけしか出ないので、どういう状況なのかが判断出来ません。

次から次で申し訳ございませんが、ご確認いただけますでしょうか。

よろしくお願い致します。

毎々、報告ありがとうございます。

　どのような命令を発行していたかわかりますか？（エラーの発生している行を含めて前後のソースと、どの行が該当行かを記載いただけると助かります）
　また、もしそれが時間のかかる命令の場合(メール受信命令等)、どんな感じの処理を行っていたかわかりますでしょうか？

度々のご確認有り難うございます。

プログラムは、リフォレンスの「メール受信」に記載のものを、各所適宜変更して実行しました。
（コメント部分もそのままで、ホスト、ID、パスワード部分のみ変更です）
別メーラーで受信してみたところ、受信エラーのメールはドコモからの携帯メールのようでした。
受信後の展開でエラーになるのではなく、受信自体ができない状況です。
あまり参考になる返答でなく、申し訳ございません。
ヘッダ情報など、必要箇所がございましたら、ご連絡下さい。

よろしくお願い致します。

同じようなメールが来ると確認ができそうですが、難しそうですね。
@docomo....は、わりと、spamでも使われて(偽装に用いられて)いるようなので、ヘッダとしては正しくないのかもしれません（意図的なのか、無知なのか、RFCに反しているSPAMは多いです）
また、携帯電話自体、RFCから微妙に外れていることもあるので、その変に原因がある可能性もありそうです。
（そのむかし、docomoがメールアドレスに、わざとRFCに反しているメールアドレスを使うよう推奨していたことはわりと有名です）

普段あまり使わない、SPAMのよく溜まるメールアドレスが１つあるので、試しつつ様子を見てみます。

メール添付メールの受信がうまく行かない件は、現在考え中です。

うぇいく様

お手数ばかりおかけして、すいません。

よろしくお願い致します。

いつもお世話になっております。けいです。

まだ、該当するメールを受信していないので確認できておりませんが、更新履歴にて修正いただけたとのこと。
また、メールの受信スピードが格段に上がっておりました。
ありがとうございました。

【その他】
可能でしたら、現在メール受信後に展開されるテキストファイルには、「cc」が記載されていませんが、それも記載していただけるとありがたいです。

上記要望もお願いできればと思っております。

お手数おかけいたしますが、よろしくお願いいたします。

互換性でちょっと迷っています。
現在のtxtの形式は、ヘッダ部分は先頭から何行目という参照の仕方で参照することが可能で、ヘッダ部分を取り除きたい場合でも一律きまった行数を捨てることで可能です。

そこに、ＣＣヘッダを追加した場合、存在するのかどうか、何行存在するのかというところが、可変になり、毎行、行の先頭を判断してゆかないと切り分けが出来なくなります。

そうすると、単純にＣＣを追加すると、txtを簡単に切り分けて利用していたユーザは困ったことになります。

既存のメールオプションのシステム変数に、簡易テキスト切り出し用のヘッダの要素を指定する方法を追加するのが影響が少なさそうかなぁ　という感じです。
（解りやすさからゆくと、オプション指定用のシステム変数の追加なのですが、たまたま同じ変数名を使っていた人は予期せぬ動きをする可能性が出てきます。）

いつもお世話になっております。けいです。

色々とご思案頂き有り難うございます。

>そうすると、単純にＣＣを追加すると、txtを簡単に切り分けて利用していたユーザは困ったことになります

正直、メールテキストを行で処理することは考えたことがなかったので（私なら「件名:」などをキーにして取り出すと思います）、そこには思い至りませんでした。

オプション指定による方式でもcc出力をデフォルトにしなければ、問題ないかなと思いますので、その方向でお願いできますでしょうか。

お手数おかけいたしますが、よろしくお願い致します。