WissenStand 21. Oktober 2026
IMAP-MCP mit Passwort oder gehosteter MCP-Server für E-Mail?
Ein passwortbasierter IMAP-MCP-Server meldet sich mit deinem Postfach-Passwort oder einem App-Passwort beim Mailanbieter an, ein gehosteter MCP-Server mit OAuth gibt deinem Agenten dagegen nur ein widerrufbares Token mit den bestätigten Rechten. Für die Wahl zählen zwei getrennte Fragen: wie sich der Agent beim MCP-Server anmeldet und wie der Server an deine Mails kommt[9]. IMAP mit Passwort lohnt sich vor allem bei Anbietern ohne eigene Schnittstelle und wenn alles lokal bleiben soll; für Gmail und Microsoft-Konten schließen die Anbieter diesen Weg weitgehend[5][6][7][8].
Diese Seite erklärt beide Fragen, zeigt am Beispiel von mcp-email-server, was ein guter lokaler IMAP-Server heute begrenzt[1][3], und nennt, wo gehostete Dienste ein Passwort trotzdem speichern[10].
01Zwei Anmeldungen, die oft verwechselt werden
Jeder E-Mail-MCP-Server steht zwischen zwei Seiten, und jede Seite hat ihre eigene Anmeldung. Auf der einen Seite verbindet sich dein Agent, etwa Claude, ChatGPT oder Cursor, mit dem MCP-Server. Auf der anderen Seite holt der Server Mails beim Anbieter ab, zum Beispiel bei Gmail oder Outlook.com[5][8].
Für die erste Anmeldung ist Autorisierung laut MCP-Spezifikation optional; wird sie unterstützt, trennt die Spezifikation nach Übertragungsweg. Server über HTTP sollen sich an das Autorisierungsverfahren der Spezifikation halten, das auf OAuth 2.1 aufbaut; Server, die lokal über stdio laufen, sollen es nicht verwenden und ihre Zugangsdaten aus der Umgebung beziehen[9]. Ein lokaler stdio-Server läuft also als Programm auf deinem Rechner und vertraut dem, der ihn startet.
Für die zweite Anmeldung gibt es vier Wege: IMAP und SMTP mit Passwort oder App-Passwort, IMAP und SMTP mit OAuth, die eigene Schnittstelle des Anbieters mit OAuth, etwa Gmail API oder Microsoft Graph, oder gar keine Anmeldung am Ursprungspostfach, weil Mails per Weiterleitung ankommen. Google und Microsoft unterstützen IMAP mit OAuth ausdrücklich[6][7]. „IMAP-MCP oder gehosteter MCP“ vermischt also zwei Ebenen: Ein gehosteter Server kann intern IMAP mit App-Passwort sprechen, ein lokaler Server kann OAuth nutzen.
02Wie ein lokaler IMAP-MCP arbeitet
mcp-email-server ist ein quelloffener Server unter BSD-3-Lizenz[15], der Mails über IMAP und SMTP liest, durchsucht, sortiert und sendet und unter Windows, macOS und Linux läuft[1]. Die Einrichtung beginnt mit E-Mail-Adresse und Passwort; die Oberfläche ergänzt die üblichen Servereinstellungen aus der Domain[1]. In den Projektdokumenten zu Konfiguration, Werkzeugen und Übertragung findet sich kein OAuth-Anmeldeweg für das Postfach[2][3][4].
Das Passwort verlässt dabei deinen Rechner nur in Richtung deines Mailanbieters. Im verwalteten Modus liegen Zugangsdaten unter Linux und Windows in einer eigenen Tabelle einer privaten SQLite-Datenbank, unter macOS im Schlüsselbund des Systems[2]. Passwörter nimmt die Kommandozeile nur maskiert oder über die Standardeingabe an, nie als gewöhnlichen Befehlsparameter[2].
Der Server kann die Rechte des Agenten deutlich einschränken. Schreibaktionen sind in fünf Klassen geteilt, nämlich Entwurf, Sortieren, Löschen, Senden und Ablegen; standardmäßig sind alle fünf erlaubt, eine leere Liste macht ein Konto nur lesbar[3]. Für Empfänger gibt es eine Erlaubnisliste: Ist sie leer, ist Senden ausgeschaltet, und erst ein Muster wie *@example.com oder ausdrücklich * öffnet es[2].
Über HTTP lässt sich der Server ebenfalls betreiben, dann prüft er standardmäßig Host- und Origin-Kopfzeilen gegen DNS-Rebinding[4]. Empfohlen wird für einen lokalen Client trotzdem stdio[4]. Wer den Server im Netz erreichbar macht, kümmert sich selbst um die Absicherung davor.
03Was das Passwort bei IMAP bedeutet
Ein Postfach-Passwort oder App-Passwort öffnet bei IMAP in der Regel das ganze Postfach, eine Begrenzung auf einzelne Aufgaben müsste der MCP-Server selbst leisten. Genau dafür hat mcp-email-server seine Rechteklassen und Empfängerlisten[2][3]. Diese Grenzen gelten aber nur innerhalb des Servers: Wer die gespeicherten Zugangsdaten in die Hand bekommt, umgeht sie.
Das Projekt sagt das offen. Die lokale Verwaltungsoberfläche ist ausdrücklich eine Vertrauensgrenze für einen einzelnen Nutzer; ein bösartiger Prozess unter demselben Benutzerkonto kann Dateien dieses Benutzers in der Regel lesen oder ersetzen[13]. Für einen privaten Rechner ist das eine nachvollziehbare Annahme, für einen geteilten Server weniger.
Zum Widerruf musst du beim Anbieter ansetzen. Ein App-Passwort löschst du im Konto des Mailanbieters, ein normales Postfach-Passwort änderst du, was alle anderen Programme mit demselben Passwort ebenfalls trennt.
04Wo IMAP mit Passwort noch geht
Die großen Anbieter haben die Anmeldung mit Benutzername und Passwort für Fremdprogramme weitgehend beendet. Was das für einen IMAP-MCP heißt, zeigt die Tabelle.
| Anbieter | IMAP mit Passwort für Fremdprogramme | Quelle |
|---|---|---|
| Gmail (privat) | Nur mit App-Passwort; setzt Bestätigung in zwei Schritten voraus, Google rät ab | [5] |
| Google Workspace | Seit dem 14. März 2025 OAuth Pflicht, Ausnahme App-Passwörter | [6] |
| Microsoft 365 (Exchange Online) | Basic Authentication für IMAP und POP in allen Mandanten abgeschaltet | [7] |
| Outlook.com, Hotmail | Seit dem 16. September 2024 keine Anmeldung per Basic Authentication mehr | [8] |
Google schreibt, dass App-Passwörter nicht empfohlen und in den meisten Fällen unnötig sind, und bietet sie unter anderem bei Konten mit erweitertem Sicherheitsprogramm oder bei Arbeits- und Schulkonten teilweise gar nicht an[5]. Microsoft nennt als Folge der Abschaltung ausdrücklich, dass auch App-Passwörter mit Programmen ohne Zwei-Schritt-Unterstützung nicht mehr funktionieren[7]. Für Outlook.com und Microsoft 365 braucht ein Programm deshalb eine OAuth-Anmeldung, die ein reiner Passwort-IMAP-Server nicht mitbringt.
Andere Anbieter, darunter viele Hoster mit eigener Domain, erlauben IMAP mit Passwort weiterhin. Ob und mit welchen Bedingungen, steht in der Hilfe des jeweiligen Anbieters; wir haben das nicht für jeden einzeln geprüft. Bietet dein Anbieter keine passende andere Schnittstelle, ist ein IMAP-MCP oft der direkteste Weg.
05Was ein gehosteter MCP-Server anders macht
Ein gehosteter MCP-Server läuft beim Anbieter, und dein Agent verbindet sich über das Internet; je nach Dienst meldet er sich per OAuth oder mit einem API-Schlüssel an[9][10]. Bei OAuth bestätigst du beim Verbinden die Rechte des Tokens und kannst die Verbindung später widerrufen, ohne dein Postfach-Passwort zu ändern. Dafür liegt die Verantwortung für den Server und die Daten darin bei einem weiteren Anbieter.
Gehostet heißt nicht, dass kein Passwort im Spiel ist. MCP Emails etwa verbindet Gmail laut eigener Seite mit einem Google-App-Passwort über IMAP, Outlook und Microsoft 365 dagegen mit Microsoft-Anmeldung per OAuth, und speichert je Postfach ein verschlüsseltes Token oder App-Passwort, um die nächste Anfrage stellen zu können[10]. Das App-Passwort liegt dann nicht auf deinem Rechner, sondern auf den Servern des Dienstes.
Prüfe bei jedem gehosteten Dienst deshalb drei Dinge: welchen Zugang er zu deinem Postfach speichert, ob er Mails dauerhaft ablegt und ob sich Senden getrennt vom Lesen abschalten lässt. Eine Übersicht mit Kriterien steht im Vergleich E-Mail-MCP-Server.
06Welcher Weg wann passt
Die Entscheidung hängt weniger an „lokal oder gehostet“ als daran, wo deine Mails liegen und wem du das Passwort anvertrauen willst.
- Ein Postfach bei einem Anbieter, der IMAP mit Passwort erlaubt, und alles soll lokal bleiben: ein lokaler passwortbasierter IMAP-MCP wie mcp-email-server, mit Rechteklassen und Empfängerliste eng eingestellt[2][3].
- Gmail oder Microsoft 365, und der Agent soll im Originalpostfach arbeiten: ein Server mit OAuth-Anmeldung beim Anbieter, über dessen Schnittstelle oder IMAP mit OAuth, lokal oder gehostet. Die Optionen für Gmail beschreibt unsere Anleitung zu MCP-Servern für Google-Postfächer[6].
- Kein Passwort aus der Hand geben und mehrere Adressen verschiedener Anbieter in einem Postfach: ein Agenten-Postfach, das Kopien per Weiterleitung bekommt.
07Wie Command Mail das löst
Command Mail ist unser Produkt und ein gehosteter MCP-Server, der sich überhaupt nicht an deinem Ursprungspostfach anmeldet. Deine Adressen leiten Kopien an Command Mail weiter, deshalb braucht Command Mail weder Postfach-Passwort noch App-Passwort[11]. Weiterleitung ist keine Synchronisation: Was der Agent sortiert oder archiviert, ändert sich nur in Command Mail, nicht im Originalpostfach.
Dein Agent verbindet sich über Streamable HTTP mit OAuth 2.1, PKCE und dynamischer Client-Registrierung[11]. Das Zugriffstoken gilt eine Stunde, das Aktualisierungstoken 30 Tage, und beide lassen sich widerrufen. Über OAuth gibt es die Rechte mail:read, mail:draft, mail:send-approved, mail:send und mailboxes; auf der Freigabeseite kannst du jedes angefragte Recht abwählen, und mail:send für Senden ohne Freigabe ist dort zu Beginn ausgeschaltet[11] (App-Code, Commit d6ad1ce). Senden ohne Freigabe ist zusätzlich an die Autonomiestufe auto des Absenderpostfachs, einen Sendeschlüssel je Mail und ein Tageslimit gebunden[11][12].
Die Grenzen gehören dazu. Kopien deiner Mails liegen bei einem weiteren Anbieter, der FYN Labs LLC in den USA, mit App und Datenbank bei Cloudflare; Anhänge liegen in Cloudflares EU-Jurisdiktion[14]. Leserechte gelten für alle Postfächer eines Kontos, und mail:read erlaubt je nach Autonomiestufe auch Sortieren. Free sendet nicht. Eine weitergeleitete Gmail-Adresse wird dadurch nicht sendefähig, Absenderadressen richtest du einzeln ein[11][12].
Du kannst kostenlos starten und deinen Agenten zunächst ohne Senderecht verbinden; soll er nur lesen, stellst du die Postfächer zusätzlich auf die Autonomiestufe read.
08Prüfstand
Stand: 2026-10-21. Projektdokumente von mcp-email-server, Google-, Microsoft- und MCP-Seiten sowie die Seite von MCP Emails wurden an diesem Tag abgerufen[1][10]. Die Aussagen über Command Mail wurden gegen den App-Code im Commit d6ad1ce geprüft (oauth.ts, oauth-scopes.ts, Freigabeseite unter src/routes/oauth/authorize, outbox.ts). Wir haben keinen der genannten Server selbst installiert oder mit einem echten Postfach getestet.
Häufige Fragen
Ist ein IMAP-MCP-Server mit Passwort unsicher?
Nicht automatisch. Ein lokaler Server wie mcp-email-server hält das Passwort auf deinem Rechner und kann Schreibaktionen und Empfänger begrenzen. Das Risiko liegt darin, dass ein Postfach-Passwort oder App-Passwort meist das ganze Postfach öffnet und nicht nach Aufgaben unterscheidet.
Funktioniert IMAP mit Passwort noch bei Gmail und Outlook?
Bei Gmail nur noch mit App-Passwort, das die Bestätigung in zwei Schritten voraussetzt; Google rät selbst davon ab. Bei Outlook.com und Microsoft 365 ist die Anmeldung per Benutzername und Passwort abgeschaltet, dort braucht ein Programm OAuth.
Heißt gehostet automatisch, dass kein Passwort im Spiel ist?
Nein. Gehostet beschreibt, wo der Server läuft. Wie sich dein Agent anmeldet und wie der Dienst auf dein Postfach zugreift, sind davon getrennte Fragen. Manche gehosteten Dienste speichern für IMAP-Postfächer weiterhin ein App-Passwort, nur eben auf ihren eigenen Servern.
Was hält mein Agent bei einem gehosteten MCP mit OAuth in der Hand?
Ein Zugriffstoken für den MCP-Server, mit den Rechten, die du beim Verbinden erteilt hast. Bei Command Mail läuft dieses Token nach einer Stunde ab, wird über ein Aktualisierungstoken erneuert und lässt sich widerrufen; ein Postfach-Passwort sieht der Agent nicht.
Brauche ich für ein Postfach bei einem kleinen Anbieter einen IMAP-MCP?
Wenn der Agent direkt im Originalpostfach arbeiten soll und der Anbieter keine andere passende Schnittstelle bietet, oft ja, oder einen gehosteten Dienst, der IMAP für dich spricht. Command Mail geht einen anderen Weg und bekommt Kopien per Weiterleitung, sodass gar kein Postfach-Passwort nötig ist.
Quellen
- mcp-email-server: README
- mcp-email-server: Configuration
- mcp-email-server: MCP tools and mutation permissions
- mcp-email-server: Transports
- Google: Mit App-Passwörtern anmelden
- Google Workspace: Transition from less secure apps to OAuth
- Microsoft Learn: Deprecation of Basic authentication in Exchange Online
- Microsoft: Modern authentication now needed for Outlook.com in non-Microsoft email apps
- Model Context Protocol: Authorization (2025-06-18)
- MCP Emails: Hosted email MCP server
- Command Mail: plans, connection and permissions
- Command Mail: Berechtigungen und Autonomie
- mcp-email-server: Security
- Command Mail: Privacy policy
- GitHub API: mcp-email-server (license BSD-3-Clause)