パスワードを忘れた？ アカウント作成
Close
3145 story

FOMAとDDIポケットはメールの相性が悪い？ 100

ストーリー by wakatono
出すと必ず添付ファイルつき 部門より

mabu 曰く、 "セキュリティホール memoで知ったのですが、ZDNet Mobile Newsの記事によると、ドコモのFOMAから送信されるEメールには、添付ファイルの有無に関わらず必ずヘッダに「Content-Type:Multipart/mixed～」がつくそうです。そして、これをDDIポケットで受信すると毎回「添付ファイルあり」になってしまうんだとか。特に、ライトEメールの場合は添付ファイルを受信しようとすると最低5円課金されるため、両社の手抜き仕様によってユーザが直接的な被害を受けているそうです。"

ドコモのページにもDDIポケットのページにも今のところこの問題に対するコメントはない。こいつは思わぬ落とし穴。早期改善を求む…

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

FOMAとDDIポケットはメールの相性が悪い？ More

  • DDI ユーザよりZDNet ＆ Docomo様へ (スコア:3, すばらしい洞察)

    by kicchy (4711) on 2002年06月05日 22時41分 (#103137)
    > DDIポケット側のサーバにも問題が皆無とはいえない。
    > ライトEメールではヘッダ情報を信じきってしまっているし、
    > Eメールではヘッダ情報から添付ファイルが存在すると
    > 思いこみ、実際には受信されないので大きなサイズの
    > 添付ファイルが届いたものと誤判断してしまっている。

    もともとヘッダ情報がなぜあるかという理由を考えれば
    DDI側には全く非がないことが分かる。
    ヘッダ情報は、大きな本体の情報を直接見なくとも
    効率よくメールを捌くために存在する情報である。

    つまり、普通の郵便物だと「郵便番号」に当たると言えるだろう
    ZDNetの記事の書き方を郵便物になぞらえてたとえると

    「ドコモから発信される手紙は郵便番号が間違っている
    　のだからちゃんと住所を確認して配信しましょうね」

    ということだ。郵便番号の存在意義は？

    Docomo様、対応よろしくお願いします。

    > もっとも常識的に判断すればDDIポケットをあまり責める
    > ことはできないだろう。誤まったヘッダ情報でEメールを
    > 送信してくるのはFOMA、正確にはドコモのメールサーバ
    > だからだ。

    記事を書く際、中立的な立場であろうとするあまり
    誤った表現を取ってしまっただけであろうと、
    今回は思っておくことにする。
    「あまり」という単語を取れば誤解はなかったのだが・・・
    • 郵便番号と言うより納品書だな。
      結論は同じとこに行くが。

      一方、今時はFOMAに限らずMaliciousなメールも多いので、盲目的に信じるのもどうかとは思う。
      空添付メールに課金してしまったり、でかい添付ファイルと勘違いして動作がスタックしたりというのは受け手のシステムとしてどうよ?と思わないでもない。
      (FOMAの発信方式がMaliciousで、要改善であるのとは別。)
      シェア
      親コメント

    • ・・・と、まあ (スコア:1)

      by kicchy (4711) on 2002年06月05日 23時30分 (#103174)
      扇情的に書いてみたものの
      今度は冷静に、Docomo側に立って考えてみる。

      「マルチメディア情報を送信するときは、
      　body一つでも multipart/mixed の方が便利なんだよね
      　別に仕様上問題ないでしょ？」

      ・・・了解。

      ですが、できればテキストデータ「のみ」の送信の際は使わないでください。
      以上。

      あれ？やっぱDDIユーザだと、見方偏ってますか？

      誰か～ Docomoのフォローしてあげてくださーい
      シェア
      親コメント

      • Re:・・・と、まあ (スコア:0)

        by Anonymous Coward
        DoCoMoのフォローする気は全然ないのですが、ZDNETの元記事
        にあるヘッダからは添付ファイルがあるとは特定できず、単なる
        マルチパートのメールが来ているとしか判断できないので

        この情報を元に誤課金をしていたのであればそれは明らかにDDIのミスなんじゃないの。

        と思ったりします。

        もっと

        • Re:・・・と、まあ (スコア:1, 参考になる)

          by Anonymous Coward on 2002年06月06日 9時40分 (#103369)
          いやなんつーか、DDIPのライトEメールの課金方法をちゃんと知ってます?
          ■　 ライトEメールとは
          　 １． Ｈ"LINKのEメールアドレスあてのEメールがセンターに届いた場合に、全角１２３文字（※１）までのEメールを、自動的に端末が受信します。
          と言う単なる文字数制限なので、multipart で受けてしまった場合には余計な mail body 部分が発生し(or 添付ファイルがあることでライトEメールとして扱われなくなり)、結果として文字数を超えてしまうと言うのが問題だと思います。

          DDIP 側が multipart をサーバで解除するわけにも行かないし、端末仕様は当然固定だし、対策しろったって無理じゃないのかなぁ。
          シェア
          親コメント

          • Re:・・・と、まあ (スコア:1)

            by imo (5135) on 2002年06月06日 11時14分 (#103440)
            >をちゃんと知ってます?

            知ってますよ。 (^^)

            >結果として文字数を超えてしまうと言うのが問題

            そうですね。
            でも、文字数で別種サービスにしたり、そこで課金するかしないかはDDIPの仕様ですね。
            今回に限らず、おかしなメールが来る可能性を無視した仕様で迷惑を蒙るのはユーザなんですよねぇ。
            シェア
            親コメント

  • RFC (スコア:2)

    by Kow (2603) on 2002年06月06日 0時12分 (#103195) ホームページ 日記
    RFCって単なるメモ書きですよね？
    それをどう実装するかってのとは話が違いますよね？

    • Re:RFC (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2002年06月06日 5時43分 (#103304)
      そう考えるのはあなたの自由ですが、
      そういう考えで他人とつながろうとするのは迷惑なのでやめてください。
      シェア
      親コメント

    • Re:RFC (スコア:1)

      by sakamoto (8009) on 2002年06月06日 10時10分 (#103387) 日記
      まあ、話はプロトコルなので、守れば通信ができる、守らなければ 通信ができないということです。 どうしてメモ書きでも公開されているかというと、 守れば通信ができるようになるからです。
      --
      -- 哀れな日本人専用(sorry Japanese only) --
      シェア
      親コメント

    • Re:RFC (スコア:1)

      by iwa (2980) on 2002年06月06日 10時53分 (#103421)
      > RFCって単なるメモ書きですよね？

      「単なる」ではないと思いますが。

      STD1(RFC3000): Internet Official Protocol Standards [ring.gr.jp]
      > Status of this Memo
      >
      > This memo is an Internet Standard.
      > Distribution of this memo is unlimited.

      こんなの付いてるRFCは多数ありますが。
      シェア
      親コメント

    • Re:RFC (スコア:0)

      by Anonymous Coward
      > RFCって単なるメモ書きですよね？

      おっしゃるとおり

      > それをどう実装するかってのとは話が違いますよね？

      一般論としては、製品／商品の説明にインターネット対応の電子メールとか、MIME対応とか書いてあったら、RFC（Standard Track以上）準拠でないとまずいんじゃないかな。

      本論とはややずれますが、

      ユーザーが多いけど標準非準拠（デファクトスタ

  • 無理も無い (スコア:1, 興味深い)

    by Anonymous Coward on 2002年06月05日 22時22分 (#103127)
    以前メールソフトを作った事がありますが、
    mime仕様を守ってないMUAなんて当たり前。
    (当然mimeなんて信用していない設計しました)

    携帯メールはサブジェクトをエンコードしない、
    数千行も改行無し、特殊文字に泣かされたりと
    散々でした。

    それらに比べたら文字コード問題、
    HTMLメール問題なんて屁でもなかったです。
    かかった時間の8割はソケット周りとGUIですが。

    規格を守るなんて実仕様の前では絵空事なんだろうか。

    • Re:無理も無い (スコア:0)

      by Anonymous Coward
      規格を守るなんて実仕様の前では絵空事なんだろうか。
      絵空事でしょう。少なくともマイクロソフトが大きな面をしてる限りは。
  • RFC2046 を読むと multipart で一個だけ中身を含むのは 一向に構わないみたい。

    5.1 Multipart Media Type の節でも、「一つまたはそれ以上の ……」というくだりがあるし、5.1.1 では multipart で 丁寧に text/plain が一つだけ含まれていて、ずばり「 The use of the "multipart" media type with only a single body part may be useful in certain contexts, and is explicitly permitted. 」って書いてあるし。

    ただ、例をよくみてもらえればわかると思うけど、multipart と 言っても同時に通常の本文も存在できるわけだから、 通常の本文のみを表示して multipart 部分を処理しないような 仕様というのはあり得るとも思います(あらゆる MUA がフルセット のMIMEを実装しなければならないわけではないし)。

    ということでFOMA側の実装にルール違反はないけれど、 メッセージを multipart とかに押し込んじゃうと 相手側で処理できないリスクがあるって感じじゃないかな?

    --
    -- 哀れな日本人専用(sorry Japanese only) --

  • DDIは悪くないんじゃ？ (スコア:0)

    by Anonymous Coward on 2002年06月05日 21時56分 (#103108)
    ＞両社の手抜き仕様

    ドコモが一方的に悪いように感じるけど？

    • Re:DDIは悪くないんじゃ？ (スコア:2, すばらしい洞察)

      by imo (5135) on 2002年06月06日 6時04分 (#103309)
      1.送出する側の「(みんなに)うれしくない」仕様
      2.受信する側の「(ユーザに)やさしくない」仕様

      どっちもどっちだと思うよ。

      ドコモがなんでもかんでもドンブリで出すのもアレだと思いますが、
      課金する/しないの垣根の仕様はDDIが作ってるわけで、そこが野放図なのはDDIの責任でしょ。
      さらに、Eメールのサイズオーバーと判断する仕様は言うに及ばずって感じで。
      シェア
      親コメント

    • Re:DDIは悪くないんじゃ？ (スコア:1)

      by longest (8987) on 2002年06月05日 22時08分 (#103112)
      同感。ドコモが手抜き・一方的に悪いに１票。
      なにかと迷惑なドコモ。
      ほとんど関係ないが、しばらく前まで、うちの鯖(postfix)からメイルを送信すると高い確率で遅延するのがドコモ（非FOMA）だった。
      シェア
      親コメント
    • 同感.
      そもそも、誤ったContent-Typeを付けているのだから悪いのはドコモだと思います
      リンクしてある記事には、DDI側は、「ヘッダ情報を信じきってしまっている」と書かれていて、それがいけないことのように書かれていますが、それは、間違いでしょう
      メールのヘッダは、ボディの構成やエンコード方法などボディ部分を正しく再現するための情報なのだから、PHSがこれらの情報を信用してメールを表示することは、正しい動きだと思います
      シェア
      親コメント
      • GIFを添付して、

        Content-Type:image/gif

        となっちゃうと、読めないケータイというのがありました（添付無しになるんだったかな..）。
        で、そのすぐしたに、ファイル名が書いてあるんです（どんなヘッダだったか、忘れてしまいました）

        Content-Type:image/gif hoge.gif

        み

        • Re:DDIは悪くないんじゃ？ (スコア:1, 参考になる)

          by Anonymous Coward on 2002年06月06日 0時13分 (#103197)
          # DDIっていうと、「第二電電」かと思ってしまう。
          # DDI-Pっていう方が、一般的なんですかね？それとも、ただ「ポケット」？
          # 「エッジ」の方が、良いのか....。

          Content-Type: image/gif
          Content-Disposition: attachment; filename=hoge.gif

          が、正解だと思います。
          シェア
          親コメント
      • こんなところにももう一人。
    • 肝心のFomaのメールをちゃんと調べてないんですが、 ちらっとRFC2046に目を通した限り、BNF的にはbodyは１つでも かまわないように読み取れるのですが、間違ってます？

      規格を乱用するのがいけないのか、規格から勝手な仮定を導いちゃんと実装して いないのがいけないのか…。 MIME規格の詳しい人の助言希望。
      • 5.1.1, page 21には

              The use of the "multipart" media type with only a single body part
              may be useful in certain contexts, and is explicitly permitted.

              NOTE: Experience has shown that a "multipart" media type with a
              single body part is useful for sending non-text media types. It has
              the advantage of providing the preamble as a place to include
              decoding instructions

        とあります。かいつまむと、
        ・パートが一つだけの"multipart"はOK
        ・non-textなデータを送る時に便利だよ

        だからRFC2046的にはDocomoもDDIもハズしてる…？
        シェア
        親コメント

  • どうなんでしょうか (スコア:0)

    by Anonymous Coward on 2002年06月05日 23時19分 (#103160)
    multipart/mixedって宣言してても問題はないよね。
    添付ファイルがあるはずだ，って判断するほうが 間違ってるんじゃないの？
    まあ，気色悪いことはたしかだけど。

    • 携帯電話に限らなくても IMAP な環境だけで head 部分だけ拾ってる場合などを考えると、やはりちゃんとした head をつけてあげないと、相手が困っちゃう気も。

      Takeshi HASEGAWA

      シェア
      親コメント
    • part がひとつも無くてもですか？

      • Re:どうなんでしょうか (スコア:1)

        by nackey (3237) on 2002年06月06日 0時56分 (#103218)
        ZDNETの記事からだけでは、ヘッダにmultipart/mixedとあることだけが明確になっていて、メッセージボディが
        1. partに分かれていない(text/plainのパートすらない)

        2. text/plainのパートがひとつだけある
        のどちらなのかがわからないのですが、partが一つもないと判断したソースはどこにあるのでしょうか?
        シェア
        親コメント
        • ZDNetの記事によると、「FOMAから送信されたEメールでは、必ず「Content-Type:Multipart/mixed～」がヘッダに付加されている」とのことなので、プレインテキストの普通のメールも含めてそうなっているということでしょう。そのときに、まさか、

          This is a mu

  • ZDNetよ (スコア:0)

    by Anonymous Coward on 2002年06月06日 0時11分 (#103194)
    > ライトEメールではヘッダ情報を信じきってしまっているし

    だったら、何を信じればいいんだ！？と問い詰めたい・・・。

    郵便が届いて、箱を空けたら手紙が１枚入っていた、郵便局になんだ！手紙だけじゃねーか！箱開けて確認しろよな！と怒れるのか？

    ---
    臆病な匿名野郎Ａチーム

  • ドコモが悪いと (スコア:0)

    by Anonymous Coward on 2002年06月06日 2時53分 (#103264)
    (´ー｀).｡oO（ドコモが「悪い」とこうやって罵詈雑言の嵐になるが
    　　　　　　　　J-PhoneのメールサーバがRFC無視しまくりだった(今は知らない)のは
    　　　　　　　　誰も文句言わないのは何故だろう…

    正直、サービス開始時のSkywalkerメールほど酷いものはないと思うが。
    今は直ってるんですかね？
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常