hoge.ne.jpのsmtpサーバがxxx@hoge.ne.jpしかacceptしないでSMTPのOUTBOUND制限されている時に、
foo.orgでアカウントを持ってる場合かつ、foo.orgのsmtpサーバがSMTP over SSLに対応していなかったりして、foo.orgのアカウントが重要な連絡などに使われていたら(;´Д`)
該当プロバイダでは、外の MTA に対する pop before smtp / smtp-auth が使えなくなりますね。
プロバイダが提供するメイルアドレス以外のメイルアドレスを利用する場合、
(1) yahoo.co.jp の MTA を pop before smtp / smtp-auth にて認証後利用
(2) プロバイダが用意する MTA を利用
(3) 自鯖に MTA を設置して利用
のいずれかを使って送信しますが、 25 番ポートが塞がれると (2) しか使えなくなります。
yahoo.co.jp / hotmail.co.jp みたいなフリーメイルアドレスの利用が制約される以外に、会社のメイルアドレスを自宅から利用する場合にも制約を受け、殆ど全てのメイルはプロバイダの MTA を通さざるを得なくなることとなりましょう。
そうすると、仮に受信したメイルのエンベロープ From に記されるメイルアドレスのドメインと、メイル発信元の IP のドメインとが一致するか否かを見るような設定をしている受信 MTA の場合、 spam と誤認識してしまう可能性があると思います。実際そんな設定をしているところがあるのかは知りませんが。
| yahoo.co.jp みたいなフリーメイルアドレスを利用する場合、
| (1) yahoo.co.jp の MTA を pop before smtp / smtp auth にて認証後利用
| (2) プロバイダが用意する MTA を利用
| (3) 自鯖に MTA を設置して利用
こう書いていたもんで、編集したら変なトコが残っちゃいました。
正しくはこうです↓
| プロバイダが提供するメイルアドレス以外のメイルアドレスを利用する場合、
| (1) 当該メイルアドレスを提供するプロバイダの MTA を pop before smtp / smtp-auth にて認証後利用
| (2) プロバイダが用意する MTA を利用
| (3) 自鯖に MTA を設置して利用
囲い込み？ (スコア:2, 興味深い)
# プロバイダは別ですけど、他人事ではないので…
hoge.ne.jpのsmtpサーバがxxx@hoge.ne.jpしかacceptしないでSMTPのOUTBOUND制限されている時に、
foo.orgでアカウントを持ってる場合かつ、foo.orgのsmtpサーバがSMTP over SSLに対応していなかったりして、foo.orgのアカウントが重要な連絡などに使われていたら(;´Д`)
こういう場合、spamやワーム対策に名を借りた囲い込みに発展しそうな気がするのですが…(;´Д`)
Re:囲い込み？ (スコア:2, すばらしい洞察)
25/TCPを通さないISPが普通になれば、それ以外で接続するサーバーも普通になると思います。
囲い込みにはなら無いと思いますよ。
囲い込み、というよりは (スコア:2, 参考になる)
プロバイダが提供するメイルアドレス以外のメイルアドレスを利用する場合、
(1) yahoo.co.jp の MTA を pop before smtp / smtp-auth にて認証後利用
(2) プロバイダが用意する MTA を利用
(3) 自鯖に MTA を設置して利用
のいずれかを使って送信しますが、 25 番ポートが塞がれると (2) しか使えなくなります。
yahoo.co.jp / hotmail.co.jp みたいなフリーメイルアドレスの利用が制約される以外に、会社のメイルアドレスを自宅から利用する場合にも制約を受け、殆ど全てのメイルはプロバイダの MTA を通さざるを得なくなることとなりましょう。
そうすると、仮に受信したメイルのエンベロープ From に記されるメイルアドレスのドメインと、メイル発信元の IP のドメインとが一致するか否かを見るような設定をしている受信 MTA の場合、 spam と誤認識してしまう可能性があると思います。実際そんな設定をしているところがあるのかは知りませんが。
元々、 smtp-auth が発信者の身元を保証する為の仕組みであったこと、 pop before smtp がその過渡期における代替策であったこと [emaillab.org]を鑑みると、これらプロトコルの存在意義が半ば失われてしまうような気がします。
多分、この流れは他のプロバイダにも波及するのでしょうけれども、過渡期において若干の混乱がありそうな気がします。
フィルタの設定においては、 RBL だけに依存せず、本文も見て spam か否かを判断するようにするのが望ましいと思います。
でも、この方策が普及すると、動的 IP を対象外に出来ますから、 RBL の管理は多少楽になるでしょう。
それと、中継ホストの特定が容易になり、今までよりも spam の判定が楽になるでしょう。
本来、ポートを塞ぐという、このような制約は好ましくないのでしょうけれども、 spam 抑止の為には致し方ないと思います。
Re:囲い込み、というよりは (スコア:2, 参考になる)
そこで、WAKWAKのリリース文 [ntt-me.co.jp]でも言及されていました、Submission port(port 587)ですよ。まだ使えないところがほとんどだと思いますが、MTAとMSA(Message Submission Agent)を区別する方向にある(RFC2476)とすれば、流れとしては正しいかと思います。
今後のSender-IDに代表される送信者認証技術が普及するとすれば
> (1) 当該メイルアドレスを提供するプロバイダの MTA を pop before smtp / smtp-auth にて認証後利用
を、Submission portで行うという形がメール送信の最終形になるでしょう。
# ちなみに、SMTP over SSLは Submission portでのSTARTTLSに集約されると思われます。
>多分、この流れは他のプロバイダにも波及するのでしょうけれども、過渡期において若干の混乱がありそうな気がします。
これは何をするにしても難しい問題ですね。混乱を完全に避けようとすると鶏卵問題でいつまでたっても実行できないという事態に…
Re:囲い込み、というよりは (スコア:1)
当初の原稿に
| yahoo.co.jp みたいなフリーメイルアドレスを利用する場合、
| (1) yahoo.co.jp の MTA を pop before smtp / smtp auth にて認証後利用
| (2) プロバイダが用意する MTA を利用
| (3) 自鯖に MTA を設置して利用
こう書いていたもんで、編集したら変なトコが残っちゃいました。
正しくはこうです↓
| プロバイダが提供するメイルアドレス以外のメイルアドレスを利用する場合、
| (1) 当該メイルアドレスを提供するプロバイダの MTA を pop before smtp / smtp-auth にて認証後利用
| (2) プロバイダが用意する MTA を利用
| (3) 自鯖に MTA を設置して利用
Re:囲い込み、というよりは (スコア:1)
SMTP over SSLでsmtp-authなら(1)も使えるのではないでしょうか。
gmailのようなところだとWebから送るという手もありますし。
# そういうのに対応してないところの話なのかも。
Re:囲い込み？ (スコア:2, 参考になる)
Re:囲い込み？ (スコア:0)
Re:囲い込み？ (スコア:0)
誰が何に囲い込もうとしてるわけ？
Re:囲い込み？ (スコア:2, おもしろおかしい)
＃こんなん？
--
「なんとかインチキできんのか？」
Re:違うな (スコア:0)
「ガンダムseedが一週早く見れるのはフレッツスクウェアだけ！」
かな。NTTつながりで。