海外からの spam が届く人は、このような画像だけ貼り付けられた spam を見ることがあるでしょう。
昨年から急激に増え始めた、所謂「画像spam」と言う奴です。
メール本文にASCIIなどで文面を書いた場合、ベイジアンフィルタやマッチングフィルタによって迷惑メールとして処理される為、spam の主流となりつつあります。
しかし、このメール非常に対処がし難い訳です。
なんせメール本文が無いので本文から spam かどうかを調べる手段がありません。
手がかりはメールエンベローブからとなるのですが、殆どの場合差出人は詐称されており、X-Mailer や User-Agent は Outlook 等に偽装されており、日付は無いわと散々たる物です。
このような画像spamに対抗する為、OCR のように画像を解析して中の文面を読みとりフィルタするような技術も開発されているようですが、正直なところ

メールに画像がついていたら１通づつ画像解析するんかい！(ﾟДﾟ)

そらーあんた余りにもＣＰＵパワー使うんじゃないか？
メーラー側でやる場合、「一旦画像がくっついたメールを受信してから破棄する」ってことになりますのでメール受信してるやんけ！人の目に晒されるか否かでしかないので、そんなら最初から目視で確認した方が早いような気がします。
受信そのものが負担な訳ですのでサーバ側で処理したいものですが、自分しか使っていないようなメールサーバならいいんですが、毎日大量のメールを処理する場合、ＣＰＵパワーが腐るほどあっても足りなくなりそうです。
サンプルで１枚ＵＰしましたが、文字の大きさや位置、色、ノイズパターンは完全にランダムに構成されており、送られてくる画像で同じ物は殆どありません。
もしOCR的なフィルタがでても、それが文字では無かったらOCRの意味も無くなりますな。あと予言（not 予想）しますが、もしOCR的なフィルタが完成しても spammer は縦書きで対応してくれちゃったりすると思います。こーゆーフィルタが国内で作られるのは随分と先だと思いますし。海外メーカーは日本語なんか対応してくれないと思いますので。
結論からすると、ムリ。マジムリ。それで正しいメールの遅延が発生したらそっちの方がよっぽど困るナリヨ。

これも全て HTML メールが悪いと思います。（またそれか

まぁぶっちゃけると現実的な対応策としては Inbound Port 25 Blocking になってしまう訳です。最近国内のISPでも Outbound Port 25 Blocking が多く行われていますので OP25B を見ることは多いと思いますが、IP25B は入ってくるメールを制限する訳です。

入ってくるメールを全て規制すれば spam も受信しなくて済むヽ(ﾟ∀ﾟ)ﾉ

ですが、メールが受け取れません。ハイ。
ですので、spam を送ってくる IP アドレスやホスト単位で規制をする訳です。
SPFやDKIMは差出人が詐称されているか否か？を判断するだけで spam に対して効果は薄いのですが、IP25B の場合、自分の所に spam を投げてくる奴だけを登録すればガシガシと破棄するので効果絶大です。

まぁ、IP25B を行う場合、どんなホストやIPアドレスを規制するか？って所が判断に悩む所ですが、海外のADSL回線から直接配信してくるような奴はガッツリとブロックするようにしてみました所、一気に画像spamが減りました。非常に快適です。（さすがにプライベートなサーバのみに適用。仕事用のサーバはメールロストの方がイヤンなのでかけませんが）

さて、この IP25B ですが、賛否両論に分かれる訳です。
OP25B の時もそうなんですが、反対派の意見としては「自由にメールが送信できねええ！」や「自宅鯖から送信ができねーよ！」とかです。
賛成派の人は「メールがロストするような可能性がある浮動IPで鯖なんて建てる方が悪い」「画像spamへの対応としては IP25B 以外なんかあるけ？」ってな具合でしょう。
ちなみに私は賛成派です。固定ＩＰで運営していますし。

