Mail Auth Info Viewer

A Thunderbird add-on to visualize email authentication, sender identity, and delivery routes. メールの認証情報、送信者の身元、および送達経路を可視化するThunderbirdアドオンです。

Mail Auth Info Viewer is a powerful Thunderbird add-on designed to combat sophisticated phishing and "display name" spoofing. It analyzes message headers and body content locally, presenting a clear, color-coded dashboard showing sender alignment, authentication results (SPF, DKIM, DMARC), phishing link detection, and delivery routes with time delays directly on the message view.

Mail Auth Info Viewer は、巧妙なフィッシング詐欺や「表示名（名乗り）」の偽装に対抗するために設計された強力なThunderbirdアドオンです。ローカルでメールヘッダと本文を解析し、送信者のアライメント、認証結果（SPF, DKIM, DMARC）、フィッシングリンク検知、および遅延時間を含む送達経路を、色分けされた分かりやすいダッシュボードでメッセージ画面上に直接表示します。

---

📸 Screenshots / スクリーンショット

✅ Fully Authenticated (認証成功)

The dashboard always starts collapsed to save screen space, showing only the status badge and verdict tags. ダッシュボードは常に折りたたまれた状態で表示され、ステータスバッジと判定タグのみが見えます。

Click to expand the full dashboard with authentication details, delivery route, ARC chain, and link safety analysis. クリックで認証詳細・送達経路・ARCチェーン・リンク安全性分析の完全なダッシュボードを展開します。

⚠️ Suspicious Link Detected (不審なリンク検出)

Authentication passes, but the email body contains a link indicator — either a genuinely suspicious pattern (IP-address link, IDN homograph, URL shortener) or simply an untrusted external domain. The badge shows AUTH PASS in orange with either a "Suspicious link" or "Untrusted link domain" verdict tag, depending on the nature of the finding. 認証は成功していますが、メール本文にリンク指標が含まれています — 本質的に怪しいパターン（IPアドレスリンク、IDNホモグラフ、短縮URL）か、単に未信頼の外部ドメインかのいずれかです。バッジはオレンジの認証成功に、指標の性質に応じて「不審なリンク」または「未信頼のリンクドメイン」の判定理由タグが付きます。

❌ Authentication Failed (認証失敗)

SPF, DKIM, or DMARC has explicitly failed. The red badge with individual verdict reason tags shows exactly what went wrong. SPF・DKIM・DMARCのいずれかが明確に失敗しています。赤いバッジに個別の判定理由タグが表示され、何が問題かが一目瞭然です。

💀 Link Mismatch Detected (リンク偽装検出)

Deceptive link text detected — the displayed URL differs from the actual destination. The flashing LINK MISMATCH badge is the highest severity level, overriding all other verdicts. リンクテキスト偽装を検出 — 表示URLと実際のリンク先が異なります。点滅するLINK MISMATCHバッジは最高レベルの深刻度で、他のすべての判定を上書きします。

---

🌟 Key Features / 主な機能

• Shadow DOM CSS Isolation: The dashboard is encapsulated in a closed Shadow DOM, completely preventing HTML email CSS (e.g., * { font-size: 20px !important; }) from contaminating the add-on display. The Shadow DOM host itself is placed directly under <html> (just before <body>) rather than inside the email's body, and its layout properties (display, width, max-width, margin, position, transform, etc.) are pinned with inline !important. This keeps the dashboard at full width even when an email constrains its body — for example, malformed HTML that contains a stray <body style="max-width:480px"> inside a table, whose attributes the HTML parser merges into the real body element — without altering how the email itself is displayed.
  • Shadow DOM CSS隔離: ダッシュボードをclosed Shadow DOMでカプセル化し、HTMLメールのCSSがアドオン表示に影響することを完全に防止します。Shadow DOM のホスト要素自体もメールの body の中ではなく <html> 直下（<body> の直前）に配置し、レイアウトに関わる指定（display・width・max-width・margin・position・transform など）をインラインの !important で固定しています。これにより、メールが body の幅を制限している場合——例えばテーブル内に <body style="max-width:480px"> を含む崩れた HTML で、HTML の構文解析ルールによりその属性が本来の body 要素に合流するケース——でも、メール自体の表示を変えることなくダッシュボードを全幅で表示します。
