緊急連絡システムのicloud問題解決
緊急連絡システムを運営しているけど、最近 icloud.com 宛のメールが届かないといった問題が発生していた。
いくつかのサイトでは、MXレコードを引く際の DNS の情報が大きい場合、qmail が失敗するなどの情報から、対処などを施していたが、icloud の配信でこういった症状が出ていた。
色々と調べてみたが、icloud.com は、メールの X-Header が含まれると、受信を拒否するのが原因ということが見えてきた。
緊急連絡システムでは、トラブルが発生した際の履歴を追えるように、X-EMC-…. という拡張ヘッダを埋め込んでいた。
今回、icloud.com, mac.com, me.com のメールアドレスの場合は、X-EMC- を付けないように処理を加えたところ、無事にメールが送信できることが確認できた。
しかし、こういうキャリア毎の事情は、わからないわ…(x_x;;
緊急連絡システムでrblsmtpd
メモ：緊急連絡システムで、迷惑メールが届いている。変なリレーはされていないけど、エラーメールが配送できずに溜まってる。
設定を改めて確認して、迷惑メール対策が弱いのでブラックリストなメールサーバからの受信をしないように、rblsmtpd を導入。rblsmtpdの設定は、以前の運用経験からすぐに設定できるかと思ったけど qmail が systemd 用に設定ファイルが変わっているので、修正場所を探すのに手間取った。
icloud.com メールが届かない
qmail の DNS 512byte パケット問題のパッチをあてたものを使っているつもりだが、また緊急連絡システムのメールQueueが icloud.com 宛のメールで埋まっていた。
そこで、参考記事(icloud.comやme.comやhotmailにメールが届かない時)を参考に以下の設定を行った。
mail.add_x_header
(( /etc/php/7.0/apache/php.ini )) mail.add_x_header = Off
smtproutes
(( /var/qmail/control/smtproutes )) icloud.com: mx1.mail.icloud.com me.com: mx1.mail.icloud.com nifty.com: smmx.nifty.com hotmail.com: mx1.hotmail.com :
((2018/11/30))
icloud.com の情報を smtproutes に書き込んで、メールが流れるようになったけど、改めて確認したら、me.com 宛が詰まってた。”me.com:mx1.mail.icloud.com”を追加。
緊急連絡システムのOS更新など
緊急連絡システムのOSが、Ubuntu/trusty でそろそろ、サポート期間に近づいているので、OS の更新を行った。
Ubuntu 更新
更新自体は、do-release-upgrade コマンドで、xenial に更新が進む。
$ sudo do-release-upgrade
しかしながら、openssh-server が、更新でエラーがでて、かなり悩んだ。解ってみれば、単純なミスで、自作の /etc/init.d/script を書いてあったけど、その insserv ヘッダで、ssh をコピーしてヘッダ部の # Provides: sshd の行を書き換えてなかった。
このおかげで、insserv が、ssh はすでに登録されている…と勘違いしていた。
緊急連絡システムの文字コードUTF-8 に変更
Ubuntu の更新をかけたら、php5 が使えなくなったため、php7.0 に更新を行うが、これに合わせ、取り扱い文字コードを EUC-JP から UTF-8 に変更を行った。
緊急連絡システムは、内部でデータベースを利用せず、テキストファイルですべてを管理しているが、最初は利用組織毎の設定ファイルや、データファイルをエディタでチマチマと修正を始めたけど、大量の組織のため、途中で断念。perl でファイル名や記載時のエンコーディングを修正するスクリプトを書いて一発変換。
あとは、プログラム中のエンコーディング依存の部分を修正し、送信できることを確認してひとまず移行作業完了。
xenial の snapd いるの？
以前から発生していた、Ubuntu のサーバで snapd がうまくインストールできないトラブル。 install しようとすると古いバージョンを削除するときの prerm script でエラーとかいうメッセージがでるので、/var/lib/dpkg/info/snapd.prerm を編集して、エラーの出る処理の前に exit 0 を入れたりしながら、無理やり削除して、インストールを試みるけど、こんどは、postinst でエラー。
原因がつかめずに、四苦八苦していたけど、「バージョンアップして trusty を使っているなら、/etc/apt/sources.list などの中にある xenial 関係を消せ」という記事を見つける。
まさに、xenial を upgrade した trusty だったので、/etc/apt/ を探すと、php 関係のパッケージで、
deb http://ppa.launchpad.net/ondrej/php/ubuntu xenial main
というのが見つかったので、早々に消してみた。その後、”aptitude update ; aptitude safe-upgrade” を実行したけど、特にパッケージが消されたりもしなかったし、これで OK かな。
緊急連絡システムとメール分析システム
私が管理している丹南地区緊急連絡システムで、利用者の方から『「受信確認」作業をしているのに、記録されていない…』との相談を受ける。
メール分析システム
上記の現象は、昨年度に行った迷惑メールの分析システム対策が原因であった。
緊急連絡システムでは、ユーザに送った文面の末尾に URL を添付し、その URL をユーザにアクセスしてもらうことで、受信確認を行っている。
一方、連絡システムで、ユーザがメールアドレスを変更したり、ユーザ登録にミスがあると、相手に届かないメールが発生する。最近のメールシステムでは、プロバイダが迷惑メールの分析をすることがあり、この分析処理の中でメール内のURLを、分析システムがアクセスしていると思われる。
コレ以外にも、チャット表示形式のメールアプリでは、届いたメールの概要を確認するために、文中のURLをアクセスするものもある。このような処理が行われると、ユーザがメールを読んでいないのに、受信確認の URL をアクセスされ、受信確認が済んだことになってしまう。
最初、この現象を把握し状況を確認したら、このような分析システムの多くは逆引きできないIPアドレスからアクセスしていることが判明した。そこで、逆引きできないIPアドレスからの受信確認は、アクセス履歴を保存しないように改良を行っていた。
さらなる対策
しかし、今回相談を受け確認を行った所、逆引きできないIPアドレスの中に、通常のユーザからのアクセスも含まれていることが分かった。
そこで、今回以下のような改良を行った。
逆引きできないアドレスからのアクセスの場合には、以下のような送信フォームを表示し、ユーザが「確認」ボタンを押すことで受信確認の記録を行うようにした。
この方法は、ユーザが受信確認のために2回ボタンを押す必要があるが、止む終えないかな。
緊急連絡システムメンテナンス
大雪の連絡が飛び交う中、緊急連絡システムを確認したら、mailqueueに over 800 件の大量メール。配送に影響でているのかと色々と確認したら、メールアドレス間違いでエラーになったメールが各学校に送られていないみたい。
エラーメールが行き渡らないのは別途確認ということで、あまりにも大量なので強制的にエラーメールの未配送を選んで、メールを削除。
sakura.ioでIT人材育成
さくらインターネット様による高専のIT教育支援を受け、sakura.io,Arduino用シールド,IchigoJam が届きました。
これらの機材を使い、電子回路からインターネットへと幅広い開発の経験から、創造的IT人材育成にチャレンジします。
IT教育支援の共同研究(H30年3月まで)として、以下のテーマに取組みます。
- sakura.ioを用いた、低学年でのIoT連携実験
- おなじく、高学年での創造的なシステム構築演習
- さくらのクラウドを用いた、クラウド環境実験
- これらを応用した卒業研究
歯みがきロボコン工作教室
今年は、プッシュリベットを多用して、子供中心で作っても、早く組み立てができました。
歯みがきロボコン工作教室マニュアル
例年、福井県歯科医師会さん主催で、お手伝いしている 歯みがきロボットコンテストでの夏休みの工作教室を明日に控え、 組み立てマニュアルを作成。
