Outlook Add-in Mailbox 1.16: Şifreli Mesajlar ve EWS Kararı
Outlook tarafında bir süredir COM/VSTO ile web add-in’ler arasındaki uçurum sessiz sessiz kapanıyordu. Mailbox 1.16 GA olunca açıkçası “ha, nihayet” dedim (buna dikkat edin). Bu ne anlama geliyor? Çünkü o “web add-in’ler hâlâ olmuyor” diyen meslektaşlarımın en sağlam dayanağı şifreli posta tarafıydı, hani orada gerçekten eli boş kalıyorduk; şimdi o argüman baya zayıfladı.
Bu yazıda Mailbox requirement set 1.16 ile gelen yenilikleri sadece “şunlar geldi” diye geçmeyeceğim. Sahada bunun ne anlama geldiğini, Türkiye’deki kurumsal yapılarda nasıl karşılık bulduğunu. Özellikle DLP (data loss prevention) projelerinde işimizi nasıl değiştireceğini konuşacağım. Mesele sadece API değil; mesele, eski VSTO eklentileri yavaş yavaş kenara çekilirken bizim nereye yaslanacağımız.
Peki neden?
Önce büyük resim: Neden bu sürüm önemli?
Microsoft Outlook tarafında uzun zamandır “yeni eklentilerinizi web tabanlı yazın” diyor. Güzel laf, tamam. Ama iş gerçek hayata gelince, COM/VSTO ile yaptığınız birçok şeyi web add-in tarafında yapamıyordunuz; şifreli mesajlara müdahale edemiyor, geniş alıcı listelerini rahatça değerlendiremiyor, oturum içinde state tutarken de sürekli duvara tosluyordunuz.
Mailbox 1.16 bu yarım kalmışlığı kapatma yönünde atılmış ciddi bir adım. Açık konuşayım: Tam kapanmadı, hâlâ eksik yerler var. Ama OnMessageDecrypt, EWS token diagnostic API’si. Genişletilmiş alıcı/SessionData limitleri bir araya gelince, kurumsal müşteriye “artık VSTO’dan çıkabiliriz galiba” deme noktasına geldik; yanı küçük bir rahatlama değil bu, baya köprü kuruluyor.
Ve işler burada ilginçleşiyor.
Bence bu sürümün en hayatı tarafı OnMessageDecrypt. Çünkü Türkiye’deki finans ve kamu yapılarında “şifreli posta zorunluluğu” hâlâ COM eklentilerini ayakta tutan başlıca sebep.
OnMessageDecrypt: Event-based şifre çözme nihayet geldi
Vallahi, Olayın tam merkezinde OnMessageDecrypt var. Kullanıcı şifreli bir mesaj açtığında Outlook bu eventi tetikliyor; eklentiniz mesajı tanıyor, çözme işini yapıyor, içeriği gösteriyor ya da hata varsa kullanıcıya söylüyor. Sizden beklenen şey işe protokol tarafı — yanı kurumsal güvenlik politikanız neyse onun mantığını kodlamak.
Bu önemli çünkü daha önce şifreli mesaj senaryolarında ya AIP / Microsoft Purview MIP üstünden çözüm üretmeye çalışıyordunuz ya da VSTO ile dirsek çürütüyordunuz, başka yol yok gibiydi zaten. Şimdi kendi PKI altyapınızla, kendi HSM’inizle ya da kendi key vault’unuzla entegre web add-in yazabiliyorsunuz; üstelik macOS’ta, Windows’ta ve Outlook on the web’de aynı kodla çalışıyor.
Çok konuştum, örnekle göstereyim.
Tipik bir senaryo nasıl görünür?
Diyelim ki bir holding bünyesinde yurt dışı şube ile yapılan yazışmaların tamamı kuruma özel bir anahtarla şifreleniyor. Eskiden bunu VSTO eklentisiyle hallederken kullanıcının makinesindeki sertifika store’una müdahale eden kuyruklarla boğuşuyordunuz; şimdi manifest’e şu satırları eklemeniz yetiyor: Copilot Code Review Azure Repos’a Geldi: Sahadan İlk İzlenimler yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Agent Framework ile Kendi Claw’unu Kurmak: Saha Notları yazımıza da göz atmanızı tavsiye ederim.
{
"extensions": [
{
"requirements": {
"scopes": ["mail"],
"capabilities": [
{ "name": "Mailbox", "minVersion": "1.16" }
]
},
"autoRunEvents": [
{
"events": [
{
"type": "messageReadingComposeOnSendOrDecrypt",
"actionId": "onMessageDecryptHandler"
}
]
}
]
}
]
}Küçük bir detay: Sonra handler tarafında item içeriğine ulaşıyorsunuz, kurumsal key servisinizle konuşuyorsunuz ve çözülmüş içeriği geri yazıyorsunuz. Bitti gibi dürüyor ama aslında asıl iş burada başlıyor; Outlook gerisini toparlıyor.
EWS token bitti mi? Bitmedi mi? Artık sorabiliyoruz
Açık konuşayım, Şimdi gelelim benim için sessiz kahraman sayılabilecek API’ye: Office.context.mailbox.diagnostics.ews.getTokenStatusAsync. Kubernetes AI Politikası: Açık Kaynak Sürdürücülüğü Yeni Çağda yazımızda bu konuya da değinmiştik.
Microsoft Exchange Online tarafında EWS callback token’larını kapattı. Türkiye’de hâlâ on-prem Exchange ile çalışan baya kurum var; sağlık sektörü var, kamu var, bazı holding yapıları var… Yanı bulutta veri tutmayız politikası olan herkesin elinde on-prem halen canlı dürüyor. Kısacası EWS ölmedi demek biraz kolaycılık olurdu; defin işlemi uzadı diyelim. Cosmos DB Rolleri: Uygulamam İçin Hangisi Doğru Seçim? yazımızda bu konuya da değinmiştik.
Bu API sayesinde artık eklentiniz çalıştığı ortamda EWS token’larının desteklenip desteklenmediğini sorabiliyor. Sonuca göre iki farklı kimlik doğrulama akışı kurabiliyorsunuz: Graph + Nested App Authentication mı kullanacaksınız yoksa eski güzel EWS mi? Kod aynı kalıyor; davranış ortama göre şekilleniyor.
Türkiye perspektifi: Hibrit gerçek, bulut hayal
Sahada sık gördüğüm şey şu: Birçok kurum kâğıt üstünde Microsoft 365’e geçmiş gibi görünüyor ama mailbox’ların önemli kısmı hâlâ on-prem’de dürüyor. Hibrit yapı uzun süre daha yaşayacak gibi dürüyor; hatta dürüst olayım, beklediğimizden uzun yaşayabilir de. Bu API’nın getirdiği esneklik ISV ekipleri için aslında bir geçiş köprüsü anlamına geliyor.
Şöyle ki, Neyse uzatmayayım; burada asıl mesele şu: yarın herkes buluta geçer diye düşünüp sadece online’a yazarsanız şaşırırsınız. Öyle rahat yok henüz.
DLP ve içerik işleme tarafındaki üç güzel haber
Şahsen, Mailbox 1.16’nın sessiz ama etkili tarafı mevcut API’lere gelen iyileştirmeler öldü desem yanlış olmazdı galiba. Üç tane öne çıkan konu var ve üçünün de DLP / CCM (content compliance management) yapan ekiplerin yıllardır beklediği türden şeyler olduğunu söylemek mümkün. Bu konuyla ilgili Claude Opus 4.8 Fast Mode Copilot’ta: Hız mı, Cüzdan mı? yazımıza da göz atmanızı tavsiye ederim.
1. contentId: Inline ekleri ayırt etmek
Şöyle söyleyeyim, Peki neden önemli? Bir mailde 10 tane resim varsa bunların kaçı gerçek ek, kaçı imza içindeki logo, kaçı body içinde gömülü inline resim? Eskiden bunu anlamak için MIME kazmanız gerekiyordu. Açıkçası çok keyifli değildi.
Sahneye artık attachment objesindeki contentId property’si çıkıyor.
DLP eklentiniz örneğin dışarıya giden 20 MB’lık Excel’i yakalamaya çalışırken imza logosunu yanlışlıkla ek saymıyor.
False positive azalınca kullanıcı da mızmızlanmayı bırakıyor.
Yöneticiler de sistemin işe yaradığını düşünmeye başlıyor.
Baya fark ediyor yanı.
Böylesine basit görünen şey neden dertti?
Bir şey dikkatimi çekti: DLP projelerinde bazen sorun teknoloji değil algıdır. Kullanıcıya üç kez yanlış alarm verirseniz sistemin kalan kısmını kimse dinlemez. İşte contentId tam burada rahatlatıyor;
bir anda her şeyi çözmüyor. Işi toparlıyor,
özellikle inline görsellerin böl olduğu mail akışlarında,
gereksiz uyarıları ciddi biçimde azaltabiliyor. Hmm,
küçük detay gibi dürüyor ama etkisi büyük olabiliyor.
Kaldığımız yerden devam edelim mi?
Aşağı yukarı böyle bir fayda sağlar:
- Daha temiz sınıflandırma:
- Daha az false positive:
- Daha az kullanıcı itirazı: (bu kritik)
- Daha az gereksiz operasyon:
Kısacası?
Sıkça Sorulan Sorular
Mailbox requirement set 1.16 hangi Outlook sürümlerinde çalışıyor?
Microsoft 365 abonelikli güncel Outlook on Windows, Outlook on Maç, yeni Outlook for Windows ve Outlook on the web’de destekleniyor. Mobile tarafında kapsam genişliyor aslında, ama henüz — itiraz edebilirsiniz tabi — tam parite yok. Bence production’a almadan önce hedef kullanıcılarınızın Outlook build numaralarını mutlaka kontrol edin, sonradan baş ağrısı olmasın.
VSTO eklentilerimi hemen Mailbox 1.16 web add-in’e taşımalı mıyım?
Hemen değil. Ama 2026 boyunca planlamaya başlamak mantıklı olur. Mesela şifreli posta çözen eklentileri önceliklendirin, yanı 1.16 tam da bu konudaki en büyük açığı kapatıyor. UI’sı karmaşık olan ya da başka uygulamalarla COM köprüsü kuran eklentileri işe dikkatli analiz edin, açıkçası bu kısmı aceleye getirmeyin.
OnMessageDecrypt eventi sadece S/MIME için mi çalışıyor?
Bi saniye — Hayır. Aslında event-based akış, sizin tanımlayacağınız şifreleme protokolüne göre işliyor. S/MIME, PGP veya kurumsal özel bir şema kullanabilirsiniz, hani seçenek oldukça geniş. Outlook size sadece “bu mesaj şifreli” sinyalini. Içeriğe erişim olanağı sağlıyor; protokol mantığını sız yazıyorsunuz.
EWS token diagnostic API’si Exchange Online’da neden gerekli?
Exchange Online’da EWS callback token’ları artık verilmiyor, dolayısıyla API size “desteklenmiyor” döner. Ve sonuç: eklentiniz, yanı alternatif kimlik doğrulama akışına (Nested App Auth, Graph) geçmesi gerektiğini anlıyor. Hibrit ortamlarda işe EWS hâlâ kullanılabilir mi değil mi, bunu deterministik şekilde öğrenebilirsiniz. Tecrübeme göre bu ayrımı erken yapmak çok iş kurtarıyor.
SessionData limitinin artması neye yarar?
Oturum boyunca eklentiniz içinde veri taşımak istediğinizde işe yarar. Mesela kullanıcı bir maile birden çok ek ekledikçe, DLP eklentinizin her ek için ayrı ayrı HTTP çağrısı yapması yerine oturum içinde önbellekleme yapabilirsiniz. Hem kullanıcı deneyimi iyileşiyor hem de backend maliyeti düşüyor, bence en pratik yeniliklerden biri bu.
Kaynaklar ve İleri Okuma
Microsoft 365 Developer Blog: Mailbox requirement set 1.16 duyurusu (inanın bana)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments