(IT) 自ドメインの設定が参加しているメーリングリストの配信に影響があった話

趣味のランニングのチームのメーリングリストのサーバーの運営をしている。
そんなもん、Googleでも何でも適当な無料サービスがあるだろ、なんて指摘は全然承知はしているんだけど、Webサーバー用にドメインもあるので、だったらチームのドメインでPostfix運用してMLエンジンもいれてメーリングリスト運用しちゃおう、ってことになっちゃって。
広告が入るのがイヤ、ってのもメンバーの皆さんにあったりとか、過去の経緯もあったりで。

前置きここまで。で、このメーリングリストのサーバーからのメールの一部をドコモ様が拒否していることが発覚。
レジェンドMさんから「XXXX番とYYYY番が届いてねえぞ!」と怒りのLINEが。あ、MLなんて止めてLINEグループにしちまえ、なんてご指摘もご遠慮くださいね笑
調べてみたら、3月中旬くらいから送信者がオレの場合にだけ、ドコモ宛とicloud宛のメールが先方のサーバーの拒否(Usesr Unknown)でバウンスしてた。同じメーリングリストで他の人が送信した場合は同じ宛先でもドコモのサーバーは受け取ってくれているのに。
まあ、メーリングリストのメールって、本当の送信者のドメインと送信元のサーバーのドメインが違うので、あやしいといえば怪しいのは承知してるんだけど、なんでオレのだけ?
と思って更にログを調べてたら、icloudさんのバウンスのログにヒントがあった。ちなみにドコモのサーバーの拒否ログはこんな

to=<hogehoge@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.240]:25, delay=1.3, delays=0.09/0.02/0.1/1.1, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.240] said: 550 Unknown user hogehoge@docomo.ne.jp (in reply to end of DATA command))

「そんな人、知りません(プイっ)」みたいなログしか残らない。
これに対してicloudさんのログはヒント付き。

