http://earth.endless.ne.jp/users/stakasa/spam/wforum/wforum.cgi?mode=allread&no=5072&page=0

niftyサーバ問題のスレッドですが、
大きくてなかなか壮観ですけどちと大きすぎるので
新スレッドに移動しましょうか？
しかも週末に入りますが現時点ではniftyの返答があったという
話は入っていませんのでもう少しかかる可能性があります。

　なおこれに関して私が作った頁は以下。
http://www2g.biglobe.ne.jp/~stakasa/spam/nifty-mondai.html

　トップページに掲げるかについての御意見、
ありがとうございます。
まず、今週中に前向きな反応が無いようなら
トップに掲げようかとも考えていたのですが、
問題が問題であること、
言うまでもなく大きな会社ですので
社内で「権限のある人達へ」周知・理解させ、
方向を決定するのに（若干の）猶予も
必要かもしれない気がしてきたのでもう少し様子を見ます。

　迷ってるんですけどね。

こんばんわ、SPAMはやだね！！です

> 　なおこれに関して私が作った頁は以下。
> http://www2g.biglobe.ne.jp/~stakasa/spam/nifty-mondai.html

見ましたー。
でもRFC2505ってRecommendationsですよね？
だとしたら必須じゃないのでRFC違反ではない気もします。

でも、niftyさんから満足のいく回答が来るといいものです！

> でもRFC2505ってRecommendationsですよね？
> だとしたら必須じゃないのでRFC違反ではない気もします。

Recommendationsであることはあまり重要ではありません。
RFCの用語では"MUST"、"SHOULD"、"MAY"が使い分けられていますが、
このことは"MUST"とされている項目だけを満たせばよい、という意味ではありません。

"MUST"は必須事項、
"SHOULD"は特別な理由がない限り従うべき事項、
"MAY"は実装者に委ねられている事項です。

"Best Current Practice"は、ネットワークの一員であれば従うべきものです。

niftyがどのような実装をしようとそれは自由です。
しかし、ルールを守らないのであればコミュニティに参加してはいけません。
それはインターネットの精神に反します。
法律ではなく技術で、放縦ではなく良識でコミュニティは発展してきました。
niftyの行っていることはコミュニティの恩恵を受けながら、その円滑な運用を妨げる行為です。

> Recommendationsであることはあまり重要ではありません。
> RFCの用語では"MUST"、"SHOULD"、"MAY"が使い分けられていますが、
> このことは"MUST"とされている項目だけを満たせばよい、という意味ではありません。

なるほどー！
じゃあプロバイダーなら守らないといけないですね！

> "Best Current Practice"は、ネットワークの一員であれば従うべきものです。

でも、Best Current Practiceって「実装者に検討と示唆を要求するもの」って感じですよね？
だとするとやっぱりRFC違反というより、RFCを推奨してないって感じなんでしょうか？

> niftyの行っていることはコミュニティの恩恵を受けながら、その円滑な運用を妨げる行為です。

早く改善されることを望みます！

> 　なおこれに関して私が作った頁は以下。
> http://www2g.biglobe.ne.jp/~stakasa/spam/nifty-mondai.html

> 見ましたー。
> でもRFC2505ってRecommendationsですよね？
> だとしたら必須じゃないのでRFC違反ではない気もします。

　私の書き方の問題ですかね。

「SPAMはやだね！！」様は御存知のことと思いますが、
改めて書いておくと、もともとインターネットというのは
どこが強制に作ったものでもなく、お互いそれぞれ
（サーバ管理者を中心としてユーザも含めて）
が円滑・適正なネットワークを組めるように提唱されたルールを守りながら参加することで
その安定した発展と維持を図ってきたシステムですよね。

http://hp.vector.co.jp/authors/VA002682/rfc_what.htm
http://rfc-jp.nic.ad.jp/introduction/WhatisRFC.html
http://e-words.jp/w/RFC.html

　ということで、「違反」といっても法律でいうような
感じとは違うんでそれを踏まえた上で強い言葉を使ったんですが．．．

　まあそういう点では厳密に言えば「違反」などの言葉は
相応しくないともいえるかもしれず、
私も事を過剰に荒立てる書き方を好むわけではないので
「概要」で使っていた強い言葉は少し和らげました。

　ただ「モラル違反」とかいう言葉もあるように、
じゃあモラルってのは必須なものかっていうとそういうわけでもない気がするんで、小節タイトルの
「インターネットのルール違反」
という言葉は残してあります。

