SMTP送信の方法

2008/08/30 未分類 spok
SMTPサーバー送信は、実装としては2種類あるかと思います。ここではその解説です。

基礎知識

メールは一般的には以下のような配送ルートで送られます。

一般論
クライアント(Qdmail) → 配送元SMTPサーバー(A) → 配送先AMTPサーバー(B) → 相手のPC
最後の(B)→相手のPCはPOPプロトコルであり、その他はすべてSMTPプロトコルで配送されます。
ここでQdmailは、クライアントとなります。
PHPのmail関数を利用した場合は、以下のようなルートです。
クライアント(Qdmail) → mail関数 → sendmail・配送元SMTPサーバー(A) → 配送先AMTPサーバー(B) → 相手のPC
sendmailは、PostFixであったりQmailであることもあります。QmailとQdmailは違いますので、ご留意下さい。
sendmailというのは、ひとつのプログラムで、送信サーバー、中継サーバー、受信サーバーの1台3役のサーバーなので、よく理解がごっちゃになりやすいので気をつけて下さい。

mail関数とSMTP送信の違い

mail関数の方がSMTP送信の段取りをやってくれるため、PHPプログラムは簡単になります。一方で、mail関数そのものが、ちょっと改行コードの取り扱い等に難点があり、文字化けの原因になったりします。

SMTP送信は文字化けについては、mail関数より信頼性が高いものの、SMTPプロトコルでの送信をPHPプログラムが面倒見無ければならないので、面倒です。Qdsmtpは、その面倒さを引き受けて、ユーザーの負担を軽くするものです。

SMTP送信の種類

SMTP送信の中にも大きく2種類があります。

その1(中継サーバーに配送を委託する方法)---Qdsmtpはこの実装。
クライアント(Qdmail) → 配送元SMTPサーバー(A)(認証が必要) → 配送先AMTPサーバー(B)(認証不要) → 相手のPC         

その2(直接相手先のSMTPサーバーに配送してしまう方法)
クライアント(Qdmail) → 配送先AMTPサーバー(B)(認証不要) → 相手のPC
一般的にSMTP送信と言った時にどちらを指すのはかは、私の経験不足でわかりません。どなたか、知っていたら教えて下さい。

認証について

過去のインターネットの世界では、SMTPは認証不要でした。しかし、それがスパムメールに悪用されるようになり、POP Before SMTPという疑似認証方式が多くで採用され、現在では、SMTP AUTHというIDとパスワードでの認証が必要になっています。
ただし、認証が必要なのは、他のSMTPサーバーに送信する中継サーバーだけです。
なぜなら、配信先のSMTPサーバー(B)は、どこのサーバーから接続されるのがわからないから、それを認証必須にしてしまうと、特定の相手先からしかメールを受け取れないことになっています。
したがって、多くのSMTPサーバーは、以下のような設定になっています。
自分が管理するメールボックス宛であれば、認証必要なく接続を許可し、他のサーバーへの中継要求は認証があれば許可するが、認証がなければ拒否する。
だから、配信元サーバーは通常認証が必要になります。そうでないとスパムの踏み台にされてしまうからです。もし、現状で認証の必要のない配信元サーバーを公開しているのであれば、即刻サーバー停止すべきものです。

2つの方法の違い

その1(中継サーバーに配送を委託する方法)
認証ありで第三者中継を許すサーバーにで接続し、各到達地点のSMTPサーバーに中継してもらう。

この方法の利点
  • 到達地点のSMTPサーバーになんらかの理由で接続できなかった場合でも、最初のSMTPサーバーが、メールを留保し、後で、送り直しをしてくれるため、到達確立が安心できるレベルにある
  • いつも同じSMTPサーバーに接続するだけでよいので、面倒がない
  • 安定した配送元SMTPサーバーであれば、しっかり配送してくれる
