詳しくは下記↓
SMTPのRFC規約改定
抜粋します。
迷惑メール対策が世界的に標準化されつつあるという感じですね。
IPV6、、、まだ触れたことがないので、あまり実感がないです。
実用されているところを見たり経験してみたりしたいですねー。
個人的にはここが一番うけた。
SMTPのRFC規約改定
抜粋します。
Section 2.1で送信用途にのみSMTPを利用する、 いわゆる(Mozilla ThunderBird などの)メール クライアントはRFC 4409のMessage Submission Protocol を使用するように推奨しています。 Message Submission Protocolの詳細は割愛しますが、 メールを送信(投函)するだけの場合はSMTPの 25番ポートではなくMessage Submissionの587番 ポートでサービスにアクセスするべきということです。 日本国内では多くのISPがスパムメール送信防止 のためにOutbound Port 25 Blockingを実施している 場合も多いので、既にMessage Submission Protocol の利用は一般的となっていますね。 |
Section 6.2ではいわゆる「迷惑メール」に触れています。 要約すると以下のような感じです。 ○全てのメールに対してバウンスメッセージを返す という方針は実用的ではない。 ○無闇にメールをドロップすることはインターネット メールの信頼性を台無しにしてしまう。 ○無効なリターンアドレス(エンベロープのFrom アドレス)のメールは本当に無効と判別できたときに のみにドロップするべき。 ○敵意を持った内容(これを決めるのは本仕様の範囲外) のメールに対する受け側に有用であると判断できない 限りはバウンスメッセージを送信すべきでない。 メールのバウンスを悪用したスパムメールが横行して いる現状を踏まえた記述となっているのですが、結局 どうすればいいの?という感じです。 簡単にメールをドロップしてはだめだけど、悪意のある メールにはバウンスメールを返すな。ということが 言いたいのでしょうけど、そんな都合のいいこ とが簡単にできれば苦労しませんね…。 |
RFC 2821で"A RR"(Address Resource Record) となっていた箇所が、"address RR"となっていました。 これはIPv6のアドレス資源レコードが"AAAA RR" で あるためです。 また、Section 5.2でIPv4とIPv6のデュアルスタック に関する記載が追加されています。 RFC 3974(SMTP Operational Experience in Mixed IPv4/v6 Environments)では標準としては十分でない としていますが、ローカルな状況を考慮して、IPv4と IPv6相互の運用を容易にするメカニズムを供給する ことが望ましいと述べています。 |
IPV6、、、まだ触れたことがないので、あまり実感がないです。
実用されているところを見たり経験してみたりしたいですねー。
- J. Klensinさんの住所が変更。 |
個人的にはここが一番うけた。
免責
この記事やプログラムによって生じた事故・損害などは一切保証致しません。ご自身の責任でご使用ください。
子育てブログ「おとう日記」はじめました。
興味ある方、是非ご覧下さい!
おとう日記
コピペプログラマの倉庫を作りました。
サンプルプログラムなど置いておきますのでお立ち寄り下さい。
コピペプログラマ倉庫
良ければ↓投票お願いします↓ m(._.)m ペコッ
人気ブログランキングへ
0 件のコメント:
コメントを投稿