　御了承、御理解下さいませ。

　と、思いつつも問題の箇所って

> 2.2.1. Direct MTA-to-MTA connections

> It MUST contain:
のmustって必須の意味じゃないのかなあ？

｜1.3. Terminology
｜ Throughout this memo we will use the terminology of RFC2119, [4]:
｜ o "MUST"
｜ This word or the adjective "REQUIRED" means that the item is an
｜ absolute requirement.
って書いてあるし。

> o The IP address of the caller.

でこれが問題のIPではないんですかね？

って、私の文で
「ReceivedにおいてIPアドレスを残すことはインターネットの推奨ルールで
あるRFCに定められているという。」
と書いているように知ったかぶりをするつもりはない
（というかしらんし^^;）ので教えて下さるとありがたいです。
ってうだうだしているうちにSakurai様のレスが．．．．

　う〜ん、とりあえず．．．
「セキュリティの問題」と称して
受信者に送信側のIPアドレスを渡さない仕様にしているのは
niftyさんとしてはRFC全体を見回した上で、
相当根拠があるのでしょうから示して頂きましょうか（^^;）

　Sakurai様はRFCの上の部分の根拠を示した上で、
私は１年半以上のspam啓発・対応とアドバイスをしてきた上での
問題点指摘なんですけど、それらに見合うniftyさんの返答がほしいところですね。

> 　ただ「モラル違反」とかいう言葉もあるように、
> じゃあモラルってのは必須なものかっていうとそういうわけでもない気がするんで
> 「インターネットのルール違反」
> という言葉は残してあります。

了解です。こっちのほうがしっくりきますね。
「モラル」って人それぞれ線引きが難しいとは思いますが、
ニュアンスが伝わるということであいまいだけどいい言葉だと思います！

> > It MUST contain:
> のmustって必須の意味じゃないのかなあ？

そうなんですよー。でも、RFC2505自体が「推奨」だと
この「MUST」ってどう解釈するのが妥当なのかなと思いました。※「推奨」ってことも僕の勘違いかもしれませんが、すみません


> と書いているように知ったかぶりをするつもりはないので
> 教えて下さるとありがたいですね。

いえいえ、僕のほうこそ英語苦手でして、、RFCも難しくて（＞＜）
もっと詳細を教えていただけるとうれしいです。
細かいところをぐだぐだいってしまいすみませんでした。

> 　う〜ん、とりあえず、「セキュリティの問題」と称して
> 受信者に送信側のIPアドレスをつけない仕様にしているのは
> niftyさんとしてはRFC全体を見回した上で、
> 相当根拠があるのでしょうから示して頂きましょうか（^^;）

ですね！これがこないと話になりませんね！

僕のあやふやな発言にコメントしていただきアリガトウございます！

　ちなみに、推奨であれ、ほとんど必須であれ、その仕様を守らずに
日本全国をスパムまみれにした、そして法律まで作らせてしまった
大功績者が携帯のキャリアさんであるのは言うまでもありません。

　ただ、それによって、規則を守っているインターネット側として
深刻な影響を受けたわけではありませんので、ドコモは
インターネット側からは糾弾されなかったわけです。
　その結果、専ら注目されたのはユーザ達の不満と
キャリアと彼らへの対応、さらに通信事業と言うことで行政の
対応だったわけですが、
根本としてインターネットのルールを守らないことが
墓穴を掘る大きな原因になったのは忘れてはならないことです。

　だから私も書いて在るとおり、これを糾弾するのは自分の為じゃないです。
私はニフティがそういう仕様にしていてもなんら痛くないですし。
nifty自身が墓穴を掘るだけだと思っているんですが．．．

　ただ同じインターネットユーザとして、niftyユーザの
spam被害者を見捨てることは
スパム反対論者としては、簡単に出来ません。
だから声を上げているのです。

　通常の企業への糾弾と違って究極的には「niftyに為に」
声を上げているんですが、そのことが理解されるのだかどうだか．．．．

＃ちなみに携帯ユーザは実質的に見捨てていましたね、当サイトは（^^;;）。
＃ごめん、携帯も持てない身分だし（まあ必要ないというせいもあるが）。

＃まあ「見捨てる」という言葉はさすがに使いませんでしたし
＃暗にそれを示す旨は頁の各所でも書いていたんですけどね、
＃分かる人は分かっていただいていたはずです。

