もう１台のサーバも管理していて、貧乏だからサーバー機の更新ができてなかったんだけど、この８月にトラブったのね。HDDがこけたんだけど、本体がOSX10.6だからもう、さすがに無理かと思い、MacMiniのEl Capitan サーバにすることにしたのさ。購入したのはYosemiteの時ですぐにでもできるかと思いつつ、結局できなくて年末休暇にやることになったのね。
○ Yosemite machineでEl Capitan インストールを実行して、インストーラをダウンロードしたところで停止しOS X El Capitan インストール.appをアプリケーションに保存する
○ 32GB SDカードをMacOS拡張（ジャーナリング）でフォーマット
○ OS X El Capitan インストール.appで32GB SDカードにEl Capitan をインストール
○ 同カードにOS X El Capitan インストール.appをコピー
SDカードのスピードが遅いので１時間位かかる
これまでのMacMini
○ ネットケーブルを外す
○ CCCでバックアップ作成 （５分）
○ TimeMachineでHDDにバックアップ作成（５分）
○ シャットダウン
新しいMacMini
○ 32GB SDカードのEl Capitan から起動
○ SDD を消去、MacOS拡張（ジャーナリング）でフォーマット（１分）
○ 従来のMachineのバックアップであるTimeMachine HDD を接続
○ El Capitan を内蔵SDDにインストール
○ インストール中に転送元があるかと聞いてくるのでTimeMachine HDDを選択。すべての項目をコピーする（３時間くらいか）
○ El Capitan ほかアプデート。
○ CCCアップデート
○ OSX Server をダンロード・インストール
○ OSX Server を起動
ユーザ名のエイリアスが引き継がれておらす、新たにエイリアスを、自分のを除いて、設定できない。
Webサーバ
Server.appで Webサイト をみて
サーバWebサイト すべてのIPアドレス… ポート８０ をダブルクリックして
サイトファイルの保存場所 を /Library/Server/Web/Data/Sites/[ドメイン名] の directory を選択する…. うまくいかない。
とりあえず、メールサーバとしては引き継がれたのだが、Webサーバがまだうまく行かない。取り合えず、メールができるので、ゆっくりやることにして、風呂、酒、飯 モードになりました。すんません。
[ 追記 ] 翌日；
とりあえず、デフォルトのまま、/Library/Server/Web/Data/Sites/Default にこのサーバのトップページであるindex.html を置き、ユーザのdirectoryのSites directoryへのシンボリックリンクをこのDefault directory内に作成することで、Webサーバはなんとかうごかした。
MySQL をインストールしたんだけど動かない。こいつが動かないとBlogやWebメールができないのだ。インストールしてシステム環境設定のMySQLで起動ボタンをクリックしても動いてくれない。なんてこった。
MySQLを起動すると
デフォルトの /etc/my.cnf ではsocket の場所が client も mysqld も /var/mysql/mysql.sock となっている。/var はシンボリックリンクで、実は /private/var なのだ。
だからmy.cnfの[client ]も[ mysqld] も
socket=/private/var/mysql/mysql.sock
と書き換えた。
んでもって$mysqld restart
Can’t connect to local MySQL server through socket ‘/private/var/mysql/mysql.sock’
とかいって動かない。
$mysqld restart とやると
/usr/local/var/mysql/ にファイルが作れないとかいうのでこdirectory ２を777なんかにっしちゃうんだけど、動かない。エラーを吐いてくるんだが意味がわからん。なさけなや。
「サイト管理」カテゴリーアーカイブ
Mailman 宛先数が多すぎます
なんか、設定事項を忘れちゃうんだよね。新しいメーリングリストを作ったとき
管理画面の「プライバシーオプション」
→「宛先フィルタ」
の １０ を ０ にして無制限にする。
この宛先数というのは、投稿したメールに記載されている宛先（送付先）の総数でCcとBccもカウントされる。つまり、該当のメーリングリスト宛てのほかに１０件の個別のメールアドレスが宛先にあるとこのエラーが立つ。
２学年の学生メーリス（２学科x２クラスx２学年＝８ケのメーリス）の他に、このメーリスに登録されていない関係者が宛先に３人いると、８ケのメーリスすべてでこの設定を０にしておかないと配信は保留されてしまう。メーリスだけ配信停止だから関係者３名には届くのだ。
Yahooメールが６月で廃止
中小私立大学などはメールサービスを実施するのが負担だから、教職員は別にして、学生には大学が供与するメールアドレスとして、ドメインはその大学独自のではあるが、実際にはYahoo の無料メールを利用しているところが多いと思う。Google も同様に、ドメイン名を大学独自にするが、実態はG-mailという無料サービスをやっている。Yahoo が提供している大学等へのメールサービスが来年６月で廃止になる。
あっちの大学ではこれまで学生へ供与するメールアドレスがYahooだったのでG-mailに変更することになったのだ。現在の４年生はほとんどが卒業しちゃうから関係なく、１年生はすでにG-mailの方にしたので、２、３年生が移転手続きをする必要がある。移転といっても、前のメールを捨てちゃえば、問題はない。
管理者は、メーリングリストを構築して学生との連絡に使っているのだ。他の教員にも公開しているので、利用されている。
Yahooメールはスマホに自動転送すると、サーバから消えちゃうからパソコンでアクセスできなくなっちゃう。添付書類なんかあってスマホに転送されちゃうと学生は困ることになる。スマホでエクセルファイルを可能でも加工しないだろ。学生はそもそも、大学が付与したメールアドレスを使わない。もっぱらスマホメールなのだ。
だから、メーリングリストにはスマホのメールアドレスを登録させている。問題は学生は自由にメールアドレスのアカウント部分を変更しちゃって、届け出ないのだ。だから連絡がついているのかわからない。エラーメールが来ても対応できない。
G-mail はスマホで見るアプリがデフォルトであるし、パソコンでも見える。つまり添付書類があってスマホで処理できなければパソコンで処理できるのだ。
そこで、メーリングリストに登録するメールアドレスは新しい大学が供与するメールアドレスにすれば、学生はメールアドレスを変更できないし、スマホで連絡できるし、パソコンでも読めることになったのだ。
大学が供与するメールアドレスをメーリングリストを作成するから、電子ファイルでくれといったら、担当部署から断られた。個人情報だから渡せないのだそうな。学生への連絡という業務でやっているんだぜ。大学の e-leaningシステムでも、科目履修者へ一斉送信ができる。しかし、授業担当者だけが使える。クラスの学生、複数クラス、複数学年への一斉メール連絡はできない。できるようにしろと３年以上前からお願いしているのだが実施されない。今度はまた別に学生フォローシステムとかいうのが立ち上がって、こっちではクラス別メーリングリストができそうだというので、現在のメーリングリストを教えてこれと同じ機能にしてくれと依頼中だ。いつできるかわからん。
というわけで、管理者が作成したメーリングリストを運用し続けないといけないわけだ。学生の新しいメアドは大学がくれないから、学生から収集する必要がある。
このメーリングリストは大学公式ではないよ。参加するかどうかは各自の自由だよ。でも担任等から連絡が行くよ。それでよかったらメアドを管理者まで送ってね。
というわけだ。大学はメーリングリストに変な情報が流れることを極端に恐れているのだ。どうやら前例があったらしい。担任が用件でもない、つまらんことをつらつらとスマホメールで流したことがあったらしい。だから学生は受信拒否にしてしまい役たたずになったらしい。そのトラウマがあるらしく、なかなか大学公認メーリングリストを作ってくれない。
昨日の委員会で２、３年生のどれだけが新しいG-mailに移転したを調べたら、３０％程度との報告があった。それではメアド収集ができない。学生に新しいメアドをよこせと言っても移転していなければ収集は不可能だ。
学生へどのようにしたら、YahooメールからG-mail へ、昔のメールをそのまま引き継いで移転できるのかの説明サイトがあるに違いないと思って、そのサイトを知らせて、移転を促進させようと思ったわけだ。大学のサイトをうろついていたら、なんとすごいページに行き当たったのだ。
教員が、学籍番号、あるいは氏名で学生のメールアドレスを検索できるサイトが用意されていたのだ。検索出力はもちろん新しいG-mailのメールアドレスだ。データベースになっているのだ。その検索ページには検索対象のすべての情報（データベース）が表で掲載されてしまっているのだ。学年、学科名、学籍番号、氏名、メールアカウント、そしてなんということか、初期パスワードまで掲載されているのだ。４年生を除く全学生のだ！！
ひでー。個人情報の漏洩云々をわめく部署のすることかよ。
おかげで、学生が移転してようがいまいが関係なく、学生からメアドを収集することなしに、該当学生のメアドを収集できてしまったのだ。これを使ったら違法なのかな？
[ 追記 ]
当然、該当部署に、人を介して、知らせてやったらそのページは無事削除されましたよ。でも、お礼の言葉もないよ。黙っていたってよかったんだぜ。
WP plugins アップデート
WordPress のプラグインをアップデートしようとすると
「更新失敗: ディレクトリを作成できませんでした。」
となりアップデートできない。こうなると
/Users/hoge/sites/blog に .maintenance が作成され、これが生きているときこのブログにアクセスすると
「現在メンテナンス中のため、しばらくの間ご利用いただけません。」
と表示され、ブログがみえなくなっちゃう。コマンドラインでログインして
$ rm .maintenance
で削除する必要がある。
Plugins directory のmode をだれでも描き込み自由の 777 にしてもだめなのだ。
さてどうしたもんか。
WordPress 4.4–ja に自動更新 が立っているので「今すぐ更新」ボタンをクリックすると
「更新用ファイルを展開できませんでした
となって更新もできない。えーい面倒だwp-content を777 にしちゃえ。
更新を展開しています…
展開したファイルをチェックしています… 更新が必要な翻訳が一部あります。
更新が終わるまでしばらくお持ちください。
更新用ファイルを展開できませんでした
インストール失敗
んが。だめだ。
[ 追記 ]
もう一つのサーバではワンクリック ・アップデートが問題ない。これまでどっちも同じようにワンクリックで更新できていたのに。なんでだろ。そのうちできるようになることが過去にあったからな。ちと放置。
MacにWinからリモート・ログイン
あっちの大学の普段使っているパソコンはMacなのだ。こいつにリモートでログインして、自宅やこっちの大学であっちの大学の仕事をする必要がある。もちろん、global ip addressなど割り当てられていないから単純にターミナルとかではログインできない。
もっぱら、TeamViewer を使っているのだが、先日、接続中になにかが発生して、接続できなくなってしまったのだ。リモートで再起動しないといけないことになったのだが、もちろんリモートでログインできないから、再起動ができない。
実は同じオフィスにあるWinのPCもTeamViewer でログインできるようにしてあったのだが、このWin機にTeamViewer でログインして、さらにMacにリモートでログインできればMacを再起動できるはずと思ってTera Term を起動してログインしようとしたらできなかった。設定していなかったからね。
つーわけで、Mac のほうはシステム環境設定 ⇨ 共有 ⇨ リモートログイン にチェックを入れる。もちろんログインできるユーザのリストに自分がはいっていることを確認する。
Win の Tera Term ではMac のprivate ip address を入力してSSH2 で、
ユーザ名を入力して
Challenge/response にしてOKをクリックするとパスワードを聞いてくるから入力すると接続できる。これで、Macが起動しているが、なんかの理由でTeamViewer がこけちゃっているとき再起動できることになる。TeamViewerは起動項目になっているからね。
なんか日本語が必要なときは /users/[ ユーザ名 ] のdirectory に .bash_profile というファイルを作り、
bash-3.2$ vi .bash_profile としてexport LANG=ja_JP.UTF-8 の一行を書く。
bash-3.2$ cat .bash_profile
export LANG=ja_JP.UTF-8
ですね。これで日本語のファイル名がWin Tera Term で見える。
Challenge/responseでなく通常のパスワード認証にするためには/etc/sshd_config を編集しろとあったが、ssh_config がなかった。ssh_config~orig をコピーして ssh_config としてPasswordAuthentication yesがコメントアウトされていたので# を取り除き生かしたのだが、通常の平文パスワード認証にならなかった。だからssh_configは削除した。
Challenge/responseで問題ないからだ。
カーソル（ポインタ）が行方不明
Macでマウスを左右に激しく振ると、カーソルが大きくなる。知ってた？
いつのバージョンからだろうか？
システム環境設定 → アクセシビリティ で以下にチェックする。デフォルトでチェックされているはず。
マウスを激しくシェイクすると、下のようなイメージでカーソルが大きくなる。
カーソルが行方不明になるときがあって、便利だ。
[ 追記 ] 2015.11.12 El Capitan からのようだ。
ちなみにWin7 の場合は、コントロールパネル → マウス ポインターオプション Ctrlキーを押すとポインターの位置を表示する（S） にチェックを入れ、適用ボタンをクリックする。
上図のように、コントロールキーを押して離すとカーソル（ポインタ）のあるところで同心円が表示される。デフォルトでは OffになっているからOn にしておいて問題はないだろう。
どっちがいいかというと、Macの方だな。カーソルがなくなっちゃうと、ついマウスを動かすでしょ？]]>
プライベートアドレスでのオープンリゾルバ問題
Open Resolver 問題というのがある。ネットワークの通信はip address で行われるが、それでは数字の羅列なので人が理解できない。だからその数字列をわかりやすい登録したアルファベット文字列（ドメインネーム）と対応させて、通信するシステムがDNSなのだ。だから利用者はDNSサーバにまずアクセスしてip address を取得して、そのip address で相手先に接続するのだ。全てのip address とドメインネームの対応表を１つのDNS サーバが受けもつなんてことはありえない。ヒエラルキーがあって、下のレベルで解決できるときは、上のDNSに問い合わせることがないようになっている。最上位のDNSサーバは全世界で７台、そのうちの１台は日本のどっかにあると昔聞いたが、最近はどうなんだろ？設置している場所は秘密だ。ここが攻撃されるとネットがとまっちゃうからな。
なので、下位のDNSサーバは無数にあるのだ。このDNSサーバは要求があるとすぐ答えてくれるが、１台のDNSサーバがどこからの要求にも応じると、大量の要求が押し付けられてそのサーバが止まってしまう。このような大量のパケットを受けて答えるわけにはいかないので、普通、どんなDNSサーバも自分のとこだけ と応じる範囲を限定している。しかし、この限定ができていないルータ・サーバがあるわけで、これを Open Resolver 問題という。広く誰から（Open）の要求でもドメインネームとip address の対応を解決（Resolve）してあげますよというわけだ。
このDNSサーバがインターネットに直接接続していて、自由に問い合わせを受け付けるようになっていると、大量の問い合わせが合った場合、自分で解決できない要求は、より上位のDNSサーバに問い合わせに行くし、本来の自分のサブネットからの問い合わせに答えることができなくなってしまう。ウイルスがこれを利用して大量のDNS要求パケットを送りだすのがDos攻撃というわけだ。ウイルスが特定のサブネットを使えなくしてしまうのだ。だから、これをチェックするサイトが作られている。オープンリゾルバ確認サイトなんかだ。しかし、当然ながらイントラネット内のプライベート・アドレスのDNSサーバには対応していない。
問題は、このようなルータがイントラネットにあって、そのイントラネット内にウイルスに感染したPCがあってこのルータを標的にしたときだ。このルータの下のサブネットはルータが一杯一杯なので、なかなかネットに繋がらないことになる。さらにこのルータは上流のDNSサーバに無駄な大量の問い合わせを行うので、イントラネット全体のスピードが落ちてしまう。外には全く影響がない。自分のとこだけが被害を被るわけだ。
どうやら、この問題が発生したようだ。つらいのは、ルータを自由に導入していいとしていて、だれがどのip address （もちろん privateだ）を使っているのか把握できていないことだ。企業ではなく大学だからな。ユーザが勝手に導入したルータがopen resolver 問題を解決できていないとするとーーちょっと前のルータ（無線AP）はデフォルトでは対策されていない――そして、どっかのPCが Dos攻撃ウイルスを持っていて、このルータを攻撃しているらしいのだ。
☆ open resolver 問題を抱えているルータを排除する。
☆ ウイルス感染PCを探しだす
が対策なのだが、ルータのip address がわからない。よわった。感染しているPCを探すのはもっと大変だ。
もしip address がわかったら nslookup で調べる方法。
問題のルータのWAN 側で使っている ip address がわかったとき、そして
192.168.123.123 だったとする。
$ nslookup #と入力すると >プロンプトになるから
> server 192.168.123.123 #と入力すると
Default server: 192.168.123.123
Address: 192.168.123.123#53
> set type=ANY #と入力し
> google.com #googleを解いてもらうと
;; connection timed out; no servers could be reached
>
となったら、ルータの外からDNSの問い合せがあっても答えないということ
になる。これが正常。
もし下記のように google.com のip address が帰ってきたらオープンリゾ
ルバになっているということだ。
ルータの下（内部）から、同じことを行うと
$ nslookup #と入力すると >プロンプトになるから
> server 1192.168.123.123 #と入力すると
Default server: 192.168.123.123
Address: 192.168.123.123#53
> set type=ANY #と入力し
> google.com #googleを解いてもらうと
Non-authoritative answer:
Name: google.com
Address: 216.58.220.238
google.com nameserver = ns4.google.com.
略
ns1.google.com internet address = 216.239.32.10
>
となってgoogle のip address を解いてくれる。つまり、ルータの内部から
はDNS問い合せに応じていることになる。（もし、こうでなかったら、この
ルータの下ではインターネット接続ができないから、動いているルータなん
だらこうならないわけがない）。
> プロンプトの後に exit と入力して nslookup を終了する。
dig を使う場合
$ dig @192.168.123.123 google.com ANY
; <<>> DiG 9.8.3-P1 <<>> @192.168.123.123 google.com ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;google.com. IN ANY
;; ANSWER SECTION:
google.com. 211 IN A 216.58.220.238
google.com. 5715 IN NS ns4.google.com.
略
ns3.google.com. 5714 IN A 216.239.36.10
ns1.google.com. 5714 IN A 216.239.32.10
;; Query time: 57 msec
;; SERVER: 192.168.246.67#53(192.168.246.67)
;; WHEN: Tue Oct 27 14:16:05 2015
;; MSG SIZE rcvd: 378
$
だったら問い合わせに答えたということになる。
$ dig @192.168.123.123 google.com ANY
; < <>> DiG 9.8.3-P1 < <>> @192.168.123.123 google.com ANY
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$
はDNS問い合わせに答えなかった場合だ。
ip address がわかってないと大変だ。WinでEXPing.exe 使って、そのセグメントで利用されているip address を探し、そのほとんどがパソコンかプリンタなんだけど、上記のコマンドを打って見る。なんてやってられないな。
スクリプトを作って…. どっかにないかな？面倒だ。
教えてもらった。検索範囲を192.168.100.0. のネットだとすると
#!/bin/sh
for i in `seq 1 253`
do
echo “dig @192.168.100.$i google.com”
echo “dig @192.168.100.$i google.com” >> result
dig +time=3 +trie=1 @192.168.100.$i google.com >> result
done
をMacのターミナルで実行すると、
$ for i in `seq 1 253`
> do
> echo “dig @192.168.100.$i google.com”
> echo “dig @192.168.100.$i google.com” >> result
> dig +time=3 +trie=1 @192.168.100.$i google.com >> result
> done
で止まるから エンターキーを押すと
dig @192.168.100.1 google.com
dig @192.168.100.2 google.com
….
dig @192.168.100.253 google.com
$
と約３秒ごとに、対象ip address を１つづつ増加させてdig を実行していく。
結果はデスクトップに result という名前のファイルで保存される。
dig @192.168.100.55 google.com
; < <>> DiG 9.8.3-P1 < <>> +time=3 +trie=1 @192.168.100.55 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
とあれば192.168.100.55はDNSをやってないよ。
dig @192.168.100.56 google.com
; < <>> DiG 9.8.3-P1 < <>> +time=3 +trie=1 @192.168.100.56 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 25178 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 299 IN A 173.194.117.225 google.com. 299 IN A 173.194.117.227 google.com. 299 IN A 173.194.117.224 google.com. 299 IN A 173.194.117.230 google.com. 299 IN A 173.194.117.232 google.com. 299 IN A 173.194.117.229 google.com. 299 IN A 173.194.117.226 google.com. 299 IN A 173.194.117.228 google.com. 299 IN A 173.194.117.231 google.com. 299 IN A 173.194.117.233 google.com. 299 IN A 173.194.117.238 ;; Query time: 59 msec ;; SERVER: 192.168.100.56#53(192.168.100.56) ;; WHEN: Thu Oct 29 15:04:04 2015 ;; MSG SIZE rcvd: 204
とあれば192.168.100.56はDNSをやっているよというわけだ。
ルータのWAN側のネットで実施すれば、オープンリゾルバになっているルータの検出ができるわけだ。ルータのした（内側）ではDNSサービスを行うのが当然だからDNSサービスをやっているという応答で問題ないが、同じip address のルータがWAN側からアクセスしてDNSをやっているとうのはopen resolver でまずいわけだ。
dig +time=3 +trie=1 @192.168.100.$i google.com
—–
のようにオプションを指定すると、タイムアウト3秒で1回のみ試行となり、調査の時間が短縮できる（一般的なデフォルトはタイムアウト5秒の3回試行だ）。
相手側が重くなっていると応答に時間がかかることがあるので、タイムアウトは少し長めがいい。
—–
素晴らしい！！
毎年、大学では電源回路のチェックのために定期的に停電がある。法規で決まっているようなので、これを避けることはできない。電源のチェックとは何をするのか分からないが、電源を落として、つまり停電状態で調べることになる。単なる漏電チェックだったら、停電にすることはない。大学では土曜日、日曜日の９時−１７時が停電期間なのだ。
サーバを含めたネットワークを含めた機器を管理するようになってから、毎年、この１０月は、停電実施の前日の夜にサーバをシャットダウンし、日曜日１７時頃再起動するのが通例になっていたのだ。通電のない時期のみ、すなわち土曜日朝落として夕方再起動、日曜日朝落として夕方再起動が最もユーザにとっていいのだが、土日働きたくないというか、何らかの理由で土日にできないと、問題になるので、ユーザには金曜日１８時頃から月曜日朝９時までネットは使えないと案内していたのだ。ちょうど、科研費の締め切りで、科研費はネットに接続されていないと申請できないので、ユーザからなんとかしてくれとの声が大きいのだ。しかし、停電で電源チェックをするのは外部の専門業者で、この専門業者のスケジュールは年間決まっている。毎年、決まった時期に、決まった組織の電源チェックをするわけで、おいそれとスケジュールをいじる事はできないのだ。
サーバ本体はすでに、大学の別の、サーバが集まっている部署に移設され、外注業者によって管理されているので、問題はなかった。つまり、停電時には、大学外からのアクセスは可能だが、学内は停電でネットワークが止まるので、利用できないという状況になっていた。
今年は、昨年建物が昨年耐震工事で改築され、そのとき、G回路という非常用電源に停電時は接続される回路が新設され、ここにネットワークの基幹部が接続されることになったのだ。そこで。医学の基幹部であるノードを維持する電源は確保できるようになったので、停電時、何かをシャットダウン・再起動する必要がなくなったのだ。電源切替時はUPSがあるから、数分、電源が途切れても問題ない。末端のスイッチまでは電源が供給されないし、ユーザがおいたハブとかデスクトップも利用できないから、ノードが生きていても利用にとっては変わりがあるわけではない。
つまり、土日に大学にでてくる必要がなくなったのだ。素晴らしい！！
もっぱら非常用電源＝G回路ができたからだけどね。
昔は、停電になると連絡していたのに、帰宅前にシャットダウンしなかったため、朝、通電されたとき、過電流が流れてこわれちゃうパソコンが続出したことがあった。
ネットワーク機器は、そもそも停電、再通電で壊れるようなことはないように作らえている。電源スイッチがないものもあるしね。
このサーバもG回路に接続していたので、停電時に問題はなかったはずだ。「停電後に自動的に再起動する」にチェックが入っているから停電後自動的に再起動したのが今の結果なら、ターミナルで last とコマンドを入力すると、何時に reboot されたかがわかる。もっとも最近のreboot は９月となっているので、この停電時はずっと動いていたわけだ。
大学のアカウントを搾取して…
件名：こんにちわ
親愛なるつくばユーザー
このメッセージは、筑波大学Webメールの大学からです。我々は、最新のアンチスパムとアンチウイルスソフトウェアをインストールし、メールボックスのスペースにストレージを増やしています。私たちは、にあなたを要求する ここをクリック し、つくばアカウントが更新されます有効にしてつくばアカウントの新しい性質を楽しむために正しくつくばアカウントの詳細を入力してください
あなたのつくばアカウントを更新するには、ここをクリック し、指示に従ってくださいする必要があります。このアップグレードの練習に参加しなかった場合は、アカウントが非アクティブレンダリングされます。
ご理解をいただき、ありがとうございます。
著作権©筑波の2015大学。 全著作権所有。
なんじゃ？このメール。日本語になっていない。で、「ここをクリック」をクリックすると；
という大学のロゴのあるページに行く。
メールのヘッダーには；
From: University of Tsukuba <bfitzpa5@binghamton.edu
とある。もちろんでたらめだ。大学の職員のID、パスワードを盗んで何に使うのだろうか？ま、ともかく集めて誰かに売るんだろうな。
この日本語からGoogleの翻訳サイトで英語に翻訳すると；
This message is from the University of Tsukuba Web mail University. We install the latest anti-spam and anti-virus software, you have to increase the storage space of the mailbox. We, in Click here to request you, Tsukuba account Please enter the details of correctly Tsukuba account to enjoy the new nature of the to Tsukuba account enabled it will be updated
To update your Tsukuba account, click here, you need to please follow the instructions. If you did not participate in the practice of this upgrade, the account is inactive rendering.
英語で読むとなんとなくわかりやすい。だから、多分、英語から日本語に自動翻訳されたのを使ったのだろう。
メーリスのdocomo問題
docomoはメーリングリストによる配信、つまり内容が同じメールが複数のユーザに送付された場合、リストの誰かのメアドが変更されて、そんなユーザがいないとか、そのドメインがらの受信を拒否しているとかいうのが一人でもいると、全員がメールを受理しなかったというエラーメールを返してくれる。
例えばメーリスの配信先に @docomo.ne.jp が１０人いたとする。そのうちだれか一人がメアドを変更した、あるいは受信拒否していると１０人のアカウントすべてからそんなユーザがいないとdocomoは返すわけだ。しかし、その該当者を除く９名にはメールが届いているのだ。これは迷惑メール排除の方法なのだ。メーリスのほうは、数回エラーメールが帰ってくると、そのメールアドレスは死んでいるとして配信停止にするわけだ。
というわけで、一人メアドを変更すると、だいたい１／３くらいが@docomo.ne.jpユーザなので、彼らには配信されないことになってしまう。その犯人探しは、メーリスではなく、メーリスで自動的に配信停止になっているメールアドレスに個別にメールを出すことで調べるのだ。大抵の場合、メアドが変更になっているので、そのようなメアドはないよとエラーが帰ってくるから犯人がわかる。
しかし、今回は違った。返事が遅くて困るのだが、何回か催促したり、友人経由でメール以外の方法で伝言が伝わった結果、全員が、メーリングリストではないメールを送付すると受け取っている。こうなると、犯人はわからない。メールアドレスを変更したのではなく、メーリスからのメールのみドメイン名とかで判断して、受信拒否にしているのだ。通常のメールはメーリスのドメインと異るドメインから送信しているからな。
ま、メーリスに流れるメールの数からいって、また１ヶ月位あとで、一斉にdocomoユーザには配信しなくなるだろう。ただし、docomoもこのような操作を毎回しているわけではないような気がする。だからもっと時間はかかるかもしれない。いずれにしろ、メアドを変更した・受信拒否した奴には届かないが、そうではない奴らには、エラーが帰ってきても届いているようなので、いいことにする。
この問題は、本年度限りだろう。来年度から、学生に配布するメアドはYahoo からG-mail に変わるからだ。Yahoo は教育機関への無料メールサービスをやめちゃうからだ。Yahooメールはスマホに転送すると、サーバからなくなっちゃう。だからパソコンで再度見るということができない。だからメーリスに大学配布のYahooメールを使えなかった。スマホのメアドをメーリスに登録したのだ。学生はスマホ優先だからな。G-mail はアプリをスマホにインストールすれば、メールをスマホでもパソコンでも読める。既に、デフォルトでインストールされている。だからメーリスへの登録は大学が配布するメールアドレスで、これはアカウント名を変更できない。