#imap mail

[filemakerexperts]

# Volltext-Suche über 100 000 Mails- und sie reagiert in 50 Millisekunden

Wie wir den klassischen FileMaker-WebViewer-Suchpatterns einen modernen Such-Backend untergeschoben haben, ohne die FileMaker-Datei selbst zu berühren. Mit einer SQLite-Datenbank, die schon im System lag. Mit einer Eingebauten von SQLite, die kaum jemand kennt. Und mit einer 2-Stunden-Implementierung, die jetzt für Datenbestände von 100 000 bis 10 Millionen Mails ausreicht, bei gleichbleibend sub-100-ms-Reaktion auf jeden Tastendruck.* --- ## Das Problem Im Mail-System eines Kunden lagen nach dem großen Legacy-Import knapp 96 000 Mails. Das vorhandene Suchpattern war ein bewährter FileMaker-WebViewer-Trick: Eine **gespeicherte Berechnung** pro Datensatz baut ein HTML-Schnipsel (`

…

`), eine zweite **ungespeicherte Berechnung** verknüpft alle Schnipsel zu einer großen HTML-Seite mit Suchfeld, der WebViewer rendert sie als `data:`-URL, JavaScript filtert clientseitig per `data-search`-Attribut. Bei 5 000 Datensätzen ist das **magisch**: man tippt, die Liste filtert sich sofort, kein Server-Roundtrip, kein Lag. Bei 10 000 noch ok. Bei 92 000 stirbt es. Konkrete Zahlen aus der Diagnose: - `Liste()` über 96 000 Datensätze: **10–30 Minuten** pro Aufruf (Oder FileMaker gibt auf) - Generiertes HTML: **~75 MB** als String - `data:`-URL: bei manchen WebKit-Versionen über 64 MB einfach gekappt - 92 000 DOM-Knoten + JS `querySelectorAll` pro Tastendruck: **mehrere hundert Millisekunden** zähes Laggen Kurz: Das Pattern skaliert auf 5–10 k Datensätze. Bei 92 k bricht es. ## Die Optionen Drei klassische Wege: **A — Vorfilter.** Statt alle Mails zu zeigen, immer nur eine sinnvolle Teilmenge (letzte 90 Tage, Mails eines Kontakts). Reduziert auf <2 000 Datensätze, dann funktioniert das alte Pattern wieder. Pragmatisch, aber zwingt den User in eine starre Vorfilter-Logik. **B — Klassische FileMaker-Suche.** Suchfeld → ExecuteSQL → Ergebnismenge in Listenansicht. Skaliert auf Millionen, verliert aber das schöne Live-Filter-Gefühl. **C — Server-side-Index.** Ein eigener Such-Endpoint im PHP-Backend, der gegen eine speziell optimierte Such-Datenbank fragt, JSON zurückliefert, vom WebViewer per Fetch konsumiert. Skaliert auf Millionen, behält Live-Filter, kostet aber ein paar Stunden Aufbau. Variante C wäre normalerweise Cadillac-Engineering. In dem Moment, als der Kunde fragte „haben wir nicht schon eine SQLite im System?", wurde sie zur Anderthalb-Stunden-Lösung. ## Der entscheidende Aha-Moment Der PHP-Mailclient hatte schon eine SQLite-Datei. Genauer: `mailclient/data/links.sqlite`, eingerichtet für die kleine Verknüpfungstabelle `mail_links`, die Mail-Message-IDs auf FileMaker-Entitäten (Kontakte, Projekte, Konten) abbildet. PDO-Treiber konfiguriert, `db()`-Helper definiert, Schema-Initialisierung idempotent. Alles da. Und dann der zweite Aha: **SQLite hat seit Version 3.9 einen eingebauten Volltext-Index namens FTS5.** Eine virtuelle Tabelle, die Token-basierte Volltext-Suche über Millionen Datensätze in <50 ms macht. Genau das, was Apple Spotlight nutzt. Kostenlos, ohne Plugin, ohne externen Index-Service. Ein schneller Check, ob FTS5 in der PHP-SQLite-Installation kompiliert ist: ```php $pdo = new PDO("sqlite::memory:"); $pdo->exec("CREATE VIRTUAL TABLE t USING fts5(x)"); $pdo->exec("INSERT INTO t VALUES ('hallo welt'), ('foo bar')"); $r = $pdo->query("SELECT x FROM t WHERE t MATCH 'hallo'")->fetchAll(PDO::FETCH_COLUMN); // → ['hallo welt'] ``` Ein „FTS5 verfügbar: ja" als Antwort, und das Projekt war von „2 Tage Aufwand" auf „2 Stunden" geschrumpft. ## Die Architektur ``` FileMaker WebViewer PHP-Mailclient SQLite +-------------------+ +-------------------+ +----------------+ | + JS | fetch(q=...) | /api/search_mails | SQL | mails_fts | | rendert Top 100 | <------------> | sucht im FTS5 | <-----> | (92k Mails) | +-------------------+ JSON +-------------------+ +----------------+ Tastendruck ^ | bei jedem neuen DS | /api/index_mail (von FM aufgerufen) ``` Drei neue PHP-Endpoints, eine FTS5-Tabelle, ein Python-Initial-Lauf, eine neue FileMaker-Berechnung mit ein paar Dutzend Zeilen JavaScript. Mehr nicht. ## Die FTS5-Tabelle ```sql CREATE VIRTUAL TABLE mails_fts USING fts5( pk_mail_id UNINDEXED, message_id UNINDEXED, betreff, body, absender, empfaenger, datum UNINDEXED, id_contacts UNINDEXED, id_account UNINDEXED, z_eingang UNINDEXED, thread_root_id UNINDEXED, tokenize = 'unicode61 remove_diacritics 2' ); ``` Zwei Details lohnen Erklärung: **`UNINDEXED`-Spalten** werden gespeichert, aber nicht in den Volltext-Index aufgenommen. Sie sind als reine Lookup- und Filter-Felder gedacht. So bleibt der Index kompakt: nur das, was wirklich durchsuchbar sein muss (`betreff`, `body`, `absender`, `empfaenger`), trifft den Tokenizer. **`remove_diacritics 2`** im Tokenizer ist der versteckte Held: er normalisiert alle Akzente und Umlaute. Eine Suche nach „muller" findet „Müller", „Mueller" und „Müller". Bei einem multilingualen Mail-Archiv mit deutschen, französischen, türkischen Namen ist das nicht Nice-to-have, sondern Funktionalität. ## Der Initial-Lauf Bei 96 000 Mails wäre ein Datensatz-für-Datensatz-Index-Update über die FileMaker-Skript-Engine vermutlich ein Stundenprozess. Python machte es in **15 Sekunden**: ```python import sqlite3, csv conn = sqlite3.connect('mailclient/data/links.sqlite') conn.execute("PRAGMA journal_mode = WAL") conn.execute("PRAGMA synchronous = NORMAL") for csv_file in [mailausgang_csv, maileingang_csv]: batch = [] with open(csv_file, encoding='utf-8') as f: for row in csv.DictReader(f): batch.append(( row['Message_ID'], row['Betreff'], row['Body_Plain'], row['Absender_mailadresse'], row['Empfaenger'], # … )) if len(batch) >= 1000: conn.executemany("INSERT INTO mails_fts (...) VALUES (?,?,...)", batch) conn.commit() batch = [] ``` 6 100 Datensätze pro Sekunde mit Batch-Inserts und WAL-Mode. Das Ergebnis: 91 935 Mails im Index, Datei-Größe der SQLite ~250 MB, Initial-Investment zum Aufbauen einmalig 15 Sekunden, danach für immer verfügbar. ## Der Such-Endpoint PHP, gut 80 Zeilen Code. Der Kern: ```php $sql = " SELECT pk_mail_id, message_id, betreff, absender, empfaenger, datum, id_contacts, id_account, z_eingang, thread_root_id, snippet(mails_fts, 3, '', '', '…', 12) AS snippet FROM mails_fts WHERE mails_fts MATCH ? ORDER BY rank LIMIT 100 "; ``` `snippet()` ist eine eingebaute FTS5-Funktion: sie nimmt das Body-Feld (Index 3), markiert die Treffer-Worte mit ``-Tags und schneidet 12 Tokens links und rechts ringsum raus. Das Ergebnis sieht aus wie Gmail-Suchergebnisse: man tippt „heiratsurkunde", sieht ein paar Zeilen Body-Kontext mit gelb hervorgehobenem Treffer. `ORDER BY rank` sortiert nach FTS5-internem Relevanz-Algorithmus (BM25). Die häufigste/beste Übereinstimmung erscheint oben. Kein Tuning, kein TF-IDF-Selbstbau nötig. Etwas mehr Sorgfalt verlangt das Mapping von **Benutzer-Eingaben in FTS5-Query-Syntax**: ```php $tokens = preg_split('/\s+/', $userInput); $clean = []; foreach ($tokens as $t) { $safe = preg_replace('/["\\\\:()*]/', '', $t); if (preg_match('/[@.\-]/', $safe)) { $clean[] = '"' . $safe . '"'; // E-Mail-Adresse als Phrase } else { $clean[] = $safe . '*'; // Prefix-Match für "mueller" → "muellermann" } } $ftsQuery = implode(' ', $clean); ``` Drei Regeln: gefährliche Sonderzeichen rausnehmen, Token mit `@`/`.` als Phrasen (sonst zerlegt FTS5 sie an Punkten), normale Wörter als Prefix-Match mit Stern (damit „mueller" sofort matcht, sobald 7 Zeichen getippt sind, ohne dass der User ENTER drücken muss). ## Das Frontend Im WebViewer: ```javascript let timer = null; function suche(q) { clearTimeout(timer); timer = setTimeout(() => doFetch(q), 200); } function doFetch(q) { if (!q || q.trim().length < 2) { document.getElementById('liste').innerHTML = '

