210.ちと違うよなぁ？ |
|
| 投稿者: | ぴゅあ - 2003年07月07日 10時37分47秒 |
| その１ > http://www02.so-net.ne.jp/~hat/imail/cover.html メルの仕様って話でしょ？ メルで扱っているフォーマットはどういうものであるかとか サーバー・クライアントがどういう対応をして作られていればいいかとか いったこと 少なからず設定に関わる部分も含まれてくるし メルとは？ということでも知っておいて全く無駄ではないけど 直接的に「これで設定方法の全てが解る」という意味ではかなり離れた部分でもあるんではないかな ただし知ることが大切なのには変わりない その２ > > 今、DelegateのADMINのメールアドレスは全くの架空なので > > 遊びでそのメールアドレスにメール送れるようにするとか… > これは複雑に考えなくてもDelegateでEメールアドレスを書き換えてもらえばよかった(*^_^*) ちぃーっと目的が違うんぢゃないかな？ 機能としてはそれなりな規模の組織ネットワークで出てきたりするんだと思うけど各サーバーを抜けて最終的にインタネ上に辿り着く際置き換えをしてやらないとうまく抜けていかない場合というのがある と この辺はどの本に書いてあったのか忘れたので(ってそれらしきは判ってるんだけどさらっと見たのでは見当たらない)正確な表現ではないけど でもって「架空の」としたのを実際に「現実の」というものとしたいのでこれだと「架空の」のまま 帰ってきたときは再び「架空の」に戻ってくれるのか？ってのもそうなるものでもある筈だけど(このままではそうでもない気がするので)完全とは言えない気がする ってか言えない筈である 出したのは「架空の」だけど帰ってくるのは「実在の」にならないかな？ 何故なら「架空の」のが架空のままだから ややこしくて解らんかな？ 現時点までにテストしたのはローカルなドメインにローカルなアカウントでローカル上で「実在する」メアドとして送受信テストした 従って「架空の」ではない しかしこれは「インタネ上には存在できない」(のであって現実に「架空の」ではなく「実在の」である)ので「「インタネ上で使うことは」できない」 書いてあるようにMOUNTでアドレスの置き換えをしたのではそれは全て置き換えたアドレスのものとなってしまう・・・のであまり嬉しくない インタネ上で自由なアカウントが使えるというのは飽くまで「実在の」が自由なのにならないとホントのそのメアドとして区別されないのでそれはインタネ上で使えるアカウントを作ることになる 実験で使ったメアドはプロバイダ側から提供された・・・つまり他人によって指定されたメアドを使っているだけであって飽くまで自分が作ったのではない(希望したアカウントで作れたメアドだ・・・ってのはちと意味が違う) とどうするかと言うと自分でアカウントを管理しないといけない・・・ので自前でSMTPサーバーが立ち上がってくるということになる (あちしのこれまでの勘違いだとPOPサーバー・・・だが正しくはメル受け取りのためのSMTPサーバー＠メル送信のためには制限されていなければプロバイダのSMTPサーバーに頼んだのでいい) ここより前の段階のローカルでの試験は前に書いたように成功したので今度は自分が接続したときのIPアドレス(でも可能なんだろうけどそれでは不便なので自ドメインを使うということに自然となってしまうだろう)上でSMTPサーバーが動きそこで管理されるアカウントがインタネ上を飛びまわれるようにするってことである ※プロバイダから提供された１つのメアドを使って複数の人で共有する(振り分ける)という方法も古くからある手段ではある そこで １つはローカル上で使えるメアドがある そしてインタネ上で使えるメアドもできることだろう 共に同じメアド(例えばインタネ上のメアド)として使えたんでもいい １つのメアドが実はもう１つのメアドを持っている(エイリアスを・・・という感じ) しかしそうしない目的は ローカルはインタネ上より通常高速に伝送できる 今送ろうとしているメルがローカル間でのやりとりであるということが明白であれば一度インタネ上(プロバイダのサーバー)へ出て再び戻ってくるなんてのは無駄であることは用意に推測できる また巨大な添付ファイル(数百キロバイトになれば既に巨大と言っていいだろう)をそんなルートで流したくない のでインタネ上へ出ないといけないメルはインタネ上へ ローカルで済むメルはローカルの範囲内だけで という制御をしたいということである それはぢぶんにとって嬉しくなることだけでなくインタネ上即ちインタネを利用する全ユーザーへに対してメリットを与えることになる と考えて計画していることだけどどうかな？ でもって実際に運用した場合宛先としてローカルとインタネのメアドが混じってしまうことがありうる その場合にどう対処するかという点もある ちっと細かな部分を的確に挙げられてない嫌いがあるけどそういったポリシーでSMTPサーバーの構築を考えてみていたりする 単にローカル上で或いはインタネ上でサーバーを立ち上げてメルを扱いたいというだけなら簡単に終わっちゃうことよね＠正しい設定が判ってインタネ上では相手に受け入れられるだけで コメント>> |
|
209.DelegateのsmtpプロキシサーバーのEメールアドレス書き換え |
|
| 投稿者: | Pyzar - 2003年07月07日 0時24分24秒 |
| > 今、DelegateのADMINのメールアドレスは全くの架空なので > 遊びでそのメールアドレスにメール送れるようにするとか… これは複雑に考えなくてもDelegateでEメールアドレスを書き換えてもらえばよかった(*^_^*) せったーさんのサイトに簡単な例がありました delesmtp.confに次の記述を書き加えるだけでした MOUNT=架空の@メールアドレス smtp://実在の@メールアドレス # Delegateって万能！？ コメント>> |
|
208.Delegateでsmtp |
|
| 投稿者: | Pyzar - 2003年07月06日 20時44分34秒 |
| やっぱり… Delegateでやってみようかな。難しそうだけど… 時間かかると思う…あんまり解説してる人いないし… とりあえずお勉強！！ http://www02.so-net.ne.jp/~hat/imail/cover.html コメント>> |
|
207.おっと忘れた |
|
| 投稿者: | ぴゅあ - 2003年07月06日 10時13分16秒 |
| トップのリンクミスってるよ すぐ気付くだろけど コメント>> |
|
206.え！？そんな簡単？？ |
|
| 投稿者: | ぴゅあ - 2003年07月06日 10時01分32秒 |
| 悩みに悩んだ挙句WU-IMAPを動かしてみました そういや今のRed Hatではvsftpdに取って代わったftpdも以前はWU-FTPDでしたね(同じワシントン大学のものだった筈) なんで悩んだかって・・・ WU-IMAPに関する情報が殆どないってかどう設定するのか何処にも書いてない もしかして何も設定が要らない？？とか悩みつつ SSLの設定手順だけは出てるけど設定ファイルらしきもなし /etc/xintd.d/内にipop2, ipop3, imap, pop3s, imapsが見付かるだけなので思い切って単純にdisable=no 送受信とも出来ましたとさ make時にsendmail/Postfixの環境に合わせてあるってことなんかな？ あまりに簡単過ぎてホントにこれでいいの？？なんだけど 確かにサーバーにログインしてメルを取ってくるだけだからtelnetでそうであるようにその程度でいいのかも知れないけど 試したのはipop3(POP3)とimap(IMAP4) IMAP4はなんか動きが怪しいのでやめた POP3が使えれば十分だもんね て ことでメル関係で攻めるはPostfixのみか WU-IMAPにはAPOPもあるようなことを書いてたような気がするけど設定方法がよく判らんのでpop3s(POP3/SSL)でも試しておけばいいかな で そのまま寝ちまって忘れてたこと Delegateのnobody権限絡みで探してて見つけたんだったかな http://www.zdnet.co.jp/enterprise/0307/03/epi01.html 静岡大のサイバースペースセキュリティ情報も結構タメになる こんなのあったのかぁ(あってもおかしくないが) http://www.doraemon-mail.com/ コメント>> |
|
205.頭痛いの退いたかな・・・ |
|
| 投稿者: | ぴゅあ - 2003年07月06日 8時25分22秒 |
| さっきは寒かった > このPostfixはPostfixのユーザーとグループを作ることを推奨していますよね > Delegateのデフォルトはユーザー・グループともnobody権限のようです PostfixとDelegateは別物なのでいいんぢゃないでしょうか 例としてもnobody権限でと書かれてますし セキュリティ関連の記事を探せば何か出てきそうにも思いますけどないならDelegateでは問題なしということなのかも ただ専用ユーザーを作るというのは彼方此方で出てくるのでやっておいて損はないのかも？ 別の制限(ネットワークアドレスとか)を行っているからいいということかも知れませんね 別の話だけどひとつ思い出したのは(プロクシサーバーは最早要らんのでは？絡みだけど) iptablesで制限掛けてますよね そしてDelegateでも制限掛けてますよね これは２重に制限が掛かるということです それはそれでいいと思う 無駄ではあるけど多重にチェックされることでそれだけ精度が上がる (２重３重のセキュリティ・・・とかよく？聞きますよね) ただここでiptablesとDelegateは２つが並列であるわけではないです(筈です・・・としとくけど) ２つの並列と言うのは２つのルート(通り道)って意味です Delegateはiptablesの内側にある筈です(たぶん) つまり iptables(IN)−Delegate(IN)−Delegate(OUT)−iptables(OUT) であって iptables(IN)−iptables(OUT) Delegate(IN)−Delegate(OUT) となっているのではない(筈)ということです ので２重ということです ずっとLinuxによるルーターに移行したいと考えていたのはWin上のプロクシサーバー(知名度のある市販ソフト)が全てを捉えてくれない(先の後者のように２つ(以上)のルートができている)ような感じだったのでWinによるルーターをやめたかったのです(Win自身が見えないところが多過ぎてめちゃ怪しいというのも強くあったが) ただDelegateをSMTPサーバーとして動作させる場合・・・ これもきっと同じような制限で片付くということなんだろうと思いますけど ただmailは一番セキュリティホールとして狙い易いものかも知れないので本当にそれでいいのか十分にドキュメントを確認したりするのがいいのかも？ Postfixは簡単に動いてしまいました クライアント＠Winのメーラーを設定してメールを送信してみましたがすんなりとLinuxサーバーのメールボックスへ届いてくれました まずはローカル(イントラネット)としてのテストなのでここまでですが 外部からの受信はまだです(Linux内ではmailコマンドで見られる＠POPサーバー不要？) そりゃsendmailしか入ってないし でもってインタネ上のドメインを利用したテストも(イントラとの混在を含めて) ・・・と そのまま寝ちった(照) 続きをどう書こうかと考えつつ寝ちったからどう書くか忘れたけど(汗) 受信にはUW IMAPを使うことにしました というかこれしかないっぽい？ こやつはPOP2/POP3/APOP(POP3)/IMAP4をサポートらしい メールの管理をクライアント主体で行くならPOP サーバー主体で行くならIMAP どういう違いかというとメールの保管場所をクライアントに置くかサーバーに置いておくか あちしはその意味ではPOPの方を好みます ただ実験ではIMAPも「動くか」くらいは試してみたいので(簡単に？)両方使えるUW IMAPは嬉しいけど メルをサーバー上に置きたいというユーザーは多いようで(普通のパソを使っていても)携帯メルでは適しているということで採用されているらしいけど移動端末とかディスク容量の小さいクライアントが多くて・・・という時にはいいらしい でもね POP/IMAP云々というより POPサーバーを使っていてもメーラーで「サーバーから削除しない」を選択するとサーバーにメルを貯めておくことができる これは一時的にそういう操作をしたいときには役に立つ 例えば自宅と会社で同じようにメルを受け取りたいとか ただし貯め続けるんではなく取り終ったら削除するように適切に設定するとか操作するとかするのが望ましい(と考える) しかしそういうんではなくただ貯めときたいってのがあるみたいで・・・ ・メルボックスがいっぱいになってしまって受信も不可能 メルボックスのメンテのためプロバイダにお手間を取らせることに (サーバー内の他の全ユーザーにまで影響を及ぼしたかどうかだったかは忘れた) ・メルサーバーの移転で貯めておいたメルが見れなくなったよと暴れ捲くる そりゃサーバーは常に保証されているべきである だからいい加減なエンジニアと格闘しながらも少しでも信頼性を上げるためにすんごく苦労しないといけない しかし万能ではないのでユーザー側も「適切な」対処をしなければならない (この辺のサーバーの扱い方＠ユーザーは昔「コンピュータは万能である」と「万能ぢゃないぢゃないか」と言い争ってた？共に間違った捉え方の上での言い争いと似たようなものがあるか？ あちしには勝手に言ってなさいだが) IMAPサーバーはサーバー内に保管することを主張しているのでこの場合はサーバー内に持つというのは適切と言えるだろう＠正しく使って初めて生きるってことよ ただサーバー上に保管するにもサーバーでなくったって自分のパソでも「ハードディスクがいっぱいになって困った」と騒いでいる人も多いが なんでいっぱいになったかってそれは適切に整理してないから サーバー上の各自のスペース(ホームディレクトリ)だって同じことになっているだろう とサーバーのメルボックスが管理されてないメルで溢れてしまうということも疑うまでもなく明白であったりする サーバーで全員のメル本体を管理するというのは各自で管理するより膨大なコストとリストが伴う また何度もメルを取り直すということは通信コスト等も掛かる(有線だとあまり目に見え難いので実感がないだろうけど) 特別な環境(例えばモバイル端末が主体で自分に持つのは大変とか)であるとかネットワークの考え方でIMAPを採用するということもあるだろうけど実際どちらを選択するかは慎重に行うべきもんなんだろう 一般には最初からPOPで行くってのが正解なのかも 賢いユーザーが殆どなネットワークではIMAPってのが正解だったりするのかな デフォルトではSMTPサーバーのメルボックスは共有領域を使っていることになるようなので(/var/spool/mail/)一般的な環境では各自のホームディレクトリ内にメルボックスを配置して(要quota設定)各自の責任で管理させるのが適当なんだろう という風にサーバーってのは正しく動いた・安定している・安全だとかだけでなく何をどう選択して構築するか(それの方が難しく一番難しい要素だろう＠対ネットワーク/マシンではなく対人だから・・・)ってのも重要な要素だろうと考えたりする ちと休憩したら(？)受信テストも始めてみるかな Webからのsendmailの実験もあるけどちと悩むのは インタネとの関連をどうするか インタネとはメルサーバーが異なる(現時点)のでイントラネットなメルを別途扱うにはクライアント側のメーラーで専用のメルボックスを用意すればいいので問題はないのだが・・・ ・送信先にインタネとイントラと混じって書かれる場合があり得る＠特に(実験とかではなく)ユーザーが普通に使う場合＠実稼働環境ということだわな この場合プロバイダのSMTPサーバーに接続するわけにはいかない インタネとイントラで使い分けさせるというのもウザッタイのでブーイングだろう のでネットワーク内のSMTPサーバーに送信しそこで外部へ配信するメルかどうかを振り分けさせ外部へはプロバイダのSMTPサーバーへリレーするとしないといけない またこのときCCとかだと受け取った側に全員に返信するとされてしまった場合イントラのアドレスが含まれていると問題が出る(インタネ上には存在しないんだから)ので外部へのCCにはこれを含めないようにすることができるのか＠ユーザー側で含めないようにさせるというのは不可能(ミスは必ずある) いくつかあると考えてたけど１つにまとまっちったかな これができないと外部SMTPサーバーへのリレーは始まらないのよね ・イントラでのみ使うならそう設定するだけ ・インタネでのみ使うならSMTPサーバーを立てるのは無駄でしかない(環境によってはそうであるとは限らないが) ・イントラ・インタネで共用するならそういう仕組みを作らないといけない これが終わったらMLへの挑戦かな ・タイプ１：メンバーへの同報(SPAMとして使わんように（−−；) 決まったメンバーにまとめて通知(定期業務連絡とか)を送らないといけないんだけどいちいちアドレス帳から入れるのは面倒(楽に一括して入れられるメーラーもある筈だけど)って声もあったりする ・タイプ２：一般のML これはシステムが違うわな コメント>> |
|
204.RE:Postfixに挑戦してみるかな |
|
| 投稿者: | Pyzar - 2003年07月05日 21時25分34秒 |
| ZDNetのPostfixのページを少し見てきました 面白そうですね(*^_^*) 今、DelegateのADMINのメールアドレスは全くの架空なので 遊びでそのメールアドレスにメール送れるようにするとか… で、ZDNetのPostfixのページ見ていて思い出したのですが… このPostfixはPostfixのユーザーとグループを作ることを推奨していますよね Delegateのデフォルトはユーザー・グループともnobody権限のようです でも、そういえばどこかでDelegateのユーザーとグループを作ってる人もいたなあと… この時、デーモンを起動する権限を持ったユーザーとグループをそれぞれ作ったほうがいいのか、 それともnobody権限で起動しちゃえばいいのか、少し迷って少し検索してみたのですが、 ますますわからなくなって…結局Delegateはデフォルトのnobody権限で起動しています。 ＞ぴゅあさん その辺り教えて頂けるとありがたいのですが… コメント>> |
|
203.便利なコマンド見つけた |
|
| 投稿者: | ぴゅあ - 2003年07月05日 15時17分44秒 |
| それはファイルリスト(コマンド一覧)ページ作成に合わせたのでいいけど vipwってのが使われてるのを見かけたので使ってみたらvi /etc/passwdの強化版て感じ サイズから見てスクリプトではなくコマンドとしてちゃんと作られているみたい(確認はしてないけど) でもって あるかな？と思ったらvigrってのもあったですよ コメント>> |
|
202.Postfixに挑戦してみるかな |
|
| 投稿者: | ぴゅあ - 2003年07月05日 15時08分14秒 |
| 以前は検索してもいい感じのものは見当たらなかったんだけど なんかヨサゲに思えるのがすぐに出てきたのでやってみようかと (あちしの場合全然操作が解らんと思ってずっと長い間放置してたのが仕事でつかわにゃとなったときになんでこんなスイスイ使いこなせるの？というのはかなりよくあるのでそれと同じで前も見ていたものがそう思えたのかもだが・・・ 最近の実例では・・・ 友達からIISがうまく動かんと相談されて触ってみたけどまず入り口から何していいのか解らん状態・・・が数年後それまで全く触ってないのにすんなりサーバー設定して普段使って居る人が知らん設定までして動かしてたり WebSphere(綴り合ってたかな)を突然触ってやはり同様に動かせてたり これまでずっとIDE統合環境て操作解らんしかつC++なんぞちゃんとやったことないから解らんよてのが使いこなしてたり 特技なんかな(照)) で 自分も素で驚くそんな余談はさらっと済ませて 勝手にURL載せさせてもらうけど http://axon.phys.nagoya-u.ac.jp/~murase/sys/mail/postfix.html 邦訳されてるのは嬉しい しかし飽くまで訳なんだよねぇ いやそれはそれで有難い 少しは読むのが楽になる 本当に欲しいのは「実際にはそこからどうする」なんだけど 怪しい感じがする解説サイトだけは山ほどあるけどねぇ http://www.zdnet.co.jp/help/tips/linux/l0282.html そんな簡単に動かせていいの？ http://www.zdnet.co.jp/help/tips/linux/l0152.html そうなのか てことでこの辺を利用させてもらえばある程度何とかなるかな？と 大体いつも止まってしまっていたのは「固定のグローバルIPアドレスを取得している場合の例」というのは山ほどあるけど １．まずはローカル内だけで動かせるようにしたい ２．(オマケで)可変のグローバルIPアドレスでもなんとかできる時代になった(比較的楽にの意)のでインターネット上でのアカウントを作るテストをしてみたい(て できるんかな・・・ はできるだろう) １だけでも実験は十分なんだけどね ２は必要ないっちゃあ必要ない でもってsendmailをコマンドラインで動かすというのもほぼそのままできるってことのようなのでsendmailで悩むより(実際探しても難しいっぽい)Postfixでいいかなと＠因みにうちのプロバイダもPostfixを使っているらしい でちとぢぶんの思い違いが判ったのは 「SMTPサーバーはメールの送信をするだけでなく受信もする」ということ ちゃんと(以前に読んだことある本を見れば)解ることなんだろうけどSMTPサーバーの終着点はPOPサーバーか？とか思ってたりしてそのリレーの仕組みがぐちゃぐちゃになってたけど終点もSMTPサーバーらしいということ POPサーバーはSMTPサーバーが受信したメールを取り出してクライアントに渡せるようにするサーバーという位置付けらしい これはずっと勘違いしてたなぁ つまりはPOPサーバーに何を使うかはSMTPサーバーのメールボックスを見ることができる「使用しているSMTPサーバーに対応できるPOPサーバー」を選ぶようにしないといけないということ http://www.zdnet.co.jp/help/tips/linux/l0283.html 最近zdnetとatmarkitには色々とお世話になってるなぁ てか結局ここに辿り着くことが多いらしい 最近はここに辿り着けるとホッとする感じでもあるらしい (一時期使ってたTAのサポートがatmarkitだったような記憶もあるんだけど似てただけか気のせいかも・・・ ので検索して初めてatmarkitが出てきたときにはオッ!と思ったものだが) てことで基本的にはいくつかの設定ファイルを今まで触ってきた設定ファイルと同じような感覚で設定すればいいだけのようである のでちと追ってみようかなと 因みに現在のフルインスト状態ではsendmailが稼動中でPostfixは止まっていた で最小構成のルーターマシンにはPostfixは入ってなかった POPサーバーには何処でもでてくるPOP3サーバーというのもつまらんのでちと違うプロトコルを実験してみたいかなと コメント>> |
|
201.だめでしたか |
|
| 投稿者: | ぴゅあ - 2003年07月05日 13時41分35秒 |
| 書こう書こうと思ったまま書いた気もする部分もあるんだけどそのまま寝たらしい(照) 「文字化け」って言っていることからフォントデータ絡みかなと思われたわけですが > 英字の文字化けですからcannaは関係ないですよね… 英字ってのがホントに英字なのか？というのもあるし 化け方を見ればなんとなく推測が付くこともありますがそれは直接見てないのでなんともですが > XFree86とかでしょうか… > # 文字化けしてる時でも"USB"とかの文字は文字化けしてないんですよね… > XFree86のバージョンを古いのに変えてみればいいのでしょうか Xは入れてないのにX関連のモジュールがインストされるわけですが それがなんでか？・・・と言えばフォント周りとかをサポートしてるんだろうとは思います エンジンがダメならXFree86の本体側ですがフォントデータかな？と思われる部分もあり ただ後で正常に戻るんですよね・・・ 文字化けしている間に選択されているフォントなんだろうか・・・ ここからでは調べようがないだけになんともです でrpm -qa | grep fontsで該当を探して・・・ と書こうと思ってたら実践してましたね そう言えばルーターはまだRed Hat 8のまま fonts-ja kon2-fonts ttfonts-ja XFree86-100dpi-fonts XFree86-75dpi-fonts が入ってました このうち使われないだろうと思うけど含まれているのはkon2-fontsがアップデート対象に入っているようです (しかし使われているかもしれない・・・以前のバージョンでブート中に明らかにフォントが変わっているのを見た記憶がある) 何が悪さしてるのかなぁ？ WebサーバーもLinuxにしちまおうかと思っているところ なんでWinのままにしてるかって・・・Winで立ち上げてたからだけど WAS(JSP)とかIIS(ASP)とかDBとかを(IISはまず思わんと思うけど(照))再び使いたいと思うかもしれないと思ってたのがあるけど 当分思いそうにないし なんかDMZに単独で孤立させてたら意味不明のエラー出てるし Webページをアプリケーション化(PSPとでも呼んでやろうかな(照)既にXSIとか呼んでるけど)してるから重いかもだし(テストサーバー＠Duron/800では特に感じないけど) しかしLinuxにするとなるとWebサーバー周りは簡単だけどsendmailよねぇ WinではsendmailもどきをCで作って代用してたけど(たって名前を同じにしているだけで送信機能しかないメーラーってだけだが) ルーターのiptablesの整理もしなきゃ DMZ上のマシンの管理をもっと楽にする方法を考えんとだし て それにはLinuxページの充実かぁー でまた尻込み・・・ あれ？ ちんだ・・・ まだまだ学ぶべきことは山盛りだなぁ てぇことは文字化けも今は支障ないなら置いといて色々と他を知った方がいいのかも 少なくとも今までの情報を整理するとup2dateをやった辺りというのは判ってるんだし 次の適当な機会に合わせて検証してみるのが時間が無駄にならなくていいかも て 頭痛いなぁ ずっと家に居るからかな ちっときっちてんにでも行ってこよか 今日はめっさ天気いい 梅雨は明けたのかな？ 来週はまた愚図つくようなことを予報してたような気もするけど コメント>> |
|