JMAP Nedir? IMAP'in Yerini Almaya Aday Modern Mail Protokolü

Mail kutunuzu açtığınızda telefonunuz neden bazen 8-10 saniye "Senkronize ediliyor..." der? Cevap büyük ölçüde tek bir kelimede: IMAP. JMAP, IMAP'in 40 yıllık mirasının yerini almaya gelen modern bir alternatif.

IMAP 1986'da tasarlandı. O zamanlar "internet" denen şey üniversite kampüsleri arasındaki dial-up bağlantılardı, mobil cihaz diye bir kavram yoktu, JSON daha icat edilmemişti. IMAP hâlâ bu mirası taşıyor ve modern mail istemcilerinin altında garip bir gerilim yaratıyor. JMAP — JSON Meta Application Protocol — tam bu boşluğu doldurmak için RFC 8620 ve RFC 8621 olarak yayınlandı.

Bu yazıda IMAP'in neden eskidiğini, JMAP'in pratikte ne getirdiğini ve hangi durumda hangisini seçmeniz gerektiğini anlatıyorum.

IMAP'in 1986 mirası

IMAP4 (RFC 3501) hâlâ aktif. Çalışıyor, evet. Ama "çalışıyor" ile "iyi" arasında fark var.

IMAP'in temel sorunları:

  • Chatty protocol. Tek bir "yeni mailleri kontrol et" işlemi için onlarca round-trip gerekebilir. Mobil bağlantıda her round-trip 100-300 ms ekler.
  • Push yok. IMAP IDLE komutu push'a en yakın çözüm ama her hesap için açık TCP bağlantısı tutmak zorundasınız. 5 hesaplı bir telefonda 5 ayrı IDLE bağlantısı = sürekli açık radyo = pil katliamı.
  • Batch operations zor. 200 maili "okundu" işaretlemek için 200 ayrı STORE komutu. JMAP'te bu tek bir request.
  • State sync yok. IMAP istemcisi sunucudaki değişiklikleri "biliyor" mu? Hayır. Her seferinde polling yapması gerekir.
  • Stateful bağlantı. Bağlantı koparsa state kaybolur. Yeniden SELECT INBOX ve yeniden senkron.
  • Search sunucu tarafında zayıf. Tam metin arama IMAP'in standart parçası değil; her sunucu kendi extension'ını koyuyor.

Bu sorunların hepsi 1986'da problem değildi. Bugün, mailinizin %80'i mobil cihazda açıldığı bir dünyada, hepsi problem.

JMAP — JSON Meta Application Protocol

JMAP, Fastmail mühendisleri tarafından geliştirildi ve IETF tarafından standartlaştırıldı:

  • RFC 8620 — JMAP Core (transport, auth, batch, push)
  • RFC 8621 — JMAP Mail (mail-specific data model)

Temel fikir basit: JSON over HTTPS, REST-benzeri, tek round-trip multi-method.

JMAP bir mail protokolü değil aslında — bir veri senkronizasyon protokolü. Mail onun ilk uygulaması. Calendar (JSCalendar), Contacts gibi uzantılar da var.