Mindestens 2 Zeichen…

'; return; } fetch(`${API}?q=${encodeURIComponent(q)}&limit=100&token=${TOKEN}`) .then(r => r.json()) .then(d => render(d)); } ``` Zwei Details: **Debouncing mit 200 ms.** Tippt der User „mueller", wird nicht für jeden Buchstaben ein Request abgesetzt. Erst wenn 200 ms keine neue Eingabe kommt, geht der Fetch los. Das schont den Server und ist auf modernen Maschinen subjektiv noch immer „sofort". **Race-Condition-Schutz mit `lastReq`-ID.** Wenn der User schnell tippt und der erste Request langsamer zurückkommt als der zweite, würde die Liste sonst kurz die alte Antwort zeigen. Über einen lokalen Zähler werden veraltete Antworten verworfen. ## Die CORS-Falle Beim ersten Test im WebViewer: nichts. „Load failed". Ein typisches Browser-Mysterium, das eine Stunde Diagnose verschlingt, wenn man's nicht kennt. Erklärung: Der WebViewer lädt seine HTML-Seite per `data:`-URL. Aus Browser-Sicht hat eine `data:`-URL als Origin den Wert `null`. Macht der eingebettete JavaScript-Code dann einen `fetch()` an einen HTTP-Server, prüft der Browser CORS (Cross-Origin Resource Sharing). Liefert der Server keine `Access-Control-Allow-Origin: *`-Header, wird die Antwort blockiert — der `fetch()` erhält einen generischen „Load failed"-Fehler ohne nähere Erklärung. Fix: zwei Zeilen im `json_response()`-Helper: ```php header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); ``` Sofort lief alles. Eine dieser Sachen, die man einmal gelernt hat und nie wieder vergisst, aber bis dahin Stunden kosten kann. ## Performance — die echten Zahlen Über 96 935 Mails, gemessen direkt am Server, dann inklusive HTTP-Roundtrip aus dem WebViewer: | Such-Typ | SQL-Zeit | HTTP-Roundtrip | |---|---:|---:| | Volltext „mueller*" | 4 ms | 59 ms | | Volltext „heiratsurkunde" | 4 ms | 55 ms | | Volltext + Filter (z_eingang=1) | 5 ms | 34 ms | | Phrasen-Suche „aicher.com" | 4 ms | 42 ms | Der HTTP-Roundtrip ist dabei der Löwenanteil. Die eigentliche FTS5-Query liegt **unter 10 ms** — auch bei Millionen Datensätzen würde sich daran wenig ändern. Vergleich mit dem alten Pattern: | | Liste-basierter WebViewer | FTS5-Backend | |---|---|---| | Initiales Rendering | 10–30 m | <100 ms | | Tastendruck-Reaktion | 100–500 ms (DOM-Filter) | 50–100 ms (HTTP) | | HTML-Größe initial | ~75 MB | ~1 KB pro Request | | Skalierungsgrenze | ~10 000 DS | 10 Mio+ | | Body-Volltext-Suche | begrenzt, kein Stemming | voll, mit Diacritics-Normalisierung | | Sortierung | nach Anlegen | nach Relevanz (BM25) | | Snippet-Hervorhebung | nein | ja, mit `` | | Sonderzeichen/Umlaut-Toleranz | nein | ja | ## Wartung Damit der Index nicht veraltet, muss er bei jeder neuen oder geänderten Mail aktualisiert werden: - **Mails per IMAP abholen**: das FileMaker-Skript ruft nach jedem neuen Datensatz `Mail indizieren` auf, der schickt den DS per POST an `/api/index_mail.php` - **Mails senden**: macht der PHP-Endpoint selbst nach erfolgreichem Versand - **Manuelle Änderungen** in FileMaker (Betreff editiert, Body angepasst): per Skript-Trigger OnRecordCommit → `Mail indizieren` Bei Inkonsistenzen genügt ein Reset: Python-Script neu laufen lassen, leert den Index, baut ihn neu auf. 15 Sekunden. ## Bilanz Was am Ende steht: - **Live-Volltext-Suche über 96 935 Mails** mit <100 ms Antwortzeit - **Sub-50-ms-Performance auf der DB-Ebene** — würde auch bei 10 Mio Datensätzen noch unter 100 ms bleiben - **Snippet-Hervorhebung** mit Kontext-Wörtern um den Treffer herum - **Umlaut- und Akzent-tolerant**: „muller" findet „Müller" - **Filter-Kombinationen**: Volltext + Kontakt + Richtung + Thread (über zusätzliche URL-Parameter) - **Skaliert** auf jeden Datenbestand, der realistisch in FileMaker liegt - **Wartung minimal**: PHP-Endpoint indiziert neue Mails automatisch, Python-Script setzt bei Bedarf alles zurück Das Pattern ist breit übertragbar. Überall dort, wo FileMaker mit großen Datenmengen Live-Suche bieten soll — Kontakte, Aufgaben, Dokumente, Logs — ist FTS5 in einer Helper-SQLite die richtige Antwort. Die FM-Datei selbst bleibt unangetastet, die Suche läuft daneben, der WebViewer ist die Brücke. ## Was als Nächstes käme Drei mögliche Erweiterungen, die diese Lösung von „funktional" zu „brillant" heben würden: 1. **Server-side Pagination**: aktuell 100 Treffer pro Anfrage. Bei einer „1000 Treffer für muller" könnte „Mehr laden"-Button mit `offset`-Parameter ergänzt werden. 2. **Faceted Search**: Aggregations-Endpoint, der für eine Such-Query liefert „X Treffer in Inbox, Y in Sent, Z bei Kontakt A". Bietet sofortige Verfeinerungs-Optionen. 3. **Synonyms-Wörterbuch**: für Geschäftsbegriffe Synonyme definieren („Rechnung" matcht auch „Invoice"). FTS5 unterstützt das über Custom-Tokenizer. Aber: nichts davon braucht es heute. Sub-100-ms-Volltextsuche über 96 000 Mails reicht für die nächsten Jahre. Das Pattern ist offen, falls je gebraucht. --- **Stack:** - SQLite 3.x mit FTS5 (in praktisch jeder modernen PHP-Installation enthalten) - PHP 8.x, PDO-SQLite-Treiber - FileMaker WebViewer mit `data:`-URL + JavaScript-Fetch - Python 3 für den einmaligen Initial-Index-Lauf **Code-Umfang nach Implementierung:** - `lib/helper.php`: +40 Zeilen (FTS5-Tabelle + `index_mail()`-Helper) - `api/search_mails.php`: ~100 Zeilen (komplett neu) - `api/index_mail.php`: ~40 Zeilen (komplett neu) - `/tmp/initial_index_mails.py`: ~80 Zeilen (einmalig) - FileMaker-Berechnung `wv_html_search_fts`: ~80 Zeilen JavaScript+HTML in einer FM-Calc - FileMaker-Skript `Mail indizieren`: ~12 Steps