＃　それでも問題の本質が受信にお金がかかるからとか、
＃ドコモが実はスパムの親分だとか、そういう意見には
＃スパムはそういう問題じゃない
＃というのは所々で主張して、問題の本質を分かって貰うように
＃言ってきたつもりですが．．．．

> 　う〜ん、とりあえず．．．
> 「セキュリティの問題」と称して
> 受信者に送信側のIPアドレスを渡さない仕様にしているのは
> niftyさんとしてはRFC全体を見回した上で、
> 相当根拠があるのでしょうから示して頂きましょうか（^^;）

実際、すべてのMTAが"Received:"に接続してきたホストのIPアドレスを記録するわけではありません。
例えば、ファイアウォールの内側にMTAが二つ存在して、
MTA-Aが外部から受け取り、MTA-Bにそれを転送し、
MTA-Bはまた外部に送り出すという時に、
内部のネットワーク構成を明らかにする必要はないため、
MTA-BがMTA-AのIPアドレスを記録しないことは珍しいことではありません。
IPアドレスを公にすることは、必ずしもセキュリティ上問題ではないですが、
だからといって公開する必要もないのです。
こうしたケースではきちんとメールが配送される限りにおいて、
IPアドレスを記録しなくても何ら問題ではありません。

しかし、niftyの行っていることは、
不特定多数の外部とやりとりをするMTAがIPアドレスを記録しないという、
まったくもって論外な行動です。
彼らのいうセキュリティとは顧客であるユーザのものではなく、
ましてや彼らのネットワークのでもなく、spammerのそれです。

標準を守らないことで不利益を蒙るのは常にユーザです。
なぜそんなことがまかり通るのか…ユーザの無関心と無知がその理由の一部をなしているからです。

標準無視はOEに代表されるMSらの専売特許だと思っていましたが、
どうも悪い風潮が流行りはじめているようです。

　そういえば前のスレッドの投稿で

投稿時間：2002/10/28(Mon) 12:12:18
投稿者名：浪人
Ｅメール： ＵＲＬ　：
タイトル：Re^7: ヘッダのIPアドレスが隠れているspam

> IPを隠したいとき…っていう解説ページも見つけましたが
> （有償版のsendmail）
>
> http://www.tsc.ant.co.jp/products/Sendmail/sendmail2xfaq.htm#sendmail_cf
>
> なぜこんなことをわざわざ解説するんでしょう？？
> 隠したときのメリットって一体何？
> 予想できる方おられたら教えて下さいませんか。

というのがありましたけど、ええっと私はサーバ知らないので
上の頁で書いてあることが全くといって良いほど理解できないんですが．．．

あれ？まず上のリンクは
http://www.tsc.ant.co.jp/products/Sendmail/sendmail2xfaq.htm#HRECEIVED
の間違いですよね。
で、本題で以前（結構最近）になんかのやり取りを読んでいたときに、
たとえばあるネットワーク内から出すメールがあったとき、
ネットワーク内での伝達経路に関して詳細に残すのは、
中のネットワークの構造を推察させることになり、
悪意のあるものの存在を考えると望ましくないので
削ってから出す、というような話を見ました。

　大規模なネットワークの場合にはそういうこともあるのかなと思いつつ、よくわからないです（汗）。
−−−−−−−−

　余談ですが、niftyは99年の日本初のスパマーへの仮処分申請といい
先日の「さわやかさんスパマーへのアクション」と言い、
決してユーザがspamの被害に遭うことを何とも思っていない
会社ではなく、むしろ他社よりも真摯だと思います。

　そういう点もあってこの事例で腰がみょーに重いのは納得できないっちゅーか
やむにやまれぬ事情があるのか、
「戦うspam被害者」の存在をイマイチに思っているのか、
よくわからないんですが．．．．

>あれ？まず上のリンクは
>http://www.tsc.ant.co.jp/products/Sendmail/sendmail2xfaq.htm#HRECEIVED
>の間違いですよね。
>で、本題で以前（結構最近）になんかのやり取りを読んでいたときに、
>たとえばあるネットワーク内から出すメールがあったとき、
>ネットワーク内での伝達経路に関して詳細に残すのは、
>中のネットワークの構造を推察させることになり、
>悪意のあるものの存在を考えると望ましくないので
>削ってから出す、というような話を見ました。

