はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2024 の14日目です。 ここで書くできごとは、私が12年前に招いたネットワーク障害の話です。 書くにあたって当時の資料やメモを見たのですが、「あああああああああ! 何を考えているんだこのお馬鹿さんは」という気持ちにしかなりませんでした。 こういうことに気を付けねばならない、こういうことをしてはいけないと自戒の碑として、書いておく次第です（ご迷惑をおかけした関係者の皆様、本当にすみませんでした）。皆様の参考になれば幸いです。 背景 担当していたサー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

メールの世界にGmailさんが新たな闇を投入 (インターネットの)メール受信・送信は闇あふれる世界だと思うのですが(*1)、そこに 2023年10月7日、新たな闇要素をGmailさんが投げ込んでくれました。（正しくは2023/12月頭現在、闇がモリモリ増えてる。補足①②参照） (*2 最下部キャプチャあり) えーと、「1日あたり 5,000 件を超えるメールを送信する送信者」はこの事項を守ってね……とあります。要件と書いてあり、2024/2/1から実施と急なうえに、項目が SPFとDKIMの設定 逆引き 迷惑メール率 メール形式 Gmail の From: ヘッダーのなりすまし ARC DMARC ダイレクトメールの場合(……なんとかかんとか) 登録解除 と9個もある。 何これ……？と様々な人を戸惑わせています。 インターネットにつながっているそこそこの規模の組織は、1日あたり 5,000

メールに送信者のアイコンをつけて送りたい、って何？ 毎日いろいろなところから届くメール、 アプリやWebメールでこんなふうに送信者のアイコンが表示されるときがあります (例、インスタ)。 多くはこういう人のアイコンとかイニシャルのアルファベットとかこういうそっけないものです。 アイコンが表示されてると誰から来たかわかりやすい。 ECサイトとかWebサービスの送信者としては受信者に一目で識別してもらえるようメールに送信者のアイコンをつけて送りたい。 もし自社のメールアドレスを送信者メールアドレスに騙ったフィッシングメールがあれば受信者のフィッシングメールからの保護に寄与する（セキュリティー側面）。送信者のアイコンがあれば受信者に見られる可能性も増える（マーケティング側面）。 しかし、その方法がなぜかいくつかあってどれを選べばいいか悩む、これが今回取り上げる闇です。 ※以下、受信者に表示される

といった感じです。（この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。） "No.～基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20～500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。 知ってる人は知っているが、知らない人はぜんぜん知らない 最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が 「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」 と話したことがありました。その瞬間、 嫌なことを思い出したのか顔を曇らせたり苦笑いをす

iOSのメールプライバシー保護機能が闇動作なので紹介したい iOS15(2021/9/21リリース)では、メールプライバシー保護機能(MPP - Mail Privacy Protection)なる機能が導入されました（iPadOSやMacOSも同様に導入）。標準メールアプリが対象で、iOS15で標準メールアプリを起動するとこんな画面が出てきます（画像はiPadOS15ですが）。見たことある方、多いのではないでしょうか。 この機能に関するAppleさんの説明は iPhoneでメールプライバシー保護を使用する にあり、 送信者に対しIPアドレスが隠されること メールが開かれたかどうか送信者は確認できなくなること が謳われています。 この実現方法を調べたら驚きの挙動でして、 いままでITPの謎動作とかを対岸の火事だと思って眺めていたらメールの方にもやってきたわ 、という気分になったので紹介して

※この記事12/23が空いていたので、代わりに投稿しました。ライトなものです。 Tomcatの最新バージョンは9.0 現在の Apache Tomcat の最新メジャーバージョンは9.0です。 https://tomcat.apache.org/ を見ると、2020/12/25 現在 Apache Tomcat 9.0.41 Apache Tomcat 8.5.61 Apache Tomcat 7.0.107 が更新されています。2011/1にリリースされたTomcat7.0もようやく2021/3/31にEOLを迎えると発表されています。 http://tomcat.apache.org/tomcat-70-eol.html いつかは、いま運用保守したり開発しているアプリケーションをTomcat10に乗り換える必要がありますが、ここに頭の痛い問題があります。Jakrta EE 9 のパッケ

