ホーム » スタッフ » 斉藤徹 » 産学共同 » 緊急連絡システム

緊急連絡システム」カテゴリーアーカイブ

2024年3月
 12
3456789
10111213141516
17181920212223
24252627282930
31  

検索・リンク

緊急連絡システムサーバ移転

Azureサーバ上で動かしていた緊急連絡システムだけど、azure 仮想マシン(クラッシック) で構築してあったけど、クラッシックが2023/3月より動かなくなるので 最近の仮想マシン形式(ARM)のサーバに移転。
といっても、またサーバ移転しなくちゃいけなくなりそうだけど。

qmailからpostfixに移行

これに合わせて以前より問題となっていた qmail ベースで一部サーバにメールが届かない(設定触って届くようにしているけど…)問題を解決。postfix での配送になったので、大量メールでの配送遅延は大きくなったかもしれないけど、さほど影響しないはず。

DKIM, SPF 対応

メール配信に postfix を使うようにしたから、メールの認証も SPF だけでなく opendkim を使って DKIM にも対応させてみた。現時点では、DNS 設定の修正が完全に終われば、spam 扱いも改善されるはず。

SPF は、ドメインから発信されるメールサーバ情報を DNS で公開することで、不正なメール発信を防ぐ方式。DKIM は、DNS に登録してある公開鍵と、個別のメールに付けられる公開鍵を比較することで、不正なメール発信を確認できる仕組み。

緊急連絡システムにSendGridを使ったら

丹南地区の緊急連絡システムを動かしているけど、最近はメールが届かないといった連絡を受けることも多い。

2021/09/10 については、docomo.ne.jp 宛のメールの配送でトラブルが発生し、設定を見直すことで無事に配送ができるように復旧することができました。

基本的に無料で提供しているサービスだけれど、Azure のサーバから送信すると、迷惑メールの送信者と誤認される可能性が高く、最近のキャリアではメールが届かないなどの問題が起こりやすい。

正しく配信されるようにするために、サーバを信用してもらえるような構成にすることも考えられるが、設定のメンテナンスの負担も懸念される。そこで、Azure サーバでメールを配信するための、有料サービス SendGrid を使うことを検討してみた。

最初に、有料システムを利用することになるので、どの課金体系を利用するのかを判断するために、現在の緊急連絡システムの月別のメール流量を集計してみた。この結果、最近ではコロナによる連絡も多いのか平均4万通/月のメールが流れている。多い時には、10万通を超える場合もある。(下図参照)

これを、元にSendGrid を使った場合の費用を算出してみる。一番安い料金 “Essencial 4k” では、1900円/月 (4万通/月,これ以上は、0.125円/通)、”Essencial 10k” では、3800円/月(10万通/月, これ以上は0.094円/通)となる。これを見ると、現状の平均 4万通 からしても Essencial 4k を採用すれば、約 年額 45,000 円 以下に収まると思われる。(下図参照)

 

緊急連絡システムの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 でファイル名や記載時のエンコーディングを修正するスクリプトを書いて一発変換。

あとは、プログラム中のエンコーディング依存の部分を修正し、送信できることを確認してひとまず移行作業完了。

緊急連絡システムとメール分析システム

私が管理している丹南地区緊急連絡システムで、利用者の方から『「受信確認」作業をしているのに、記録されていない…』との相談を受ける。

メール分析システム

上記の現象は、昨年度に行った迷惑メールの分析システム対策が原因であった。

緊急連絡システムでは、ユーザに送った文面の末尾に URL を添付し、その URL をユーザにアクセスしてもらうことで、受信確認を行っている。

一方、連絡システムで、ユーザがメールアドレスを変更したり、ユーザ登録にミスがあると、相手に届かないメールが発生する。最近のメールシステムでは、プロバイダが迷惑メールの分析をすることがあり、この分析処理の中でメール内のURLを、分析システムがアクセスしていると思われる。

コレ以外にも、チャット表示形式のメールアプリでは、届いたメールの概要を確認するために、文中のURLをアクセスするものもある。このような処理が行われると、ユーザがメールを読んでいないのに、受信確認の URL をアクセスされ、受信確認が済んだことになってしまう。

最初、この現象を把握し状況を確認したら、このような分析システムの多くは逆引きできないIPアドレスからアクセスしていることが判明した。そこで、逆引きできないIPアドレスからの受信確認は、アクセス履歴を保存しないように改良を行っていた。

さらなる対策

しかし、今回相談を受け確認を行った所、逆引きできないIPアドレスの中に、通常のユーザからのアクセスも含まれていることが分かった。

そこで、今回以下のような改良を行った。

逆引きできないアドレスからのアクセスの場合には、以下のような送信フォームを表示し、ユーザが「確認」ボタンを押すことで受信確認の記録を行うようにした。

この方法は、ユーザが受信確認のために2回ボタンを押す必要があるが、止む終えないかな。

緊急連絡システムメンテナンス

大雪の連絡が飛び交う中、緊急連絡システムを確認したら、mailqueueに over 800 件の大量メール。配送に影響でているのかと色々と確認したら、メールアドレス間違いでエラーになったメールが各学校に送られていないみたい。

エラーメールが行き渡らないのは別途確認ということで、あまりにも大量なので強制的にエラーメールの未配送を選んで、メールを削除。

緊急連絡のメールによるトレンドツイート

丹南地区の緊急連絡システムを運用していて、この時期はインフルエンザの 記事が急増する季節。しかし、多くの小中学校で流行っていても、 関係者以外はメールの閲覧などもできず、情報の活用が難しい。

そこで、緊急連絡システムのメールタイトルで、トレンド情報を集計し その日の情報を自動でTwitterに報告するシステムを作ってみた。

crontab で学校の対応が出揃う9時頃に、2日間のメールタイトルの中から 感染や大雪といった特定キーワードで分類したキーワードを含んでいる メールを抽出し、一定量を超えたら Tweet する。

数日運用していたが、集計期間が1日程度では、キーワードの当たり外れ の影響も大きいし、数日にすると同じネタを数日繰り返しTweetされてしまう。 そこで集計は2日間とし、出現頻度が30%を越え、 検出されたメールの発信された時間の平均が1日以内であった場合に Tweetするように変更を加えた。

動作例は丹南地区緊急連絡システム#EmcFukui自動警報を御覧ください。

緊急連絡システムの”~”の文字化け対策

緊急連絡システムの利用者の方から、 「URL内の”~”が文字化けして、利用者確認のURLにアクセスできない」といった トラブルがあるとのご指摘を受けた。

その方の話をまとめると、緊急連絡システムの末尾に付けられる利用者確認のURLの行が、 Docomo の SPモードメールなどで、” ̄”に書き換えられてしまうため、らしい。

送信:http://XXX.fukui-nct.ac.jp/~emc/alive.php?.....
受信:http://XXX.fukui-nct.ac.jp/emc/alive.php?.....

URLの中の”~”は、ホームディレクトリを表すために、広く一般的に用いられている URL の 記号文字であり、こんなものを書き換えてしまう SP モードメールがアホと叫びたいけど、 なんらかの対応を…と考えてみた。

緊急連絡システムのプログラムに、大きな変更を加えたくないので、 URLを “~”無しでもアクセスできるように変更し、 メール送信時に、”/~emc/…” で送信すべき場所を “~”無しのURLの ”/emc/…” で送信するように変更した。

RewriteEngine on
RewriteRule ^emc/(.*)$  /~emc/$1 [L]

システム

最新の投稿(電子情報)

アーカイブ

カテゴリー