• Per-Tab Message Binding: Each dashboard analyzes the message displayed in its own tab or window. A message opened in a background tab is never analyzed with the headers of the message in the tab you are looking at, and if the tab cannot be identified, no dashboard is shown rather than one for a different message.
  • タブごとのメール対応付け: 各ダッシュボードは、自分が表示されているタブ・ウィンドウのメールを解析します。背景タブで開いたメールが、いま見ているタブのメールのヘッダで解析されることはありません。タブを特定できない場合は、別のメールの判定を出すのではなく、ダッシュボードを表示しません。
• Always-Collapsed Panel: The dashboard always starts collapsed for every email, keeping the status badge and verdict reason tags visible at a glance without consuming screen space. Click to expand for full details.
  • 常時折りたたみパネル: ダッシュボードは全メールで折りたたまれた状態で表示され、ステータスバッジと判定理由タグのみが見える省スペース設計です。クリックで詳細を展開できます。
• Manual Toggle: You can expand or collapse the detail view at any time by clicking the header bar.
  • 手動開閉: ヘッダーバーをクリックすることで、いつでも詳細ビューの展開・折りたたみを切り替えられます。
• Collapsible Detail Cards: SPF, DKIM, and DMARC cards show status at a glance with expandable details on click. Link Safety Analysis shows warnings upfront with collapsible domain/resource lists (auto-expanded when any finding is detected).
  • 折りたたみ式詳細カード: SPF・DKIM・DMARCカードはクリックで詳細を展開。リンク安全性分析は警告を常時表示し、ドメイン/リソース一覧は折りたたみ（指標検出時は自動展開）。

---

🔒 Security Verdict Philosophy / セキュリティ判定の思想

This add-on is designed for mail administrators and security-conscious users who want to verify that email authentication is properly configured. The verdict logic is intentionally strict:

このアドオンは、メール認証が正しく設定されているかを確認したいメール管理者やセキュリティ意識の高いユーザー向けに設計されています。判定ロジックは意図的に厳格です:

Badge Hierarchy / バッジ階層

Badge	Condition	条件
💀 LOOKALIKE DOMAIN	The sender's own domain imitates another domain with look-alike characters (mixed scripts, another script's Latin-looking letters, look-alike Latin characters, or resemblance to a trusted domain), regardless of authentication results.	送信者自身のドメインが、紛らわしい文字（文字種の混在、ラテン文字に見える別の文字種の字、紛らわしいラテン文字、信頼済みドメインへの酷似）で別のドメインになりすましている。認証結果に関係なく判定。
💀 LINK MISMATCH	Deceptive link text (displayed URL differs from actual destination), a link to a look-alike of the sender's or a trusted domain, dangerous URI schemes, or embedded HTML forms detected. Not suppressible by the trust list.	リンク先相違（表示URLと実際のリンク先が不一致）・送信者や信頼済みドメインに似せた別ドメインへのリンク・危険なURIスキーム・HTMLフォーム埋め込みを検出。信頼リストでは抑制されない。
💀 DISGUISED TEXT	A text direction override (RLO/LRO) reorders the displayed characters in the display name, subject, body or an attachment file name, regardless of authentication results.	表示名・件名・本文・添付ファイル名で、双方向テキストの上書き（RLO/LRO）が表示の並びを入れ替えている。認証結果に関係なく判定。
❌ AUTH FAILED	SPF, DKIM, or DMARC explicitly failed	SPF・DKIM・DMARCのいずれかが明示的にfail
⚠️ AUTH PASS	DMARC passed but other issues (alignment, spoofing, suspicious links including QR codes pointing to another domain, untrusted link domains, original sender not verified by a forwarding service, look-alike Reply-To domain, Subject not signed while DMARC relies on DKIM alone)	DMARC passだがアライメント・なりすまし・不審リンク（別ドメインを指す QR コードを含む）・未信頼リンクドメイン・転送サービス経由の元送信者未検証・Reply-To ドメインの偽装・DKIM のみで DMARC pass なのに Subject が署名対象外等の問題あり
⚠️ PARTIAL	Some auth passed but DMARC not passed	一部認証passだがDMARC未通過
✅ AUTH PASS	All checks passed — safe	すべてのチェックに合格 — 安全

Link Safety Severity Levels / リンク安全性の深刻度レベル

