はてなブックマーク

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

※この投稿について 前半でIPレピュテーションとは何か？という説明をしていますので、未読の方は一読することをお勧めします。 メールというインターネットの闇とIPレピュテーション（だけど重要）(前編) https://qiita.com/nfujita55a/items/5848fcfbbe6cbf7d98c3 この後半では、IPレピュテーションをよくしてメールを滞りなく送りたいときの光要素と闇要素を、光→闇の順に書いています。 メールを円滑に送るためIPレピュテーションを高めたい、何ができるの（光要素） まずは、IPレピュテーションを含めて、メール送信を円滑に行うためにすることが大別して3つくらいあると思います。 送信ドメイン認証する いわゆるSPFやDKIMです（最近はこれにDMARCが加わる）。SPFなら送信側が「DNSを使ってこのEnvelope-FromのメールはこのIPアドレス帯

と、この例では3回の通信がなされます。1が終わったら 2、2が終わったら 3とバケツリレーされます。 ※3の後に、メールボックスにあるメールをWebで見たりPOP3などでメーラーがメールを取得したりする このSMTPを使用したメールのバケツリレーの様相は、ブラウザとWebサーバーが End to End なHTTP(S)と大きく異なります（HTTPにもプロキシはあって通信が多段になることはありますが、バケツリレーではない）。 「IPレピュテーション」という概念は、上の表の2の通信、インターネット越しに送る側と受け取る側がSMTP通信するところに係わります。 レピュテーション=評価、です。メールにおけるIPレピュテーションとは、受け取る側の送る側の送信元IPアドレスに対する評価 です。この評価によって、受け取る側のメールサーバーは メールを速やかに受け取り受信者の受信箱に配送する メールを受

頭の痛い表ができました。 いまどき「インターネット画像参照」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