済みません。m(__)m 早とちりでした。高崎様の書かれた通りです。

上記のリンクは（修整感謝）ローカル情報の削除をするって意味で、これなら合点がいきます。
誤解してました。濡れ衣で済みませんでした＞ANT様

Sakuraiさんが書いて下さっているように、ローカルネットワーク内での送受信では、AとBの別のドメインを持つサーバーがCをリレーして外部にメールを出す際に、Cのサーバーがヘッダを書き換えて代表のドメイン名だけにする、いわゆるマスカレード（なりすまし）は、一般に行われています。
この場合AとBのサーバーはIPを表に出す必要はありませんので、くだんのヘッダIP部分は削られてもかまいません。内部のリレー情報が外に漏れない、いわゆるセキュリティの為に削ることもあります。ただしこの場合のマスカレードは直接管理下にあるドメインのみです。今回の@niftyのように、外から来たものの情報を意図的に隠すような事は行われません。

> Sakuraiさんが書いて下さっているように、ローカルネットワーク内での送受信では、AとBの別のドメインを持つサーバーがCをリレーして外部にメールを出す際に、Cのサーバーがヘッダを書き換えて代表のドメイン名だけにする、いわゆるマスカレード（なりすまし）は、一般に行われています。
> この場合AとBのサーバーはIPを表に出す必要はありませんので、くだんのヘッダIP部分は削られてもかまいません。内部のリレー情報が外に漏れない、いわゆるセキュリティの為に削ることもあります。ただしこの場合のマスカレードは直接管理下にあるドメインのみです。今回の@niftyのように、外から来たものの情報を意図的に隠すような事は行われません。


もしかすると@niftyサーバの問題はこの辺りに原因があるのではないかという気がしてきました。

・@niftyはインターネット事業を展開していたinfowebとパソコン通信事業を展開していたNiftyServeが合併して誕生した。
・そのさい、パソコン通信事業を残すためにinfoweb仕様とNiftyServe仕様のサーバがそのまま引き継がれた。
・結果として、両仕様のサーバ間の中継があたかも外部とのやり取りのように記録されてしまう。
・それを何とかしようとした結果が現在の欠陥仕様。

ようは、顔は１つでも身体が２つある状態（現在は１社でも施設的には２社分）なので内部と外部の区別が付かない状況に陥っている。
したがって、内部情報を伏せようとすれば外部情報も伏せざるを得ないという特殊な事情を抱えているのではないかということです。

＃内部情報を伏せたいという意図はわからなくも無いです。
＃だからといって、外部情報まで伏せてしまうのは・・・。

アクセスポイントでかなり長い間infowebがありましたね。
今もあるんでしょうか？

newebの場合、サーバ名はかなり早い段階でdionに統一されています。
残っているとすればメール・会員webくらいなのでは？
仮に内部で転送するにしてもdionではこのようなことは聞いていません。
やはり富○通が・・・（以下略）。

> アクセスポイントでかなり長い間infowebがありましたね。
> 今もあるんでしょうか？

さて、どうなんでしょう？
元々、ニフティサーブの方の会員だったのでよくわかりません。
infoweb.ne.jpドメインは有効みたいですが。

> newebの場合、サーバ名はかなり早い段階でdionに統一されています。
> 残っているとすればメール・会員webくらいなのでは？
> 仮に内部で転送するにしてもdionではこのようなことは聞いていません。

@niftyの場合はISP同士の合併ではなくISPとパソ通会社の合併です。
現在、会員種別が２種類あって異なるサービス内容となっています。
一方はパソ通仕様な旧ニフティサーブ会員で、もう一方はISP仕様の
アット・ニフティ会員です。会員種別を変更する場合にメールBOXの
作り変えが必要なことを考えると、別々のサーバで管理されていると
考えるのが妥当かと思います。

A=パソ通(NiftyServe)仕様サーバでnifty.ne.jpとniftyserve.or.jpを管理（ums5**.nifty.ne.jp系）
B=ISP(infoweb)仕様サーバでnifty.comとinfoweb.ne.jpを管理（mail5**.nifty.com系）

A〜B間の転送は１社に統合された結果、内部的な情報であるにもかかわらず、
実際には外部のやり取りと同等な方式になっている。（元々、別会社の物で
それぞれのサービス仕様を残したため）
推測に過ぎませんが、当たっているとすればパソ通ユーザーに配慮した結果
とも取れるので気の毒といえばいえるかも・・・。
＃言い訳にはならないと思いますが