個人的には賛成派なので、その意見としてインターネットは自由であるべきと言う思想や考えはわかるんですが、なんでもありじゃ困る訳ですよ。
どっかのニュースで見ましたが、インターネットのメール流通の大半がspamメールで占められているそうです。ほんとーなら、もっと快適に使えるはずのネットワークもそんなメールで大渋滞を起こしています。おまけに自然回復する可能性は殆ど０な状態で。
まぁ、OP25B がもっと普及したら IP25B なんて必要なくなるんですけどね。

自宅鯖やDDNSが悪いわけじゃありませんが、そーゆーのを悪用している人がいて、それに対してなにもルールも規制もない状態ではしょうがないと思いますけどね。

ふと、SPF のドラフトの和訳を読んでいて気が付いたことが。

ドメインの識別名で、_spf.example.com がどうのこうのとか書かれています。
v=spf1 redirect=_spf.example.com
みたいにして複数のドメイン管理を一つのサーバで管理しようみたいな感じだったのですが・・・ふと思ったことが。

ドメイン名に、アンダーバーって使っていいんだっけ？

Microsoft の SPF 情報を確認してみると、_spf-a.microsoft.com とかになっている。nslookup で TXT フィールドを引っ張ってみると、別段問題なし。
自作ツールでも気にしたことなかったので、そのまま _ を送信していて問題ないんで、通るんでしょうけど、ドメインじゃなくて、FQDN（つーかサブドメイン）だったら別に問題ないんかなー？

でも、こういう紛らわしいアンダーバーを使わずに、デフォルトで使用してＯＫな
ハイフンで定義すりゃええのに。

JEAG 辺りに問い合わせしてみたい気もするんだけど、シカトされそうなんで止めておくことにします（笑）

しかし、DNS が現在もっとも成功しきちんと運営されている分散化システムだとしても、DNS の機能ばかり使ったものが多いなぁ。
DNS ばかりに頼った機能がどんどん増えていき、ある日 DNS に重大なセキュリティホールが見つかったりしたら、どうするんだろう。
なんて思ったりもします。

なんか、アメリーカでは 2008年くらいには主要部分は IPv6 に移行するとかなんとか。（うろおぼえ）

国内ではどうにも動きが鈍い（それに大手ISP が IPv6 をオプションで追加料金取ったりしてるんで）のですが、まぁ、それなりに動いているようです。

当然、将来的には IPv6 に移行するのは確実な訳ですので、石橋を叩いて渡らない私は、IPv6 に対応しておくべーとライブラリを書き直してみたり。

WindowsXP には、IPv6 はデフォでインストールされていませんので、MS のサイトから追加コンポーネントでゲットしてきます。
さーて、Winsock 2.2 で初期化してうごかそーかなーと思ったら・・・