v1.1.6 introduces a four-tier categorization of link indicators. Each tier has a distinct severity and user action path:

v1.1.6 ではリンク指標を4段階に分類しています。それぞれ深刻度とユーザーが取るべきアクションが異なります:

Level	Examples	Meaning	Resolvable by whitelisting?
critical	Deceptive link text, links to look-alikes of the sender's or a trusted domain, javascript:/data: URIs, embedded forms	Confirmed phishing indicators (promotes to LINK MISMATCH badge)	No
suspicious	IP-address links, IDN links (homographs flagged as such), URL shorteners, QR codes pointing to a domain other than the sender's	Patterns inherently risky regardless of who sent them	No
untrusted	All links external, main CTA external	Simply unknown to the extension — recipient hasn't trusted the domain yet	Yes (add to trusted domains)
privacy	Tracking pixels	Privacy notice only, not a phishing indicator	N/A (informational)

レベル	例	意味	ホワイトリストで解消可能か
critical	リンクテキスト偽装、送信者や信頼済みドメインに似せた別ドメインへのリンク、javascript:/data: URI、フォーム埋め込み	確度の高いフィッシング指標（LINK MISMATCHバッジに昇格）	不可
suspicious	IPアドレスリンク、IDN リンク（ホモグラフはその旨を明示）、短縮URL、送信者と別のドメインを指す QR コード	送信者に関係なく本質的に怪しい書式	不可
untrusted	全リンク外部、メインCTA外部	単にアドオンにとって未知なだけ — ユーザーがまだ信頼表明していない	可（信頼済みドメインに追加）
privacy	トラッキングピクセル	プライバシー上の注意喚起。フィッシング指標ではない	該当なし（情報提供）

Green (✅ AUTH PASS) Requirements / グリーン条件