JMAP'in IMAP'e göre yapısal farkları:

  • Tek endpoint. https://api.example.com/jmap — hepsi bu.
  • Method-based. Mailbox/get, Email/query, Email/set — REST-vari isimlendirme.
  • State token'ları. İstemci sunucuya "ben X state'indeyim" der; sunucu sadece o noktadan sonraki değişiklikleri döner. Polling yerine delta sync.
  • Push standart. WebSocket veya server-sent events ile gerçek push, IDLE hack'i değil.
  • Batch native. Tek HTTP request'te birden fazla method, hatta önceki method'un sonucunu sonrakine referans verebilirsiniz (#prevResult syntax'ı).

Pratik farklar — tablo

BoyutIMAPJMAP
Yıl1986 (rev. 2003)2019
FormatBinary-ish, line-basedJSON
TransportTCP, statefulHTTPS, stateless
Mobil pilYüksek tüketim (IDLE)Düşük (push subscription)
Round-trip ortalaması5-151-2
Batch operationsTek tekNative batch
Delta syncYok (polling)State token'larıyla native
SearchSunucuya bağlıSpec'te standart
Attachment handlingRFC 822 MIME parsingBlob upload/download endpoint
AuthSASL, çoğunlukla passwordOAuth2 öncelikli
İstemci karmaşıklığıYüksek (state management)Düşük (REST + state token)
Tek cümlelik özet IMAP istemciyi sunucu state'ini taklit etmek zorunda bırakır; JMAP sunucuyu single source of truth yapar.

Hangi mail engine'ler JMAP destekliyor?

Public bilgi olarak şu sunucularda JMAP desteği var:

  • Stalwart Mail Server — JMAP-first tasarlanmış, IMAP'i de destekliyor
  • Cyrus IMAP (Fastmail'in fork'u) — production JMAP
  • Apache James — JMAP support
  • Topicbox / Fastmail — JMAP'in doğum yeri, ticari mail servisi

İstemci tarafında destek hâlâ az. Thunderbird'de deneysel, mobil tarafta çoğunlukla Fastmail'in kendi uygulamaları. Apple Mail ve Outlook hâlâ IMAP/Exchange yolundalar. Ekosistem büyüme aşamasında.

Geliştirici perspektifi

IMAP'le çalışmış biri için JMAP nefes açıcı. Karşılaştıralım — "Inbox'taki ilk 10 maili getir" işlemi.

IMAP (pseudo)

A001 LOGIN user pass
A002 SELECT INBOX
A003 FETCH 1:10 (UID FLAGS ENVELOPE BODYSTRUCTURE)

Her satır ayrı round-trip. Response binary-ish, parser yazmak zorundasınız. State sunucuda.

JMAP

POST /jmap HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{
  "using": ["urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail"],
  "methodCalls": [
    ["Email/query", {
      "accountId": "u1",
      "filter": { "inMailbox": "inbox-id" },
      "sort": [{ "property": "receivedAt", "isAscending": false }],
      "limit": 10
    }, "q1"],
    ["Email/get", {
      "accountId": "u1",
      "#ids": { "resultOf": "q1", "name": "Email/query", "path": "/ids" },
      "properties": ["subject", "from", "receivedAt", "preview"]
    }, "g1"]
  ]
}

Tek HTTP request. #ids ile ilk method'un sonucunu ikinciye besledim. Response saf JSON. Auth Bearer token. State'i sunucu tutuyor.

Yazılım mühendisi açısından bu sadece sözdizimi farkı değil — debugging, tooling, library ekosistemi tamamen farklı. JMAP request'ini cURL'le test edebilirsiniz. IMAP'i openssl s_client'la sürünerek test edersiniz.

Ne zaman JMAP, ne zaman IMAP?

JMAP seçin, eğer:

  • Yeni bir mail istemcisi / SaaS yazıyorsanız ve sunucu tarafını kontrol ediyorsanız
  • Mobil-first bir ürün hedefliyorsanız (pil ve latency kritikse)
  • Mevcut mail sunucunuz Stalwart, Cyrus veya James gibi JMAP-native bir engine
  • OAuth2 + modern auth flow'una geçmek istiyorsanız
  • Üçüncü parti uygulamaların hesabınızla kolay konuşmasını istiyorsanız (REST API gibi)

IMAP'te kalın, eğer:

  • Mevcut istemcileriniz (Outlook, Apple Mail, Thunderbird stable) JMAP konuşmuyorsa — ki çoğu konuşmuyor
  • Sunucu tarafınız klasik (Postfix + Dovecot, eski Exchange) ve değiştirme planınız yok
  • Kullanıcılarınız "mail kutum hep aynı kalsın" diyen son kullanıcı segmentinde
  • Compliance / audit gereksinimleri IMAP'in olgun ekosistemine bağlı

Hybrid pratiktir

Stalwart gibi modern sunucular hem IMAP hem JMAP konuşur. Sunucuyu JMAP-capable bir engine'e taşırsanız eski istemciler IMAP'le devam eder, yeni istemcileriniz JMAP'in nimetlerinden yararlanır. Geçiş için iyi bir köprü.

Sonuç

IMAP ölmedi, ölmeyecek de — en azından 10 yıl daha. Ama altyapı kararı bugünden veriliyorsa ve mobil önemliyse, JMAP-capable bir sunucu seçmek geleceğe yatırım. Protokol seviyesinde 30 yıllık teknik borcu temizliyor.

Türkçe kaynak hâlâ kıt. Eğer JMAP'le pratik deneyim biriktirip yazarsanız, niş'in tepesinde tek başınıza oturuyorsunuz.

Hanbisan Mühendislik Notları · 17 Mayıs 2026 ← Tüm yazılar

İletişim