Delphi で肝心要の GetAddrInfo が使えねえええヽ(;´Д`)ノ

まぁ、いつものことです。えぇ。だって Delphi だもの。
SDK 2003 からそれらしきヘッダを探してきて、片っ端から Object Pascal に移植していきます。（GetAddrInfoW があるのに、GetAddrInfoA が無い所で少々ハマった。getaddrinfo で Define してるやん・・・ws2_32.dll をエディタで覗いて確認しちゃったよ）

なんか、新しい構造体が増えているなぁ。size_t なんか使うなよ。移植しにくいったらありゃしない。ブツブツ言いつつもさくっと移植完了。
動く動くヽ(ﾟ∀ﾟ)ﾉ

Winsock 1.1 の時は GetHostByName とか使う訳ですが、これの代わりになるのが上記の GetAddrInfo です。この GetAddrInfo でうｓが、GetHostByName と比べてなかなか賢くできており、１つのホスト名に複数のIPアドレスが割り当てられている場合なんかはどれを引っ張るのかわかりません。（全部取りたい時は DNS とかに問い合わせする必要があります）

しか～し！ GetAddrInfo はコール１発で、列挙してくれるのですんげー便利です。
IPv4 で取得したいときは、AF_INET 指定すればいいし
IPv6 で取得したいときは、AF_INET6 を指定すれば個別に取得もできます。
（同時に両方ゲットすることもできます）

ちなみに、Winsock 2.2 は下位互換があるので、Winsock 2.2 で初期化しても問題なく GetHostByName を使うこともできますが、こりゃ使わないと損です。

つーか、IPv6 対応なんてそんなに難しくないはずなのになんで少ないんだろね？
（まぁ、日本語の資料が極端に少ないってのもありますが・・・手持ちの Winsock2 の専門書にも GetAddrInfo の G の字も書かれてなかったし）
あと、テスト環境が無いよなぁ。Windows Vista ではデフォで入っているようなので　Vista が出たら普及するかもしれません。

取りあえず IPv6 の telnet サーバでも作ってみようかと思ってます。

Ps.
画像中の IPv6 アドレスに 2001:358:123:00:00:00:00:101 とかありますが、これは単なる手抜きです。
本来の表記は 2001:358:123::101 とかになるはず。

ってのがあります。メールの送信者認証技術の主流となるだろうと思われる規格です。
Sender ID は元々 SPF (Sender Policy Framework) を改良したもので（正確には違うけど）
DKIM は DomainKeys を改良したものです。

で。

それぞれに対応するアプリ（正確にはサーバ）を作っているんですが・・・
両方とも負荷の割には効果がすくねえええええヽ（；´Д｀）ノ

まず、Sender ID、DNS に問い合わせるだけなんで、楽ぽ～！ってのが売りですが
例えばですね、Sender ID をみんな使おうぜ！って言っている Microsoft の設定データを取得してみると・・・（カウント１）

v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg.microsoft.com ~all
（microsoft.com への問い合わせ結果）

こんなんでました～ヽ(ﾟ∀ﾟ)ﾉ

まぁ、簡単に読むと、まず、MX なんで、microsoft.com の MX レコードに指定されているのは信頼できるかもよ？（カウント２）
次に、include がありますが、これは「別のサーバにデータ置いてるからさ、そっちに聞いてよ」ってことなんで、聞いてみると（カウント３）

v=spf1 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 a:delivery.pens.microsoft.com a:mh.microsoft.m0.net ~all
（カウントＡｘ２で、５）

こんなんでました～ヽ(ﾟ∀ﾟ)ﾉ
ip4 とかは IP アドレス直ってことですね。取りあえずゲットしたので戻って

次にも、include があるんで、問い合わせ（カウント６）
v=spf1 a:delivery2.pens.microsoft.com a:delivery.smtp.microsoft.com mx:exchange.microsoft.com ip4:131.107.65.22 ip4:131.107.65.131 ip4:131.107.1.101 ip4:131.107.1.102 ip4:217.77.141.52 ip4:217.77.141.59 ~all

むぅ、また MX があるよ（カウント７）、a もあるなぁ（ｘ２で９）これも聞いて戻りましょう。
次も、include なんで（しつこい）、問い合わせ（カウント１０）

v=spf1 ip4:213.199.138.181 ip4:213.199.138.191 ip4:207.46.52.71 ip4:207.46.52.79 ip4:131.107.1.18 ip4:131.107.1.19 ip4:131.107.1.20 ip4:131.107.70.12 ip4:131.107.70.16 ~all

あぁ、ここは IP だけですね。戻るっす。
次も include かよ！（ﾟДﾟ）（カウント１１）

v=spf1 a:smtp.msn.com a:smtp2.msn.com a:smtp3.msn.com a:smtp4.msn.com a:smtp5.msn.com a:smtp6.msn.com ~all

a が６っすね。（カウント１７）
全部情報ゲットしたっす～。お疲れさまです。
で、カウントってのは DNS に問い合わせる回数ですね。まぁ実際にはついでにデータが飛んできたり DNS サーバにキャッシュが残っている訳ですので回数は減るんですが最大で１７ってことです。
さて、この１７回。「microsoft.com を名乗るメール１通に付き１７回発生」する訳です。
まぁ、DNS クエリのパケサイズの問題があるから include で分割するのもわかるんですがね。多すぎ。
SPF から Sender ID にするときに、TTL というか expire みたいなパラメータを規定しておけばいいのに（e:1d なら、２４時間に１回は問い合わせしてね、とか、e:30d なら３０日に１回とか）、そういう知恵が無かったようで、そのまま仕様として流してもうたからさぁ Sender ID で送信者認証をするサーバの負担増大！当然 DNS 鯖への負担もＵＰ！ＵＰ！
巷に溢れている Sender ID の情報には、こういう具体的な負荷ＵＰの話は全然書かれて無くて、「さぁ、これに対応すれば未来は明るいぞっと！」って記事ばかり。
実際さぁ、うちのサーバに届くメールは全体で 3000通/1day（うち spam率98%以上） なんですが、少なくとも DNS サーバへの問い合わせは 3000回あるわけですな。
Bind 自体は非常に堅固なので心配はしてませんが、トラフィック食われてイヤんな感じがしないでもないです。
（当然、こんなデータはキャッシュさせるように作りましたがね）

さて、お次は DKIM 。やふ～！が提唱していることもあり、@yahoo.co.jp から送信して取得してみました。（必要な DomainKey-Signature の所のみね）

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=yj20050223; d=yahoo.co.jp;
h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type;
b=JoDZKzf9jxwLifIVoZQiukiga7FULCZYvQ+xzH2GRfbRuGExPs2QmqvuLLvgr3u2U9KZ7yoSFhaz/9maolQcOQ/VsuTZN0uD+b5go0PjsPdLJH0iM8KDzDoUaJEkLuRj ;

えーと、Message-ID と Received と Date と From と Subject と To と MIME-Version と Content-Type から「デジタル署名」を作って、DNS 鯖から公開鍵を取得してそれぞれ SHA1 でハッシュ化して、整合性を確認しろってことらしいです。

公開鍵の取得に１通につき１回ＤＮＳへの問い合わせ（これもセレクタで判断して当然キャッシュしますが）、メールヘッダからRSAデジタル署名を作らなければなりません。「１通づつ」

めんどくさいよ、ＣＰＵパワー使いすぎだよ（ﾟДﾟ）
転送するときは、Received を追加するんで、当然再署名が必要になるよヽ(ﾟ∀ﾟ)ﾉ
メーリングリストだと、From とか To とか Subject 書き換える場合が多いから、これも当然再署名が必要になるよヽ(ﾟ∀ﾟ)ﾉ
再署名するときは、サーバ側で、RSAデジタル署名作ってヘッダに書き込まないとダメダよ！
どっかの記事で転送とかメーリングリストの場合は署名範囲を小さくすればいいとか「馬鹿」なことを書いていたけど、To とか From とかを含ませなかったら、どうやって送信者を認証するんですか！？

えーと・・・長文になっていますが・・・
正直に言うと「どっちも無駄に終わりそうなんで対応したくない」が本音だったりします。
でもなぁ、Sender ID はともかく、DKIM は RFC になりそうだし。
クライアントが欲しい言うので、コツコツとコーディングしてますが、RSA がめんどくせーなー。OpenSSL とか使えば楽そうだけど、ライセンスわけわかんね！ってことなんで自前で作ってます。

まぁ、なにを言いたいかと言うと、中身を知らずに「DKIM 対応だぜやっほう！」とか「Sender ID に対応したぜ、うひょー」とかいうエンドユーザーは思いの外サーバの負担が大きくなって「なんか通信おそーい」とかになったりして。
（UDP は超軽いとか言う奴がおりますが、UDP だってパケットだぜ、念力で届く訳じゃないのよ？パケットだけじゃなくって、サーバ側のソケット資産だって使うのよ？）

そして余りそういう現実的なことを考えずに「こうすればいいんだ！」って決める規格決定側もなんだかなぁ、と。

ちなみに、Sender ID と DKIM 両方とも「安全なメール『かもしれない』」がわかるだけです。spam 対策なんてなんないなんない。よっぽど IP レベルで中国とかの IP を総ブロックした方が確実で安心です（乱暴）

って記事を教えて貰った。
読んでみると、三角とか四角とか丸を使い、それぞれに色をつけて保存する技術だそうな。
話だけを聞くと「おぉ、凄い発明だ」と思うのですが、よくよく読むとなにかおかしい。

ちょっとタイトルに踊らされている感がありますが、別に目新しい技術でも発明でもないんでは無い？と。
つまりね、今のPCの色データって「RGB」をそれぞれ 8bit 使って 1677万色を表現しています。 0xFFFFFF = 16,777,215 ってことです。
それぞれに 8bit 使っているので 3byte 使う訳ですが、これを「青の 00 は 0x000000 青の 01 は 0x000001 ... 緑の 00 は 0x000000 緑の 01 は 0x000000...」とすれば
記憶容量は３倍になります。横に RGB と並べるのでは無くて縦に RGB と並べる訳ですね。ぶっちゃけると光の三原則を使ってブラウン管に色を表示しているのと同じことです。

これに更に、△□○◇の４パターンの形状を追加するとします。
青の△の中に 00 は 0x000000
青の□の中に 00 は 0x000001
青の○の中に 00 は 0x000002
青の◇の中に 00 は 0x000003
青の△の中に 01 は 0x000004
青の□の中に 01 は 0x000005
青の○の中に 01 は 0x000006
青の◇の中に 01 は 0x000007
（以下略）
同じ面積１の中の情報量は更に４倍に跳ね上がります。
つまり、元データの 1/12 になる訳ですね。

CD や DVD や紙媒体限定でいえば、印刷や書き込める領域（面積）が限定されています。容量を増やす為に一番簡単なのは面積を増やす訳です。
今の DVD の技術を使ってレーザーディスクサイズのディスクを作ったら、そりゃーものすごい容量になります。
でも、今度は「占有面積」の問題がでます。LDが消えた理由は場所を取るからです。
CDやDVDの方がコンパクトですしね。なので、領域を大きくすることはできません。
同じサイズでより多くの情報量を記憶させるには、記憶密度を上げる必要があります。
その一つの方法として、１データ辺りが占有する面積を減らすことです。
A4の紙に、1mm x 1mm の大きさで字を書くと、最大 62370文字書けます。
（297 x 210）、これを 0.5mm x 0.5mm の大きさで字を書くと、249,480文字になります。４倍ですね。
Rainbow Technology は、大きさを小さくするのでは無く（いや小さくはするんですが）一つ一つのデータに更に色や形を取り入れてルールを作り（Rainbow format って言うらしい）１面積当たりの情報密度を上げる発明ってことになります。

ここまでですと、凄い技術ですね！ってことなんですが、実現にあたって大きな壁が。

読みとり装置の問題です。
CD や DVD などは、レーザーを当てて 0 1 を読み取ります。
HDD は、ヘッドで磁気の ON/OFF を 0 1 に割り当てて読み取っています。
たとえば CD の場合は「ピックアップで光をを当てて反応アリ！これは 1 です」
「反応がありません！これは 0 でした」と言う感じになります。
単純ですね。

しかし、Rainbow Technology の場合は「ピックアップで光を当てて『形状を読みとり』『更に色を読み取って』判定を行います」
手間が２段階ほど増えています。
形状を読み取るのは OCR のような技術で可能でしょう。
色の判断はスペクトル判定で可能でしょう。
技術的にはOKです。
しかし、更に壁があり、記事中に書かれているような記憶容量を確保する為には非常に面積を小さくする必要があり、紙のような媒体にそれを印刷する技術、更に更に紙のノイズを除去する技術（CDとかDVDには誤りを検知する機構がありますので、同レベルの物が必要ですね）、どっこい更にその装置をコンパクトにまとめる技術などの壁があります。あ、あと速度もね。
紙に250GByte書き込めましたけど、それを読み取る装置はビデオデッキくらいのサイズがあります。更に A4１ページを読み取るのに６０秒かかります。
では、なかなか CD や DVD に取って代わるのは難しいでしょう。

あと、積層技術ってーのがありまして、一番最初に書いた縦に並べるってのを DVD などでは、１層目、２層目として記憶容量を増やすことをしています。
体積は若干増えるけど、面積は同じってことですね。

まぁ、将来的にこのような発想は色つきのバーコードなどに応用されていくのでは無いかと思います。A4に250GByte は現実的ではありませんが、通常のバーコードで数十バイトしか記憶できなかったものが、QRコードにより数Kバイトに拡張されました。
このQRコードの各マトリックスに色を付ければ更に数倍になると思います。
（まぁ、これもバーコードが普及した理由として白と黒に限定していたので、高速に読みとりが可能で、更に判定ミスが少ないって理由があります）

読みとり側の新しい技術の開発に期待age と言ったもののように受け取れました。

Ps.
おっと、トラックバックを消しているんだった。
元記事は
http://d.hatena.ne.jp/starocker/20061126/p1
です。

最近まめに自宅に帰るようになったので、USB のメモリスティックにソースを入れて持ち帰るようにしています。
自宅でも当然のように仕事をしますので、ソースの整合性が取れなくなります。
事務所のサーバ経由で扱えばいいのですが・・・

転送が面倒です。（きっぱり）

自宅側はＡＤＳＬなので遅いのねん・・・
で、１日に書くコード量が多いので間違っても新しいバージョンのソースに古いソースを上書きすることは許されません。
CVS などのバージョン管理ソフトを使えばいいんですが、どうにも・・・馴染めない。
特にコーディングスタイルがソースを余り分割しないので数が少なく（そしてでかい）ので手間の方がかかってしまいます。きちんとスタイルを確定して綺麗に設定すれば手間もかかんないと思うんですけどね。

先日もマニュアルの一部を古いもので上書きしてしまい泣く泣く同じものを書く羽目になったりと困ったちゃん状態なのでちょっとしたソフトを作ってみたり。

常駐していて、ワンクリックで指定したファイルをアーカイブして日付と時間を付けてバックアップするようなソフトです。
全然 CVS のような綺麗な管理じゃないですが、悪くないです。

でも、もっと設定が簡単で２点間の差分も確認できて頻繁な更新に対応したバージョン管理ソフトってないかなぁ。
いつかソースの上書きをしてしまいそうで怖いです・・・（苦笑）

昨夜、開発マシンのビデオカードを変更して再起動を行ったら、ハードウェアが更新されたので再アクティベーションが必要だというメッセージが表示され３日以内にアクティベーションを行う必要があると表示された。
当然ながら XP Pro の正規ユーザーなので自信満々に再アクティベーションを行ったのですがアクティベーションを通過しない。

「やれやれ、電話でアクティベーションか」

と思って電話での自動対応によるアクティベーションを行ったのだがこれも通らない。
なんでだ！と思ってそのままオペレータに接続し口答でのアクティベーションを行うことに。

そこで聞かれたのは
「ＯＥＭ版を購入された時と同じハードウェアですか？」
「ハードウェアの変更はされましたか？（ビデオカードを変更したと伝える）」
「他のＰＣにインストールを行っていますか？」
などなど・・・

別にこういう質問自体は構わない。再アクティベーション用のＩＤも出されたので
アクティベーションは通過した。

最後にオペレータと話をしているので、ちょっとした疑問をぶつけてみた。

「ＰＣを自分で組み上げて利用しています。ＸＰはＣＰＵやマザーボード、メモリー、ＨＤＤとセットで購入しました。
自作ＰＣは将来的にグレードアップすることを考慮して選択をしています。
ＯＥＭ版を購入された時のセットでなければいけないと言っていましたが
例えばＣＰＵだけをアップグレードをした場合は、ＸＰを再度購入しなければならないのですか？」

答えは

「セットで購入したのであれば、ＣＰＵ交換時にＸＰを再度購入する必要がある。場合によってはアクティベーション用のＩＤを配布することはできない」

です。

確かに、Microsoft の OS は違法コピーの対象としてはトップクラスにあるだろう。
その対策としてアクティベーションという認証方式を入れたことも当然かもしれない。
アクティベーションがインターネット経由でできない場合は、電話でのアクティベーションもできるので対応に不備がある訳ではない。

しかし、ＣＰＵとセットで同じＯＳを再度購入しなければアクティベーションをさせないと言う点については「やりすぎだよなぁ」と思うわけです。
パッケージに書いてあるから問題ないとかと言う問題ではなくて、そこまでコストをかけて認証をさせてメリットがあるんだろうか？
無駄にコストアップをしているようにしか思えないのですが・・・

ネットワーク系のソフトウェアの開発を行っていると、道徳的な問題に突き当ることがあります。それは「ソフトウェア・コンプライアンス」

ぶっちゃけると「開発者として機能を追加してよりよいソフトウェアにしたい」と考えると「この機能を追加することにより将来的に問題（不具合では無い）が発生する」場合があるからです。

身近な例でいきますと、大量メール配信ソフトなどがあります。
「早く多くのメールが配信する為に様々な手法や機能を取り入れていく」ことにより「これを使った spam 業者がより多くの spam メールを配信することができる」という問題になります。しかし、これはソフトウェアの目的が早く多くのメールを配信することなのでしょうがない問題とは思います。

しかしです。このソフトが「メールのヘッダも自由自在にカスタマイズできる」ように
なった時に困ったことが起こります。差出人を偽装したメールの配信や未来からのメールの配信(*1)が可能となる訳です。

*1 未来からのメール。「それがなに？」と思われるかもしれませんが、大抵のメールソフトは日付で並び替えなどを行って表示します。未来から来るメールは当然ながらまともなメールよりも更に上に並ぶことになり、より目に付きやすくなります。spam 業者や DM 業者はこれを見越して日付すら偽装することもあるのです。

ここで開発者は最初の問題にぶちあたります。
「さて、この機能をつけることでより柔軟にメールの配信ができるな、しかし悪用されると差出人不明のメールの配信もできてしまう」
ここで２つに分かれます。

「ソフトはあくまでも道具、使う人に任せよう」
「そこまでしてしまっては問題だ、カスタマイズできる範囲を制限しよう」

前者はいわゆる、性善説に基づくものであります。
思うに今のインターネットを取り巻く様々な問題は前者の考えに基づき様々なソフトウェアの開発が行われてきたからでは無いかと思ったりします。

少々前になりますが、HTML メールの功罪と言う記事を書きました。
これがまさに上記のようなものです。
「メールの中に HTML 組み込めばもっと表現力が広がる」機能面で考えれば行き着く場所かもしれません。従来のメールは基本的にテキストのみの表現でしたので。
しかし、その結果メールのサイズが肥大化し毎日数億通と言われる spam メールに費やされるトラフィックが数倍に膨れあがったと思われます。
更にです、日本語の spam メールでは余り見かけませんが、私のアドレス宛に届く海外からの spam はテキストとしての本文が無く全ての文字が画像になっています。
また画像に僅かですが変化を加えて送信するようになっていますので、まったく防ぐことができません。１通辺り４０Ｋ前後あるメールが毎日何十通も届きます。
ヘッダも偽装されており、差出人は適当な文字で構成されており（ただし文法的には正しい）送信したソフトの名称は Outlook Express などを偽装しています。
海外からもメールが届くので、英語＝spam と言った乱暴な振り分けはできません。
spam に対して効果が高いと言われたベイズ理論を使ったベイジアンフィルタも画像に対してはお手上げです。
もし、OCRソフトのような機能をもったメールソフトが出たとします。
「画像の中に文字が書かれている」場合でしたら効果はあるかもしれませんが
「画像が見るに堪えられないような内容」であったら？

思うのは「メールは文章を送るもの。画像が必要であれば添付すれば良い。添付画像を直接見れる必要もない。」でよかったと思います。
しかし「メールで文章以外も送りたい。添付されているファイルが画像であれば開かなくても直接見れれば便利じゃない？」と言う機能に対する欲求によって追加された機能により spam 対策が難しくなっていきます。そしてこれだけ普及してしまった現状どうしようもなくなっています。

とてもとても難しい問題です。

下に BDS2006 の事を書きましたが、Delphi7 からの移行の理由のもうひとつとして新しいプラットフォームへの対応もあります。
一応 Delphi7 で WindowsXP には対応しているのですが、Delphi7 は Windows2003 には正式に対応していない為、今後 Windows2003 や Windows Vista がメインになった場合に（特に Vista）困らないようにする為な話もあります。

で、Delphi7 ももうかなり古い開発環境な訳でして、ちょこちょこバグがあったりします。
Borland も直す気が無いようなので自分で標準ライブラリを修正していたりするんですが、この辺りが直っていたり効率がよくなっているといいなーなんて目論見もあります。

さて、サービスアプリケーションの開発で Delphi には TServiceApplication などというとても便利なクラスが用意されているのですが、これの効率が非常によくないのです。
どうよくないかと言うと、サービスアプリケーションもフォーム型アプリケーションを同じ基本クラスを利用している為に余計なメッセージに反応してしまうのです。
サービス型なので WM_UPDATE とかに反応しなくていいのに、反応したりして余計なことをしてくれちゃったりします。別にきちんと動くのでいいんですがパフォーマンスを限界まで出す必要がある場合にこれは困ります。

そういう訳で、TServiceAppliaction などと言うクラスは利用せずに昔ながらの方法で API 直叩きでサービスアプリを作っているのですが（ちょっとした奴なら TServiceApplication を使うんだけどね、簡単だから）
「TServiceApplication の効率が良くなっているに違いない！きっとそうだ！」と
わくわくしながらソースを見ようと思ったら、トライアル版にはソースがついてない・・・
仕方がないので、BDS2006 の TServiceApplication を使って軽く１本作ってみてバイナリを覗いてみると・・・変わってないじゃん(ﾟДﾟ)
怪しいメモリリークも修正されてないぽいし・・・

.NET API 自体になっても、まーた API 叩きまくりんぐかよ！ヽ(;´Д`)ノ
まぁ、現状の API 叩きまくり形式もそのままコンパイル通るからいいけどさ。
これはかなり期待していたんだけどなー