全ドメインを管理する代表サーバ（C）があればOKという感じがします。
外部とはCでやり取りしてC〜A間とC〜B間で内部転送というような感じで。
＃思いきり、お金がかかりそうですけどね

>もしかすると@niftyサーバの問題はこの辺りに原因があるのではないかという気がし
>てきました。
>
>・@niftyはインターネット事業を展開していたinfowebとパソコン通信事業を展開して
>いたNiftyServeが合併して誕生した。
>・そのさい、パソコン通信事業を残すためにinfoweb仕様とNiftyServe仕様のサーバが
>そのまま引き継がれた。
>・結果として、両仕様のサーバ間の中継があたかも外部とのやり取りのように記録さ
>れてしまう。
>・それを何とかしようとした結果が現在の欠陥仕様。

うーん。そのへんに原因がありそうというのは説得力がありますね。
それで思いついてちょっと今実験中。
ヘッダを書き換えている原因の一つはなんとなくつかめました。（笑
あとで報告します。

まず実験結果を見て下さい（笑
浪人@nifty.ne.jp 宛てと浪人@nifty.com 宛てに外からメールを出しました。

【浪人@nifty.ne.jp 宛て】
Received: from 浪人.別ISP.jp (浪人.別ISP.jp [xxx.xxx.xxx.xxx])
by ums518.nifty.ne.jp (8.9.3+3.2W/3.7W011207) with ESMTP id QAA16511
for <浪人@nifty.ne.jp>; Sat, 2 Nov 2002 16:10:59 +0900 (JST)

ums518.nifty.ne.jp[202.248.37.231]で受けている。
sendmailも古いバージョンで、IPは消えていない。
---------------------------------------------
【浪人@nifty.com 宛て】
Received: from mail506.nifty.com (mail506.nifty.com [202.248.37.214])
by ums518.nifty.ne.jp (8.9.3+3.2W/3.7W011207) with ESMTP id QAA16600
for <浪人@nifty.ne.jp>; Sat, 2 Nov 2002 16:11:04 +0900 (JST)
Received: from 浪人.別ISP.jp ※[IPが消えている]
by mail506.nifty.com (8.12.6/3.7W-07/15/02) with ESMTP id gA27Aff5011081
for <浪人@nifty.com>; Sat, 2 Nov 2002 16:10:42 +0900

mail506.nifty.com[202.248.37.214] で受けて、内部で ums518.nifty.ne.jp に転送。
その際にIPが消えている。（消したのは mail506.nifty.com の sendmail）
---------------------------------------------

私は古いユーザーですが、アドレスの@以下の部分は nifty.ne.jp 又は nifty.com のどち
らかを選ぶことが出来ます。
どちら宛てでも結局 ums518.nifty.ne.jp のメールボックスに届きます。
この場合に言えることは、古くからのユーザーに？ nifty.com を付けたアドレスも使えるよ
うにした為に、この転送処理が必要となり（同社ネットワーク内の転送）その時にIPを削っ
ているとも受け取れます。
これ以外のケースでも、同様の内部転送が生じてくるはずで、つまり NIFTY-SERVE と@nifty
の共存の産物という指摘が当たっている可能性を示唆しています。

この検証では、あくまでも@niftyが内部処理でIPをわざわざ消している原因を考えているだ
けで、@niftyの[タコ仕様]の正当性を検証しているわけではありませんので念のため。
内部処理で生じたISP側の不都合の為だけに、一般ユーザーが不利益を被る事は断じて避けて
欲しいと思います。

ううっ！

>【浪人@nifty.com 宛て】
>Received: from mail506.nifty.com (mail506.nifty.com [202.248.37.214])

この@niftyのSMTPサーバー
http://spamcop.net/w3m?action=checkblock&ip=mail506.nifty.com
202.248.37.214 is not listed, but should be.
だって。2002年10月31日のヘッダを見るとムトーではないか！

> この@niftyのSMTPサーバー
> http://spamcop.net/w3m?action=checkblock&ip=mail506.nifty.com
> 202.248.37.214 is not listed, but should be.
> だって。2002年10月31日のヘッダを見るとムトーではないか！

内部転送およびIP欠落による誤報ですかね？
本来、2行目のReservedに記録されるべきIPが欠落しているから
1行目の転送時のIPのみで判断されてしまっているような・・・。