その代わりに、そのSMTPサーバーに自分がアカウントを持っていなければなりません。例えば、私はレンタルサーバーのSMTPサーバーやso-netのアカウントも持っていますので、たまにso-netのSMTPサーバーに認証ありで、中継してもらっています。

その2(直接、配送先のSMTPサーバーに接続する方法)
送り先のメールアドレスに合わせて、その都度異なる(当該メールを管理する)SMTPサーバーに認証なしで接続して送信することになります。

例えば、ドコモユーザー(***@docomo.ne.jp)に送信する場合には、mfsmax.docomo.ne.jpというSMTPサーバーをdocomo.ne.jpという情報からインターネット上で逆引きして探しだし、そこへ接続します。
gmailユーザー(***@gmail.com)であれば、gmail.comの受信サーバーたるASPMX.L.GOOGLE.COMを探しだし、そこへ接続します。

認証なしサーバーは第三者中継は行わないものの、そのSMTPサーバーが管理するドメイン(サブドメイン)のメールボックス宛であれば、認証なしで受け入れます。

この方法の利点
  • 直接接続なので認証がいらない
という点です。

一方で、欠点もあります。
  • 送り先のメールアドレスから、IPアドレスなり、SMTPサーバーなりを逆引きしなければならず、また、接続エラーの場合の処理を自前で実装しなければならない
  • エラー処理は、PHPだけでは完結が難しく、必ず、サーバーの設定等も必要になることが多いので、可搬性のよくない(万人向けではない)ソフトになってしまう
  • そのPHPプログラムが動作するIPアドレスによっては、配送元から接続拒否をされる場合がある

配送元が接続拒否をする場合とは?

その2(配送先サーバーに直接送信)の場合によく問題となるのが、例えばdocomoユーザーへのメールが届かない、という問題です。参考<Radish3(Docomo対策編)>-パソコンおやじ
ドコモでは、スパム対策のために、「怪しいとドコモが判断した送信元サーバー」からは、接続を受け付けないか、極端に待たせるか、優先順位を下げるなどの設定にしているようです。
ここではドコモを取り上げましたが、このように送信元サーバーの制限をするプロバイダは他にもあるそうです(詳しくは調べていません。)
何を持って「怪しい」と判断するかは、そのサーバーの管理者のポリシーなのでなんともいえませんが、いわゆる「プロバイダ事業者」が管理するサーバーは特段の問題はないものの、ダイナミックDNSなどでIPアドレスが頻繁に変更となるサーバーや、これまでに大量送信が確認されたサーバー、もしくは見慣れない?サーバーなどは問題となることが多いようです。
これは、私たちが、PHPを使って直接配信先に接続しようとした時、配信先のサーバ-に、審査されることを意味します。
例えば、会社のテストサーバーから繋ぐと、「怪しい」と判断されるかも知れませんし、それを運用環境にもっていってIPアドレス等が変更になれば、「怪しくない」と判断されるかも知れません。その逆もあるかも知れません。このように、開発環境と運用環境で、接続確立がかわるため、開発は面倒です。

この問題は、配信先のサーバーの問題であるため、その1(中継サーバーに中継してもらう)方法でも、起こりえます。しかし、通常、その1の方法の場合は、かなり信頼性のあるプロバイダやレンタルサーバー事業者のSMTPサーバーを利用することが多いので、問題が表面化することは少ないといえます。
逆に、その1の方法でも、自社で立てたテストサーバーのようなものであれば、同様の問題がでてくる可能性はあります(あくまでも可能性)。

Qdsmtpの対処と今後

現状

現状では、その1の方法だけなので、いろんな所にメールを送りたければ、サーバー認証またはPOP Before SMTPにて、対処しないといけないと思います。

今後

いずれは、Qdsmtpも、その2 の方法もサポートしたいとは思いますが。。。。時間があれば。
その時には、その2の方法を接続を試みて、接続負荷だった場合には、その1の中継サーバーにお願いする、というような方法になるでしょう。