@ rfc 2231と2183を見てきました。マルチパート/関連 MIME ペイロードの処理。
以下が構文的に正しいかどうか、具体的には最初の Content-Type の「開始」属性かどうかを解読しようとしていますが、正しい RFC を見つけることができませんでした。
Content-Type: multipart/related; boundary="=_34e1b39f5c290f66360ff510d4c38da4"; type="application/smil"; start="<cid:eaec2c30d892902b14044d57dbb6ff85>"
--=_34e1b39f5c290f66360ff510d4c38da4
Content-ID: <eaec2c30d892902b14044d57dbb6ff85>
Content-Type: application/vnd.oma.drm.message; boundary=ihvdxymhvdhobklkqbcn;
name="IrishJi2.dm";
Content-Disposition: attachment;
filename="IrishJi2.dm";
--ihvdxymhvdhobklkqbcn
Content-Type: audio/mpeg
Content-Transfer-Encoding: binary
好奇心旺盛な人のための背景情報。application/vnd.oma.drm.* ファイル タイプは、ペイロード アイテム (mp3、jpg など) の単なるラッパーであり、セルラー デバイスに、ラップされたファイルが保護されたペイロードと見なされ、転送または転送を許可しないように指示します。とにかく電話。契約上の義務がなければ、ラッパーをはぎ取り、ペイロードを送信して満足するだけですが、それは簡単すぎて、おそらく違法です。