モーグルとカバとパウダーの日記

モーグルやカバ(EXカービング)山スキー(BC)などがメインの日記でした。今は仕事のコンピュータ系のネタが主になっています。以前はスパム対策関連が多かったのですが最近はディープラーニング関連が多めです。

androidのGmailアプリでプロバイダメールの設定の「名前」が反映されない

androidGmailアプリを使うと、プロバイダのメールのようにPOP3で接続するアカウントを設定することができます。
これは普通にPCのメールソフトにメール設定した場合と、同じ感じで利用することができます。

しかし、このGmailアプリからメールを送ったとき、メールの送信者名が表示されずにメールアドレスのままで届いてしまうことに気が付きました。

設定内容で「名前」という、メールを送った際に送信者として表示される項目があるのですが、この項目が設定されていても送信者名に設定されず、そのままメールアドレスだけが From に設定されて出されてしまいます。

きっとメジャーな問題だろうからネット上に情報出ているだろう、と思ったのですが、Gmailアカウントでの「名前」の変更などはよく出てくるものの、プロバイダメールの設定で送信者名がうまく設定されない、という情報は見つけられませんでした。

なにか参考になる情報があれば教えて下さい。

Windows 10 (2004) アップデートにより Windows Live メールが動作しなくなる

コロナ関係ないのですが、ここ半年くらいブログエントリー書くのサボってしまっていました。
小ネタです。

Windows Live メール」という Windows 7 の頃によく使われていたメーラーがあります。
Live メールは Windows 10 にはもう新規でのインストールはできず、2017/1/10 にはマイクロソフトのサポートも完全に終了しています。

しかし、Windows 7 からアップグレードして Windows 10 にしたようなPCだとそのまま Live メールが使えたため、そうやって利用しているユーザもまれに見かけました。

さて、今年の5月に発表された Windows 10 のアップデート(Windows 10 May 2020 Update)が今頃になってやっと当たるようになってきました。

するとこのアップデート後に Live メールが

0x800c013e 不明なエラー

というエラーにてメールの送受信ができないという状況になるようです。

すでにだいぶ前にサポートも終了しているため、マイクロソフトからは公式になにか書かれているわけではないのですが、たぶんアップデートが引き金で動かなくなっているのは間違いないと思います。

OutlookThunderbirdなど他のメーラーに移行されることをおすすめします。

(追記)

twitterで教えていただいたのですが、レジストリ変更して、強制的に Live メール内部のメール一覧情報を作り直しをさせると動くようになるらしいです。
どうしても Live メールを使い続けたい方はご参考に。

Windows Live メール 2012で「メッセージを表示できませんでした」となる – OSAKANA TAROのメモ帳

Gmailで普通のinboxの中だけを検索する

Gmailで未読が2ある状態になっているものの、探してもどうしても見つからない、という状況になりました。

以前も同じことがあり調べたことがあった

Gmailで「ソーシャル」タブ等に自動分類されたものを排除して検索 - モーグルとカバとパウダーの日記

のですが、今もまだ通常のinboxを探す方法がないのだろうか?と思ってまた調べてみました。

最近?はより簡単に指定できるようになったようで「category:primary」と指定してやればいいようです。
自分の言うところの「普通のinbox」はGmailのタブ「メイン」のところを指していますが、あれは「プライマリ受信トレイ」と呼ぶようです。

Gmailのプライマリ受信トレイのみを検索するにはどうすればよいですか?

category:primary is:unread

介護ハッカソン長野に参加

これ書いてるのすでに2月末なのですが、2/1(土)に介護ハッカソン長野に参加させていただきました。

www.kaigohackathon-nagano.com

介護ハッカソンとは、介護系の方とコンピュータ系のエンジニアがチームになって、介護現場での問題をWeb技術やIoT等を利用して改善するのを競い合うハッカソンです。

2回開催され、3/7(土)の2回目のときにチームの発表を行って、審査と優勝者が決まことになっていました。
が、この新型コロナの問題で、2回目はチームで一人のみが代表で参加して発表、ということになりました。

このハッカソンは元々、9月にやる予定だったのが台風のため延期になってこの日程だったので、開催に関わられた皆さんは色々とほんとに大変だったと思います。

