# hermes-mail-browser -- /search ne filtre pas par date reelle de reception

**Date** : 30/07/2026
**Contexte** : tentative d estimation du volume de mails TT depuis 2024 (projet nyora-notes-TT / RAG personnel mail).

## Constat

Le endpoint `/search?q=...` de hermes-mail-browser fait du matching texte brut sur la requete OWA,
pas un filtre sur la date reelle de reception. Test : q=received:2024 a retourne des mails recus
en 2025 (12/08/2025, 22/09/2025, 26/02/2025, 31/01/2025) simplement parce que 2024 apparaissait
dans le sujet (numeros d AO type AO 76/2024, N066/2024). OWA traite received:2024 comme un
terme de recherche libre dans ce contexte, pas comme un operateur de plage de dates fiable via cette API.

## Autre limite observee

/folders retourne count:0, folders:[] ou time out -- coherent avec le bug de staleness deja
documente le 24/07 (liste virtualisee OWA non remontee sans navigation fraiche forcee). Pas de comptage
fiable par dossier via cette route en l etat.

## Cout reel

Chaque appel /search prend ~35-40s pour 5 resultats (automatisation navigateur reelle sur OWA,
pas une API rapide). Inadapte a une iteration/pagination pour estimer un volume total -- risque de
degrader ou perdre la session authentifiee live (auth manuelle noVNC, MFA).

## Recommandation

Pour un comptage de volume par dossier/periode : lire directement le compteur natif OWA (volet dossiers,
ou Filtrer > par date) via noVNC (port 8810) -- 30 secondes, fiable, zero risque sur la session.
Ne pas utiliser /search avec un mot-cle annee en attendant un filtre de date reel.

## A faire si le filtre date devient necessaire

Verifier si OWA supporte un operateur de date fiable dans son moteur de recherche natif (ex.
received>=01/01/2024) teste directement dans l UI avant de l attendre de cette API generique.


## MAJ 30/07/2026 -- cause racine trouvee et corrigee (partiellement) : DNS Pi-hole

En creusant la question de Nabil ("pourquoi /folders ne marche pas, est-ce a regler tout de suite"),
inspection des logs container : SmartScreenDnsResolver timeout sur outlook.office.com et
outlook.cloud.microsoft, avec en consequence un /inbox qui remontait carrement en 502 Bad Gateway
par intermittence -- pas seulement /folders, un vrai bug de prod deja actif avant le projet RAG.

Cause : hermes-mail-browser tournait sans override DNS, donc resolution via Pi-hole (meme classe
de bug que la duplication Telegram corrigee le 09/07 sur hermes-agent-*).

**Fix applique** : ajout `dns: [1.1.1.1, 9.9.9.9]` dans docker-compose.yml, recreate du container.
Verifie : resolution DNS immediate (getent hosts en <1s, avant : timeout), /auth/status repond en
22ms (avant : dans la chaine de timeouts), session browser persistee sans besoin de re-auth noVNC.

**Ce qui reste casse malgre le fix DNS** : /folders. Comportement desormais **flaky et non lie au
DNS** -- soit timeout a 30s+, soit reponse rapide (~3s) mais vide (`count:0`). C est un bug cote
implementation (selecteur/logique de lecture du volet dossiers OWA, probablement arbre virtualise/
replie non deplie par le scraper), pas un probleme reseau. A traiter comme un vrai chantier de dev
sur l app hermes-mail-browser, pas un quick fix -- necessite d inspecter le code Playwright de la
route /folders.

**Confirmation /inbox** : ne retourne QUE des items de mail (raw_text, aria_label) -- zero info de
dossier/sous-dossier. Ne lit que le volet liste des messages, jamais le volet dossiers.

**A faire cote versioning** : ce changement compose vit sur /volume1/docker/hermes-mail-browser,
non versionne en Git depuis le NAS (pas de .git ici, conforme a la regle Git absent du NAS).
Nabil doit committer/push depuis son Mac (/Volumes/docker) pour capitaliser ce fix dans l historique.