Qdsmtp-Simple SMTP Mailer for PHP

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

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

SMTP送信の種類

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

その１（中継サーバーに配送を委託する方法）---Qdsmtpはこの実装。

クライアント(Qdmail)　→　配送元SMTPサーバー(A)（認証が必要）　→　配送先AMTPサーバー(B)（認証不要） →　相手のPC

その２（直接相手先のSMTPサーバーに配送してしまう方法）

クライアント(Qdmail)　→　配送先AMTPサーバー(B)（認証不要） →　相手のPC

一般的にSMTP送信と言った時にどちらを指すのはかは、私の経験不足でわかりません。どなたか、知っていたら教えて下さい。

認証について

過去のインターネットの世界では、SMTPは認証不要でした。しかし、それがスパムメールに悪用されるようになり、POP Before SMTPという疑似認証方式が多くで採用され、現在では、SMTP AUTHというIDとパスワードでの認証が必要になっています。
ただし、認証が必要なのは、他のSMTPサーバーに送信する中継サーバーだけです。
なぜなら、配信先のSMTPサーバー(B)は、どこのサーバーから接続されるのがわからないから、それを認証必須にしてしまうと、特定の相手先からしかメールを受け取れないことになっています。
したがって、多くのSMTPサーバーは、以下のような設定になっています。

自分が管理するメールボックス宛であれば、認証必要なく接続を許可し、他のサーバーへの中継要求は認証があれば許可するが、認証がなければ拒否する。

だから、配信元サーバーは通常認証が必要になります。そうでないとスパムの踏み台にされてしまうからです。もし、現状で認証の必要のない配信元サーバーを公開しているのであれば、即刻サーバー停止すべきものです。

２つの方法の違い

その１（中継サーバーに配送を委託する方法）

認証ありで第三者中継を許すサーバーにで接続し、各到達地点のSMTPサーバーに中継してもらう。

この方法の利点

到達地点のSMTPサーバーになんらかの理由で接続できなかった場合でも、最初のSMTPサーバーが、メールを留保し、後で、送り直しをしてくれるため、到達確立が安心できるレベルにある
いつも同じSMTPサーバーに接続するだけでよいので、面倒がない
安定した配送元SMTPサーバーであれば、しっかり配送してくれる

その代わりに、そのSMTPサーバーに自分がアカウントを持っていなければなりません。例えば、私はレンタルサーバーのSMTPサーバーやso-netのアカウントも持っていますので、たまにso-netのSMTPサーバーに認証ありで、中継してもらっています。

その２（直接、配送先の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アドレスによっては、配送元から接続拒否をされる場合がある

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

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

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