• SPF pass, DKIM pass, and DMARC pass
• At least one DMARC alignment (SPF or DKIM) with Header From — alignment only counts when the underlying auth method passed
• No display name spoofing detected
• The sender's domain does not use look-alike characters and does not resemble a trusted domain (homograph)
• The Reply-To domain, if any, does not use look-alike characters and does not resemble the sender's domain
• No critical, suspicious, or untrusted link indicators detected in email body (QR codes in images contained in the message are read and checked as links)
• No text direction override (RLO/LRO) that reorders the displayed characters in the display name, subject, body or attachment file names
• If a forwarding service recorded the original message's authentication (e.g. addy.io X-AnonAddy-Authentication-Results), the original sender's DMARC must be pass
• If DMARC passes only through DKIM alignment (SPF not aligned), an aligned passing DKIM signature must cover Subject (otherwise the message could be a DKIM replay with a swapped subject)
• Note: When DMARC passes but the message is not green for another reason, the badge is ⚠️ AUTH PASS even if the envelope sender is empty (Return-Path: <>) or unavailable, because DMARC validates the header From regardless of the envelope sender
• Note: Envelope domain mismatch alone does NOT block green when DMARC pass with alignment is satisfied (supports legitimate third-party sending services like SendGrid)
• Note: DMARC p=none does NOT block green (authentication itself succeeded), but the DMARC card highlights the weak policy in red for administrators
• Note: Authentication strength findings (sub-2048-bit DKIM keys, rsa-sha1, l= partial body signing, unsigned Subject/Content-Type/Reply-To, sp=none, pct<100) likewise do NOT affect the badge — they appear inside the DKIM/DMARC cards as administrator guidance, following the same treatment as p=none. The only exception is an unsigned Subject while DMARC relies on DKIM alone (see above)
• Note: Tracking pixels (privacy level) do NOT block green (ubiquitous in legitimate marketing emails), but are reported in the Link Safety Analysis card with 🕵️ markers
• Note: Untrusted link indicators remain orange (not green) until the user explicitly trusts the domain — the extension does not assume legitimacy for any unknown external domain
• Note: A DKIM-Signature header without a verification result from the receiving server (e.g. servers that record results only in SpamAssassin's ) is shown as "signed (unverified)" in the DKIM card, but DKIM still counts as and blocks green — SpamAssassin headers are not trusted as an authentication source

---

• SPF pass、DKIM pass、かつ DMARC pass
• SPFまたはDKIMの少なくとも一方がHeader Fromとアライメント（アライメントは対応する認証がpassの場合のみ成立）
• 表示名なりすましが検知されていないこと
• 送信者のドメインが紛らわしい文字を使っておらず、信頼済みドメインにも酷似していないこと（ホモグラフ）
• Reply-To がある場合、そのドメインが紛らわしい文字を使っておらず、送信者のドメインにも酷似していないこと
• メール本文に critical・suspicious・untrusted のいずれのリンク指標も検知されていないこと（メールに含まれる画像の QR コードも読み取り、リンクとして検査する）
• 表示名・件名・本文・添付ファイル名に、表示の並びを入れ替える双方向テキストの上書き（RLO/LRO）がないこと
• 転送サービスが元メールの認証結果を記録している場合（例: addy.io の X-AnonAddy-Authentication-Results）、元送信者の DMARC が pass であること
• DMARC が DKIM アライメントだけで pass している場合（SPF 非アライン）、アラインして pass した DKIM 署名が Subject を署名対象に含むこと（含まない場合、件名を差し替えた DKIM リプレイの可能性がある）
• 注: DMARC が pass していて他の理由でグリーンにならない場合、エンベロープ送信者が空（Return-Path: <>）や取得できないときでも ⚠️ AUTH PASS を表示する（DMARC はエンベロープ送信者に関係なくヘッダ From を検証するため）
• 注: DMARCがpassかつアライメント成立時は、エンベロープドメイン不一致のみではグリーンを阻害しない（SendGrid等の正当な外部配信サービスに対応）
• 注: DMARC p=none はグリーンを阻害しない（認証自体は成功）が、DMARCカード内でポリシーを赤色表示して管理者に改善を促す
• 注: 認証強度の所見（2048ビット未満のDKIM鍵・rsa-sha1・l=部分署名・Subject/Content-Type/Reply-To の未署名・sp=none・pct<100）も同様にバッジ判定には影響しない — p=none と同じ扱いで、DKIM/DMARCカード内に管理者向け警告として表示する。唯一の例外は、DMARC が DKIM だけに依存しているときの Subject の未署名（上記）
• 注: トラッキングピクセル（privacyレベル）はグリーンを阻害しない（正規のマーケティングメールにほぼ必ず含まれるため）が、リンク安全性分析カード内で🕵️マーカー付きで報告する
• 注: 未信頼リンク指標はユーザーが明示的にドメインを信頼するまでオレンジのまま（グリーンにはならない） — アドオンは未知の外部ドメインに対し正当性を仮定しない
• 注: 受信サーバーの検証結果が無い DKIM-Signature ヘッダ（SpamAssassin の X-Spam-Status にしか結果を記録しないサーバー等）は DKIM カードで「署名あり（未検証）」と表示するが、DKIM は none として扱いグリーンを阻害する — SpamAssassin ヘッダは認証結果の情報源として信頼しない

The principle is: only unavoidable situations (e.g., third-party infrastructure) get a green badge; anything fixable by the domain administrator or resolvable by the recipient (via trust whitelisting) should be flagged.

原則: 業者や設定を変えてもどうしようもない不可抗力だけをグリーンに。管理者の努力で解決できる不備、または受信者の信頼表明で解消できる未知ドメインは警告対象にする。

DMARC Policy Color Coding / DMARCポリシーの色分け

Policy	Color	Meaning
reject	🔵 Blue	Strong protection — rejects unauthenticated mail
quarantine	🟠 Orange	Partial protection — quarantines suspicious mail
none	🔴 Red	No protection — a fixable configuration weakness

ポリシー	色	意味
reject	🔵 ブルー	強い保護 — 未認証メールを拒否
quarantine	🟠 オレンジ	部分的保護 — 不審なメールを隔離
none	🔴 レッド	保護なし — 設定変更で解決できる不備

The policy is read from the receiving server's Authentication-Results: the published p= value when the server records it in a comment (for example (p=REJECT sp=NONE dis=NONE)), otherwise the policy.dmarc= property defined in RFC 7489 (for example GMX writes dmarc=pass header.from=example.com policy.dmarc=none). policy.dmarc is the policy evaluated after sp= and pct= are applied, so p= takes precedence when both are present.

ポリシーは受信サーバーの Authentication-Results から読み取ります。サーバーがコメントに公開値 p= を記録していればそれを（例: (p=REJECT sp=NONE dis=NONE)）、無ければ RFC 7489 で定義された policy.dmarc= プロパティを使います（例: GMX は dmarc=pass header.from=example.com policy.dmarc=none と記録します）。policy.dmarc は sp= や pct= を適用した後に評価されたポリシーなので、両方ある場合は p= を優先します。

---

📥 Installation / インストール

Download from ATN (Thunderbird Add-ons)

You can also download the latest release directly from GitHub: GitHubのReleasesからも最新版をダウンロードできます: GitHub Releases

---

🏗️ Building from Source / ソースからのビルド

Requires jsQR in the lib/ directory (not included in the repository; see VENDOR.md and lib/README.md).

lib/ ディレクトリに jsQR が必要です（リポジトリには含めていません。VENDOR.md と lib/README.md を参照）。

npm install
cp node_modules/jsqr/dist/jsQR.js lib/
cp node_modules/jsqr/LICENSE lib/jsQR-LICENSE.txt

Windows (PowerShell)

pwsh -NoProfile -ExecutionPolicy Bypass -File build.ps1

Linux / macOS (Bash)

chmod +x build.sh
./build.sh

Both scripts read the version from manifest.json, stage the required files including _locales/, lib/ and VENDOR.md (stopping with an error if lib/jsQR.js is missing), produce a .xpi package in .release/, and generate a SHA-256 checksum file.

---

🏛️ Architecture / アーキテクチャ

manifest.json           Extension manifest with i18n support
background.js           Registers content scripts, handles message API (full message, raw header block for header-order verification together with the raw `name`/`filename` lines of each MIME part for the RLO/LRO check, and QR code reading from `data:` URI images and image parts via messages.getAttachmentFile + createImageBitmap/canvas, decoded in qr_worker.js with a per-image time limit), always for the message displayed in the requesting tab
qr_worker.js            Worker that runs the QR decoder on pixel data, so that a slow or pathological image can be cut off by terminating the worker without blocking the background page
VENDOR.md               Third-party library sources, versions and checksums
lib/
├─ jsQR.js              QR code decoder (jsQR 1.4.0, Apache-2.0, unmodified; user-provided), loaded only by qr_worker.js when a message has images
└─ jsQR-LICENSE.txt     License of jsQR (user-provided)
psl_data.js             Public Suffix List data + getOrganizationalDomain()
options.html + options.js  Trusted link domains management (add/remove/import/export) + compact display mode toggle
messagedisplay.js       Main logic — 9 core functions:
│
├─ parseEnvelope()          Address extraction, PSL-based alignment (domains normalized to ASCII/Punycode), mailing list, display name spoof & Reply-To mismatch detection, sender and Reply-To homograph detection (mixed scripts, whole-script look-alikes, look-alike Latin characters, skeleton match against trusted domains)
├─ parseAuthResults()       Auth parsing with authserv-id filtering & display (exact name match to the boundary host found by a top-down walk that stops at the first hop not clearly internal; every such header above the boundary Received, or only the first one directly below it with a same-name ARC-AR above as evidence, is trusted; Received-SPF used only from above the boundary), multi-DKIM with header.d/header.i fallback, per-signature alignment, Received-SPF fallback, RFC 8601 comment-aware semicolon splitting (preserves `header.d=` etc. when key-info such as `(2048-bit key; unprotected)` appears in DKIM results), authentication strength detection (sub-2048-bit DKIM keys from A-R comments, rsa-sha1, `l=` partial body signing, DMARC `sp=none` / `pct<100` from A-R comments), DKIM signed-header coverage from the `h=` tag of each aligned passing signature (matched by domain and selector; Subject/Content-Type always expected, Reply-To when present; only Subject gates the verdict), provider-specific ingress detection for Microsoft 365 / Exchange Online, mailbox.org, Hostpoint and GMX (contiguous provider hop walk to the inbound entry point, passing through Exim self-handoff hops for Hostpoint, trusting only the topmost provider-format A-R after verifying its position in the raw header order, plus queue-ID binding for mailbox.org; name-based authserv-id matching is skipped once a provider route is found, so forged A-R naming the boundary host are never trusted) and Microsoft 365 internal-delivery detection, forwarding-service original-sender results (`X-AnonAddy-Authentication-Results`), `DKIM-Signature` domains/selectors left unverified by the receiving server (display only)
├─ parseRoute()             Delivery route from Received headers with IP classification (including Exchange-style parenthesized IPv6 such as `(2001:db8::1)`) and per-hop TLS/encryption status extraction (TLS version, cipher suite, plaintext-protocol detection)
├─ parseArcChain()          ARC chain parsing (RFC 8617)
├─ parseMessageBody()       MIME tree traversal to extract HTML/text body content
├─ analyzeLinkSafety()      Four-tier phishing detection (critical/suspicious/untrusted/privacy): deceptive text (hosts compared in ASCII form), look-alike domains of the sender or trusted domains (skeleton match, links and text URLs), dangerous schemes, forms, IP/IDN/shortener links (aggregated per type; IDN shown as Unicode (ASCII), homographs distinguished), text URLs (extracted with `<br>`/block boundaries as separators, ended at Japanese punctuation and where the host's last label switches from ASCII to non-ASCII), QR code contents (URLs checked like links; another organizational domain is suspicious and not suppressible by the trust list; non-URL contents counted only), all-external & CTA analysis, tracking pixels, resource domains, trusted domain whitelist, external link domain collection for one-click trust
├─ determineSecurityStatus()  5-tier verdict (phishing > auth failed > auth pass warning > partial > auth pass) with auth-gated alignment, per-reason tags including "link_untrusted", "relay_original_unverified", "dkim_replay_risk" (Subject unsigned while DMARC relies on DKIM alone), "sender_homograph" (promoted to the LOOKALIKE DOMAIN phishing badge), "reply_to_homograph" and "bidi_override" (a reordering RLO/LRO found by detectBidiOverrideSpoofing() in the display name, subject, body or attachment names — header values decoded from the raw headers by decodeMimeWords()/extractMimeFileNames() because Thunderbird strips the control characters from its decoded values — promoted to the DISGUISED TEXT phishing badge), and privacy-level findings excluded from verdict
├─ generateReportText()     Generates structured plain-text analysis report with all findings for clipboard export
└─ buildUI()                Shadow DOM isolated, i18n'd, dark-mode-aware rendering with always-collapsed panel, optional compact display mode (reduced info-bar height), collapsible auth cards (full RFC 8601 properties), per-signature DKIM display ("signed (unverified)" when only a `DKIM-Signature` header is present), authentication strength warnings inside DKIM/DMARC cards, TLS status column in delivery route table with visual indicators (🔒⚠️🔓), collapsible link safety with severity-aware styling (critical/suspicious/untrusted/privacy), inline Trust shortcut on untrusted findings when a single external domain is identified, copy-to-clipboard button in header, verdict reason tags

_locales/
├─ en/messages.json     English (default)
├─ ja/messages.json     日本語
├─ fr/messages.json     Français
├─ de/messages.json     Deutsch
├─ es/messages.json     Español
├─ ar/messages.json     العربية
├─ ko/messages.json     한국어
├─ zh_TW/messages.json  繁體中文
├─ zh_CN/messages.json  简体中文
├─ pt_BR/messages.json  Português (Brasil)
├─ ru/messages.json     Русский
└─ it/messages.json     Italiano

Domain Alignment: Organizational Domain (RFC 7489)

Previous versions used simple suffix matching (endsWith), which could produce false positives with multi-level TLDs (e.g., evil.co.jp matching legit.co.jp) and false negatives with deep subdomains (e.g., a.b.google.com not matching c.google.com).

v1.0.8+ bundles a curated Public Suffix List (psl_data.js) covering 60+ countries to extract the Organizational Domain per RFC 7489. Both the Header-From domain and Envelope-From domain are reduced to their organizational domain before comparison.

---

📄 License / ライセンス

This project is licensed under the GNU General Public License v3.0.

The released add-on bundles jsQR 1.4.0 (lib/jsQR.js, an unmodified copy of dist/jsQR.js from the npm package; source and checksum in VENDOR.md), licensed under the Apache License 2.0 (a copy is included as lib/jsQR-LICENSE.txt).

配布するアドオンには jsQR 1.4.0（lib/jsQR.js。npm パッケージの dist/jsQR.js を無改変で同梱。入手元とチェックサムは VENDOR.md）を同梱しています。ライセンスは Apache License 2.0 で、その写しを lib/jsQR-LICENSE.txt として同梱しています。

Copyright (C) 2025 Shota (SHOWTIME)