普段、仕事でも遊びでも Borland Delphi7 を使ってソフトウェアの開発を行っていますが、次の Windows Vista になると Win32API が主流では無くなると言うことなので（使えるけど、メインは .NET API に切り替わる）次の言語を選択する時期が来ています。

思い起こせば DOS 時代には Turbo Pascal を使い
Windows 3.1 の Win16 API に変わった時点で Turbo Pascal for Windows になり
Windows95 の Win32 API に変わった時には Delphi 1.0 になり、Win32 API と
付き合ってもう１０年近くなります。バリバリの現役の間に次の API に巡り会えるとは！

ってーことで、久しぶりに開発環境を購入する予定。ターゲットは Borland Developer Studio 2006 です。
Delphi & C# & C++ の統合環境名優れものです。Kylix も入っているんかな？
Delphi8 と Delphi 2005 はかなり評判が悪くずっとバージョンアップをしていなかった
のですが、BDS2006 はかなりまともになっているって話もありましたので。

取りあえずトライアル版をダウンロードして、現行で開発して利用しているライブラリがどれくらい動かなくなるかをチェックしています。移行中に致命的な問題が発生した場合は購入を延期しようと思っていましたが・・・
一発でコンパイラ通っちゃったよ（笑）＜偉いぞ過去の俺！

まぁ、Object Pascal と言えども、コーディングスタイルが WindowsAPI の塊のようなものですので通らない方がおかしい訳ですが・・・メモリマネージャを利用するくらいかな（笑）

Delphi7 と比べるとちょっと実行ファイルが大きくなりますがご愛敬ってレベルです。
相変わらず EXE １本だけで外部DLLを一切必要としないファイルが作れます。
Borland製の強力なライブラリである VCL もそのまま使えます。
ただ、VCL の登録にかなり悩んでみたり・・・（今回は自動で User Package 作ってくれないのね）
なーんかインターフェースがＶＢっぽい気がしないでもないんですがキニシナイことにしましょう。

取りあえずトライアル版は３０日使えるので、その間にできるだけのチェックをして（特に開発中のソフトに致命的な不具合がでたら困るので）そしたら購入だ！