ハッカソンでは、介護系の方に意見を聞きながら、アジャイル勉強会でやったように考えをポストイットに書いてホワイトボードにぺたぺた張っていきまとめていく、というようなことでアイデア出しと意見の整理を行いました。
この辺は、勉強会でやったことがそのまま活かせてとてもよかったと思います。
さらに、出てきたアイデアも他とちょっとひねった感じになっていて、良いのでは、と思っています。

Ubuntuでiptablesの設定を永続化したつもりでハマる

Ubuntu 18.04 LTS を利用しているサーバがあり、そこでiptablesの設定がしてありました。

Ubuntuだとiptablesの設定はそのままではなぜか保存がされず、iptables-persistentを入れないと永続化ができないとなっています。
で、下記サイトのように

Ubuntuでiptablesの設定をiptables-persistentで永続化する

Ubuntu 18.04 LTS iptables Fail2ban 設定等 | ひかるLOG

iptables-persistentを入れて

/etc/iptables/rules.v4

に設定を書いて永続化ができたつもり、でいました。

が、サーバメンテでリブート後DNSの通信が通らなくなり、確認したところiptablesの設定が以前のものに戻ってしまっていて止めていました。

iptables-persistentの設定例を見ると /etc/iptables/rules.v4 (と rules.v6)に設定を書くとなっているのですが、実は /etc/iptables 以下に

/etc/iptables/iptables.rules

というファイルが元々ありました。

自分はこれがあっても rules.v4 ファイルが有ればそちらが使われると思っていたのですが、この設定ファイルがあるとこちらのほうが優先して使われてしまうようです。

とりあえずこのファイルをリネームすることで解決しました。

PostfixでOpenSSLのバージョンでwarningが出る

古いCentOSに入っているTLS1.2対応したPostfixが、下記のような warning をずっと出していて大丈夫なのか、どうすれば止まるのか、という相談をうけました。

warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.0.2 may not be compatible with OpenSSL 0.9.8

調べてみると、src/tls/tls_misc.c 中の tls_check_version 関数でこのwarningを出しており、OPENSSL_VERSION_NUMBER と SSLeay() の間でバージョンの違いがあると出るようでした。

そこで OPENSSL_VERSION_NUMBER を確認すると

/usr/include/openssl/opensslv.h

#define OPENSSL_VERSION_NUMBER       0x0090802fL

の設定が使われており、後からソースで入れたOpenSSLのバージョンと合っていないためとわかりました。

Postfixインストール時には下記オプションつけて

-L/opt/openssl/lib

後から入れたOpenSSLライブラリ指定していたのですが、include については指定されていなかったようです。

そこで include についても下記のように、後から入れたOpenSSLの include を参照するように追加してもらいました。

-I/opt/openssl/include

これで warning がでなくなりました。

NSEG勉強会で3件LTしました

もうひと月以上経ってしまったのですが、勉強会は報告エントリ書くまでが勉強会!ということで今更ながら書きます。

NSEG 19/08 フリープレゼン会 - connpass

久しぶりにNSEGの勉強会が開催され、このままでは@hATrayfloodさんが死んでしまう!と思っていくつかネタを考えていたら、結局3件ともLTやることになりました。

の3本です!

どれも20分のLTなので内容は浅めです。

milter-managerの話はもっと色々と説明すべき内容があるのにLT用にだいぶ短くしてしまっているので、今後ブログのエントリで詳しく書きたいと思っています。

今回、ひさしぶりにNSEG開催されたんですが、やっぱもうちょっと頻度保つようにできたらなと思いました。 とりあえず平日夜会を再開したいと思ってます。

@hATrayfloodさんの発表内容が、すんごい大変そうな話で、なぜこんな苦行をやってるんだろう… なんかの修行なんだろうか?と思って聞いてたんですが、終わってから後から気が付いたのですが、スマホだと拡張機能とか使えないから、ブラウザに機能追加したいと思ったら、自前ビルドで機能追加するしかないのでこんな話になるのですね。 この仕事はしんどすぎる… と思いました。

GmailアプリでのPOPメール送受信は直接行われている

自分の認識が誤ってたのでメモ。