"Recieved: from"まで削るMTAがあるんですね。
名前解決できないようですが。
これを見ると「泥縄っぽい設計」に思えるのは、素人の気のせいでしょうか。

Received: from mail506.nifty.com (mail506.nifty.com [202.248.37.214])
by mx2.rim.or.jp (8.9.3+Sun/3.7W) with ESMTP id JAA28531
for <x>; Wed, 23 Oct 2002 09:40:41 +0900 (JST)
Received: from mail53.nifty.com
by mail506.nifty.com (8.12.6/3.7W-07/15/02) with ESMTP id g9N0eUBG020331
for <x>; Wed, 23 Oct 2002 09:40:30 +0900
Received: by mail53.nifty.com (8.12.6/3.7W-03/04/02)
id g9N0eVWW027033; Wed, 23 Oct 2002 09:40:31 +0900
Received: by mail53.nifty.com id 3db5effe699249;
Wed, 23 Oct 2002 09:40:30 +0900
Received: from ums502.nifty.ne.jp
by vsmail503.nifty.com (8.12.6/3.7W-07/15/02) with ESMTP id g9N0dLxB007837
for <x>; Wed, 23 Oct 2002 09:39:21 +0900
Received: from mailin-01.mx.aol.com
by ums502.nifty.ne.jp (8.12.5/3.7W-06/10/02) with SMTP id g9N0cvq3002916
for <x>; Wed, 23 Oct 2002 09:38:59 +0900

> http://spamcop.net/w3m?action=checkblock&ip=mail506.nifty.com
> 202.248.37.214 is not listed, but should be.

リスト履歴を見るともっと笑えて、登録されてはすぐにもみ消すようなことをしていますね、＠nifty。

Listing history:
listed: 2001/11/21 20:03:01 +0900
delisted: 2001/11/22 15:28:01 +0900
listed: 2001/12/09 13:29:01 +0900
delisted: 2001/12/10 6:53:02 +0900
listed: 2001/12/12 9:36:01 +0900
delisted: 2001/12/13 5:52:01 +0900
listed: 2002/02/02 12:09:01 +0900
delisted: 2002/02/03 6:17:01 +0900
listed: 2002/02/08 11:16:01 +0900
delisted: 2002/02/08 11:56:02 +0900
listed: 2002/02/08 13:10:01 +0900
delisted: 2002/02/09 11:08:01 +0900
listed: 2002/04/08 9:21:10 +0900
delisted: 2002/04/09 8:57:09 +0900
listed: 2002/04/22 14:21:01 +0900
delisted: 2002/04/23 13:54:01 +0900
listed: 2002/10/31 10:10:02 +0900
delisted: 2002/10/31 14:07:02 +0900

そんなことをやるよりタコ仕様を改善すればいいだけの話なのに・・・。

> リスト履歴を見るともっと笑えて、登録されてはすぐにもみ消すようなことをしていますね、＠nifty。

SpamCopはreport ratioがthreshold以下に下がると自動的にリストからはずします。
niftyは気づいていないだけかと。

ニフティからようやく返事が来ました。

--- ここから ---
　お問い合わせいただきました、メールヘッダー情報のReceived行のドメイン
部分にIPアドレスが附加されない件についてですが「RFC2822」にて、必須項目
とはなっていないため、「nifty.com」のメールサーバーでは附加されておりま
せん。

　また、「Anti-Spam Recommendations for SMTP MTAs」に関して扱った「RFC 2505」
がございますが、「RFC 2505」の分類されているカテゴリ「Best Current Practice」
につきましては、必須項目ではなくRecommendations(推奨)レベルとなってい
るため、弊社メールサーバーでは「RFC 2505」が適用されておりません。

　なお、弊社側におきましても「RFC 2505」は、SPAM対策のために今後必要な
項目として認識しており、現在のところ適用日は未定ですが、今後の適用に向
けて努力していく所存でございますので、何卒、ご理解賜りますようお願い申
し上げます。
--- ここまで ---

　RFC2822で必須になってないから，RFC2505は推奨レベルだから・・・
というのは，以前にここで何方かが報告されていた通りの回答ですね。

　それでも，以前は言及していなかったRFC2505に言及しているところを見ると，
少しは学習しているようです。