to=<hogehogehoge@icloud.com>, relay=mx02.mail.icloud.com[17.57.156.30]:25, delay=31, delays=0.1/0/1.9/29, dsn=5.7.1, status=bounced (host mx02.mail.icloud.com[17.57.156.30] said: 554 5.7.1 Your message was rejected due to shirao.net’s DMARC policy. See https://support.apple.com/en-us/HT204137 for info (in reply to end of DATA command))

「なんや、しらんけど、shirao.netのサーバーのDMARCポリシーがそうせえ、書いてるから拒否しとくわー。ちなみにここ参照な」ってことらしい。
ああ、なるほど。shirao.netの中の人が送信してると主張している割に送信元のサーバーが違うドメインだった場合は、拒否してくれ、ってDNSに書いた記憶があるわー。ってことでshirao.netのDNSのTXTレコードを確認。

_dmarc.shirao.net TXT v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@hogehoge.com; ruf=mailto:dmarc@hogehoge.com

これの「p=reject」ってところが「もし違うサーバーからshirao.netを語るメールが来ても信用しないで拒否してちょうだい」って意味。これを「p=none」に書き換えたらドコモ様も受信してくれるようになった。MLのドメインから来ても信頼してみてね、ってこと。
ただ、この設定は一時的にはいいけど、永続的に設定するのは非推奨らしいので、他の設定を調査を継続中。まあでも、とりあえずは解決した。
ドコモやicloudみたいな広義でのISP(Internet Service Provide(死語))は時々メール受信の判定ルールを好きなタイミングで緩めたり厳しくしたりするんで、こういうことがたまに起こるみたい。今回も3月中旬に急にこのDMARCの判定を厳密にするようになったっぽい。同じように困ってる人の助けになりますよう。あ、自分がメールで使ってるドメインのDNS設定いじれる人ってそんなにいないか笑

(お父さん) これから還暦同窓会を企画する58~59歳の幹事さんへのアドバイス

それまでクラス会やら同窓会やら、ほとんどやってこなかった人々も還暦が近くなって、仕事や家族の環境に大きな変化がある年代になるとどうやら昔の仲間に会いたくなるらしい。日本人だけ?なの?
しかも日本には60歳を「還暦」として、ひとつに節目に扱ってる傾向があるので、このタイミングで集まろうとなるのは自然なことなのかもしれない。
親の介護が必要になったり、または亡くなってしまったり。
子供が結婚して孫がいる人もいれば、まだ子供がまだ小さくて学生だったりという人もいて、そのあたりはバラエティ。
仕事は早期退職?役職定年?継続雇用?給料半減?年金どうする?自分の健康・病気などなど、ちょうど60歳くらいにはいろんな転機があるので、同年代の誰かと話したくなる感じでちょっと人恋しくなるのかな。
という中で誰が言うでもなく、同窓会やろうよ的な声が上がってプロジェクトが立ち上がるわけで。
2025年2月開催で自分の高校時代の同窓会を企画し、開催したことから、後輩の皆さんへのアドバイスを残すという老害作業をしてみることにする。
個人的にはミニ「プロジェクトX」風の中のスーバルー笑

(1)日程と会場は半年以上前に決める
プロジェクトを立ち上げたのは2024年6月。幹事(言い出しっぺ)のTと、事務局(雑用)のオレの二人でスタートし、今でも常に連絡を取っている仲間数人に声をかけ、5人程度でプロジェクトを開始した。
とにかく日程を決めて場所を抑えることが大事。全体の人数の1/3~1/5くらいの数で予約するくらいでいいと思う。オレの場合には、高校があった千葉県JR市川駅前のホテルを6月に100人で仮予約した(同窓生は360人)。これは電話でOKだった。日程と場所が決まるだけでも、連絡した時に具体的な事が伝えられるので受け取った側の判断もしやすくなる。9月になってに「すぐ近くに他にいい会場がある」という情報があり確認してみたが、あらかじめ決めていた日程ではもう空きがなかったので、やはり半年くらい前には会場は決めてしまわないとダメみたい。

(2)各クラスでスタッフを決める
プロジェクトの立ち上がりの段階で全クラスのスタッフがそろっていなくても、半分くらいのクラスのスタッフが決まれば、まずはそこでキックオフミーティングをしておおまかなスケジュール感とか規模感を共有しておくといいようだ。当初スタッフのいなかったクラスからも後日立候補があり、ほとんどのクラスでスタッフが揃い、連絡係として機能するようになった。

(3)声がけをする母集団を形成する
やっぱりこういう時は運動系の部活のつながりは強固でアテになる。定期的にOB会をやってる部の人から繋げて行くことで告知が進んだ。Facebookの検索はあまり役にたたなかった。まず、登録している割合が低い上に検索されない設定いしている人もいるので、フルネームで検索してもまず引っかからない。結婚して名字が変わった人なんかの場合、まあ見つからない。
最終手段として9月頃、卒アルの巻末にある住所録にある住所へハガキを出すことにした。昨今の社会情勢から、「高校の同級生のXXです」と電話しても怪しまれるだけで、話が通じる気がしなかったこともある。また、封書ではなく、ハガキとすることで、内容を見ることができるため、受け取った実家の誰かも安心して本人へ渡してくれるだろう、という予測のもとだ。郵便番号3桁の40年前の住所に出しても、運が良ければ年老いた両親がまだ住んでいる可能性もあるが、到達率は低いだろう、と想定はしていた。結果として7割以上は宛先不明で戻って来たが、逆に言えば2割ちょっとは到達したらしい。これを読んだ人が、年賀状でつながっている友人に連絡してくれたりして、拡がりは生まれたので、効果はゼロではなかったようだ。

(4)サイトを作っておく
Googleサイトを活用して案内サイトを作っておいた。とにかく、このURLを拡散さえしてくれれば、届いて欲しい人に情報が届くだろう、というサイト。
日時と会場と申込みフォームへのリンクだけ貼っておけばOKだ。事務局の問い合わせ先のメールくらいは書いておいた方がいいかもね。
どこまでを公開にするか、非公開ページを作ってログインさせる?とかいろいろ考えたけど、60歳に近い人々はITフレンドリーな人の割合がギリギリ低いので、そういうところで敷居を高くしても誰も得しないので、公開ページのみとした。
会費は事前振込としたかったので、銀行口座の案内が必要だったが、これはフォーム入力があった人への返信メールに書くことにして口座情報の公開はしないようにした。

(5)意外な落とし穴は振込とキャリアメール
振込なんて、ネットで瞬殺という人も少なくない。メールを送信して数分後に振込を完了してくれる人も多い一方、「振込とは銀行へ行ってするもの」と思ってる人のなんと多いことか。チコちゃんに叱られろ。手数料だって高いし面倒くさいじゃん、とは思うものの、そういう人にそんな事、わざわざ言っても今回だけのことだし、「お手数おかけしてすみません」とお詫びをしつつ振り込んでもらった。結果としてメール送信後、数週間後に振込確認ができたという人も少なくない。
もうひとつの問題はdocomo.ne.jpとかezweb.ne.jpとか使ってる人。まさかフィーチャーフォンを使い続けてる人はいないんだろうけど、スマートフォンに切り替えても携帯キャリアのメールを使い続けてる人は少なくない。そして、今どきのキャリアメール、着信拒否の場合でもエラーメールを返して来ないし、サーバーまで着信しても迷惑メールフォルダに振り分けたり、着信の通知はするが中身を見せてくれない、みたなことまでするらしい。結果としてそれらのドメインを使っていて、メール着信設定を言われるがままにしているい人にはメールは届いていないのだが、オレの携帯のアドレスから転送したり、親しい友だちに聞いてもらったりして、なんとか口座情報は全員に伝わったようだ。gmail率はかなり高かったが、キャリアメールも10%はいたので、彼らに対するケアはしばらくは必要なのかもしれない。

(6)結局はLINE
facebookのグループとかメッセンジャーも使ってたけど、スタッフ間のやり取りも全体の連絡用も結局はLINEになっちゃう。まあ、キャリアメールを使い続けてる人でもLINEはやってるからね。還暦近い人でもLINE浸透率はかなり高いということがわかった。
スタッフLINEグループ、全体のLINEグループに加え、各クラスごとのLINEグループも作って事前のコミュニケーションを活発化させた。事前に「場を暖める」にはやはりLINEが最適なようだった。

(7)出席連絡があった人を公開
これが割と効果があった。申し込みフォームに入力があった人の名字だけ、案内ページに掲載した。こんな人が申し込んでますよ、と。「あいつが来るなら行かない」なんてネガティブなことよりも「あの人が来るなら私も行こう」と捉えてくれる人が多くて、参加者増加に弾みがついた。

当初、幹事チームでは「50人も集まればいいよね」という話でスタートした。100人の部屋は取ったものの、50人くらいだったら着席でやればいいし、とか言ってたけど、蓋を開けたら120人参加。先生も7人も来てくれて(生きてるだけでも奇跡な年齢の先生もいたりして)、立食で盛会となった。

今回隠れた功労者だったのは同窓生のM君。彼が母校の現役の教員だったことが同窓会の成功に大きく貢献してくれた。当日午前中に校内見学会を開いてくれたり、昔の資料や写真を図書室から発掘してくれたりして出席者への情報提供の厚みが出た。彼には会の最後に校歌の歌唱指導(笑)というライフワークも披露してもらい、同窓会の締めには大変ふさわしいものとなった。


これからしばらくは各クラス単位で旧交を温め、8年後、卒業50年の節目に再会することを約束して閉会とした。
うん、やってよかったよ。みんなありがとう。

p.s.
サイトのURLやハガキ文面の例は個別に問い合わせもらえれば共有しますので、ご連絡ください。

(IT) AWSでメールサーバー立てててspamhaus.org使ってると受け取ったメールを全部SPAM扱いされる

もう、メール送信サーバーを自前で運用するなんて、面倒くさいだけで何のメリットもないけど、意地と趣味で続けていたりする。合計6ドメイン、3サーバーでメールサーバーの運用をしている。全部AWS上のpostfixだ。
今日の昼頃、そのうちの一つのメールサーバーで運用しているメーリングリリストへ送信できないよーというメッセージを頂いた。エラーの内容がわからなかったのと受け取ったのが出先だったので、エラーメール転送してくださいとだけ返信して、帰宅後に対応を開始した。
とりあえず、サーバーにログインしてログをみると、確かにエラーになっている。

Nov 3 11:04:39 ip-10-0-1-97 postfix/smtpd[23376]: NOQUEUE: reject: RCPT from 送信元サーバー[IPアドレス]: 554 5.7.1 Service unavailable; Client host [IPアドレス] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/[AWSのパブリックIPアドレス]; from=<送信元アドレス> to=<送信先アドレス> proto=ESMTP helo=<送信元サーバー名>

spamhausとは、無料のブラックリスト判定サービス。サーバーの設定で「spamhausがSPAMと判定しているサーバーから来たメールは問答無用で拒否する」という設定ができるもの。
最初あんまりちゃんと読まないで、自分のサーバーがブラックリスト登録されたんだと思いこんで、解除依頼すればいいんだろうとたかをくくっていた。そう、なぜかブラックリストに追加されて解除依頼は過去にも経験があったからだ。
spamhaus.orgのブラックリスト確認ページへ行って、自分のメールサーバーのIPアドレスやドメインを入れても問題ないと出る。

なんでだ?
ログをもう一度よく見てみると、SPAM判定されているのは送信者側のサーバーのようだし、リンクされているのはAWSのRoute53(DNS)のIPアドレスのブロック確認ページだ。天下のGmail様から来たメールも見事におはじきになっておられる。どういうこったー?
こういう時はtwitter検索で同じ症状の人を探すのが近道。というわけで、見事に原因にたどり着けた。
9月22日に
AWSから無料でspamhaus使ってるメールサーバーには全部SPAMって答えるよ、さもなければ有料サービスにお入りなさい」と書かれた告知がリリースされているを発見。君か。10月18日から順次適用とな。オレが管理している3サーバーでは、11/1適用が1台、11/3適用が1台、残る1台は未適用という感じだったが、これから順次適用されていくと思うので、該当する管理者は対応を急いだ方がいい。
具体的な対応としては、/etc/postfix/main.cfに書かれているこのエントリーの「eject_rbl_client sbl.spamhaus.org」という部分を削除し、適切なspamチェッカーを設定すればOK。ようするにspamhausを使わなくすること。

smtpd_client_restrictions = (もろもろの許可設定),reject_rbl_client sbl.spamhaus.org,

念のためpostifixやその他のモジュール(DKIMとかdovecotとか)を再起動して復旧となる。
早く気がつけてよかった。死活監視では気が付けない問題なので、利用者からの問い合わせじゃないと気が付けない。
同じ症状で困っている人に向けてblogにしておいた。

(IT) jcomのメールサーバーの行儀が悪い

shirao.netというドメインを20年くらい前に取得して、主にメールでつかっている。
メールサーバーも最初は当時の所属会社にひっそり置いたSunのマシンにqmailを入れて稼働を開始し、その後自宅のSun Ultra10で稼働させていたが、震災の計画停電のタイミングでawsへ移行した。いったんOCNのCloud-nに浮気をしたものの、USリージョン閉鎖に伴い再度awsに戻ってpostfix化したりして。業界の人ならわかると思うけど、自分でメールサーバーを運用するというのはもう、無駄でしかない。
メールを使うだけならGmailでええやんけ、が正解。自分のドメインも持ち込めるし。
自分でメールサーバーを運用していると、攻撃パターンとか迷惑メールのトレンドを肌で感じることができ、少なからずシゴトに活かせるので、面倒だが、好きでやってる感じかな。
実家の両親にも最初からこのドメインのアカウントを使わせていて、メーラーはOutlookを触らせず、最初はAl-Mail、最近ではThnderbirdを使わせている。

ここ一週間くらい、実家の母(84)から俺のアカウントにメールが届かないという事象が発生していた。

同じドメインで同じサーバーを使っている俺も父も何事もなく送受信できているにもかかわらず、だ。
ログを見てみると、こんな感じでrejectしてた。

予想されるストーリーはこんな感じ。
(1)Thunderbirdのアップデートか何かでshirao.netドメインのSMTPサーバーの設定が飛ぶ
(2)その後の送信時に、回線のグローバルIPからJCOM回線と想定され、SMTPサーバーにJCOMのデフォルトが設定される
(3)母から俺あてのメールはshirao.netの中で完結するのに、なぜかjcomのサーバーらしきサーバーから飛んで来る
(4)そのjcomらしきサーバーはomta0014.jcom.zaq.ne.jpという名前でくる。(0014の数字の部分はその時々で違う)
(5)omta????.jcom.zaq.ne.jpというサーバーは正引きでIPアドレスを引けない
(6)ホコリ高き(笑)我がサーバーは正引きできないサーバーからのメールを受け取らない
(7)親子の断絶が生まれる
(8)余談だが、母のお友達のjcomユーザーのメールもrejectしてるが、全部jcomが悪いからね

俺のGmailのアカウントだとメールが届くので、それを使って「ThunderbirdのSMTPサーバーの設定を確認してくれ」と伝えたが、結局どこをどう見ればいいのかわからんと言われ、俺もThundebirdユーザーじゃないので、見ないとわからんということで、クイックアシストすることに。

普通の人なら、スタート>Windowsアクセサリ>クイックアシスト、と言えば、2秒で行けると思うのだが、84歳は一筋縄ではいかない。スタートメニューがなんだ酷いことになってるらしく、Windowsアクセサリに到達できない。作戦変更して「スタートで右ボタン押して検索でkuikkuと打つ」を電話で128回叫んでようやくクイックアシストの「支援を受ける」ボタンに到達。ここまで30分。
クイックアシストで母PCの中をみたら、ThnderbirdのSMTPサーバーはやはり、jcomのデフォルトに変わっていたので、shirao.netの設定に変更。パスワードを設定するところがなかったんだが、テスト送信時に認証のパスワードを聞かれ、無事に設定終了。母PCから俺のアカウントへのメールが開通した。クイックアシストで入ったら10分で解決。昔は、千葉県北部まで足を運んでたが、このクイックアシストは便利だし、感染防止にも役立つな、これ。それにしても年寄りはなぜスタートメニューが酷いことになるんだろうか。確かに酷かったけど、そっとクイックアシストを閉じたなど。

とはいえ、正引きできないサーバーでメール送信してくるjcomのサーバー、ダメだと思うぞ。きっと、届いてないメールたくさんあると思うんだが、大手プロバイダだし、確信犯ってことなのかしら。設計間違えちゃったのかしら。

(IT) お世話になります

「お世話になります」:これから取引をするかもしれない会社へのメールの書き出しの定型句
「お世話になっております」:既に取引のある取引先へのメールの書き出しの定型句

という違いがあると指摘され、愕然としている55歳(告白)。
主に接客業などのサービス業においては常識らしく、入社時研修で覚えるべき項目とのこと。
これまで、何の疑いもなく、取引があろうがなかろうが、「お世話になります」しか使ってなかった。みんなどうしてた?
常日頃、メールの件名がどうだ、成増がどうだとえらそうに書いてるクセに知らなかったことがあったとは誠に恥ずかしい。恥ずかしい記念に晒しておく。ああ恥ずかしい(棒)。

知らなかったくせに反論するわけではないのだが、マナー大好き日本人は勝手にいろいろなルールを設定して魔女狩りをしてきた感じがしないでもない。
社内を宛先としているメールの頭に「お疲れ様です」とつけるのも同じ。それ意味あるか?って思ってるから、つけないようにしてる。
電子メールという後発のコミュニケーションツールにおいて、レガシーなツールである「電話」で運用されていた(なんとなくやってきた)マナーをそのまま適用したのではないかと推察する。「お世話になります」も「お疲れ様です」もそもそもは電話マナーだよねえ?

さらに新しいツールであるLINEやSlackやTeamsでは「お世話になっております」も「お疲れ様です」も書かないのが主流だし、「件名」も存在しない前提でコミュニケーションが成立しているし、それでも電子メールからのシフトは進んでいる。社内だけではなく取引先とも。
だからといって新しいツールでの新しいマナーを古いツールへ適用することは、理屈はどうあれ、社会的信用のためには、避けるほうが無難であることは理解する程度に歳は取ったわけで。

そんなわけで、自分に言い聞かせるために再度書いておく。
「お世話になります」:これから取引をするかもしれない会社へのメールの書き出しの定型句
「お世話になっております」:既に取引のある取引先へのメールの書き出しの定型句

(意訳:土下座する大和田常務の顔で打っていると思ってください)