[filemakerexperts]

Wie wir die FileMaker-Mail-Lösung von einem Plugin befreit haben

# Wie wir die FileMaker-Mail-Lösung von einem Plugin befreit haben *Eine kleine Migrations-Geschichte: von Dacons MailIT zu einer eigenen PHP-Mail-Pipeline mit echtem Threading, ohne Plugin-Lizenzen, ohne lokalen Mini-Webserver, ohne Vendor-Lock-in. Was als „der Kunde will Konversations-Ansicht" begann, wurde zur kompletten Neuverdrahtung der Mail-Schicht. Mit überraschend wenig Code und einigen Erkenntnissen, die wir hier teilen.* --- ## Ausgangslage: ein Plugin, das alles entscheidet Der Kunde hatte eine FileMaker-Mailtabelle mit gut 49.000 Datensätzen. Eingehende und ausgehende Mails, Anhänge in zwölf globalen Container-Slots, Verknüpfungen zu Kontakten, Projekten und Konten alles solide gewachsen. Und alles durchwoben mit dem Plugin **Dacons MailIT**. MailIT ist ein in die Jahre gekommenes, aber durchaus mächtiges Plugin. Es bringt IMAP, POP3, SMTP, sogar einen kleinen lokalen Webserver mit (für die Inline-Bilder-Darstellung im WebViewer) und das in einer fertigen Beispieldatenbank, die viele Kunden direkt als Basis übernehmen. Das war hier auch passiert: die DB-Struktur stammte aus der „Mailit Ticket"-Demo. Der Wunsch des Kunden klang harmlos: **„Ich möchte, dass zusammengehörige Mails als Konversation angezeigt werden."** Klingt nach „ein bisschen Sortierung". Wurde zum Anlass für eine vollständige Plugin-Befreiung. ## Die Diagnose: Threading geht so nicht Threading auf Mail-Ebene heißt: aus losen Datensätzen wird eine Konversation. Eine eingehende Mail mit `In-Reply-To: ` gehört zur Mail mit `Message-ID: `. Mehrere Antworten auf eine Antwort bauen einen Baum. Mail-Clients wie Apple Mail oder Outlook lösen das seit zwanzig Jahren — in FileMaker bauen wir uns das selbst. Das Schema hatte schon `Message_ID` und `In_Reply_To`. Reicht für eine Stufe Rückwärts. Für tiefe Konversationen reicht das nicht — dafür braucht's den `References`-Header, der nach RFC 5322 die ganze Vorgänger-Kette mitschleppt. Und der war nicht da. Plugin lieferte ihn auch nicht. Außerdem: das Match-Feld in der DB hieß `Message_id_suche` und war definiert als `LiesAlsZahl ( Message_ID )`. Bei einer Message-ID wie `` ergibt das **`3`**. Dreiundsiebzig Mails matchen damit munter zusammen. Bug seit Jahren unentdeckt — weil bisher niemand drüber gestolpert ist, dass es nicht funktioniert. ## Die Idee: ein PHP-Mailclient gibt's schon Wir hatten in einem anderen Projekt einen kleinen PHP-Mailclient liegen — IMAP über `webklex/php-imap`, SMTP über PHPMailer, eine SQLite-Tabelle für die Verknüpfung Message-ID ↔ FileMaker-Entität, ein paar HTML-Seiten für den WebViewer. War als Prototyp gedacht (dann als AddOn), lag aber zu rund 70 Prozent funktionsfähig herum. Die Idee schrieb sich von selbst: - **MailIT komplett raus.** Keine Plugin-Lizenz mehr, keine MailIT-Templates, keine „Plug-in not installed"-Dialoge. - **PHP übernimmt die Mail-Mechanik.** Senden, Abholen, Anhänge, Folder-Listing — alles per JSON-API. - **FileMaker bleibt die Heimat der Daten.** Anzeige, Beziehungen, Threading-Logik, Verknüpfungen mit dem CRM — bleibt nativ. Die Architektur: ``` FileMaker (PRJ_CRM.fmp12) PHP-Mailclient +------------------+ +--------------------------+ | TAB_Mail | ←─ JSON-Import ── | /api/list_inbox_messages | | TAB_MailAccount | ─→ JSON-Send ──→ | /api/send_mail | | Skripte/Layouts | ─→ Anhang holen → | /attachment.php | +------------------+ +--------------------------+ ↑ ↓ └── data/accounts.json ←── sync ─── TAB_MailAccount ↓ IMAP/SMTP Server ``` ## Die zentrale Architektur-Entscheidung: Stateless, aber pragmatisch Klassisch hat man zwei Wahlmöglichkeiten: **A) Reines Stateless** — jeder API-Aufruf bringt die Server-Credentials mit. Sauber, aber FileMaker müsste bei jedem Klick die Account-Daten extrahieren, in ein JSON packen und mitschicken. Bei einem WebViewer-Aufruf (`view.php?...`) geht das nicht — der WebViewer kann nur GET-URLs absetzen, ohne JSON-Body. **B) Session-basiert** — Login-Endpoint, Session-Token, ablaufende Tokens. Sicher, aber erheblich mehr Code, vor allem auf FileMaker-Seite. Wir entschieden uns für eine dritte Variante, die in der Praxis am unauffälligsten ist: **Account-Cache in PHP, gefüllt aus FileMaker.** FileMaker pflegt die Mail-Accounts in einer eigenen Tabelle `TAB_MailAccount` (mit IMAP-Host, SMTP-Port, Username, Passwort, allem). Beim Speichern eines Accounts in FileMaker wird per Skript einmalig `POST /api/sync_account.php` aufgerufen. Der PHP-Server cached die Account-Daten in einer `data/accounts.json`. Ab dann reicht in jedem API-Aufruf eine `account_id` — PHP resolvt sie selbst. Vorteile: - FileMaker muss Credentials nur **einmal** synchronisieren, nicht bei jedem Klick. - HTML-Views (`view.php`, `attachment.php`) funktionieren mit GET-Parametern. - Die Quelle der Wahrheit bleibt FileMaker — `accounts.json` ist nur Cache. - Wechsel des Mail-Passworts: Wert in FileMaker ändern, Sync-Knopf, fertig. Kein Code-Deploy, kein PHP-Anfassen. Für die Authentifizierung selbst genügt ein **statischer Bearer-Token**, der in einer `.env` auf PHP-Seite und einer Custom Function `CF_API_Token` auf FileMaker-Seite hinterlegt ist. JWT wäre Overkill für eine Backoffice-Lösung. ## Threading: das eigentliche Herzstück Der ursprüngliche Wunsch — die Konversationen — bekam jetzt das passende Datenmodell. Vier neue Felder in `TAB_Mail`: | Feld | Zweck | |---|---| | `References` | Komma-getrennte Liste aller Vorgänger-Message-IDs aus dem RFC-5322-Header | | `thread_root_id` | Die Message-ID der Wurzel des Threads — alle Mails desselben Threads tragen denselben Wert | | `thread_depth` | Einrückungstiefe, 0 = Wurzel, sonst Vorgänger + 1 | | `thread_seq` | Sortierreihenfolge innerhalb des Threads (für später) | Plus drei **normalisierte Match-Felder** für die Self-Joins: ``` Kleinbuchstaben ( Trimme ( Substitute ( Message_ID ; [ "<" ; "" ] ; [ ">" ; "" ] ; [ " " ; "" ] ; [ "¶" ; "" ] ) ) ) ``` `Message_ID_norm`, `In_Reply_To_norm`, `thread_root_id_norm` — alle indiziert. Damit wird `` zu `[email protected]`, sauber gegen Großschreibung, Klammern, Whitespace. Drei Self-Join-TOs: | Tabellenokkurrenz | Beziehung | Liefert | |---|---|---| | `T34_mail_MAIL\|\|parent` | `In_Reply_To_norm = Message_ID_norm` | direkten Vorgänger (max. 1 DS) | | `T34_mail_MAIL\|\|replies` | `Message_ID_norm = In_Reply_To_norm` | alle Direkt-Antworten (0..n) | | `T34_mail_MAIL\|\|thread` | `thread_root_id_norm = thread_root_id_norm` | alle Mails desselben Threads | Das **Skript „Mail einreihen"** läuft nach jedem neuen Datensatz und kennt vier Regeln, in dieser Reihenfolge: 1. `In_Reply_To` leer → eigene Wurzel: `thread_root_id = Message_ID`, `thread_depth = 0` 2. Vorgänger ist über `T34_mail_MAIL||parent` erreichbar → erbe `thread_root_id` und setze `thread_depth = parent.depth + 1` 3. Vorgänger fehlt → Fallback auf erste ID aus `References` (per ExecuteSQL gegen `Message_ID_norm`) 4. Komplett verwaist → eigene Wurzel Was hier passiert, ist klassische Hierarchie-Synthese auf Datensatz-Ebene. Der Witz: das Skript läuft **ohne Mehrfach-Durchgänge** auf einem importierten Datensatz, weil der Vorgänger bei chronologischer Reihenfolge (älteste zuerst) bereits korrekt einsortiert war. Für den seltenen Fall, dass eine Antwort vor ihrem Vorgänger ankommt, gibt's das `Threading_Backfill`-Skript, das iterativ bis zur Konvergenz läuft. ## Die schönste Überraschung: kein Webserver nötig MailIT hatte einen lokalen HTTP-Server, der bei jedem FileMaker-Start auf einem konfigurierbaren Port hochfuhr. Zweck: Inline-Bilder in HTML-Mails (``) im WebViewer anzeigen können. Der WebViewer braucht eine URL — MailIT lieferte sie über `localhost:Port`. Das war wackelig: Port-Konflikte, fehlende Berechtigungen, der berühmte „Failed to start local web server"-Dialog. In unserer neuen Lösung war dieser ganze Webserver-Komplex schlicht **überflüssig**. Wir haben einen echten Webserver, auf dem der PHP-Mailclient ohnehin läuft. Inline-Bilder werden entweder direkt als `data:`-URLs ins HTML eingebettet oder über `attachment.php` ausgeliefert — der WebViewer holt sie sich wie jedes andere Bild. Allein dieses Detail würde eine Plugin-Migration rechtfertigen. Es waren zwei `Email_Send_*`-Felder weniger im Schema, eine ganze Skript-Sektion „Start/Stop Web Server" entfernt, und keine mysteriösen Port-Konflikte mehr. ## Eine ehrliche Falle: Auto-Eingabe-Berechnungen Drei Tage lang lief das System scheinbar perfekt. Dann fiel auf: nach jedem Mail-Abruf wurden die seit gestern gesendeten Mails wieder mit-importiert. Doppelt, dreifach. Der Doppel-Match auf `Message_ID_norm` griff nicht. Diagnose: das `Message_ID_norm`-Feld war bei neu angelegten Datensätzen **leer**. Warum? In FileMaker hat eine Auto-Eingabe-Berechnung standardmäßig die Option **„Vorhandenen Feldwert nicht ersetzen"** angehakt. Das klingt harmlos, ist aber tückisch: beim Anlegen eines neuen Datensatzes wird die Berechnung **einmal** ausgeführt — mit leerem Quellfeld. Ergebnis: leeres Norm-Feld. Wenn das Skript danach `Feldwert setzen [ Message_ID = "" ]` macht, greift die Berechnung **nicht mehr**, weil der Wert „schon vorhanden" ist (auch wenn er leer war). Lösung: Häkchen raus. Dann rechnet FM die Auto-Eingabe bei jeder Änderung am Quellfeld neu. Klassische Falle, von der man als FileMaker-Entwickler nie genug Schaden nehmen kann. ## Was am Ende stand Nach gut anderthalb Tagen Migration: - **MailIT komplett raus.** Keine Plugin-Abhängigkeit, keine Lizenzgebühren pro Client, keine plugin-spezifischen Skripte mehr. - **Plugin-frei auch im Mehr-Client-Betrieb.** Der PHP-Mailclient läuft einmal zentral. Mehrere FileMaker-Clients teilen ihn — auch FileMaker Server, WebDirect oder iOS Go funktionieren ohne Anpassung. - **Echtes Threading** mit Self-Joins, Einrückung, Reply-Indikatoren (↩/↪/↳) und einer Detail-Ansicht, die die ganze Konversation chronologisch zeigt. - **Multi-Account-fähig** ohne Code-Änderung. Accounts kommen aus FileMaker, neue Postfächer brauchen nur einen Datensatz. - **OAuth-ready** — die Architektur ist offen für XOAUTH2 (Gmail, Microsoft 365), wenn ein Kunde das braucht. Heute nicht aktiv, aber morgen kein Architektur-Eingriff mehr. - **Mehrere To-Empfänger** funktionieren sauber, ein- wie ausgehend. - **Robuste Anhang-Verarbeitung** über eindeutige `imap_folder + imap_uid + att_index`-Adressierung statt fragiler Message-ID-Suche. ## Lessons Learned Drei Sachen würde ich aus dieser Migration mitnehmen: **1. Plugin-Befreiung lohnt sich oft erst auf den zweiten Blick.** Der ursprüngliche Anlass (Threading) hätte auch innerhalb von MailIT mit Krücken gelöst werden können. Aber sobald man den Schritt einmal geht, fallen reihenweise andere Probleme weg, die man als „normal" akzeptiert hatte: der Webserver-Dialog, die Lizenzpflege, die Limitierung auf einen Account, die fehlende OAuth-Option. Eine Migration zahlt sich oft erst durch die Aufräumarbeit aus, die man nebenbei mitmacht. **2. Eine PHP-Bridge ist im FileMaker-Kosmos unterschätzt.** „Aus URL einfügen" mit cURL-Optionen ist mächtig — Bearer-Tokens, POST mit JSON-Body, alles geht. Wer mit FileMaker eine Datenquelle anbinden will, die kein klassisches Plugin hat (Stripe, GitHub, eine interne API), sollte den PHP-Sandwich-Ansatz im Hinterkopf haben. Schneller geschrieben als ein eigenes Plugin, einfacher zu testen, und unabhängig von der FileMaker-Version. **3. Normalisierte Match-Felder gehören in jedes Schema mit Fremd-IDs.** Egal ob Mail-IDs, Telefonnummern, IBANs, ISBN: das Original-Feld bleibt, ein `_norm`-Feld als indizierte Auto-Eingabe-Berechnung daneben, und der Match läuft darüber. Spart langfristig die seltsamen Bugs, bei denen ein User mal mit Großbuchstaben tippt und nichts gefunden wird. --- **Stack im Überblick:** - FileMaker 22 mit deutscher Lokalisierung - PHP 8.3 mit `webklex/php-imap` 5.x und `PHPMailer` 6.x - Apache als HTTP-Frontend - SQLite für die Mail-↔-FileMaker-Verknüpfung - Bearer-Token aus `.env`, Account-Cache in `data/accounts.json` - Keine Browser-Frameworks, kein npm, kein Build-Schritt **Code-Umfang nach der Migration:** - `mailclient/`: rund 1 200 Zeilen PHP, davon etwa die Hälfte aus dem Prototyp übernommen - FileMaker: 5 neue Skripte (`Mails abholen`, `Mail senden`, `Mail beantworten`, `Mail einreihen`, `Threading Backfill`), eine neue Tabelle (`TAB_MailAccount`), 7 neue Felder, 3 neue Beziehungen - Aufwand inklusive Schema-Refactor, PHP-Anpassungen und Tests: ungefähr zwölf Stunden, verteilt über drei Arbeitstage