よく知らないアプリケーションの性能と戦う、という状況(再掲) 私が設計したわけでもなく開発したわけでもなく、レビュー参加とかで辛うじて全体はわけるけど、いまからソース見る時間もないし、開発した方は性能面の対処が覚束ない。突然性能面で火を噴いてなぜか自分が召喚されて2~3時間でどうにかしたい、という闇な状況にどういうふうに対応していたっけ自分、というのを経験則100%で書いてみようと思います。 前編・中編はこちら。 よく知らないアプリケーションの性能と戦わないといけないときの防衛術（前編） https://qiita.com/nfujita55a/items/3760cd099ca890f5a4d4 よく知らないアプリケーションの性能と戦わないといけないときの防衛術（中編） https://qiita.com/nfujita55a/items/555350e61b73db3a2b8c この後

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 1 98508 360384 135488 2872176 0 0 29952 148 758 610 7 1 75 17 0 1 0 98508 379232 135496 2853328 0 0 24564 0 690 556 6 1 75 19 0 0 1 98508 397460 135504 2835056 0 0 20344 0 716 572 5 1 75 20 0 0 1 98508 393880 135512 2838664 0 0 36316 0 859 705 9 1 75 16 0 0 1

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※この投稿について 前半でIPレピュテーションとは何か？という説明をしていますので、未読の方は一読することをお勧めします。 メールというインターネットの闇とIPレピュテーション（だけど重要）(前編) https://qiita.com/nfujita55a/items/5848fcfbbe6cbf7d98c3 この後半では、IPレピュテーションをよくしてメールを滞りなく送りたいときの光要素と闇要素を、光→闇の順に書いています。 メールを円滑に送るためIPレピュテーションを高めたい、何ができるの（光要素） まずは、IPレピュテーションを含

メールというインターネットの闇 ※この文書では メール＝e-mail です メールというと哀れみの目線がエンジニアからとんでくる昨今 わたしのお仕事の半分以上はメール関連なのですが、ITなエンジニアの集まりで「メールのお仕事してます」というと うわ、レガシーな領域の人なんだ！ メールってまだ仕事になるの？ スパム屋さんかな？ と、マイナスというか哀れみな目線をいただくことがあります。 大きな本屋さんに行ってみると分かるのですが（例えば、丸の内オアゾの丸善さんとか）、メールの書き方など仕事でメールをどう活かすかみたいな本はありますが、システム的な見地の送受信に関する本は、ここ5年出版されていません。 たぶん、Postfix実践入門(2010/9/3発売)が一番新しい思います。 https://www.amazon.co.jp/Postfix%E5%AE%9F%E8%B7%B5%E5%85%A

頭の痛い表ができました。 いまどき「インターネット画像参照」NGなメール環境は世界的に珍しいのですが、さらに、メールアドレスだけ見ても「インターネット画像参照」できるかは分からないのです。だって、メールアドレスを見ても相手がどんな受信環境かは分からないですから。 ソフトバンクのiPhone用メールアドレス @i.softbank.jp は例外で、これだけは「インターネット画像参照」OK確定です。 携帯キャリアメールアドレスの「インターネット画像参照」NGな環境に、「インターネット画像参照」するHTMLメールを送ると、真っ白になったり、「×」画像がたくさん並んだ表示になります。 「えっ？テキストとHTML両方を含んだマルチパートで送るんだから、不都合なHTMLパートではなくテキストパートが表示されればいいのに」と思った方は鋭い。マルチパートはそのような目的のためにあるものですが、携帯キャリア

この記事は、メール Advent Calendar 2018 8日目のものです。 そもそも、テストのメール配信事故ってなに？ 様々なインターネット用のシステムで欠かせないメールの送信。テストでも実施すると思います。ところが、不用意なテストの実施で送ってはいけない先にメールを送ったり、テストの不足によって本番になってメールを送信できなかったり、とトラブルが発生することがあります。これをテストのメール配信事故と呼んでみます。 ※もっと良い呼び名があるかもしれない。 下記のようなパターンがあるかと思います。 第三者に送信 例えば、ECサイトのテスト環境の会員データを hoge@abc.com とか fuga@test.com など、適当なメールアドレスで作ります。テスト環境で決済するたびに hoge@abc.com に決済完了のメールが飛んでいくのですが、abc.com はアメリカ ABC Ne