　今すぐ直すという訳ではささそうですが，今後の適用に向けて・・・　
と書かれているのがせめてもの救いでしょうか。

> 　お問い合わせいただきました、メールヘッダー情報のReceived行のドメイン
> 部分にIPアドレスが附加されない件についてですが「RFC2822」にて、必須項目
> とはなっていないため、「nifty.com」のメールサーバーでは附加されておりま
> せん。

ガキの言い訳ですね。
そのうち「RFCは法的な拘束力を持つものではない」とか言いそうです。

> 　また、「Anti-Spam Recommendations for SMTP MTAs」に関して扱った「RFC 2505」
> がございますが、「RFC 2505」の分類されているカテゴリ「Best Current Practice」
> につきましては、必須項目ではなくRecommendations(推奨)レベルとなってい
> るため、弊社メールサーバーでは「RFC 2505」が適用されておりません。

この論理で行くとopen relayも正当化できるでしょう。

| 特定電子メールの送信の適正化等に関する法律
|
| 電気通信事業者による情報の提供及び技術の開発等
|
| 電子メールサービスを行う電気通信事業者について、特定電子メールに
| よる電子メールの送受信上の支障の防止に資するそのサービスに関する
| 利用者への情報提供及び新技術の開発又は導入の努力義務を設ける。

> 　なお、弊社側におきましても「RFC 2505」は、SPAM対策のために今後必要な
> 項目として認識しており、現在のところ適用日は未定ですが、今後の適用に向
> けて努力していく所存でございますので、何卒、ご理解賜りますようお願い申
> し上げます。

現在のところまったく反対なことが行われているわけです。

> 　それでも，以前は言及していなかったRFC2505に言及しているところを見ると，
> 少しは学習しているようです。

それなりに（謎）注目されているようですから当然です。

> 　今すぐ直すという訳ではなさそうですが，今後の適用に向けて・・・　
> と書かれているのがせめてもの救いでしょうか。

その間ユーザの権利はniftyによって制限もしくは侵害され続けます。

さて、SpamCopのユーザでもある場合は、ジレンマに陥ります。
niftyの態度を改めさせるには、
spamを報告してブラックリスト入りさせることが効果的ですが、
そうすると自分が蹴られてしまいます。

どういう配送をしているのかよくわからないのですが、
少なくともMXレコードがn個ある場合、
SpamCopのthreshold（しきい値）を超えるには、
単純にn倍の報告が必要になります。

http://spamcop.net/w3m?action=checkblock&ip=mx.nifty.com

・さらにその端末が"Received"フィールドをすでに偽造していた場合、第三者が「なりすまし」の被害を受ける可能性がある
・結論として、niftyのユーザはspam被害に対して有効な措置をとることができない、回避方法も存在しない
・以上の事実はユーザに明らかにされておらず、事前に判断することができない

これを読んでるniftyの窓口担当者＋技術者はぜひ反論して欲しいものです。

>　なお、弊社側におきましても「RFC 2505」は、SPAM対策のために今後必要な
>項目として認識しており、現在のところ適用日は未定ですが、今後の適用に向
>けて努力していく所存でございますので、何卒、ご理解賜りますようお願い申
>し上げます。

ここの所が重要ですね。前回のセキュリティ云々のために入れてないという言い訳は
していないわけで、意味不明の弁明は出来ないということがわかったのでしょう。
（まあ、同じ担当者じゃないだろうけど）
ユーザーの声をさらに大きくして要望する必要があります。

何の件だったか忘れましたが、相当昔にFGAL系で大騒ぎして、皆で要望しまくりで、
かなり早い時期にシステム上の不具合修整を勝ち取った（笑） 事があります。
あーなんだっけ？年だなぁ。忘れてしまった。

約束を反故にされてはたまらないので
実現まで粘り強く監視しないといけませんね。

管理人はニフティ問題のページのアップデートは
しないのですか？

そういえば、ニフ問題のペ−ジどうするんですか
まだ、トップにお目見えにならないんでしょうか



＃とっくに、ニフ逃げ出した奴（私）は余計なお世話だったかしら
＃とにかく　上げ

> そういえば、ニフ問題のペ−ジどうするんですか
> まだ、トップにお目見えにならないんでしょうか

＠niftyのユーザスペースで出てくるようでなくてはまずいのですが、

　当面、ここのトップからリンクして公開度を強めるのは反対しません。　＃ｓａｇｅ