[filemakerexperts]

Seamless Email Integration for FileMaker – now in English!

Seamless Email Integration for FileMaker – now in English! Now available: FM MailBridge – the add-on for anyone who wants to integrate email into their FileMaker solutions seamlessly. No external tools. No manual workarounds. Just pure IMAP. Whether you’re using it as a standalone on your local machine, deploying it on a server, or bundling it into your own commercial FileMaker projects – FM MailBridge makes it possible to process and manage emails directly within FileMaker. Clean, efficient, and fully customizable. What is FM MailBridge? FM MailBridge is a standalone PHP-based module that connects directly to IMAP mailboxes and delivers structured email data – including attachments – to FileMaker via Insert from URL. The complete message is returned as JSON, including: • Sender, subject, date • Email body (plain text or HTML) • Attachments (Base64-encoded, with filename & MIME type) The integration is designed to work with any FileMaker solution – locally, server-side, or as part of a commercial product. Three license models to fit your needs: 1. Single User – €49 For local use by developers or single users. Runs via local web server. 2. Server – €199 For centralized use on a FileMaker Server (via scheduled script or PSOS). No client setup required. 3. Enterprise – €699 For developers and agencies who want to integrate FM MailBridge into their own FileMaker products and resell it. Why FM MailBridge? • Direct IMAP access – no Google API or OAuth required • Works with Gmail, Outlook, hosted mailboxes, and more • Returns structured email data as JSON (incl. attachments) • Fully customizable for any FileMaker environment • No external tools – just PHP and FileMaker Technical Background The solution relies on a lean PHP script that connects to an IMAP inbox, fetches and processes emails, and returns them as JSON. FileMaker then handles this data within its own table structure. The setup is solid, battle-tested with thousands of messages, and intentionally lightweight. Product page & download: [filemaker-experts.de/applicati...](https://filemaker-experts.de/application.html)

[filemakerexperts]

FM MailBridge ist da, E-Mails direkt in FileMaker integrieren

Ab sofort verfügbar: FM MailBridge, das Add-on für alle, die E-Mails nahtlos in ihre FileMaker-Lösungen einbinden möchten ohne externe Tools, ohne manuelle Umwege, direkt per IMAP. Ob als Einzelplatzversion, für den Servereinsatz oder als Entwicklerlizenz zur Weiterverwertung in eigenen Projekten. FM MailBridge macht es möglich, E-Mails automatisiert in deine FileMaker-Umgebung zu integrieren. Übersichtlich, effizient und vollständig anpassbar. Was ist FM MailBridge? FM MailBridge ist ein eigenständiges PHP-basiertes Modul, das sich direkt mit IMAP-Postfächern verbindet und E-Mails samt Anhängen strukturiert an FileMaker übergibt. Dieses erfolgt via Insert from URL. Dabei wird der komplette Mailinhalt als JSON übergeben: Absender, Betreff, Datum, Text (wahlweise HTML oder nur Text) und wenn vorhanden, Base64-kodierte Anhänge inkl. Dateiname und MIME-Typ. Die Integration ist so konzipiert, dass sie in beliebige FileMaker-Projekte eingebaut werden kann. Entweder lokal, serverseitig oder als Bestandteil einer kommerziellen Lösung. Drei Lizenzmodelle für jeden Anwendungsfall: 1. Einzelplatz Für den lokalen Abruf durch einen Entwickler oder Einzelplatznutzer. Einrichtung über lokalen Webserver. -49 € 2. Server Für den zentralen Einsatz auf einem FileMaker Server (mit Zeitplan oder PSOS). Keine Client-Einrichtung nötig. -199 € 3. Enterprise Für Entwickler und Agenturen, die FM MailBridge in eigene FileMaker-Projekte einbauen und weiterverkaufen möchten. -699 € Was macht FM MailBridge besonders? • Nutzt reinen IMAP-Zugriff, keine Google API oder OAuth erforderlich • Funktioniert mit Gmail, Outlook, Webhostern u. v. m. • Übergibt Mails strukturiert als JSON (inkl. Anhänge) • Vollständig anpassbar für beliebige FileMaker-Lösungen • Keine externen Tools nötig, nur PHP & FileMaker Technischer Hintergrund Die Kommunikation erfolgt über ein kompaktes PHP-Skript, das IMAP-Mails abruft, verarbeitet und als JSON zurückliefert. FileMaker verarbeitet diese Daten direkt innerhalb der eigenen Tabellen-Strucktur. Der Aufbau ist stabil, getestet mit tausenden E-Mails und bewusst schlank gehalten. Produktseite & Download: https://filemaker-experts.de/application.html Fragen zur Integration, Lizenz oder Sonderfällen? Schreib uns an: [email protected]

[filemakerexperts]

Implementierung des IMAP‑AddOns in FileMaker

In unserem neuesten Video zeigen wir Schritt für Schritt, wie Sie unser IMAP‑AddOn in Ihre FileMaker‑Lösung integrieren – von der Einbindung bis zur ersten produktiven Nutzung. Innerhalb von nur zwei Minuten steht Ihnen ein vollwertiger Mail‑Client direkt in Ihrer FileMaker‑Umgebung zur Verfügung. Keine komplizierte Einrichtung, keine zusätzlichen Tools: einfach installieren, konfigurieren und loslegen. Sehen Sie selbst, wie einfach sich E‑Mails abrufen, durchsuchen und verarbeiten lassen – nahtlos eingebettet in Ihre bestehende Lösung.

Link zum Video auf Canva von FileMaker Experts

[filemakerexperts]

Mein kleiner feiner Mail‑Client, auch als Add‑on nutzbar!

In den letzten Wochen habe ich etwas entwickelt, das ich selbst schon lange gebraucht habe: Einen voll anpassbaren Mail‑Client, der sich nahtlos in FileMaker integrieren lässt. Und weil es so gut geworden ist, gibt’s das Ganze jetzt auch als Add‑on für alle, die ähnliche Anforderungen haben. Eigentlich wollte ich nur die Funktionalität des Mail-Abrufes aufzeigen. Nun ist ein kleiner FileMaker-Mail Klient daraus geworden. Was kann das Add‑on? -Durchdachte Ordnerliste, dynamisch per JavaScript erzeugt -Dateianhänge werden automatisch in Containerfelder importiert -Schlank und effizient, keine 2 MB Gesamtgröße -Vollständig anpassbar an eigene Workflows und Layouts -Einfach einzubinden und erweiterbar – auch mit eigenen Skripten oder PHP‑Backends Damit lassen sich IMAP‑Postfächer direkt aus FileMaker heraus durchstöbern, Mails anzeigen, Anhänge sichern und vieles mehr, ohne zusätzliche schwere Tools. Warum als Add‑on? Arbeite ich mit einem Plugin, dann wird es oft zeitaufwendig. Tabellen, Layouts, Scripte etc. in die eigene Lösung einbauen. Häufige schnelle Notlösung, die Dateien zum Plugin als weitere FileMaker-Datei einbinden. Das recht sich aber im späteren Prozess fast immer. Neugierig geworden? Schreib mir gern hier direkt auf LinkedIn oder besuche filemaker-experts.de für weitere Infos. Ich zeige dir gern in einer Erklärung, wie es funktioniert und wie du es in deinem System einsetzen kannst! #FileMaker #AddOn #MailClient #IMAP #LowCode #Entwicklung #Automation #BusinessTools #FileMakerExperts

[jack-leach]

Step-by-step procedure on how to setup IMAP Mail for Google, Yahoo, Zoho, Claws, Att, Bluewin. Follow the below steps to make the IMAP setup easy.

[jack-leach]

IMAP Mail - Yahoo Mail IMAP

Step-by-step procedure on how to setup IMAP Mail for Google, Yahoo, Zoho, Claws, Att, Bluewin. Follow the below steps to make IMAP setup easy.

Step 1:

Open the Yahoo Mail program’s new-account wizard.

Step 2:

Write the imap.mail.yahoo.com at the server category.

Step 3:

Set the IMAP port to 993 and SSL to Yes.

Step 4:

Enter the username and password.

Step 5:

Type smtp.mail.yahoo.com as the Yahoo Mail SMTP Server.

Visit us for more details.