Birçok iş bilgisi e-postada bulunur ve ihtiyacınız olan kısım genellikle bir ekte yer alır: teklif, imzalı değişiklik, revize edilmiş takvim. GroupDocs.Search.Mcp, Docker’da yerel olarak çalıştırıldığında e-posta dosyalarını ve arşivleri (PST, OST, MSG, EML) açar ve her mesajı ve her eki indeksler; böylece Claude Desktop, Cursor veya Copilot, arşivi yerinde arayabilir ve eşleşmenin hangi ekten geldiğini tam olarak söyleyebilir:

Posta klasörünü indeksle. Hangi mesaj fiyat artışından bahsediyor ve tam olarak ne diyor?

Yapılandırma ve sorun giderme adımlarıyla birlikte adım‑adım sürüm belgelerde bulunabilir: How to search email archives and attachments with an AI agent, locally.

E-posta bir ajan için neden zordur?

Çünkü bir arşiv, konteynerlerin konteyneridir. Bir PST klasörleri tutar, klasörler mesajları, mesajlar ekleri ve ekler de kendi başına Word dosyaları, PDF’ler ve elektronik tablolar olur. Dosya araçlarına sahip bir ajan tek büyük bir ikili dosya görür. Arşivi önce gevşek dosyalara dışa aktarmak çalışır, ancak yavaştır, hassas verileri diske kopyalar ve arşiv değiştiğinde yeniden yapılması gerekir. Ayrıca bir model PST’yi hiç okuyamaz.

Arama motoru iç içeliği kendisi yönetir. Her mesaj ve her ek aranabilir bir öğe haline gelir ve bir sonuç, konteynerin nerede olduğunu ve eşleşmenin içinde nerede bulunduğunu kaydeder.

Bir ek içinde bir eşleşme nasıl görünür?

Aşağıda üç EML mesajı ile yaptığımız testte sunucunun döndürdüğü sonuç yer alıyor. “price increase” ifadesi yalnızca onlardan birine ekli Word teklifinde bulunur; mesaj gövdesi sadece “please find the updated quotation attached” der.

-> add_to_index {"documentsPath":"mail","indexName":"mail"}
<- Indexed 'mail' into index 'mail': 3 document(s) added, 3 in the index.

-> search {"query":"\"price increase\"","indexName":"mail"}
<- { "documentsFound": 1, "documents": [
     { "filePath": "mail/2026-09-18-re-q3-pricing.eml",
       "innerPath": "quotation-Q-2026-118.docx",
       "occurrences": 1 } ] }

-> get_text_fragments {"query":"\"price increase\"","indexName":"mail"}
<- === mail/2026-09-18-re-q3-pricing.eml → quotation-Q-2026-118.docx
   (1 occurrence(s)) ===
     …Due to raw material costs we announce a price increase
   of 6 percent from 2026-11-01.…

filePath mesajdır; innerPath ekidir. Ajan şu şekilde yanıt verebilir: “Contoso’dan Re: Q3 pricing mesajı, ekli quotation Q-2026-118: 1 Kasım’dan itibaren %6 artış”, ve bu cümlenin her bölümü izlenebilir.

mail/2026-09-18-re-q3-pricing.eml          <- filePath
  |- body: "please find the updated quotation attached"
  '- attachment: quotation-Q-2026-118.docx  <- innerPath
        "...we announce a price increase of 6 percent..."

Posta üzerinde çalışan sorular

Alışılmış sorgu dili geçerlidir ve bazı kalıplar yazışmalar için özellikle faydalıdır. Tüm bunlar aynı test posta kutusuna karşı kontrol edilmiştir:

  • “Fabrikam’dan gelen hangi mesaj teslimat gecikmesinden bahsediyor?”: fabrikam AND delay. Gönderici adresleri mesajla birlikte indekslenir, bu yüzden contoso da şirketi hiç adlandırmayan bir faturayı buldu.
  • “Sipariş 77812’den bahseden tüm e‑postaları bulun”: 77812. Tam sayılar kelimedir.
  • “Ekim ayında vadesi gelen faturalar hangileri?”: invoice AND content: daterange(2026-10-01 ~~ 2026-10-31). Bu, mesaj metninde yazılmış tarihleri eşleştirir; örneğin “due on 2026-10-22”. content: öneki önemlidir: olmadan bir tarih aralığı, motorun her dosya için kaydettiği tarihleri de eşleştirir.

Neden yerel, posta için diğer her şeyden daha fazla önemlidir

E‑posta, hassas materyalin bulunduğu yerdir: kişisel veriler, müzakereler, İK konuları, hukuki tavsiyeler. Posta kutusunun bir hizmete yüklenmesini veya senkronize edilmesini gerektiren arama araçları birçok ekip için işe yaramaz. Burada arşiv, makinedeki bir konteynere salt‑okunur olarak bağlanır, orada indekslenir ve orada aranır. Çıkan tek metin, ajanın yanıtına eklediği alıntıdır ve yerel olarak barındırılan bir modelle, hatta o bile çıkmaz.

Daha sıkı bir kurulum için, arşivi salt‑okunur bağlayın ve indekse kendi hacmini verin:

docker run --rm -i \
  -v /srv/mail:/data:ro \
  -v /srv/mail-index:/index -e GROUPDOCS_MCP_INDEX_PATH=/index \
  ghcr.io/groupdocs-search/search-net-mcp:latest

Büyük bir arşivi kapsamlandırma

On binlerce mesaj içeren bir arşiv, lisansla sorunsuz indekslenir, ancak bilinçli olmak faydalıdır. Klasöre ya da yıla göre ayrı yollar (mail/2025, mail/2026) olarak indeksleyin; böylece bir yıl tek başına kaldırılabilir veya yeniden oluşturulabilir, çünkü motor tek dosyalar yerine bütün indekslenmiş yolları siler. Postayı, sözleşmelerden veya raporlardan ayrı bir indekste tutun; böylece bir yazışma sorusu diğer her şeyi karıştırmaz. Arşiv büyüdükçe, update_index eski mesajları yeniden okumadan yeni mesajları yakalar.

Dürüst sınırlamalar

  • Değerlendirme modunda bir indeks en fazla 100 belge tutar ve bir arama en fazla 10 sonuç döndürür, her mesaj ve ek sayılır, bu yüzden gerçek bir arşiv lisans gerektirir. Önce get_license_status çağırın.
  • Büyük bir PST’nin indekslenmesi zaman alır: her mesaj ve ek açılır. Bir kez indeksleyin, ardından update_index kullanın.
  • Metin katmanı olmayan taranmış ekler yalnızca dosya özellikleriyle indekslenir; OCR yoktur.
  • Sadece Docker; Linux’ta --user "$(id -u):$(id -g)" ekleyin, aksi takdirde yukarıdaki salt‑okunur kurulum kullanılmalıdır.

SSS

Bir PST dosyasını Outlook olmadan AI ile arayabilir miyim?
Evet. Motor PST, OST, MSG ve EML dosyalarını doğrudan okur; Outlook devreye girmez ve hiçbir şey dışa aktarılmaz.

E‑posta ekleri içinde arama yapar mı?
Evet. Ekler, mesajlarının öğeleri olarak indekslenir ve bir ek içinde bulunan eşleşme, ekin adını belirten innerPath ile geri döner.

Posta kutum herhangi bir yere yükleniyor mu?
Hayır. Yerel bir konteyner içinde okunur; yalnızca ajanın alıntıladığı pasajlar model sağlayıcınıza ulaşır.

Daha derine inin