AndroidGmailアプリから、ISPのメール送受信を行うためにPOPアカウントの設定が出来るが、これは普通にPCのメールソフトと同様、Gmailアプリから直接POP/SMTPが呼ばれてメールが送受されるようになっています。

これ、当たり前じゃん?と思われる人も多いと思うのですが、昔のGmailアプリではそれが出来ず、WebのGmail設定でPOP/SMTPの設定をしておいて使うようになっていました。
つまり、Gmail経由でPOPやSMTPが呼ばれるようになっていたため、接続元IPもgoogleになっていたのです。

なんかずっとその認識でいたのですが、Gmailアプリからの接続のログ見てたら、直接キャリアIPから接続しているようになっていたため、あれっ?と思って実験して確かめてしまいました。
ちゃんと知識をアップデートしていかないとダメですね。

「logits」の意味について

最近DeepLab v3+のことを調べていて、所々で「logits」という言葉が出てくるのですが、これの意味するところがよくわからない状況でした。

twitterで質問してみたところ、Higuchiさんから下記のように教えていただきました。

hinaser.github.io

TensorFlow等の機械学習フレームワークでは、これから確率に変換しようとしている出力層のニューロンの出力値を よくロジットと呼ぶことが多い。

最終レイヤーでは出力をシグモイド関数掛けてさらにソフトマックス掛けて確率として出力することが多いですが、その前のナマの値を「logits」と呼んでるということでした。

最終レイヤーの出力時の処理がシグモイド関数だけなら、その逆関数がlogitsだから、その前の値をさしてlogitsと呼ぶのも理解できます。

こういう慣習的な呼び方はぐぐってもあまり出てこないのがむつかしいところ。

メールアカウント盗られてこっそり受信されている例が結構ある話

ここのところサブミッションスパムが出されることが一定の頻度で続いていて最悪なのですが、そのことを調べていた時にちょっとイヤな例を見つけました。

サブミッションスパムで使われたアカウントがあり、ふとそのアカウントでメールの受信は来てるのかな?と確認しました。
すると、日本国内からのアクセスはないのに mail.ru ドメインからのアクセスがだいたい1時間に1回と定期的に来ていたのを見つけました。

mail.ru はロシアでメールサービスやっているところのドメインで、VPSのようなサービスもやっているところです。
なのでそこのWebメールサービスにアカウントが登録されていて、そこから受信が行われている、という可能性は考えられます。

ですが、その接続があった付近のIPで検索すると、他にも同様にアクセスされているアカウントがいくつもありました。
そしてそのうち一つは、その少し前にサブミッションスパムが出されていたものでした。
アカウント数を数えてみると、これまでサブミッションスパムで利用されてしまったよりも数倍多くありました。

あくまで状況証拠からですが、クラックされたアカウントが定期的に受信がされている、と考えるのが自然と思います。

状況まとめると

  • 外部からこっそり受信のみが行われているアカウントが結構ある
  • それらは1時間に1度くらいの頻度でメールが覗かれている

となります。

つまり、アカウント情報のもれたメールアカウントのメールを監視している大規模なネットワークが存在しているということなのです。

例えば、アカウント設定の再送をメールで行ったりしたのをフックして、そのアカウントも盗ってしまうとか、そういうのを自動でやってるのかなあ、と想像します。

これのなにが恐ろしいって、メール受信されていることをユーザは全く感知できない、ということです。

これ、大手ISPなんかだと、GoogleやLINEみたいに、普段の接続ではないIPからメール受信されました、みたいなアラート上げたりしてるんだろうか…?

こういうのって最近のセキュリティ界隈では結構知られていることなのでしょうかね?

(追記)

mail.ruのPOPしてくるIPからであること確認できたので、mail.ruに受信確認の設定がされているのだと思います。

またスマホから一つのメールアプリでまとめて読むために、mail.ruを使われる需要が結構あるようで、それように普通に設定していた可能性も高いです。

ただ、サブミッションスパムで利用されたアカウントとの重複率がだいぶ高いため、なんらかの理由で相関があるのだと思います。

例えば、そのようなユーザは他にもmail.ruのようなメール一括受信アプリを試している場合が多く、そこから漏れた or アカウント取得を主目的としたマルウェアを使ってしまった、などです。

このあたりは完全にこう、というのは結論づけることはできなそうですが。