sync: auto-sync from GURU-5070 at 2026-06-26 04:15:16

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-26 04:15:16
This commit is contained in:
2026-06-26 04:16:30 -07:00
parent 1d99dc93ed
commit 79789a8815
3 changed files with 63 additions and 2 deletions

View File

@@ -9,8 +9,8 @@ metadata:
Mailboxes: `bt@tedards.net` (Bill, owner), `y226@tedards.net` (Yvonne). Bill files mail by legal matter number into deep Inbox subfolders (e.g. "8445 BOLTON [Farmers TX]", "BOLTON, Lindsay"); a top-level "DUPLICATE need to check" folder (~11,864 items) is junk from a **botched mail import years ago** — ignore it.
Security gaps found 2026-06-25: tenant was **dehydrated** (never customized) — ran `Enable-OrganizationCustomization` (irreversible, one-time) then `Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true` (both HTTP 200). Read-back still showed `false` immediately after — propagation lag; verify later that it flipped to true and that Search-UnifiedAuditLog starts returning data (ingestion lag up to ~60min). Before this, UAL was OFF so there was no queryable audit trail for the bt@ deletions. bt@ mailbox syncs to **9 devices** (5 aging iOS Mail/EAS, a Mac Outlook, 2 Outlook-for-iOS added 2026-06-25). Per-mailbox AuditEnabled=true but not queryable since Search-MailboxAuditLog is deprecated + UAL ingestion off.
Security gaps found 2026-06-25: tenant was **dehydrated** (never customized) — ran `Enable-OrganizationCustomization` (irreversible, one-time) then `Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true` (both HTTP 200). Flag later confirmed `true`, BUT app-only `Search-UnifiedAuditLog` (via exchange-op InvokeCommand) returns **zero** records for this tenant even hours after ingestion — proven against ~11,800 known dedup MoveToDeletedItems events AND a tenant-wide `RecordType=ExchangeItem` query (both 0). Conclusion: **app-only UAL cannot read mailbox-item records here** — do NOT rely on it for mailbox-item attribution; use device-statistics sync-time + EWS bait timing instead (how the bt@ culprit was found). Before enabling, UAL was OFF entirely. bt@ mailbox syncs to **9 devices** (5 aging iOS Mail/EAS, a Mac Outlook, 2 Outlook-for-iOS added 2026-06-25). Per-mailbox AuditEnabled=true but not queryable since Search-MailboxAuditLog is deprecated + UAL ingestion off.
EXO access: use the `exchange-op` tier, not `investigator-exo` — see [[reference_investigator_exo_manageasapp_gap]]. Ongoing matter: Wirechunk/agencyzoomify.com DMARC + the bt@ "delete folder" deletions (ticket #5070, #32228).
**bt@ "delete folder" mystery — SOLVED 2026-06-26 (root cause = client-side device auto-delete).** Lindsay's (lindsay@agencyzoomify.com) Bolton-thread mail auto-moves to Deleted Items. Proven via bait test: restored the 3 msgs to Inbox via EWS, all 3 were re-deleted to Deleted Items at the identical instant (02:54:24Z) — automated, not human. Eliminated: inbox rules (incl. hidden), sweep rules, transport rules, forwarding, delegates, folder perms, and any OAuth app with Mail.ReadWrite (none exist; admin apps only have MailboxSettings.ReadWrite/Mail.Send/Exchange.Manage). Only mail-MOVE capability present = Apple native iOS Mail (appId 32f67a9b, EAS+EWS) + Outlook-for-iOS. 5 Apple/Outlook-iOS devices push-synced within 8s of the re-delete; all activity from Bill's single home IP 69.242.239.94 (NOT a compromise). Bisection test (2026-06-26 03:23): removed/disabled Outlook-for-iOS, re-moved msgs to Inbox — re-deleted again in 4s, AND the re-delete (03:23:31Z) fired BEFORE the Outlook-iOS clients re-synced (03:23:38/48) → **Outlook-iOS EXONERATED; culprit = a NATIVE iOS Mail (EAS) device** with on-device "Block Sender → Move to Trash" for lindsay@agencyzoomify.com. Narrowed to the two devices syncing at the delete instant: **iPhone16C2** and **iPad15C8** (Bill's current iPhone + iPad). On-device block list is NOT server-readable — Bill must remove Lindsay from Blocked on those devices (iOS Settings → Mail → Blocked). Note: Set-CASMailbox OutlookMobileEnabled has heavy propagation lag (didn't enforce during the test window); same lag seen on Set-AdminAuditLogConfig. To pin the exact one device, block one EAS DeviceId and re-bait. Removed 2 Outlook-iOS partnerships (they auto-re-add) + toggled OutlookMobileEnabled (reverted to true, queued).
**bt@ "delete folder" mystery — SOLVED 2026-06-26 (root cause = client-side device auto-delete).** Lindsay's (lindsay@agencyzoomify.com) Bolton-thread mail auto-moves to Deleted Items. Proven via bait test: restored the 3 msgs to Inbox via EWS, all 3 were re-deleted to Deleted Items at the identical instant (02:54:24Z) — automated, not human. Eliminated: inbox rules (incl. hidden), sweep rules, transport rules, forwarding, delegates, folder perms, and any OAuth app with Mail.ReadWrite (none exist; admin apps only have MailboxSettings.ReadWrite/Mail.Send/Exchange.Manage). Only mail-MOVE capability present = Apple native iOS Mail (appId 32f67a9b, EAS+EWS) + Outlook-for-iOS. 5 Apple/Outlook-iOS devices push-synced within 8s of the re-delete; all activity from Bill's single home IP 69.242.239.94 (NOT a compromise). Bisection test (2026-06-26 03:23): removed/disabled Outlook-for-iOS, re-moved msgs to Inbox — re-deleted again in 4s, AND the re-delete (03:23:31Z) fired BEFORE the Outlook-iOS clients re-synced (03:23:38/48) → **Outlook-iOS EXONERATED; culprit = a NATIVE iOS Mail (EAS) device** with on-device "Block Sender → Move to Trash" for lindsay@agencyzoomify.com. Narrowed to the two devices syncing at the delete instant: **iPhone16C2** and **iPad15C8** (Bill's current iPhone + iPad). On-device block list is NOT server-readable — Bill must remove Lindsay from Blocked on those devices (iOS Settings → Mail → Blocked). Note: Set-CASMailbox OutlookMobileEnabled has heavy propagation lag (didn't enforce during the test window); same lag seen on Set-AdminAuditLogConfig. To pin the exact one device, block one EAS DeviceId and re-bait. Removed 2 Outlook-iOS partnerships (they auto-re-add) + toggled OutlookMobileEnabled (reverted to true, queued). **CONFIRMED 2026-06-26 by Yvonne: found Bolton's blocked contact on Bill's NEW iPad (= iPad15C8); unblocked on phone + new iPad, checking other iPads — validates the device-block root cause.**